Published

13

Sep

2018

Position Paper

Mapping #3 uncertainty driven project execution

Competition between companies is constantly getting fiercer and fiercer. Reduction of communication barriers (for both information exchange and physical cargo) has increased the speed at which products penetrate markets. 

Mapping #3 uncertainty driven project execution

At the same time, it has become far easier than at any time in history to win a market but also to lose it. Having good product ideas is no longer enough; one has to excel at project management, too.

Unfortunately, existing project management frameworks seem to focus mostly on getting things done on time, within budget and according to specification, and the most common way of dealing with obstacles is to leave some kind of margin, be it additional time for unforeseen challenges or a mechanism for limiting the scope of the project. Existing research, however, shows that those efforts are futile. Projects fail mostly because of unforeseen obstacles, which materialize as going over budget or deadlines, delivering product of poor quality or with broken functionality – and sometimes all of these simultaneously1.

What is more, a range of different surveys report that even the giants that should excel at conducting IT projects report only a 41 percent success rate2, and 17 percent of projects can go so badly it threatens the existence of the company3. And 75 percent of business and executives believe their projects are doomed from the start4.

This is definitely an area where we could and should improve.

The diagnosis

The internet is full of various reports trying to pin-point the root cause and offering ‘unique’ insights into the domain. However, all the existing approaches focus on deviation from the assumed project baseline and look for scapegoats without understanding that project management is a fundamentally misunderstood and misrepresented skill.

The traditional approach believes project management is part of widely understood ‘operations’, as opposed to ‘strategic decision making’. In other words, that there is a body within a company that sets the direction and it is the role of the rest of the company to follow that direction without hesitation. What is more, any failure to do so is considered to be caused by incompetence.

Decisions at so-called ‘strategic’ levels are always taken on incomplete or contradictory data, and very often on ‘gut feeling’. Therefore, setting a direction for a company often means taking the path that looks the most promising. The word ‘looks’ cannot be emphasized enough. Failure to assume not everything is known is a failure at a strategic level.

Figure 1: Yin and Yang - two forces creating a harmony

Figure 1: Yin and Yang - two forces creating a harmony

The implication we can draw from this is that project management is not a separate entity and it cannot be considered to be just an ‘operational’ tool. Project management, at its deepest meaning, is basically a framework for discovering and coping with the unknown.

What is more, the ‘coping’ part involves creating feedback for the ‘strategic’ part. As a result, strategy and operations influence each other to the point that they become one and the same. Thus it is necessary to change our perspective and look at the unforeseen obstacles not as things that break our plans but as things that we have failed to discover early enough.

The solution: a new approach

The approach recommended by LEF puts the focus on continuous learning, which involves a series of small, inexpensive experiments that reduce uncertainty and, in turn, nasty and expensive surprises. Of course, there are questions around estimating and planning for uncertainty. Can we prepare for things we do not know? If yes, how? The good news is that we can, at least to some extent, and below we will show how.

Divide and conquer

Divide your project into small, manageable chunks.”

Existing evidence shows that the bigger the project, the more likely it is to fail. The difference can be as big as ten-fold5; therefore the single, most impactful action you can take to improve your chances of success is to split your project into components that can be handled by small teams. A NATO technical report6 defines a small team as a team of no more than seven people, because larger groups suffer from internal conflicts and discords.

This phase is also a good opportunity for identifying components that could be a part of more than one solution. This can:

  1. Increase the amount of shared work within the company. Doing something once, but in a good way, is far more effective than doing something multiple times on the verge of acceptance.
  2. Increase your agility. Universal, stable and shared components do not limit your options. You still can pursue different directions at a reduced cost, which is extremely important if you expect unexpected things to pop up.

Dealing with uncertainty

Smaller projects are easier to handle because it is far easier to determine what the current state-of-the-art is and what challenges may arise. There are two fundamental ways of reducing unknowns, and the first one is good old planning.

A common misconception about planning is that its goal is to create a plan. This is not true. The plan is just a side effect of planning, and the greatest value lies in the underlying research done as part of the planning process. Planning is supposed to be a learning tool. Preparing a plan without deep understanding of the subject matter is mere wishful thinking. For this reason, any plans involving large projects have very small chance of success, because it is difficult if not impossible to take into account all the important factors.

