How to Define the Nature of Your Challenge or Opportunity
More often than not, the way you define your initiatives foretells their success.
Once a year, most companies have their leadership team convene to put together their strategic plan: Here’s where we want to be by year-end 2020 (vision), these will then be the tangible business outcomes (breakthrough objectives) and this is what we need to achieve by the end of this coming fiscal year (annual objectives).
If your organization is using hoshin kanri or a similar approach, you know your leadership team isn’t off the hook at this stage: You’ll need to play “catchball” in order to ensure these goals are deployed to the organization. If your annual objectives are stretch goals—and for many reasons they should be—then chances are there’s no straightforward way to achieve them. Merely tuning your offerings and processes won’t do; chances are you’ll need to go way beyond that.
The key question then is: How do you know the nature of these “top improvement priorities,” which collectively make sure you achieve your annual objectives? The answer to that question is crucial: If you give an innovation challenge to an improvement team you are quite likely setting them up for failure.
Decision Tree: The Nature of Your Challenge
Over the past three years and in a significant number of strategy sessions, I have learned how a simple decision tree and the consistent use of language can drive the required shared understanding of a strategic initiative.
This flowchart helps leadership teams to “operationalize” their challenges: Knowing which methods will be used helps a champion guide a given initiative and allows a leadership team to steer a portfolio of them towards success. Plus, leaders can make sure the managers in charge of these initiatives master the methods they are supposed to employ.
How Can You Describe Your Challenges?
Now that you know the nature of the challenges, how can you describe them? In our experience, this is not a question of “naming conventions.” You can call it “Project Ara” but you need to be clear what that is about: design a new phone that allows the integration of hardware capabilities with the same ease that today’s phones allow integrating software capabilities: Project Ara is about the “appification of hardware.”
The following table summarizes language you can use to formulate a first version of the project description. It turns out that the best progress is achieved by replacing the generic verbs “get done,” “build,” “set up,” “improve,” “design” and “create” by more specific verbs (see the examples).
It’s a Leader’s Task to Figure It Out
Unfortunately, all too often busy managers cede to the temptation to leave “the details” to their employees. Invariably, this leads to diverging interpretations about what the problem is, which then creates a lack of focus and alignment. Worse, you can set your teams up for lackluster results and even failure. For that reason, sometimes company leaders are required to write a full or, at least a draft, charter for each of their strategic initiatives. Where and when that is possible, it is laudable and very helpful, but practically speaking, we haven’t seen that work all too often. Hence my pledge here: Business leaders should at least take sufficient care to define the operational nature of their strategic initiatives. To be fast and effective at that, they can use the simple decision tree and they should also use strong and clear language to describe the job that needs to be done.
Common Questions on Identifying the Nature of Your Challenge
Here are some of the questions people ask when applying this approach.
What is the difference between a “known solution” and a “known solution concept”?
Imagine your challenge is to “help people optimize fuel expenses for their daily commutes to work.” There isn’t any obvious solution that could simply be implemented. However, some people may have in mind a solution concept such as “let’s design an app.” That app would then learn the user’s commuting habits and suggest routes and times and when and where to pump fuel. If we choose the solution concept of an app, it would need to be designed carefully.
On the other hand, if our challenge were to “help pedestrians cross a road,” we may readily understand we need a traffic light. Classical project management would then make sure the result functions well, is built on time, in budget and without construction work disrupting traffic.
What is a “just do it” project? How is it different from “classical projects”?
Just-do-it projects are indeed similar to classical projects, yet they are very simple. They don’t require skillful project management. The solution can be implemented very fast and with minimum preparation and planning. If needed, the solution can be undone just as easily. Lastly, in just-do-it projects, all means for implementation and for assuring acceptance are in full control of the team.
What happens after we have implemented a performance or process management system?
Such a system creates the transparency you need to decide where to improve and what to improve. It helps you understand where your true challenges reside. In essence, after you have set up such a system, you are back to the start of the flow and you can then determine and quantify your challenge. The implementation of a performance measurement system may help achieve annual objectives, but it is not a top improvement priority because alone it doesn’t drive performance. Rather, it enables the organization to spot and quantify where to improve performance.
Why can’t I hand out improvement projects where teams improve multiple metrics at a time?
In most cases, such a request would mean you are asking the team to redesign the overall system. In other words, you are giving a design-task to an improvement team. If two or more metrics hang together (“making it faster is only possible if it’s also better and that will mean it’s cheaper too”), then you should formulate the goal in one metric. If they really hang together, then that improvement will drive the others. It is a leadership task to figure these things out and set the right focus.
Can’t I just tell the team that I want the so-and-so concept and then there are no more true innovation projects—it all turns into designing things the right way?
That is indeed what some companies do. Such an approach can even make sense, if the solution concept utilizes the core competencies of the company (e.g., We are good at programming, at injection molding, etc.). It should be a conscious choice, though, and you should be sure it’s the right concept. Not every problem can be solved with an app.
What if my challenge doesn’t fit into the decision flow you presented?
Chances are you can dissect your challenge into multiple sub-challenges, which then can be sent through the flow. “Flying a man to the moon and back safely” is such an example. By the time Kennedy pronounced the challenge in 1962, the recovery capsule needed to be re-built (classical project), the Titan III boosters needed to be substantially improved (improvement project) and navigation in space be completely redesigned (redesign project). In other words: Different teams need to be set up that will apply classical project management, Six Sigma or similar improvement methods, and Design for Six Sigma or other design methods.
