Even though the Project Management Institute (PMI) began delivering their Certified Practitioner program some years ago, many experienced, veteran, project managers still disregard agile methods and stress the importance of Waterfall approaches. Their rationale is simple:
Premise: Many projects fail because they have poor planning, analysis and design. Hence, more upfront planning and better analysis decreases risk of failure.
The literature over the last decade clearly shows the reasons for project failure. Whether it’s Forbes, Standish, PMI or Gartner, they all report the very similar outcomes for delivery with traditional project management frameworks.
The Project Management Institute states that six factors that must be met for a project to be successful.
According to many sources over the last decade, the outcomes defined by PMI for success are rarely achieved. So, why do projects fail?
The natural tendency in traditional, 20th century project management practice is to attempt to reduce risk through more planning, user research, requirements analysis and definition. Unfortunately, the these activities just create a false sense of security that the future solution is truly knowable through extensive analysis, definition and planning. It’s arrogant at best. You can’t predict a hand of poker. Why does anyone think that planning and requirements gathering will accurately predict people’s requirements 6, 12 or 24 months away?
In a complex environment, where more is “unknown than known”, the only true way to reduce risk is to apply Complexity Theory. Can we predict the outcome? Can we know what problems will occur during integration? Do stakeholders know what they want before they see it? Can we account today for what might happen tomorrow, or next month, or in 6-months time? Complexity theory helps us understand the future by doing the following:
This way of working is what Dave Snowden’s Cynefin framework refers to as “Probe, Sense, Respond”.
More upfront analysis, requirements documentation, and planning – typified by linear and Waterfall delivery frameworks – will only reduce risk and project failure in a “complicated domain” or “simple domain”. If won’t help in a complex domain.
Good planning, analysis and design are critical to project success, as is communication, and a shared vision of what is being delivered. The fallacy is assuming that all this effort must be entirely done up-front, in totality, by specialists and then handed down to developers in the form of documentation for them to interpret. Documented requirements can only capture explicit knowledge. It can’t capture knowledge gained about the subtleties of the context and its associated needs.
An experiment, on the other hand, creates a shared experience. The team collectively discovers whether an assumed solution creates the desired outcome.
How do you write great User Stories?
How do you create an Increment of work in Scrum? What has it got to do with the Product Goal and Definition of Done?
What metrics do you need to understand whether you’re going to achieve enterprise outcomes for agile transformations
Should you have business as Product Owners? Is the Release Train Engineer a Delivery Manager? Where do Project Managers go? Aren’t Epic Owners the executive? Everyone gets these things wrong. Find out how to avoid SAFe’s implementation traps.
Are you still asking the ‘three questions’. It’s time you learned some better patterns to inspect your progress toward the team’s Sprint Goal.
Agile project management metrics often rely on team surveys to find out how agile the organisation is. Team surveys fail for many reasons. Here’s our top tips on what to look out for and how to measure agile in a repeatable and scalable way.
Copyright © Zen Ex Machina® and ™ (2021). All rights reserved. ABN 93 153 194 220