Pattern: Execute projects to develop and improve products
Foundation Pattern: Use projects and milestones to drive product development
The Pattern
The most effective way to develop a new product or make a significant improvement to an existing product is to plan and execute a project. This project needs to have:
- An end objective. What is the project seeking to achieve?
- Optionally, phases. A large project can be divided into a few defined phases. This is helpful to increase clarity and focus.
- Milestones. Milestones are clear, agreed and significant points within a phase
To use a mountaineering analogy, in climbing a large mountain there are natural places to rest and regroup, known as camps. These are analogous to project phases.
Within each phase are a few noteworthy points — reaching these is a significant achievement and a natural place to re-evaluate the route chosen for the ascent.
The image on the left shows the final route of the Mt Everest ascent (the final phase of the project in our analogy). The marked points such as The South Col, The Balcony etc equate to milestones. These are significant points in the project. You may not know exactly how to get to these milestones, but you know when you’ve reached one!
Note that this is not a perfect analogy, whereas a climbing route can be marked out with some precision, in a complex environment the route will not be known in advance
Considerations / Objections
A project based approach is not compatible with Agile principles
Wheras the language I have used in describing this pattern does draw on traditional project management language, this is purely because this language has proved to be the most effective way of describing the concepts. The project should in fact be executed in an agile way. Whereas the project objective should be held tightly, the route to that objective should be held somewhat lightly. The business outcome therefore over-rides any plans made. The plan is altered with discoveries made. Phases generally remain stable but can change if a discovery is significant enough. Milestones change as required. And the route between milestones is not planned in great detail at all, rather the team collaboratively journey towards a milestone.
Products, not projects
“Products over projects” is a catch-phrase traditionally associated with the Agile body of knowledge. See for example Martin Fowler’s blog Products over Products. The confusion arises in the definition of ‘project’. I agree with pretty much all the views Martin expresses in his blog - I am simply using the word “project” in its true sense. That is, as per the PMI definition: “[A project] is a temporary endeavor undertaken to create a unique product, service or result.” The approaches traditionally associated with projects, such as a centralized funding model, short lived teams and so on I agree are anti-patterns. For more on stable teams refer to the pattern One Product, One Team. If you dis-regard traditional Project Management baggage the core concept of a project is extremely helpful to product development.
Our product is stable and we are not making significant improvements to it
There are many reasons a product enters a stage of stability, where no significant new features are added or improvements made. This can be because the product has reached a point of maturity and / or because improvements to the product are not a priority for the business.
In this case there is no need to execute any projects — as the product status quo is sufficient. Note that this is not to say that no changes at all will be made to the product, rather that changes made are generally to preserve and enhance operational stability rather than to improve the user experience in terms of functionality.
