The role of design thinking in fixed price contracts
Design Thinking does very well when you have somewhat loose constraints.
For instance, we don’t want to assume that our current proposed solution is the best use of resources until we’ve prototyped and tested it. We have full permission to go back to the drawing board as failure is cheap in Design Thinking, and isn’t considered failure at all, but instead it’s feedback. It’s simply data, telling us which way to go or not to go, but it’s cost us very little. This thrives when you say we’re going to get from A to B, but we’re not sure what B is, or how long it’s going to take us to get there, but we have a way of getting there… For that you need flexibility.
But what about if you already have a contract? The solution has already been selected and the scope has somewhat been committed to. This is still absolutely the norm with services in many parts of the world, particularly Australia.
An example of this is a CRM implementation, or any other customer data management system.
The technology has already been selected, the solution partner selected, a quote is given, and there’s some ‘vibe’ of what the end state will feel like.
These ‘simple’ projects are often ugly, painful, political and expensive.
Assuming our development skills are good, meaning we can translate any requirement into a feature in the system, where I find our projects usually fall over is:
- The commitment by end users to give good detail of their job requirements (‘What do you mean you need to spend 2 hours with my people?’)
- Varying degree of skills in intermediary brokers of requirements. We often rely on these people to translate how the business works into a format that can be understood by a development team. In my experience, there has almost always been a disconnect and good BA’s are still rare.
- Lack of visualisation of end state functionality prior to building. Despite a list of 1000 user stories with acceptance criteria being completed and signed off, after combining all of the functionality together as a single platform, it doesn’t live together in a way the end users expected. Who would’ve guessed that reading a spreadsheet of 1000 lines would be misinterpreted?
- Governance. A process of how we work, how we manage change, how we manage issues, how we succeed.
I’ll be focusing on the first 3 for this post.
The commitment by end users
If we’re building a product for a group of users, often we are putting in a system where work has previously been done manually, or we are replacing an old system. In both cases there is a tremendous amount of knowledge that we need to extract from the current end users.
Even if there is existing documentation and process maps, they are often outdated and there is informal processes that are locked up in years of experience and routine.
We need access to these people, significant access.
Where traditional software implementation falls over is how we access these people. It’s usually in a workshop setting, that is terribly run. I’m also talking to all you consultants that pride yourself on being good with the whiteboard. This used to be me. Eventually the business pushes back and says ‘our people have been workshopped to death’.
Nobody will ever be able to accurately translate how people work, as exceptionally well as the people who actually do the work.
The issue is, they don’t know how to translate it, share it, get consensus and progress. It’s not their role. Their role is to do the work, know the work, not communicate and optimise the work.
That’s where Design Thinking methods are critically important. A core principle of Design Thinking is participatory design. We don’t design for people, we design with people.
A skilled facilitator will keep a room occupied and engaged all afternoon and have a clear set of understood, debated and accepted process by the end of it. And guess what? The consultant has not once written on the whiteboard, not once. In fact, they’ve barely said anything. But yet it’s an effective use of time and we’ve had a clear outcome.
This is where ‘methods’ are important. A structured way of how to accomplish an outcome with a group of people. The facilitator supports the method, and the participants execute it. The participants include who we are designing for.
Varying degree of skills in intermediary brokers
I’m going to talk about this as I’ve experienced it over the last decade. The differing degree of skill in Business Analysts is terrifying. As a software development team, company BA’s play the critical role of translating how people work into a format that we can understand.
This is often done poorly. A lacklustre BA will run a workshop, map a process diagram, and leave it at that. They haven’t picked up on the cues from the audience, cues like “um, yup, I think so”, “don’t even go there”, “but sometimes”. They haven’t challenged obvious contradictions, they haven’t asked enough questions. They haven’t hunted down answers where questions still exist. And why should they? At the end of the day, they’re not developing the software and they won’t be stung if they’ve missed the odd process or two.
But yet we need these roles to understand their audience’s roles better than they do. A good BA understands how people work better than the people that do the work do. I mean this literally. They have the holistic view, they know how information is originated and terminated, three steps up and ten steps down from who they are interviewing.
For me the scariest is when our allocated BA is a contractor that has been hired for the project, with no existing knowledge of the company. It’s not a deal breaker, but it’s a warning sign.
In Design Thinking, by bringing our end users into the design process, the BA role turns into a formatting role instead of understanding. We don’t need an interface to the business, because we already have one, the business itself. The BA is still helpful, they find all the validation rules and values of dropdown fields, they help us document, but it’s the end users that are part of design team that manage how the process works.
Lack of visualisation of end state functionality prior to building
In Design Thinking, we assume anything can be prototyped and tested. A mobile app, a physical space, a public policy, a service.
Prototyping is a visual representation of something we are creating in order to test.
So there are two concepts here that we need to pause on that are different to traditional development.
A prototype is not an MVP. It’s anything that is a visual representation that we can test.
Testing is not software testing. Testing is the act of gathering feedback about the outcome of something we are building. For example, if we think a new widget will save our call centre some time, we need to test what happens well before we even start building. We test by giving users some mockups of the new widget and ask them to complete a mock call using these new screens. They’ll come back with feedback like “and now I’m going to quick log the address, oh hang on, I usually ask if they update their number here too”. We can then time them with the new wireframes and see how many steps we can reduce it by.
Testing is testing the outcome, before we start building.
Think of a survey. “Would you buy a product that will save you 1 hour a day, and cost less than $50”. You’ll get almost 100% on that survey, but what if the next screen said “Click purchase for a 30 day money-back guarantee to receive this product.”. Our result will be very different. One is a test, one is an opinion.
The Design Thinking mindset
So, include your users in your design team, get a good design thinking facilitator to lead your requirements gathering process, and prototype and test before you even fire up your dial-up modem for development.
You’ll significantly reduce risk by the common understanding of how the solution will work, you’ll have validated the outcome before building, and you’ll have comfort in the level of detail and quality of requirements.
