A Theory of Project Costs

Note: This post is over a year old and the content may no longer be accurate.

Lately I’ve been giving a lot of though to the way costs for projects are estimated. It always seems a very hit and miss affair. One designer I used to work with used to work out the costs as accurately as he could and then double whatever number he came up with – this worked as well as anything – and fairly accurately reflected the time / cost of what he was doing.

I think a lot of the problem is to do with the way projects scale – a £10,000 project is not necessarily 10 x more complex than a £1000 project, but more importantly it is far easier to scope a static webpage with 10 pages and a contact form than website where the client guidance goes something along the lines of we want it to be a bit like Facebook {edit as applicable} but aimed at Pig Farmers {edit as applicable}.

The trouble with building complex applications is that it is often hard (if not impossible) to anticipate problems until you come across them. I suppose this has a lot to do with the rise Agile Development – using it as a way of getting away from specifications that often rapidly loose any relationship to the project they define.

Development is really an evolutionary affair and clients will change their minds in response to what they see – but God is (as they say) in the details – and it is often genuinely not possible to know how a project will go once it starts to take shape. Good project management I suppose the art of reconciling these evolutionary forces with budgets, clients and what is actually possible.

Right now in my current job I don’t really have any say in how projects are costed – and they are costed as well as anywhere else I have ever worked – which is to say as accurately as possible – but of course I have to work with budgets and liaise with clients over all the technical nitty-gritty – so I have lots of time to observe.

My current theory goes something along these lines (BTW all figures are just made up)

c = minimum cost
t = cost per database table
i = number of database tables

total cost = c + (t x i)

BUT this isn’t right yet there a number of additional factors that I am trying to work into the equation so far I have:

p = Client Knowledge – an overly knowledgeable client cause as much trouble as an IT somebody who is IT illiterate – ideally we need somebody who understands what you tell and has ideas of their own but can also understand advice.

z = a factor to fine tune t x i

For Example: if i = 10 then the total cost might work out as 1 x (t x i) but if i = 60 then total cost = 0.7 x (t x i)

I wonder what ever happened to my old graphics calculator…

To be continued…