Planning, however, is not a universal tool, because it requires some knowledge to be available in advance. Planning works well for things where there is past data to base it upon. Unfortunately, the more novel the desired component, the less useful planning is; therefore it must be combined with experimenting.

Remove uncertainty as soon as possible.

Experimenting is like reconnaissance by fire. It is a way of learning about things by doing things, and usually is quite expensive.

The general rule of uncertainty-driven project management is to use planning for components that can be planned, and use experimenting early in the process to remove potential deal-breakers as soon as possible. Failing fast and learning is way more beneficial than failing late.

This leads us to the conclusion that any project is best managed as a series of small learning actions that show whether doing something is (or is not) possible in the existing circumstances. We can even say that effective project management requires the most important learning projects to be executed first, as then it is possible to change/confirm the strategy early in the process. Thus the most useful skill is the ability to distinguish between components that should be planned upon and components that should be experimented upon.

Evolution to the rescue

We instinctively understand that all components, identified by the value they deliver, are created as something experimental and over time we get to know them better.

It is important to note that the potential value of a component includes the potential of the change; it contains all the improvements and discoveries that need to be made to enable that component. So components that have high potential value can be planned upon only in a very limited scope. They should be a subject to experimentation and creating proofs-of-concept.

Figure 2: When a component is created for the first time, it has low current value and usually a significant potential

Figure 2: When a component is created for the first time, it has

Over time, because the potential is always attractive, people and businesses try to exploit it, and through a series of experiments, they reduce the unknowns and most often increase the existing component value.

Figure 3: A mature component has been extensively tested in the past. It has low potential for changes and therefore is plannable upon

Figure 3: A mature component has been extensively tested in the past. It has low potential for changes and therefore is plannable upon

I think there is a world market for about five computers.
– Thomas J Watson, IBM’s president

Unfortunately, judging the potential value is a very challenging task, because it involves guessing all the unknowns. Without a working crystal ball, it is quite easy to make far-reaching mistakes.

Fortunately, LEF’s Simon Wardley has identified common component characteristics and their values that make it possible to estimate the amount of uncertainty based on easy-to-make observations. His table is shown in Figure 4.

Figure 4 – Cheat sheet showing how various attributes and characteristics can be translated into uncertainty and confidence

Figure 4 – Cheat sheet showing how various attributes and characteristics can be translated into uncertainty and confidence

The table in Figure 4 classifies characteristics at four main stages of evolution:

  • Stage I (Genesis) describes something very new and highly uncertain. These components usually are not used commercially, so it is necessary to assume they will change over time. Lack of prior experience and data makes planning impossible.
  • Stage II (Custom-built) describes components that are used commercially, but cannot yet be acquired from vendors. The uncertainty is still high, but there is some past data and experience, although in practice it can only be acquired by hiring field experts. Experimenting is still a primary tool of learning, although it may be possible to use external consultants.
  • Stage III (Product/Rental) describes components that are available off-the-shelf. The associated uncertainty is rather low, as wide usage makes introducing rapid changes difficult. Past usage data exists, and it is relatively easy to acquire. This is the first phase in which planning, not experimenting, is a primary learning tool.
  • Stage IV (Community/Utility) describes mature components with little-to-no uncertainty. Those components are so ubiquitous, and so many businesses use them, that they cannot change easily, if at all. There is lot of past usage data and previous experience, so planning is the default tool of learning, while experimenting means reinventing the wheel – it’s a waste of time.

With that knowledge, finding the right approach to a given component or assessing how much is unknown does not look difficult. Just a small warning: we, as humans, can get extremely biased, and therefore it is worth challenging our world perception. A component that seems to be highly uncertain to us may be a well-tested commodity for other people or branch industries.

Assembling it all together

So far, we have learned that splitting a large project into small components reduces the risk of that project; we have also learned how to determine the uncertainty of a component and how to choose the right approach for it. It is time to bring this knowledge together, and it will appear that project management starts far earlier than one would have thought – it starts when the project idea is first laid out.

Determine the value delivered by the project

This is the most essential and most basic step. What can projects on the table provide? How will they contribute to the value of your company? Is there a chance that the cost of those projects will be lower than the value they deliver by an acceptable margin?

Contrary to the first impression, there is quite a lot of work to be done here – not only have users to be identified, but also their needs, potential competitors and at least short-term dynamics; whether the market will grow in the upcoming years; whether the new assets will make it difficult for a company to change; and whether the competition is likely to jump in with a more efficient product. All these factors enable you to estimate what is the time window for the project life.

