When implementing improvement systems that impact business processes and require methodology and tools; you must first define the problem you are trying to solve. Often we see organizations start with possible solutions without first define the business problem they are trying to solve. They get enamored with technology (perpetuated by software vendors) and lose sight of the desired end-state, since the end-state was never defined. In the worst cases, the end-state is defined by software vendors as the attributes of their software solution.
The ‘end-state” can also be called the “Why Statement.” Why do you need to make the change? What is not working the way you want it to now? What is the gap between the as-is and should-be? What if you didn’t make any changes, what would be the impact? The “why?” statement is also the overall goal for making the improvements in systems and processes.
Next you must define the Improvement Objectives. These are the 3-5 specific outcomes you want/can measure with the improvement intervention. We typically prioritize these objectives using a pairwise comparison of each objective to determine which objectives are the most important. This is a metric by which the improvement program can be measured to determine if it is achieving the goal. In other words;
What is not working and what would it look like when it was working right?
"And it comes from saying no to 1,000 things to make sure we don’t get on the wrong track or try to do too much. We’re always thinking about new markets we could enter, but it’s only by saying no that you can concentrate on the things that are really important."
Problem: Create a means to get across a waterway (without getting wet)
Solution: Build an un-bridge
I love the solution that RO&AD Architecten came up with (above) for the Municipality of Bergen op Zoom in the Netherlands. It is a great example of looking at the problem differently and of not using “conventional wisdom” to solve a problem. Their site is as clever as their bridge.
This “contrarian” bridge reminds me of corporate examples of technology solutions we’ve been involved with in Silicon Valley. These business and technical solutions came from people who were able to conceptualize problem/solution differently. Some organizational cultures encourage this behavior and others aggressively discourage it (knowingly and unknowingly).
Why isn’t contrarian thinking the norm?
con·trar·i·an [kuhn-trair-ee-uhn] noun: a person who takes an opposing view, especially one who rejects the majority opinion
In our experience, we’ve seen lots of bad decisions (we know in retrospect they were bad because of the measurable failure they caused later on); but at the time they were made, they were “excellent decisions” made by “subject matter experts” that could not be challenged.
Sinek’s idea is that the “Why” defines the Purpose, Cause, and or Belief of what you are trying to achieve. Often we find that this is not clearly articulated or commonly understood by a group of people, yet without knowing the “why for” of something, it is very hard to define the steps to get there and it is hard to motivate people to extraordinary performance. We all need to know why we are doing something; just knowing what we are doing and how it is done is not enough.
Often we see clients focused on the HOW (i.e. the technical solutions), yet they have not reachded consensus about WHY they are doing it and WHAT they must accomplish through the technical solution options (or the HOWs). The models are simple, the group thought process is the value.
So lets look at this idea as it is applied to a decision model (below). The Goal statement is why we are doing it, the Objectives outline what we want to achieve, and the Alternatives are how we’re going to accomplish the Objectives.
A consistent and fundamental problem we see in our practice is too many projects and not enough resources (people, materials, equipment, and money). Why?
Each project has revenue associated with it. This revenue is part of a portfolio of projects. The revenue is needed to justify the expenses (capex and opex). The more projects in the portfolio... the more potential revenue, so the logic goes.
Cut projects... then "the business plan does not work anymore." So the projects stay, even some that are past their market window, causing low/no ROI at best when they finally reach the market. Yet these "dogs" continue to suck valuable resources from the portfolio. Rarely do we see the project portfolio rationalized with the available resources. This is too scary for most companies.
We use a process called Challengeto facilitate breakthroughs in thinking with teams, such as accelerating a schedule or finding a way to reduce costs in a system.
The process we use was derived from Edward de Bono's "Lateral Thinking" concepts. His book is a must read on the subject of creative thinking. We have extended his idea and used it to get teams to step outside their paradigms and find alternative ways of approaching problems, such as how to pull six months out of a schedule that, on the surface, seems impossible.
It starts by listing assumptions, boundaries, dominant ideas, avoidance factors, polarizations, and essential factors about the project. We have a variety of techniques for facilitating this, depending on the team make-up.
In this presentation I’ll discuss a decision modeling concept we’ve developed that is based on voice-of-the-customer prioritization models created with our clients and their customers.
We call this “What, Want, How, and How Much.” Many problems can be seen from this simple metric. The order of these are important, which you will see later.
In the previous two screencasts (see links below) about the “Project Portfolio” I described the process of project portfolio prioritization using constraints. In this screencast called “Part C” I’ll introduce the time dimension to the modeling process. We still need to select the best project mix to maximize benefit in order to meet our objectives, but in this next step we’ll consider how resources are used over time. This differs from my first two screencasts in this series where we looked at resources without consideration for when projects start and how they interact over time.
In the previous screencast “Project Portfolio -- (Focus, focus, focus... you can't do it all -- Part A)” I described the process of project portfolio prioritization using constraints. Specifically, Cost and Risk factors to re-prioritize the portfolio. In this screencast called “Part B” I will show you the third constraint type using Resources. We’ll deal with the same problem statement, “How to prioritize projects based on a limitation of resources.” We need to select the best project mix to maximize benefit in order to meet our objectives.
Project Portfolio is a discussion of how to prioritize projects, when resources are finite and you need to select the best portfolio of projects to maximize benefit, or in other words, “Those projects that give you the biggest bang for the buck.” How do you prioritize projects when resources are finite?
