Just over a year ago Capital One has acquired Adaptive Path, one of the most prominent design firms of recent years. About the same time Accenture acquired Fjord, another design leader, and IBM is on track to grow their in house design team to more than a 1,000 people. What's going on?
Even though, the term 'Design Thinking' has been coined back in the 90s, only in recent years Apple, Google and other "design leaders" have been able to achieve astonishing success. Why?
Design Thinking has grown past its original applications in Product Design and Website Development. It is now a standalone discipline with clear set of methods and wide spectrum of application - from traditional consumer products and mobile apps to enterprise systems, construction, procurement and vendor management. So look and feel is no longer the only focus.
In this blog we will be diving into the practical aspects of Design Thinking, it's tools and repeatable processes - processes that Apple and Google have been quietly using to became world's most valuable companies... processes that help government agencies achieve better benefit realizations and reduce waste... processes that help project managers around the world to keep their projects on track and their business users happy.
The term 'Design Thinking' is often associated with David Kelly, Stanford professor and the founder of IDEO, one of the leading design firms established in 1991. Design Thinking started as a problem solving approach and differs from traditional analysis in that it doesn't attempt to fully define a solution upfront. Instead of taking business requirements as marching orders, designers were encouraged to seek better understanding of the situation, reasons why, core drivers and business goals.
Fast forwarding to this day and over 20 years of research, "Design Companies" have learned to appreciate what 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.
Latest advances in Design Thinking now offer a human-centric approach and repeatable processes to take all these into account and focus on just the right problems and the most efficient solutions.
I always liked to paraphrase the God Farther and say that one business analyst with a pen can save a problem faster than a dozen genius developers with latest computers. It's really is all about requirements.
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...
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?
Well, this is the reason why IBM is being so aggressive with building up its design team. And this is exactly the reason why I'm so excited to show you how you too can implement these same Enterprise Design Thinking tools and methodology on your projects in very near future.
Thanks for reading the article. Hope I was able to paint a perspective and show you why Design Thinking is now becoming a game changing competency for many enterprises and why we're seeing this trend of acquiring the design talent on such a broad scale - even by the enterprises where design has never been a key focus area.
Did I miss any of the important issues with Design or Requirements Management that you're dealing with right now? Is there a specific topic you'd like me to focus on? Would love to see your thoughts in the comments area below.
This article was written by Dmitri Khanine from CIO and was legally licensed through the NewsCred publisher network.
