Introduction

Once again, let’s acknowledge that modelling new processes is a much more risky business than modelling an existing process.  Why, you may ask?  The fundamental reason is our human desire to gild the lily.  When a building, bridge, vehicle or other physical object is being designed, we have the same tendencies – the first sketches of a new engineering project are often far more grand and extensive than the final construction.

Concrete versus Software

In “concrete” construction, we have simple methods which help to keep our feet firmly on the ground.  Construction is a well-known and well understood field.  If we are using 6,000 cubic metres of concrete, we can easily work out the cost for manufacture, delivery and placement.  The cost of formwork is easy to calculate, and the people who place it work for known rates of pay.  Estimating the cost of an engineering project is a comparatively easy thing, and detailed designs are required for projects to proceed.  Jesus once described estimating for such projects as “counting the cost”[1] and we can only count things we know about.  Planning and design allow us to count the cost.

But what is the cost of a database table?  What is the cost of one extra column?  Is a foreign key column more expensive than a simple integer column?  How much does it cost to include a not-null constraint?

This is the nub of the problem of modelling new processes.  Nothing but hanging on to your good sense can keep your feet on the ground.  Nothing but the consistent application of the same estimating techniques that are used by the fields of “concrete” engineering can protect you from pricing by guesswork.  And pricing by guesswork is about as likely to be successful as relying on winning a lottery.

So how do we go about it and expect to be successful?

Projects with a foundation in software are less clearly defined for at least three reasons:

  • The cost of the components of software is often very close to nothing.  It is the cost of production that matters.
  • Software specifications are often far too vague.  An extreme example I know of said that the required software: “must have a SimCity-like interface”.
  • With a non-tangible product, working in an area where tools and methodologies change so quickly, it is hard to tie people down to a fixed design.  After all, who wants to own a boring old Corolla when everyone is talking about a brand-new Tesla?

Meeting of the Minds

When modelling a new process, the sky is the limit.  There is no pre-existing work process, no fixed expectations, no opportunity for defining measurable improvement.  All too often, the vendor pictures a Corolla and the purchaser pictures a Tesla, while the specification could reasonably describe either.

A contract is meant to include a meeting of the minds of those involved, and this is the fundamental requirement for a project to be successful.  Avoid the Corolla/Tesla misunderstanding at all costs.

Rule: Make sure both vendor and customer have the same expectations: aim for the same type of car.

Many years ago, an engineer told me his method for improving the success rate of software projects: write the user manual first.  This may be overkill in a small project, but take it as far as you can, including screen shots, use cases, menu layouts – anything that will help to achieve a real meeting of the minds.

Observation: If vendor and customer do not have a shared understanding of the work, at least one of them will be disappointed – normally both.

 

[1] Luke 14:28-30