When it comes to risk management, requirements - related risks are usually the toughest. Imagine taking exact business specs and using them to build a system... or select a COTS solution or find a vendor to build it out. And then all kinds of new requirements are beginning to surface. Turned out, business users did not really want the system to work like that. And thiiis and that features are missing and both are really important!
And most PMs are just shaking their heads in disbelieve. "Did we not build exactly what you asked for?" Well, yeah, but...
So agile folks have been really smart about it with short iterations and putting business users on their cross-functional teams, making sure that developers never have to guess about how business processes supposed to work...
And that has been working reasonably well, except that you may still end up building the WRONG THING!
Sure, if you follow agile, you are going to build it right from the technical point of view and all of your business logic will work as it should, but how will you ensure that the RIGHT problem is being solved?
The F-16, one of the most successful military aircraft ever designed, was not built to spec. Designers recall that original requirements were calling for the Mach 2.5 speed yet that speed was never achieved.
The reason why F-16 was so successful (and still is, more than 30 years into production) is because the designers went back to their internal clients and asked why was that speed was important. Instead of just taking on the mission and trying to build an aircraft capable of achieving Mach 2.5 (which was next to impossible back in the day), instead of focusing on "proper processes", designers took a step back and looked at the bigger picture.
Turned out, the greater speed was needed to be able to escape from combat. But that was just one of the possible solutions, so alternative solutions like better view for the pilot and greater agility helped achieve the same or better results.
Taking it all the way down to a seemingly small content migration project where business has asked for a better way to migrate content - when the majority of time was actually spent on mapping of old and new content structures - focusing on the key business goals - faster migration - helped complete the project 8 times faster and save $2Million in the first year.
You see, when business people are asking for something to be built of procured, they tend to 'prescribe' solutions. And the trouble is - many times these gut feelings are taken by development teams and procurement - whatever the case might be - and followed as marching orders for defining scope and starting projects.
Agile has done a great job making business analysts put requirements in a format of User Stories. "As Records Officer I want to capture the document type and the type of vendor In order to determine retention". That does a great job at raising awareness of development team and understanding who and why needs each particular feature. But what if only a small portion of documents are coming in through this particular channel? Maybe capturing document type and vendor now should not be made a priority.
So way too often organizations are spending a lot of time striving for perfection and trying to anticipate needs of their business users instead of conducting proper user research and getting facts.
What if we used User Story format and apply it at a much higher level - at the level of a project or even a program? Who needs that project, what kind of benefits are expected to be realized and why is that important?
And what if we compliment that knowledge by observing users conduct their daily activities? So not only will we focus on correct business goals, but also try to achieve them by solving the right problem in a right way?
That's what making Design Thinking in Project Management such a powerful tool. Use it and it might push your projects into totally different direction - direction where you'll see a lot less scope creep and much higher benefits realization.