Design Thinking & IT SDLC Process
A recent opinion piece, “Why ‘Design Thinking’ is becoming a game changer for many enterprises” by Dmitri Khanine on cio.com, articulates how Design Thinking can be leveraged to improve, if not transform, the typical legacy IT Software/Solution Delivery Lifecycle (i.e. the SDLC process).
“Design Companies” have learned to appreciate what is now called the Human Factors — facts like that business requirements are created by humans and often given out in form of solutions, which may or may not be ideal and represent just one of all possible options… facts like asking business users what they want may lead a project going in a wrong direction… facts like that different types of users, different roles and personalities may have completely different ways of interacting with your systems and very different requirements.
On Requirements Management
Recent PMI study quotes that 47 percent of projects that are in trouble today are there because of a slip in requirements management.
Think about it. Out of all projects that failed to hit the mark — across all industries — virtually every second one is in trouble because of requirement management. Business users are called upon to do something that they have never signed up to do — design solutions. Business Analysts just come and ask them what would they like to see in a finished product…
Placing business users on development teams helps to better translate their vision to code but offers no protection against ineffective solutions and occasionally, going after completely wrong business goals.
Wrong solutions are being procured, implemented and developed. Years of effort are spent creating customizations, just to realize that they don’t fit very well with the way users are interacting with the system or that they’re solving the non-critical issue, while the most critical ones are left unaddressed. And that also creates confusion about scope and direction…
On Scope Creep
If you hang out with PMs, you hear a lot of complaints about the Scope Creep common phenomena – when new requirements are coming out of the woodwork long after a project is initiated and wrecking havoc in schedules and budgets. There’s also another related project risk – stakeholder management. That one is about managing expectations and dealing with ‘difficult’ people who cause Scope Creep by coming up with all of these ‘unforeseen’ requirements.
But why are they doing this?
You see, when business requirements or an RFP is created based on a ‘download’ from one stakeholder, there’s a very good chance that they will later realize that they’ve forgotten something. Other stakeholders and other business units will also pick up on missing pieces. And you have little control over when these insights can occur and whether or not this process based on spontaneous realizations will lead you to a complete and effective solution in the end.
Now what if we take most of this volatility out of user requirements? What if you could ‘magically’ extract the knowledge out of your key stakeholders and flesh out complete requirements in just a few days? What if you could also include the end users in the process to further insure against missing things – without stretching the process a lot longer?
If we do that – wouldn’t that just slash this 47 percent project failure rate down to low 5s for you? What would that mean for your current projects in terms of dollars saved and improved user productivity?
Now what if I could show you the processes your BAs can follow to get all of this done in just a few days, often before a project is started? Wouldn’t that be something you’d like to learn?
You can read the full article here.