“From projects to products” has recently become a fashionable slogan – and for a reason. In the past, an information system was a project investment. We spent a year defining it, a couple of years implementing it, and a few years utilizing it. Then we started a new project to replace the system.
In reality, our information system went through quite a bit of “maintenance”, “minor development”, and an “upgrade” during its active lifetime. In many cases the number of people needed for “maintenance” was almost as large as the number of people required for the original implementation project.
A project is meant to be a temporary organization with a clear and fixed scope, objectives, budget, resources, and duration. A product organization, on the contrary, is thought to be permanent or at least long-lived. Its mission is to deliver subsequent releases of the product and to enhance the product’s competitiveness with each release.
There is no doubt that the lifecycle of an information system today resembles a product lifecycle more than it does a project lifecycle. “From projects to products” simply means making a virtue of a necessity.
Start by establishing a product management function. A product manager leads the information system as an incremental investment, where each increment enhances the value of the system. He or she will also remain constantly on top of the business’ requirements, prioritize them and plan a constant flow of system releases that deliver the most value-creating new functions in the product. In other words, the product manager manages the value of the information system as a continuum rather than as a one-time investment.
The same goes for the “product development team”. The people actively involved in the development of the system will not go away after the “project is done”. They will remain to keep the system competitive. Sure, the size of the team may vary over time.
The shift from projects to products may sound like a huge increase in costs. Sometimes it is, sometimes it isn’t. Don’t fall into the trap of creating the product organization alongside the old project organization. You may need to re-shuffle roles and responsibilities – and change some people. Basically, you need someone who owns the definition of the product, someone who delivers the software and someone who operates it.
A project manager’s mindset is to deliver according to a plan and budget and then move on. An operations manager’s focus is to keep things running and to minimize user complaints. A product manager’s task is to keep the product competitive by managing its business case.
And what does “project to product” have to do with testing? Just imagine how differently a person responsible for delivering a project and a person responsible for a product think about quality, and how differently they’d prioritize activities. We’ll dig deeper into these differences in the next few posts.
Check out rest of the blog series here:
- Focus on risks and dependencies
- Train your digital operations people in DevOps
- Start viewing your IT investments as products rather than projects
- Shift testing left – and shift testing right
This short text just scratched the surface of moving from projects to products. Check Mik Kersten’s book Project to Product: How to survive and thrive in the age of digital disruption with the flow framework to learn more.