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.
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.
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.
Design Science, Inc.
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.
Post a Comment