Dear all,
many of our clients and especially IT departments are struggling with the dichotomy between „project“ and „product“ and the transition from working with projects to developing products.
The ones with a strong industrial production or successful IT project history (e.g. the development and rollout of ERP system templates), or a combination of the two, seem particularly challenged.
It took me a while to understand the root cause for this. From where I am now, I believe that it is a challenge to appreciate that the creation of truly digital products typically is a complex undertaking, while even large ERP rollouts or the development and production of advanced industrial products usually pose only complicated problems.
The first time we started to realize this was when we worked with the R&D department of a manufacturing systems vendor on improving the on-time delivery of their customized projects. It turned out that the technologically very advanced hardware part was complicated, but normally manageable as a traditional project. The software part was a mess. Multiple customer projects continuously competed for the same R & D resources and – despite the team leads doubling time estimates compared to what they thought was necessary if they could focus on delivering the requirements without further interference – they usually ended up delivering late. And only after a series of heated task force meetings.
Some might argue that complicated and complex are merely synonyms for a very high degree of complication. However there is a notable difference:
In complicated environments there still exists – however deeply buried – a predictable causal relationship between start- and end states. Also, the number of possible interactions between elements – if often high – is finite. To that end designing and building even an advanced production line is probably a complicated problem. Typical IT rollout projects with solidly defined and stable requirements may turn out to be very complicated – but in the end are not complex. Complicated systems can be decomposed, problems diagnosed, and their flow optimized. Think Frederick Winslow Taylor or McKinsey.
Complexity is introduced by the interaction of elements between themselves and/or with external agents. Complex systems display emergent properties that make them non-deterministic. They cannot be decomposed and the elements optimized separately. Despite a limited number of players and a clear set of rules, soccer games for example are complex and lead to unpredictable results for just that reason.
The same holds for the development of software systems with interacting components and multiple customers and/or stakeholders who keep learning and as a consequence adapting their demands.
For these reasons, real digital products – where the objective is to continuously improve towards better outcomes for the stakeholder(s) – end up being complex and cannot be managed as projects.
If one still tries to do so – as often attempted by IT organizations – continuous learning from stakeholders – and in particular user interactions is effectively precluded.
Therefore a project approach to software development may work within the confines of an enterprise, where IT users have no choice but live with a pre-defined result. In a competitive- and ever-evolving market environment, it effectively means setting yourself up for failure.
Agile software development methods like Scrum emerged to deal with complexity. By „freezing“ stakeholder interaction and new demands for iterations or project increments and focusing on the most valuable ones, complexity is reduced to a level of complication that can be dealt with with some certainty.
In today’s scaling digital projects, complexity increases exponentially and ventures into a territory that is at odds with most industrial age management paradigms for good – back to the conundrum I started out with.
The complexity challenge is however not the only difference between projects and products. The following posts provide additional insights:
What’s the Difference between a Project and a Product?
By Skip Angel – Great infographic and overview!
Product vs. Project Teams
Brand new – and by Marty Cagan. Project teams are mercenaries … (what more needs to be said to make you read this?)
Click to view!
Products Over Projects
By Sriram Narayan – “Product-mode” is a more effective way of working than projects. Profound. (Takes some time to read!)
The above just started to scratch the surface of the complexity challenge. The consequences for organizations in an increasingly digital world are mind-boggling and probably worth another Weekend Reading.
Stay tuned and have a great weekend!
Cheers,
Godehard