“So Nathan, tell me what you do for a living?”
“Well, I’m a consultant.”
“A consultant? But what do you actually do?”
This is a typical conversation whenever I meet anyone new – and not just me, but for most folks in my profession. I don’t know why, but it’s always been a little tricky to explain what, in fact, I do for a living. “I solve problems,” or “I help people clarify what they want,” or “I build management solutions” are typical responses. A past employer taught us to say, “I help clients move from issue to outcome, with pace, certainty and strategic agility.”
The truth is that I help management understand their needs and then help build solutions to meet those needs. Since my specialty is organizational and talent development, the types of needs I address are usually related to the people and leadership side of organizations. My colleagues in other specialties do the same thing, but with finance, marketing, customers, supply chains, technology or countless other areas.
Whether you are officially a “consultant” or are a specialist, program manager, project manager or just plain responsible for some type of organizational change, I’d like to introduce you to a basic consulting methodology. I often tell college students in a class I facilitate to “think like a consultant” and I believe this methodology can assist just about everyone. Here are the basic components with a basic synopsis for each one.
The first step with any new project is get the requirements. Whether your client or boss wants a new management program or a new software program, you need to figure out what specifications must be included. If you are tasked with building a new car, you need to know the requirements for fuel efficiency, safety features, speed, cost, and many other variables before you even think about beginning. For a people program, you need to know who will be a part of the program, budget, and desired outcomes of their experience – among other things. Once you get the requirements, you need to do what is referred to as “gap analysis” – which means you determine the current state and how it measures up with the desired future state. The solution will bridge the gap.
At this point, you’ll need to develop a basic approach plan that proposes such elements as options for potential solutions, steps you plan to take to build the solution, costs, timelines, and additional resources or people who will need to be involved. The main client will then provide input or make the necessary management decisions – and then you can proceed.
The penalties for skipping the Analyze phase are monumental: high probability of wasted effort, wasted time, wasted resources, rework, missed deadlines, broken promises, loss of engagement, cost overages and client (or customer) ire.
During the design phase, you essentially build an outline for the entire project. As with a writing project or presentation, you will likely begin with a rough outline from your basic plan and then progress to a detailed design outline for the project. When management wants to know what the solution will look like, you can show the design plans. Just like writing, it is much easier to make changes in the Design phase than down the road in the Develop phase.
In the Develop phase, you take the design plans and start actually building out the content or application of the solution. If you are building a training course, you take the course outline and start building lesson plans. For a technology solution, you start writing actual code or building applications.
The Develop phase isn’t finished until the solution is essentially complete. Don’t forget to include user support materials, such as job aids, reference guides, manuals or online portals, as appropriate for the project.
Once the Develop phase is finished, the temptation is to rush to the Implement phase and finish up. But first, the solution needs to be tested. You wouldn’t want to own a smartphone that had never been tested before it was released to market. Your solution needs to be tested as well. For a learning solution or new management process, an appropriate test could be a pilot group. For a technology solution, it could be scenario testing with dummy (or real) data. Take the results from the tests to address outstanding issues so that you (and more importantly, your client) can have full confidence in a successful implementation.
Implementation takes place when the solution is finally released. It can be referred to as “Delivery” or “Go-Live” as well. Once solutions are implemented, they can be extremely hard to change (depending on the type of solution). Depending on the type of solution, this phase may be a blanket switch or may be implemented in multiple degrees. Occasionally, consulting teams are not involved in delivery, which makes the transition process and reference materials that much more important.
Evaluation isn’t a stand-alone phase. It must be done for each step and on an ongoing basis. At the very least, you will want approval from your client to finish each phase, but there will likely be more evaluation than that. You’ll want to quantify the expected benefits before the solution and measure the actual benefits afterwards. Focus groups or validation by SMEs may be needed during the Design and Develop phases for large or complicated projects. For solutions that can be adjusted on an ongoing basis, continual feedback is helpful (that’s why we have customer surveys). For learning solutions, Kirkpatrick’s Four Levels of Evaluation is a good place to start.
An evaluation plan is usually created as a part of the Analyse phase.
I realize that many of my readers may not have an immediate need for a consulting methodology. But once you do, it’s here for a reference.
For those who have built new solutions, what would you add?
Nathan Magnuson is a leadership consultant, coach, trainer and thought leader. Receive his new ebook Trusted Leadership Advisor by subscribing to his website or follow him on Twitter.