Consulting Chronicles: Can Do vs Should Do

As a Consultant and Engagement Lead, the last thing you want is for your client to question the direction that your program or initiative is going. That’s where I found myself several years (almost a decade) ago on a global implementation for a fortune 10 client. Everyone was working hard but the results didn’t come as quickly as expected. So, the question on the table was: what should we do about it?

We decided to meet with key client executives to have a strategy session. One of our senior Executives was also attending this session. Suffice to say, stakes were high.

Leading up to that strategy session, we’ve had several meetings with the client and with key stakeholders at different levels. We would usually present our findings and recommendations, which for the most part was well received. But we were never able to make the necessary changes to get to the results quicker.

In prep for the meeting the delivery team met with our executives and discussed our findings and recommendations. Our executives kept asking probing questions to understand the history of the project, what we had tried, what had worked, what didn’t and how to move things forward in the right direction.

We had a lot of thoughts about how to move forward and so did our client. Based on our prep, one of our executives identified what might have been the biggest hurdle. What he said was so simple but profound. He said: ‘Just because a software can do something, it doesn’t mean we should!’ He also used an example that drove home the point.

Assume that you are a General Contractor building houses. You meet with a client who wants to build a new house. As you talk to them about their requirements, you hear them saying that they would like a glass roof in certain areas of the house — like bathroom and kitchen. And, the client asks you: ‘can you build a glass roof?’ The response is: ‘yes, we can build a glass roof.’ But your response should be: ‘why do you need a glass roof?’ If you ask that question, you may realize that the customer just wants more light in those rooms. Is a glass roof the best option? What about skylights? Unless you ask the right questions and offer the right options, you are going to build something just because the customer asked for and it was possible to do.

This was the biggest hurdle on our project. For this particular implementation, the client’s requirements were primarily to take their existing system and rebuild it using our software. Can we make our product work as per the customer’s requirements? Absolutely! However, when the client gave us requirements, our team should have asked the right questions to understand the requirements to see if the client would be willing to look at doing the same things but differently. The clients pushed for the application to work a certain way and our team did not push back. Had we pushed back, we would have realized that the client only cared about the outcome and not doing things a certain way.

Technology can make a lot of things possible and enables us to do amazing things. It can allow us to do things faster, better, more effectively and efficiently. It can help us reduce costs and increase productivity. As long as the software platform is robust enough, we can basically figure out a way to build anything.

But the real question is: just because something is possible, does it mean we do what’s possible? Or, should we do what is right. The executive shared this story with the client, and we focused on specific examples where the implementation time was significantly higher since we were trying to customize our software to fit an existing process. The moment we shared how implementation time could have been significantly less had we used out of the box capabilities and look at alternate ways to do the same things, the client got on board.

From that point on, the collective team look not just at the requirements but also what makes sense to minimize customization. The team started evaluating if there is a better way to do something rather than just do what was done in the previous system.

As the American Author Jennifer Nielsen once said: ‘…. just because it’s possible doesn’t mean it’s wise’.

Start with the intent to understand the requirements and see whether what is being asked is the best way to address the need.