In a traditional software development life cycle:
- Business identifies a problem or an opportunity.
- They predict the best solution option and send their request to IT (Information Technology) department through demand management system.
- A BA (business analysis) team meets with business unit representatives several times to determine the solution scope and detailed requirements.
- After development and testing processes, the solution is sent for UAT (User Acceptance Test). This is the first and last time that end customers are involved in the project throughout the whole project life cycle.
The success rate of this classical approach is very low. Despite the hard work of business analysts and IT teams, only a small percentage of projects are completed within target project timeline and budgets. And most of the time the project ends up with a solution that the target audience has no interest in.
Business blames IT for delivering an incomplete solution under their expectations. They also claim that due to late delivery of their requests, their proposed solution lost its importance in rapidly changing market conditions and fierce time-to-market pressures.
On the other side, IT teams criticize business units for never ending CRs (change requests) throughout the project. The project latencies and unpredictable project costs are associated with these CRs. They claim that business did not know what they really needed. This situation gets even worse if the project is started to handle on a relatively more complex problem or an opportunity.
The drawbacks of classical SDLC can be summarized as follows:
- Unclear project goals
Business and IT do not have a common and clear understanding on the project goals and target audience.
- No Customer Involvement
End customers are not involved in analysis, design and development stages. Business have a big confidence that they know customers’ needs even more than themselves. The solution scope and requirements are defined based on assumptions rather than real customer needs and insights.
- Limited Collaboration
Business and IT work in a silo based structure. Rather than a collaborative team, they move with formal sign offs to get rid of the responsibility of a potential project failure.
To prevent these drawbacks, high-performing companies embed design thinking to their SDLC as follows:
- Start with the challenge definition rather than the solution.
- When a business unit identifies a business problem, first the root causes of the problem should be elaborated.
There are usually three types of business problems:
- Known / Knowns: The root cause of the business problem is definitely known.
- Known / Unknowns: Possible root causes of the problem are known.
- Unknown / Unknowns: The team has no idea about the root causes of the problem.
Design thinking is especially effective for projects which have complexity and uncertainty with many unknowns. Solving Type 2 (complicated) and especially Type 3 (complex) challenges requires a new way of thinking with aspects of empathy, insights and experimentation. Embodying all of these, design thinking is very effective in solving complicated and complex challenges.
- Instead of predicting the best solution option and immediately sending a project request to IT (Information Technology), the business unit should propose to organize a design thinking workshop.
Business unit representatives and business analysts should frame the business problem as a challenge statement by using “how might we” (HMW) questions technique.
For instance, if they are considering to benefit from digitalization at sales and marketing but have concerns about the reaction of dealers, they should organize a design thinking workshop with the challenge of “How might we benefit from digital channels without having conflicts with our traditional dealers?” rather than posting a mobile app or web project request on demand management system.
- Design with Customers.
Business unit representatives and business analysts should also clarify the demographic and behavioral attributes of the target audience and define them as personas.
- Customers representing each persona group are invited to the design thinking workshop. Their needs, expectations and pain points are identified by customer centric techniques such as ‘Customer Journey Maps’ and ‘Empathy Maps’.
- Additionally, invisible needs and expectations of customers are identified in terms of customer insights by using techniques such as ‘Affinity Diagrams’ and ‘Mind Maps’.
Each of these outcomes can be used by business analysts as an input to determine detailed requirements at latter phases of the project.
- Workshop participants first focus on generating as many creative ideas as possible and then prioritize them according to their expected value proposition and implementation difficulty. The selected ideas are then turned into a solution concept in the form of high level prototypes.
End customers are invited again in the workshop to evaluate whether this solution concept satisfies their needs and expectations. The solution concept is revised according to the customer feedback.
The selected ideas and the prototype is used by business analysts as an input to determine solution scope. Each selected idea can be considered as a basis for use cases or user stories depending whether the SDLC methodology is waterfall or agile.
Clear definition of high level solution scope with involvement of end customers at the beginning of the project steers every stakeholder in the same strategic direction. This mitigates the risk of scope creep due to potential change requests (CRs), which result in waste due to rework throughout the project.
- Collaborate.
- Business unit representatives from diverse departments, IT teams and business analysts are invited in design thinking workshops. By this way, solution ideas are created by leveraging different perspectives within the organization in a collaborative environment.
Evaluating all of the ideas with the collaboration of business and IT helps business teams to communicate their priorities in a clearer way and helps IT teams to communicate their constraints in a more understandable way.