If you cannot identify these things, do not invest more than you can afford to gamble, as you will be gambling. You may end up with a spectacular success – or with a spectacular product flop.

Identify required components

Once you know what you do want to deliver, you may think of things you will need in order to deliver that value. For example, here is a simple analysis of components needed for two financial services projects:

Project I

Users/user needs: An e-commerce shop would like to know whether it can grant customers short-term credit, and therefore increase spur-of-the moment shopping.

Components:

  • e-commerce platform plugins
  • credit check API
  • credit score algorithm
  • relevant data sources, such as access to bank accounts
  • debt collecting services

Project II

Users/user needs: A wealthy customer with multiple bank accounts would like to know what his/her current money assets are and how they change over time.

Components:

  • mobile application with fancy UI and charts
  • aggregation algorithm
  • relevant data sources (access to bank accounts)

End your analysis when you find components that are not under your control and that you buy from your vendors.

These lists of words may be a little difficult to read, so you may prefer to draw a simple value chain to show components and their dependencies. One image is said to be worth a thousand words, and a graphical representation of the project also makes it easier to spot critical components that are missing. Figure 5 illustrates Projects I and II.

Figure 5 – Graphical map of project users, needs and components

Figure 5 – Graphical map of project users, needs and components

For a company considering these two products, it is immediately apparent that the component bank account access integration is shared, and therefore any investment in it will serve both projects.

Assess evolution level (and uncertainty)

This involves adding an additional axis to the value chain map to show the four stages of evolution, examining each component in the light of the cheat sheet (figure 4) and repositioning it on the map. The result is a Wardley Map7, as shown in Figures 6 and 7. Components on the left side of the Wardley Map (in the early stages of evolution) are associated with high levels of uncertainty, so it becomes obvious where the risks for each project are.

Figure 6 – Transition of the value chain to a Wardley Map for the Project I

Figure 6 – Transition of the value chain to a Wardley Map for the Project I

Figure 7 – Transition from the value chain to a Wardley Map for Project II

Figure 7 – Transition from the value chain to a Wardley Map for Project II

Write a learning plan

It might be that all of your projects look promising at the first glance. You have to decide what your organization’s risk appetite is. For example, when comparing the two projects illustrated above, if your appetite for risk is small, then you would have no option but to invest in Project II, as there is only the aggregation algorithm to be tested by experimenting, and doing so will prove that there is a point in investing in the other components and overall marketing.

On the other hand, if you can afford to experiment with multiple components, you can try out and prepare a working proof-of-concept for calculating a given user’s credit score (Project I). It will be way more expensive than Project II, but the rewards may be big enough to justify it, if you can afford the risk.

The point is that once you know where the uncertainties are, you can better judge your risks; and if an experiment fails (implying a project can’t be done), you can always jump back to other projects without losing too much.

Summary

The approach presented above is a tool for dealing with uncertainty, which is an institutional feature of modern business. Splitting projects into smaller chunks and focusing on efficient experimenting and rapid learning increases a company’s ability to select the right goals to pursue and limits wasted effort.

This is also an introduction to creating and managing business strategy with the help of Wardley Maps. In their full form, these can take into account not only what is within the company, but also the entire landscape of existing and potential competitors, and focus on delivering better value and faster than the competition, and disrupting competitors’ business, too. However, that full potential of mapping cannot be utilized unless one first masters dealing with uncertainty.

Mapping #3: Uncertainty-driven project execution.

download

1. https://thisiswhatgoodlookslike.com/2012/06/10/gartner-survey-shows-why-projects-fail/

2. http://www-935.ibm.com/services/us/gbs/bus/pdf/gbe03100-usen-03-making-change-work.pdf

3. https://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value

4. https://www.geneca.com/blog/software-project-failure-business-development

5. https://www.immagic.com/eLibrary/ARCHIVES/GENERAL/GENREF/S130301C.pdf

6. https://pdfs.semanticscholar.org/d9c3/e78fe82ac1fb6ac8a0375862caf06fbbb160.pdf

7. https://leadingedgeforum.com/advisory-service/wardley-maps/


Cookies

We use cookies to improve the user experience of our website. If you continue to browse, we'll assume you are happy for your web browser to receive all cookies from our website. See our cookies policy for more information on cookies and how to manage them.

Accept