What is “Project Execution”?
What is the fastest path to completing a project without sacrificing quality or security?
Be it on a large scale with teams of developers and meeting rooms filled with stakeholders or a single customer and a couple dedicated creators, Project Execution is about leveraging a team that is more than just resources to produce a viable product on time. It’s about gauging productivity on performance finding the most direct and, dare I say “lean” method for getting things done.
Project management is an individual’s skill but Project Execution is a team skill that requires a team builder!
I can’t claim that I am a guru at it but I am constantly trying to learn and refine my skills in this area.
What style of Project Management do you use?
It depends on what is needed.
Traditionally I was brought up on a waterfall method which is to get all the scope and specifications for a project, create a long planning phase to iron out the details, start the design process with approvals, pass it to your HTML architects who then kick it over to your programmers. And after it’s all done you release and watch. It’s the same game with Agile development but in shorter iterative cycles.
Again, this is pretty common but I have found that it is rife with issues like scope creep, or changes to the overall project that require going back to the drawing board for a number of features which in the end is more like spin-cycle development. There are ways to “manage” this but it is hard when the stake holders have to wait for 6 months before the product is released and have 6 months to really think about how it should be better before it gets out of the gate.
I have recently become a big fan of “The Lean Startup” methods written by Eric Ries. And I am not going to deep dive into all the ideas the book covers, nor is this a subversive advertisement of the book (But it could be! Eric, Call me!) however I agree with the idea of producing a minimal viable product (MVP) which is the very least a product can be to get early adopters interested, and then quickly start adding features and using A/B testing to validate whether the feature is going to be used, will increase a sites qualitative or quantitative values or potentially make it worse. But most of all it’s about using the user’s behaviors to determine the next step: not how they should use the site but how they actually use the site.
I am sold on the idea and practice that iterations of the “Build, Measure, Learn” process followed by clear execution and measuring reduces wasteful development, directly validates ideas with a clear ROI and produces a site that is verifiably what the end user wants.
So I can accommodate any method desired but I do have some preferences.
How can a programmer / website design guy be a Project Manager?
I have had to wear many hats. Early on in my career I ventured forth to create a two-man team which didn’t get me rich but paid the bills and taught me how to gather project specifications and learn how to work with a customer who is not always clear about what they want or the technology they want to do it with. I also learned how to work with a partner who I only knew online and collaborated via phone, messenger or video. This was a rough road and looking back I developed ideas in project management that made sense at the time and were similar to some common models.
Jump ahead 5 years, some of my jobs required flying out to meet with clients to take specifications, come up with an executable plan and fulfill it on time with no room for delay. Some of these projects taught how to break it to a customer that the “must have” feature of the hour was either going to push the release date back or have to wait for an update past the initial launch. On occasion I had to find a tactful way to say “sorry but this is taking longer than expected”. You hope to never have to say that but it is a humbling and valuable life experience and it teaches you about your limits.
A number of projects and jobs have required the management of development resources: other developers. At first it was difficult because I came from being a programmer or designer, you know.. one of the gang! Stepping from the roll of runner to facilitator, block-&-tackle and orchestrator can be a difficult move. What I learned and continue to refine are the skills to clearly communicate expectations, manage based on results, allow skilled experts the freedom to be reasonably creative, and to hold accountable those who don’t meet their own commitments.
Having come from development and programming backgrounds gives me an understanding of the daily grind in each role. I generally know when someone is underestimating a quote on time and I can spot when someone is trying to add unreasonable padding. The balance I seek lies within Project Execution where the orchestrator is inherently a servant of the development team and the execution resembles something like the "A" team instead of a dog sled team.
