Tom Gilb - Why 'Value Planning' is Important to You.

Poprosiliśmy naszych przyjaciół i współpracowników o przygotowanie artykułu mówiącego, dlaczego tematy, o których uczą są ważne. W zeszłym miesiącu opublikowaliśmy artykuł Mary Poppendieck na temat Lean. Kontynuujemy naszą serię artykułem Toma Gilba na temat dostarczania Wartości.

Tom Gilb - Why 'Value Planning' is Important to You.

Value Planning is a set of open and free tools for planning any projects, especially IT projects. Value Planning is a mind shift for IT people today, who are unfortunately focused on 'delivering code', not on delivering real measurable value to their stakeholders.

Why these knowledge and skills are important?

All projects are based on the idea of delivering value to some stakeholders. Building technology, like software, is not sufficient (or necessary!) for delivering value.

We are not thinking merely of financial value: we are thinking of any set of human values that various key stakeholders really want: this includes things like health, happiness, trustworthiness, image, reputation, environment, future employment growth, better education, family values, organizational responsiveness, value for money, political transparency, and very many other such things.

To achieve these value deliveries, we need to turn our focus towards the values themselves, and not merely the strategies which we hope will deliver the values. Strategies and architecture, the means to the ends, can fail. We need to focus primarily on our ends, our real values.

There is only one basic requirement for managing values: we need to quantify, measure, track, and be responsible for those values. Quantified responsibility. This implies an engineering culture: value engineering.

What problems do you have right now, that you cannot solve?


You need to systematically identify all the dozens of critical stakeholders involved. You need to analyze and identify their values, quantitatively.

Value Quantification

You need to know how to turn the stakeholders value ideas, like ‘much easier to use’, into unambiguously clear levels of deliverable value. For example:

Scale: time needed to successfully complete Task X, by Employee type Z.
Goal [Within 1 year]  less than 5 minutes.

It is our understanding that absolutely all value improvements can be expressed quantitatively. NO exceptions. There are several methods to do this. But you only have to Google the values you are interested in, to find many others who have achieved quantification of those values.

Management Bullshit is not necessary: not as input to a serious IT project.  That is just 'bad business analysis' if it happens. As it unfortunately normally does.

Strategy Value Impact Management

All solution ideas, all ‘means’, about how we are going to achieve the set of values within our resources can be quantified, estimated and measured, as we try them out.

All suggested means need the following systematic analysis, before we commit time and effort to using them:

  1. What are the main expected impacts of these means on all of our critical ends?
  2. What is the evidence and source of such value impact estimates?
  3. What is the level of uncertainty (±%) of such estimates. The risk they will be better or worse?
  4. How can we pilot or trial the suggested means, in a short time (a week or month), and measure the results and costs, before we commit to them on a larger scale?
  5. If the means do not work as expected, what alternatives can we rapidly try out.

Value Decomposition

In large IT projects, for example Government projects, there are usually some big ideas, ‘architecture’ that we hope will give value in the long run.

Too often, we assume the architectures, or ‘strategies’ will work, and we invest a lot of money and time implementing them. And they fail: far too often.

We need to solve this problem (big ideas that don’t actually work well) by systematically decomposing them into much smaller (1/50th for example, a month, rather than 3 years) deliverable increments. These increments can be tested and measured, before we ramp up incrementally, not all at once ever.

But most people have no methods, experience, or training in decomposition of such ideas. We are talking about 'decomposition by value', not conventional 'decomposition by construction steps'.

We have about 2 dozen teachable principles of decomposition, that most people need to learn, and to practice. Without these principles, we find smart people are in 'denial'. They claim that Strategy X 'cannot be decomposed at all'. They are wrong. They admit that later. But they just do not know how to decompose.

One powerful method we use for decomposition is an Impact Estimation table, which for the 10 top-level value-objectives, and 10 major strategies, give a decomposition of value of 100 to 1. You can see where potentially high value is waiting for you. But you will need to learn how to do value impact estimation, and how to build such a table. And you have not learned it yet, have you?

Value Prioritization

Decomposition by small value delivery steps gives us the opportunity to select the best possible value for early delivery. This sets up a flow for value increments to the stakeholders.

But management needs to decide on this policy (high value increments first). Right now there is usually no such policy. Management has not asked for it, and you have not offered it.

Value Risk Management

We are obviously very bad at managing risk of project and system failure. Google for 'failed IT Projects'. Roughly half of all projects are total failure, and most of the other half are some kind of disappointment.

We have hinted in the above text, about some of the tactics we can teach for managing risks: for making sure you deliver a continuous stream of value, thus succeeding in the eyes of the stakeholders.

