If you are reading this at a Starbucks, waiting for your CTO to arrive with his MAC, as the two of you are going to have a joint design session to build the next successful app. This article is not for you.
(You believe you know 99% of what your potential customers want and your technologist is ready to listen to you through 10 AGILE latte iterations, until all knowledge is synched and design is crisp and ready for production)
But for the majority of us involved in IT projects where stakeholders are arrayed in a succession of tollgates, from corporate sponsors and project management officers all the way down to testers and implementation support specialists; it is harder to deliver value to customers if this collective challenge is not met via a mix of IT delivery approaches (AGILE, UX, etc.) and business process improvement techniques (Lean/ 6 Sigma, BPM, etc.)
Combining Customer Centered Design (CCD) and the 6 Sigma’s Voice of the Customer at different stages of the project lifecycle is a good example of adjusting techniques to match the different thinking patterns of business and IT stakeholders.
In an IT initiative that has customers as end users there are two critical objectives:
1) We need to understand what a customer wants (Customer Satisfaction Expectations)
2) We need to deliver a product that satisfies this need (Customer Satisfaction Experience)
The Voice of the Customer (VoC) technique addresses the first objective and is readily embraced by business stakeholders. They would be very open to follow the linear workflow of this technique, because it accommodates their own reporting structure...
VOC Workflow:
Set up strategic alignment on where the business is willing to go (Voice of the customer might be the guiding light, but Voice of the Board sets the strategic boundaries and context for the initiative)
Gather and analyze data to obtain actionable feedback (Usually business data is analyzed first, as a prelude to carrying out a very focused customer survey)
Disseminate insights across all business units and set actions in motion
Review results via other surveys and/or changes in VoC metrics.
Notice how the emphasis is on backing up with data the identification of a business need and the validation of project results, not so much on thinking how will the product satisfy the customer need.
On the other hand, IT delivery stakeholders are at greater ease with the “how”. They can build on the VoC strategic insights established by the business side, and within the boundaries set by governance; they can set off a Customer Centered Design (iterative) workflow that maximizes customer experience:
Customer Centered Design Workflow:
Contextual design study
Competitor product analysis
UI design and prototype testing
Usability requirements
Software Implementation (1)
Usability tests with early product versions (2)
Change requests (3)
Back to (1) until all change requests are completed
An effective Business Analyst would need to be capable of facilitating both techniques during the project lifecycle, switching the deck of cards at different stretches, depending on stakeholders and project deliverables.
The illustration below portraits a high level view of how a business analyst would manage requirements and validate a solution for the project team, combining VoC and CCD:
First, business analyst would use VoC to deliver enterprise analysis (Business Case) and the requirements baseline validated by business owners (BRD). Next, the analyst would facilitate iterative sessions between IT and sample customers, as they assess gaps in design and deliver product (This is all done within the boundaries set by Business Case and BRD). Finally, after these Customer Centered Design sprints are completed and product is released, Business Analyst will support assessment and validation of the solution via VoC surveys and gathered metrics.
It is important to make an observation in contrast with our “Starbucks scenario” mentioned at the beginning: In a pure AGILE product lifecycle, the boundaries for CCD (desirability, viability, and feasibility) are all handled simultaneously during the sprint, because business sponsors, owners, and technologists are having the lattes together. In more complex organizations, the Business Case and the BRD will contain the viability boundary and the Business Analyst will have to take on the business role and alert project management on change requests that need to be reviewed by owners and sponsors.
Unfortunately, this is the most AGILE it can get for many organizations.
By Larry Velarde, CBAP®
