In ISV businesses, the cost of an average man-hour C (including all direct and indirect expenditures) is below the hourly rate charged to the customers P. The ratio M=P/C defines the profit margin used as a buffer to compensate for failed projects, and for investitions into new products and services.

When a software project with a fixed budget B starts, two expenditure checkpoints can be defined: the target expenditures, equal to B/M; and the breakeven expenditures, equal to B minus the cost of cancelling the project.

When the project passes the target expenditures checkpoint, it is declared over-budget. It doesn’t generate a loss yet, but its profit margin is decreasing every day. Management pays additional attention to the project. No change requests are accepted free of charge any more. The team is clearly aware of being over-budget and starts cutting edges whenever possible.

If the project approaches the breakeven checkpoint, the management would examine the situation in terms of penalties and other consequences of a failed project, and cancel the project eventually to minimize losses.

Tracking of expenditures as well as escalation of the project status don’t require a (software) process per se; they are basic project management activities similar to typing C# code or creating an image in Photoshop. Just like with C# and PSD, you just need an adequate software tool to do that.

But, because the span between target and breakeven checkpoints is typically not that large, and escalating the project only after passing the target checkpoint is often too late, it is important to be able to predict the final expenditures as soon as possible. In the simplest case, you take total expenditures up to the current date and divide them by current project readiness in percent.

Software processes promise an easy tracking of the current project readyness. In the waterfall, there are stages of the life cycle. They can be estimated separately, and knowing on which stage you are will give you a rough readyness percent. In Agile, you have more granular and realistic estimation, by dividing finished (=tested and deployed and accepted by the customer) user stories by the total number of the stories.

This all sounds great. But, it is still a bad idea forcing workgroups to follow some pre-defined process to organize readiness tracking.

Sometimes, a project consists from several stages or milestones, which are delivered to the user consequently, so it is possible to employ the waterfall method of the estimation to get the rough numbers. But it is not always the case.

Sometimes, usable user stories are already defined (for other purposes), so using them for tracking is a natural way. But, there are also projects containing only one or two user stories, or projects, where there is a high amount of work that cannot be expressed in user stories.

Besides, individuals in the workgroup may have idiosyncrasies against particular user story tools or formats, or be willing to try out new and better tools. When a highly educated (and likewise highly paid) professional finds some particular project management software not fitting to his project, his workgroup, or his working style, forcing him to use the “corporate-standard” tools anyway would decrease efficiency of operations, not increase it.

Finally, no matter how the readiness estimation is calculated, individuals may want to adjust it using their intuition, to account for possible surprises from technology, workgroup members, or the customer.

Another question is how often the readiness should be estimated.

Obviously, polling it periodically is the simplest solution, but not always effective one. In some projects, there are times when the readiness estimation can flip from “cautionally optimistic” to “catastrophic” within one day, and correcting measures are required immediately. There are also times, when the project’s risk level doesn’t change for weeks and months.

Another approach can be an event based readyness estimation, performed every time a workgroup member detects a bigger problem.

Also in this case, defining a one-size-fits-all solution (a corporate process for readiness estimation and expenditures prediction) would lead to lesser efficiency of operations. Transferring responsibility for an adequate project tracking to the workgroup members, educating them about reasons and possible methods of doing it, and providing them with all necessary tools and time, would reduce the tracking overhead to its minimum.

Part 2 of series on Software Process

Part 4 of series on Software Process