Project Processes Part I – The mechanics

The task of managing project processes usually falls upon the project management organization. This, in my opinion, is a good thing. The project leaders have the the ear of the management team, the trust of the project teams, and a unique cross-functional perspective.

I was once asked by the CTO of an engineering organization to help him design the “RIGHT” project process for his engineering team. I was a brand new employee with the company and was surprised he was entrusting me with this lofty task. He said he understood this would take time, but he hoped to see incremental progress. The existing processes weren’t working. The team had failed release after release to deliver what was considered a quality product on time. So, the CTO said to me, “LET’S TRY TO FIX IT !”.

I wondered why he asked me, a mere Project Manager in the grand scheme of things, to turn the tide. Was this some kind of test / joke / tactic to serve some other purpose ? No, it wasn’t ! He told me he made such a choice because he wanted –

• someone with a fresh pair of eyes on the events. Really, someone who hadn’t become a part of the flawed process yet, so is able to step back for a bird’s eye view but dive deep when necessary.
• someone at ground level who doesn’t intimidate the engineering team, and is able to rally people around a common purpose
• someone in a job function where the communication and organization abilities exist to make such a cross-functional initiative possible

What an interesting approach to the problem ! Instead of imposing a process, he wanted his people to work towards it and become vested in it through their project manager/leader. Project leaders often make good process architects because they know the stakeholders, the environment, and the tools available to set the right things in motion. The CTO also said, “Let’s fix it !”, which indicated I wasn’t alone in this endeavor, that I had his support, and that we were on the same team.

Here are a few suggestions on how to define and introduce project process changes (really, just like you might run any project) –

• Take the time to orient yourself. Understand the vision of the executive team and the metrics involved.
• Get to know the engineering team and the current processes. What works and what doesn’t ? Every project team member has a different approach to their task at hand. How do they work, communicate, collaborate, estimate their tasks, etc. Is the team geographically dispersed ?
• Understand the customers and the nature of the releases. Do the contractual obligations to the customer impose rich feature sets and long release cycles ? Or is the engineering team in continuous development mode where a feature is released as soon as it is ready?
• Get to know the product, its major and minor components, its strengths and weaknesses.  How much testing does it need and how elaborate is its deployment procedure ?
• Identify your ‘quick wins’ – the items that will get you the biggest bang for your buck, so you can show incremental progress to all parties. (Thx to a good friend, a successful project leader herself, for suggesting this once upon a time). Process changes are difficult to roll out. You’ll find yourself taking baby steps sometimes, and making giant leaps at other times.
• Involve different people in the definition of different problems and implementation of their solutions. This will ensure people are vested in the process even if they don’t immediately see the big picture.
• Use visual representation. Put up the ‘big picture’ process chart on a board in a central location at the office. Use color post-its or some such to mark the wins separately. This is so people see there is a method to this madness and that their efforts are helping it all come together.

How would you go about introducing process change ? I would love to hear your comments, suggestions, gripes, etc.