Project Processes Part II – Choosing the right process for your project
I’ve seen too many examples of good process initiatives that went wrong because there just wasn’t a an effort to match the process with a project. Below are examples of process intiatives that went wrong -
1) Organization-wide processes that only work for certain project types. Would you use the same hammer or spanner for different DIY projects ? Probably not. It’s a good idea to publish best practices for different types of projects, so you can adapt your process to your project.
2) Overly cumbersome process elements that make the process a burden on the project team. Heck I’ve seen even well-meaning project managers short-circuit such processes to keep their projects on track. Lightweight processes make for systematic application because the process actually helps the project without weighing it down.
3) Defining rigid processes that have been imposed upon project teams. This makes the team feel like the process is more important than people. Take the time to understand the personalities involved, and the kinds of challenges you might have by trying to apply a cookie-cutter process to varying work styles.
Common sense you say ? Too true. However, time and again project leaders make the same mistakes and then wonder why ‘the perfect process’ didn’t work.
Work out various process best practices and put them up on a board at a visible location such as the office kitchen or near the water cooler. Put the process up on a WIKI page.. anything to encourage a healthy discussion of all the improvements you’re trying to make. Encourage feedback and iterate through improvements so people know they are being heard. Change is inevitable and its best not to fight it.
Some projects can follow waterfall approaches, and some require Agile (or Agile-like) iterations. But more and more, I am starting to see hybrid processes in play, particularly, when a project requires a rich feature set to be delivered to a customer, and collaboration is key in getting the requirements nailed down.
For one such project instance, the project team had the requirements and architecture work happen with waterfall processes all the way up to design signoff with the customer. Implementation was however planned into Agile integration cycles, each iteration starting with detailed design leading up ultimately to QA and integration. When all the implementation was complete, we then switched to waterfall again to stage, document and deliver the release.
One size does not fit all ! Be creative, collaborative, and keep your processes simple and nimble. As mentioned in part I of this series, ensure your project team is vested in the process you pick and your executive team is willing to support it. Regardless of the process you pick, it is important to keep good communication, perhaps just vary the frequency of that communication based on your processes. I’d love to hear examples, comments, suggestions, etc. from you all.
