A case against detailed plans


While for now am not as active in the software consulting game. I have been there enough to come across the perils of overrefined plans. This issue primarily has come up as an artefact of how most westernized countries do work, through contracts.

A contract is a binding agreement between two or more persons or parties; especially :one legally enforceable

Now contracts and especially written ones are great, they have certainly played a key role in the formation of the economy as we know it. Yet their traditional use as loss prevention tools doesn’t auger very well with what we now know about software development.

What you find is the client what everything to be developed in written form and in great detail at while at it.

This is a bad idea. In this entry, let’s look at why detailed contract and detailed plans, in general, are a bad idea.

The future will likely turn out differently.

The art of predicting the future has a long and time honoured tradition of being dead wrong. Matt Nauvak has an extensive library of predictions made in the past and how they turned out.

The problem is when we think about the future, we simply imagine what we know today but in an exaggerated format. For example, the client imagines the application will have to handle thousands of query requests from sales managers who are looking to better understand their customers. This feature may be based on another plan to capture user activity within the application.

All this is well and good until we realize nobody wants to login to use the application and we now need to pivot! So there is no data to be showed on the beautiful dashboards to be used by the salespeople. Some time wasted, but still all good, the real problem comes six months later when the client once more wants their dashboard. You remind them you had a meeting and decided to pivot, they, of course, proceed to remind you meeting notes are not binding, contracts are!

I thus urge you, no matter how certain you feel about the project, bake within the agreement the provision things will change.

Decisions should be made at the last responsible moment

My personality registers as INTJ. One of our key strengths is the ability to make decisions quickly, as you already guessed it, this is also a weakness.

Plans are great because you are able to constrain the range of possible options and get everyone focused on one path. Swahili’s have a saying:

Kuishi kwingi kuona mengi

Roughly translated:

To live a long time is to see a lot of things.

This rings true in software. As your product unfolds more information comes to the foreground as assumptions get tested in the crucible of reality.

It would be terrible to ignore your insights because the plan you made one year ago is in contradiction to them.

Plans fail in highly dynamic environment

Homogeneity is great for some types of work. This tends to happen in routine types of businesses. To give an example, imagine the work of building an estate with fifty apartments all of the same design. There will likely be some surprises in the first few houses, but after that, you can make fairly detailed plans to take the remaining houses to completion.

Now imagine a software project, even if you were CTO at a successful startup say Stripe, if you then started your own business say Airbnb, you would still be encountering surprises every day. In fact, even if you stayed at Stripe, new technology say bitcoin, would still keep presenting new and surprising information.

Fighter pilots have a term I particularly like. OODA

Observe Orient Decide Act

The world changes, OODA loop makes sure we don’t stay stuck with our plans which are now irrelevant.

Avoid the trap of elegance

A common misconception is we love our children and that is why we give up so much for them. In reality, we actually love them because of all we have given up for them. Think about the concept of sunk cost fallacy.

Sunk cost fallacy: The idea that a company or organization is more likely to continue with a project if they have already invested a lot of money, time, or effort in it, even when continuing is not the best thing to do

Now, if you have ever been to a proper planning session, you know they can take entire days if not weeks. Once you have put in that kind of time, you generally don’t want to see it all go to waste. Your mind will play all kinds of tricks on you to ensure you stick to it.

Elegance is great, but as Reid Hoffman says:

If you are not embarrassed by the first version of your product, you’ve launched too late.

This is also true of plans if you put too much effort into your plans, its value is now lost.

Look through your own plans? Are any of them excessively detailed?  Talk to me in the comment section below or on my twitter @jchex




Published by


Software Project Manager