The Parable of the IT Project

The Parable

A person had a problem, and asked a Project Manager to help.

Following a wise methodology, the Project Manager:

  • clarified the nature of the problem, and what a solution would look like;
  • defined the solution architecture, identifying the main parts and the relationship between them;
  • built only as much as was needed at each step;
  • created each unit and its test suite together;
  • used the experience of building to test, clarify and discover assumptions;
  • when assumptions changed, revisited and revised the unit, the architecture, the solution and the problem statement as required; and
  • continued building and testing and checking until the project was complete and the problem was solved.

The Thought

In the world of IT, we are talking about Agile software development.  But this approach to managing software development can usefully be applied to the rest of life, too.

All too often, when trying to solve a problem, we take the problem statement as a given.  But the problem statement we start with, like everything else we have, is only the best we could come up with at the time: it was helpful, it was probably good, but it was almost certainly not perfect.

When you have a non-trivial but solvable problem, there are four basic steps to the solution.

  1. State the problem - clearly and unambiguously, so you - and others - can recognize when it has been solved
  2. Describe the solution - say what is essential, what is desired, and what the constraints are; say what you want, not what you dislike or what you think should be done.
  3. Design a solution - identify the major aspects, and describe the relationship between them, define the interfaces.
  4. Build the solution - only build what is needed right now, and use the real world experience gained to test what has been build already, and the assumptions made along the way; change anything that needs changing, either in this step or any of the previous ones; ensure that what you build is tested quickly and easily - you want to find mistakes and weaknesses as early as possible.

It's not rocket science, but it is hard work.  In the real world, what usually happens is something like this...

  • Someone tells you he wants to get from A to B, so you design him a bicycle.
  • Then he says he needs to get there quickly, so you design a motorcycle.
  • Then he says he needs to take some boxes with him, so you add a trailer to the motorcycle.
  • Then he says he needs to bring his three children with him, so you design a motorcycle with trailer plus three smaller, three-wheeled motorbikes which can be programmed to automatically follow the bike in front.

Of course, if you knew the actual requirement at the outset, you would have designed a car.  But you start with a sensible plan, and with each new detail, you modify it to handle that new aspect.  You rarely go back, and re-think the plan in the light of the new information.  Of course not - it would take too much work, and it would create delays.

Whatever technology you are using to address the problem, what kills the solution is generally not the technology, but the way the problem (as it has been described to you) changes as you try to solve it.  The same process kept repeating, whether I was trying to build computer software or help drug addicts get clean and start a new life.

Whatever the project, there is never the time and money to do it right, but there is always the time and money to fix it when it is done wrong.  The problem (a problem, at least) is the eternal optimism of management: "This project is different - we understand the problem well enough, so we will get the solution right first time.  Promise!"


E-mail me when people leave their comments –

You need to be a member of Just Human? to add comments!

Join Just Human?


  • Absolutely right.  This parable is, I would say, quite apposite and relevant, showing what almost inevitably happens in any human endeavour despite appearing at the outset to have an well-defined problem with a widely-accepted solution.

    Ignore the "software development" details of the parable, which are there purely to add some window dressing, verisimilitude and to provide a degree of credibility,   The whole point of this fable is that, in the absence of perfect information and cast-iron mathematical certainty, even the best-laid plans can either go wrong - or arrive at a sub-optimal situation.    Throughout my career, problem requirements generally started as one thing and ended up as something usually very different - or the projects were cancelled part-way.  Human activities are always subject to revision.

    Curiously, the greater the apparent emerging success of the project, the greater the temptation for others to bend the project to make it do something even more exciting, eye-changing and credit-worthy.   At that point, an apparently successful project often takes on additional requirements - which can lead to failure.   if only the project had continued "under the radar" with modest expectations.   The wise manager never boasts too loudly - just enough to show that steady, careful progress is being made with deadlines being met and struggles being overcome.

  • The Parable is about Computer Software; the Thought is about people and their problems. 

    The difference is that IT software is logical; people aren't. An IT solution works for all systems of the same type; people show much greater variation, they all want different things, some people don't want the problem solved at all, and people don't even agree that there is a problem in the first place. IT doesn't mind being told what to do; people do, even if the solution is a logically reasonable (wear masks during a pandemic; dont' carry guns in public). 

    • Adrian,

      Yes: the 'Parable' is about computer software, while the 'Thought' is about people and their problems.  Computer software is about people and their problems, and software development - what the 'Parable' is about - is especially about people and their problems.  In 20 years of software development, I only hit two techincal problems (and one of them was only a problem because of stupid and short-sighted management decisions) - all the other challenges were to do with the people.

      Remind me to tell you some time about when my father tried to save a multi-million pound software development project which turned into a national fiasco...


This reply was deleted.