Projects and companies that use our methods do not EVER have large failed projects. They just have a stream of improvements. The largest failure they can experience is a small increment, for example week or month, 2% of budget or time, where a trial or pilot fails to give good enough results. This of course needs to be fixed with a real value-delivery, immediately. It is not even classified as a failure: it is a success in proving that someone’s bad idea does not work; and must be changed, replaced and NOT scaled up.

Because our value delivery steps are very small (by conscious clever value decomposition) they are more transparent, initially. And we therefore normally get them right, or right enough the first time.


What is the most important thing you should know / do, that would help you in what you do?

You need to focus on genuine measurable value. Value that your project sponsors understand and appreciate.

You need to focus on delivering that value - measurably. early, frequently and continuously.

Take responsibility for delivering those values that stakeholders really appreciate. No excuses, no shifting blame to anyone else. Find ways. Be imaginative. Be holistic.

No excuses. Learn to do it. Or you will fail.

How you can achieve amazing things?

Here are some of the things we teach, and do, which ‘amaze’ people.

We have learned to measure the quality of any document or specification. To measure its intelligibility. Then to reject the normally 'bad' stuff. Especially requirements. And then to get people to teach themselves how to get their work ten times, later over 100 times better measurably. We have done this in large corporations with hundreds and thousands of employees (like Boeing) over periods of weeks, one value-improvement week after another. This discipline is called Specification Quality Control.

We have learned to take absolutely any requirement or objective for value improvement: things like 'enhance customer trust', or 'making the process far more flexible', and we have quantified what people mean and what they want. Quantifying the 'Unquantifiable' we call it. This really amazes people. And we then teach them how to do it for themselves, same day, same hour. This is an amazing breakthrough in human communication.

We have learned to estimate any number (like 10 or more) of the expected values that we expect to get from any strategy or architecture. This is called 'Impact Estimation Tables'. This is a method we invented ourselves. This gives an amazing overview of any plans, strategies or designs for any project. But most people never do this and do not know how. The result is that they adopt strategies, ideas, and architectures 'blindly'. They hope for the best. Then they are severely disappointed in the results. But they do not even know what really hit them (ignorance and arrogance). They then blame any convenient reason for failure, like other people, or 'complex wicked system'.  The amazing thing is that a useful draft of these strategy impacts can be made in a day or less. We did this for the US Department of Defence, and the Commanding General immediately told us it was the best planning method he had ever seen. He was amazed and he acted on his perception in practice.

We have trained a small (60 person, 8 year old international business) in a single day in our methods (Evolutionary Value Delivery: Evo) and they started producing 25 measurable value improvements with their product, a week later, and every week thereafter for 12 weeks before releasing the results worldwide. They then repeated this cycle for many years to this day. They got such superior product quality that they took all business from competitors and wiped out their competitors. They felt that was so amazing that 13 years later they still credit our methods for their success (Confirmit,com, change led by Trond Johansen) in public website blogs. They  were very smart young engineers, so they knew great methods when they saw them, and they made them work amazingly.

One day of training for one exceptional person (Erik Simmons) and persistent teaching and consulting internally at Intel in our methods, over 15 years, has led to over 20,000 Intel engineers being voluntarily trained in our methods, and using them to plan their products. That is amazing. Erik has a simple and humble explanation: ‘this stuff works’.

How you can make your life / team / company better?

Be the person who helps your company, and their clients ,really understand their real values: and can make them quantified - thus 'manageable in practice'.

Be the person who champions real and useful change in the way people plan and manage their work. But you need to lead by example, and work hard for years to make real change. Good ideas are half the battle. Persistent long term change effort is the necessary thing to make you a battle hero. But we will arm you with the winning ideas and tools to start becoming a hero.

So, first you need to learn the 'secret methods': we will help you there. Then you need to try them out quietly on your own work, to gain experience and mastery. Then you can start the really hard work of spreading the ideas to other people.

About Tom Gilb

Tom is the author of nine books, and hundreds of papers on these and related subjects. His latest book Competitive Engineering is a substantial definition of requirements ideas.

In the 80s, Tom helped IBM establish pioneering methods in quantifying Qualities. His methods have been widely and successfully adopted by startups, charities, and large companies such as Intel, IBM, HP, Boeing, Ericsson, and Credit Suisse.

Since 2011 ProCognita regularly invites Tom, together with Kai Gilb to visiting Poland and provide talks and courses on the methods they have developed over decades of practice all over the world in both small companies and projects, as well as in the largest companies and projects.