If you run a consulting company or you work as a consultant, I am confident you have found yourself in a situation where you did everything that was asked of you, but the project was said to have failed. The categorization that it is a failure might happen even if you delivered the project on time, according to the client specifications, and within budget. How is this possible? Having been in the consulting space for a long time now, this is a challenge I have dealt with a couple of times.
From my experience, it boils down to the definition of success. On the surface, delivering a project on time, within budget, and according to client specifications is the ultimate definition of success. Unfortunately, this is not the case. Projects are commenced to solve a specific problem. If at the end it doesn’t solve the problem, the project is deemed to have failed. At iHub Software Consulting (iSC), we have explored different ways to increase the probability of projects we take on succeeding.
This, therefore, means, as a consultant you need to rethink how you define success. Successful projects solve a problem. Executing the project on time and within budget is essential, but it has to solve a problem for it to be successful. Simple? If only it were.
There are a couple of factors that will make it difficult for one to do this well. The primary issue is the issue of how projects are identified and scoped out. It usually goes like this:
- An organization internally identifies a challenge. Based on their knowledge, they develop a term of reference and send out a call for proposals
- Different consulting companies bid for the contract. The ToR acts as the primary guideline for these companies as they work on their proposals. Vendors align their proposals to the terms outlined by the contractor to improve their chances of winning
- The contractor chooses the winning bid mostly based on how well the bid is aligned with the ToR
- The winning vendor executes the project as defined in the ToR. The outputs/deliverables have already been identified by this point.
During project execution, there is little room for change. As a contractor, you are expected to deliver what you signed off on even when there is feedback suggesting that you should pursue a different direction.
To change this worrying trend, you can adopt the designer’s mindset. In simple terms, with the designer’s mindset, we are trying to design the right product and design it right. In the sections that follow I will expound on this and share some practical tips to get you started.
Designing the right thing is about identifying a real problem and exploring the most promising solutions. Designing it right is about the process of building the solution.
Design the right thing
As consultants, we often assume that our clients understand the problem they are looking to solve. This is based on the fact that they are domain experts and face the issue daily. What we often forget is that clients are rarely the users of the products they are looking to build. As a result, the solutions they suggest might not be the right solutions.
If you want to set up your client for success the first step is to interrogate whether they are building the right thing. To do so, you have to work with the client to confirm that they have identified the right problem. Many times we are creating solutions that solve the symptoms of a problem instead of the actual problem. The ideal step to do this is before the client draws up a ToR as your intervention will be more impactful then. However, you might not always have such an opportunity.
Let us explore the tactics you can use in the two different scenarios.
Having conversations with a potential client before they draft the ToR is the ideal situation. It will require some upfront investment on your part as a consultant while exposing you to the inherent risk that you might invest time and effort and still not win the contract. The idea is to influence how the ToR is structured so that it leaves space for exploration during project implementation.
What tools/methods can you employ when having discussions with the potential client? I have found either filling out the lean canvas template or the customer journey mapping to be the most ideal.
A customer journey map is a visual representation of the process a customer or prospect goes through to achieve a goal with your company. With the help of a customer journey map, you can get a sense of your customers’ motivations — their needs and pain points (Source)
The two methods won’t require a lengthy period of your time but will help the potential client map the problem better. The ideal output from such engagement is a ToR that broadly defines the problem and allows the exploration of different solutions during implementation. My colleague Joy Kendi wrote about a project that went through this process.
Design Thinking is not a cubicle job — a case study
Design thinking is fast becoming a trend in startups and corporates alike as the need to continually innovate in order…
In most situations, as a contractor, you probably won’t get the opportunity to influence how the ToR is developed. In such a case, the best you can do is to put in a proposal that actively advocates for the design thinking approach. At iSC, we have done this a lot. We have lost a couple of the proposals that we took this approach but also won a fair share of the bids we put in. Broadly, in such a situation the proposal would advocate for an opportunity to review the problem before diving into a specific solution. Some of the methods you can use include a design kick off exercise, a field study, desktop research, or any other forms of foundational research methods that can help clarify the user needs. The lean canvas template is a good candidate here too but will probably be filled out purely based on quite risky assumptions.
The most significant risk is that your bid might not be successful. If your primary driver is helping your clients succeed, then this should be something that you can handle.
Design it right
Designing the product right speaks more to the solution you choose and more importantly how you go about implementing it. I will not explore this at length as it deserves an article by itself.
Broadly, we try to tackle some of the following challenges to design the product right.
- Developing a shared understanding of the problem — as consultants, we take on different types of projects. Seeing that it is impossible to be a domain expert in all the projects we take on, we invest in an approach that helps our clients share as much domain knowledge with our teams
- Helping our clients understand challenges faced building digital products — we find ourselves working a lot with clients who don’t have a technical background. As a result, we have to invest a significant amount of time teaching. Simple elements like how sprints are planned, tools we use for feedback, go-to-market strategies, and much more go a long way in ensuring you have a successful project. At the end of a good number of our projects, we have had clients adopting some of our communication and planning tools such as Trello and Slack
When your clients succeed, you also succeed. Success is mostly achieved when the right problem is solved in the best way possible. Invest more in helping your clients to succeed, and your company will grow in leaps and bounds.