Reduce Project Risk With One Little Change!

Yes, that's a clickbait title. And yes, it's true that one change in your delivery approach can drastically reduce your project risk by simply shrinking the time between when requirements were gathered and when the solution is delivered.

The classic response to problems with solution delivery is that "we need to undertand our requirements better before we start." At first this response sounds reasonable - if we know what we need to build then we can build it. However, theare a couple of problems with this. The first is that while people are naturally gifted at describing incremental improvements to something that already exists, the overwhelming majority of humans are very bad at visualizing a completely new thing. The second is that today's rate of change means that the half-life of requirements is decreasing at a rapid pace; put another way, requirements don't age well. So even if your business analysts are perfectly able to get into the minds of your users and describe the perfect solution that they want today, they will need something else completely by the time you deliver it.

To make things worse, anyone with any experience knows that it is very difficult to ensure that the solution matches what the user really requested or that it actually meets the engineering specifications. Mistakes will be made; assumptions will be invalidated; and miscommunication will occur.

So what's the solution? Shrink your scope! In manufacturing terms this is called "reducing the batch size." Rather than gathering all of the requirements now for a year-long project, you will be much more effective by building a high-level roadmap for the next 12 months, gathering a few requirements at a time, and then delivering and validating them before moving to the next ones. This constant cycle reduces the chance that your delivery team fails to deliver what is requested, and it reduces the chances that your customers requested the wrong thing.

This approach also reduces dreaded "watermelon project" which is green on the outside and red on the inside. It's really difficult for a Project Manager (or the people who report status to him or her) to misrepresent the true status when it is ultimately determined by what is delivered and not by some vague measure like "earned value" or "percent complete" which cannot be truly measured until the entire project is complete.

This blog post is intended to offer a brief overview of how Agile methodologies can reduce risk. For a more thorough understanding, please see Al Goerner's presentation from the 2016 Agile Alliance Conference which took place in Atlanta, GA.

So there you have it. The one "simple" change that can reduce your project risk!