On Project Economics

I visited the easyFair convention at the Swedish Exhibition Centre in Gothenburg today. I found three different vendors who sold project management software. All three products had functions for tracking the cost of a project. This isn't surprising of course. What I found interesting is that all three products used the same economic model to do it, and that model is wrong.

Huh? How can that be possible? It is not as strange as it sounds. All three products had functions for tracking the hours worked by each project member, multiply it with the hourly cost, and sum the costs for all project members, like this:

project cost = Σ(cost/hour * hours)

A simple formula, but there is something missing. Try this one instead:

project cost = Σ(cost/hour * hours) - profit

The profit here is what the customer earns from getting frequent partial deliveries during the course of the project. (It's not the total profit from the project. Oh, how I wish for MathML support in more browsers.)

In a waterfall style project, with a single delivery at the end of the project, the profit will be 0, because the software won't be used until the project is over. On the other hand, in an iterative project with frequent deliveries, such as an XP, Scrum, or FDD project, the profit may be substantial. In some cases the profit is higher than the cost of development, which means a project pays for itself even before it is finished. (I won't go into the details of how to do a Cost/Benefit analysis here.)

The problem is that by focusing only on the costs, a project manager, and other stakeholders, get a flawed view of the economic viability of a project. This is bad because it is economics that drive project decisions.

Should we add more people? Should the project be cancelled? Should we reduce the project staff? Where should we focus our efforts? The decisions are all heavily influenced by the economic model of the project.

For example, if a project can make a delivery every two months, it may be worth while, but if the deliveries are every four months, it may not be. With this information at hand, a project manager can take measures to shorten the delivery cycle, for example:
  • Reduce the size of use cases (for example by splitting large ones into smaller ones) to reduce batch sizes.
  • Make sure to use developers that know how to write unit tests, to ensure that the software is more stable during development.
  • Use automated builds and testing.
  • Prioritize features so that the most important ones (from the customer's perspective) are tackled during the first iterations.
  • Reduce iteration length to get better control of the state of the system.
etc., etc.

With a flawed economic model as the basis for decisions, the wrong decisions will be made. If a flawed model is built into the management tools, it becomes very hard to detect it. Most project managers I know just trust the tools.

Comments

Anonymous said…
When you say you wish for MathML support in more browsers, which ones are you thinking of? Just in case you don't know, our free MathPlayer plugin does the job for Internet Explorer for Windows. See MathPlayer.

IMHO, the main browser missing MathML support is Safari. We've offered to provide a MathPlayer for Safari as free download as we do for IE if they add a strong enough plugin interface. So far they haven't taken us up on the offer.

Paul Topping
Design Science, Inc.
January 25, 2006 2:23 AM
Kallokain said…
What I was lamenting was that if I had included the equations in the text in MathML format, most people would not be able to view them properly in their browsers. (Rereading the posting, I realise that I did not express myself very clearly.)

It is great that MathML plugins are available, but it is not enough to make MathML ubiquituos. Users must know about them, and be able to find and download them, or the browser must do this automatically.

As an author, I don't dare rely on readers knowledge of plugins. If I do that, I'll loose readers. (Hardy souls willing to put up with my writing on a regular basis are probably difficult to find as it is.)

Since I do have an interest in rendering equations in browsers, I will give MathPlayer a try.
January 25, 2006 6:54 PM
Post a Comment

Popular posts from this blog

Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?

Image
The major software methodology wars since the mid 1950’s. Someone was wrong on the Internet, so here we go… In a recent HBR article, It’s Time to End the Battle Between Waterfall and Agile , the author sets up a false premise: There is a war between Waterfall methodology and Agile. The war must end. And finally, you can combine the approaches to get the best of both worlds. This sounds good, but the article is based on a misunderstanding of both Waterfall and Agile. Also, there is no war between Waterfall methodology and Agile. There can’t be, because Waterfall methodology does not exist! Waterfall is a name for large projects that failed in the 1960’s. Waterfall was never a methodology, but a failure to apply the methodologies that existed back then. As I will show towards the end of this article, at least one of the “successful” Waterfall projects mentioned in the HBR article was neither successful, nor a Waterfall project. I got invaluable help from Alistair Cockburn. He fact che
Read more

Performance Evaluations, Business Strategy, and Agile Methodologies

Image
It is performance evaluation time in many companies. This can be stressful, both to the people being evaluated, and the people doing the evaluation. In companies adopting agile software development methods, the tension can be extraordinary. Individual performance evaluations run counter to agile philosophy, which emphasizes team performance over individual performance. However, managers and corporate leaders need to take a few steps back, and consider the impact performance evaluations have on the organization as a whole. Especially now, in the midst of a recession, it is important to look at a companies current policies to see if they can be improved, or if they are actually holding the company back. So, how can a manager evaluate policy? Performance evaluation policies can serve as an excellent example. I'll confine myself to discussing the so-called ‘rank and yank’ methods. These are performance reviews were employees are ranked using a forced ranking system. It usually looks so
Read more

Agile Requirements Structures, Part 1

Image
If you have worked in large Agile projects or programs, you may have noticed that there is often quite a bit of confusion about requirements, what the requirement types are, their purpose, how to write them, how to use them, and above all, what not to do with them. There are many causes for this confusion. Here are some of the more common I have seen: Nobody in the organization has read up on the requirements model it is using, so everyone makes their own interpretation. The organization deviates from a standard requirements model, but nobody knows which standard model the organization is deviating from, and/or there is no agreement about how they deviate from it. The organization has not documented its own requirements model very well. The organization mixes two or more different requirements models, often without realizing it. The organization has documented its requirements model, but finding the documentation is an epic project in itself, on par with when Henry Sta
Read more