One of the key elements of consulting that I revisit on almost every engagement, is that any puzzle can be solved if you ask the right questions. The three steps I find useful in my work are –
Why? - Why do we need to address this issue? To keep asking the why, until you get to the real problem is one of the strategies I use in cross-functional meetings. It is important to get the subject matter experts from different departments of the company together, and have them agree on what the real problem is, that we intend to solve for them with this IT project. This helps in the long run, to manage expectations and scope.
What? – What are our options to address the issue? Are there any alternatives that can be tested? What is it that needs to be done to answer the why that we framed in Step 1. The what can either be technology solution, e.g. “we need to undertake an ERP implementation.” or, a process change, e.g. “let us revise our SLAs with the vendor and see if it cuts down the inefficiencies”.
How? - How are we going to implement the solution we came up with in Step 2. What is the CRM suite that we will use to implement the new CRM system?”, “Is Oracle the right choice for this project or can Microsoft also fit the bill ?” . How are the projects going to be managed, what does the project plan look like ?
Now , let us see these three forces at play. Consider a company with a vision of overhauling their IT platforms in order to support high volume of orders and provide state of art reporting and analytical capabilities. The vision was clear, but no one asked the right questions like, “What is missing in the current system that we need a new platform ?”. Thus there was no clear consensus on why the company needed a new system.
With a weak reason to support the effort, a specious what was suggested. Whether this was really needed or not, was thus open to debate — and since it was a not a collaborative project in the first place, there was not much resistance to the solution proposed.
To implement this project a highly skilled team of professionals was put together – few folks from within the company, and an army of people brought in from the outside world. Vendors were selected; sub projects were set up and assigned to skilled managers — the team’s energy and drive was exemplary. The how pieces of the puzzle were finally put in place.
But ultimately after battling this weak foundation for two years, the project met its fate and collapsed under the rubble of unanswered “why”, “what” and “how”. A strong team with excellent skill sets, and three outstanding technology vendors could not put together the pieces in the rubble.
If only enough time was spent upfront in defining the true WHY?
Sounds like DMAIC.
It is a good idea to ask ‘WHAT IT IS THAT WE ARE TRYING TO SOLVE FOR’? before embarking on any exercise.
The answer or rather the lack of is often surprising since all the members of the team have their own interpretation or sometimes none.
Complex org charts tend to lead people to merely start following obscure instructions without really getting to define the problem statement.
Kudos for the foray into MDM – if understood and acted on right is a valuable construct on which to build a successful enterprise.