I marvel at the complexity of various finely made timepieces. I cringe at the complexity of various projects.
A timepiece is generally valued by the number of “complications” or moving parts that it has. Conversely, a project is punished by the number that it has. Unfortunately the possible surface area for project issues grows exponentially as the number of tasks within a project increases.
Working in technology consulting all of my professional life it might seem that it would be to my benefit to sell and manage a variety of large, complex projects to drive revenue. It can actually be detrimental and somewhat like a race car going too fast in the corners. If a project looses control and never crosses the finish line both the client and I have lost. I am not a management consultant, but clearly understand that is not a good approach to doing business.
The key to winning is to deliver the project in smaller, cleanly scoped and controlled phases.
Most importantly – the project must really be approached in a phased manner – it cannot just be lip service from the project team. At the end of the day a business sponsor will be expecting some business value to be produced from the project efforts and steering away from the phases approach in any regard blurs the lines around that sponsor’s expectations and can derail the project.
Consider these steps in order to help support and create a pragmatic, phased approach that I hope can assist you in delivering predictable benefit to your project sponsors.
Pragmatic Phases Project Approach
Projects only begin to provide value once they start to support or produce for the business that they are designed for:
- Fight the urge to bundle all of the business value into a single, monolithic development effort. If that efforts stumbles or is halted, the business value is impacted
- By phasing the project value can be provided to the business much earlier in the overall project life cycle
- In almost every project it is possible to decompose and prioritize various business benefits that will be made available by the project completion
Observe various dependencies and finalize the list
a. Review the list and sort it by the priority of each business benefit
b. Observe various dependencies and finalize the list
c. Schedule your project into phases on the basis of the list
Treat each phase as a traditional project
a. When complete each phase should yield a working deliverable available for review, revision and release.
b. Continuing to think pragmatically each release does not need to be made public, but should be treated as though it were final given its place in the overall project life cycle.
Hopefully the above tips help project teams avoid trying to “boil the ocean”. There are many good project teams that have fallen short of their potential by trying to address all requirements in a long running project and ultimately failing to deliver a working product. By approaching those same projects in a strictly phased manner they could have greatly increased their chances at getting their projects out of the door.
I look forward to additional thoughts on pragmatic approaches to project management for larger projects. Please feel free to drop me a line or comment.