stty consulting › our future

How to Build Your Own White Elephant

(that's pink)

Why would anyone want to build something that they never wanted or a product that doesn't do the very things they wanted it to? Well it seems a crazy question to ask but on the surface it appears that we can see there is a problem. So why when you read the plethora of trade magazine, and increasingly mainstream press, there is a seemingly endless supply of projects that are failing or have utterly failed.

When I mentioned that in my opinion too many projects I was asked "Where do you start?". "Exactly!" I replied and that is where things go wrong. It is the first few steps of any project that define the outcome.

Just imagine that you are buying a new car, do you draw up a list of criteria that will define the prefect car. If we that this analogy further, we have gone to the 'car supermarket' and when asked what we are looking for, we respond with "A green one". Now, if we all close our I eyes and think of a green car I can expect a wide variety of different makes, models, and shades of green not mention the other options 2 door, 4 door, convertible, sports car, hatchback, etc.

Many of you may say people aren't that stupid. Sorry to tell you throughout my working life so far I have been involved in many projects were the objects or desired outcomes were as ambiguous as 'make it more efficient'. I can highlight this with an example which left me not knowing whether I should laugh or cry, or in fact try to hide my utter disbelief. The Financial Director at a Medical Equipment Manufacture during a review meeting were I was explain that we must have the business more clearly define their requirements in project specifications, angrily told me that "People don't know what they want until they see it!". I would have accepted the statement if we had been discussing the previous analogy, but we were talking about the development of a non-stock purchasing system.

The development team were becoming increasingly despondent as the goals of the project moved at the whim of any member of the Supply Chain team. The Development Manager during yet another uncomfortable project meeting was told when stating that he had supplied the deliverable that had been agreed was told that the extra functionality had "been implied". As you can understand the project ran widely late, over budget and never really addressed the fundamental issues it should have done.


Relations between the Customer and the Project Manager/ Design team are sometimes marred by the former saying, in effect,"I cannot tell you what I want but I will know it when I see it".

All too often the same old thought patterns emerge:

  • You get what you pay for.
  • They are a set of 'cowboys'.
  • You have been ripped-off.
  • It's the developers fault
  • The Project Manager has to go.

If you have read this far you may feel that this is no more that a lengthy rant, well you are mistaken. I am trying to highlight the very definite need to have a good project specification / brief before you start.


All good literature relating to Project Management will tell you that a project spec should be complete, relevant, unambiguous, adequate, and consistent.

Completeness
It is essential for the spec to be specific, as far as possible nothing should be left to the discretion of the reader. At the beginning of a project this is usually owing to a lack of imagination or communication skills. In the later stages of the writing, the sheer mass of detail could become a major factor.

Relevance
It is useless to define something that is already available in a different format but in a standard form. Part of the creation of the spec should focus on the wasting of resources reinventing the wheel.

Unambiguousness
Relations between the Customer and the Project Manager/ Design team are sometimes marred by the former saying, in effect,"I cannot tell you what I want but I will know it when I see it". In order to define a contract the spec the customer need to clarify their ideas.

Adequacy
If the spec is only sufficient to meet the true need of the circumstances the relationship between the cost and performance may never be established.

Consistency
A spec includes several separate requirements which are to be satisfied simultaneously. This can only be achieved if they are not mutually exclusive.