Budget overrun or estimation deficit

The messages about budget overrun by IT projects are becoming more frequent again. Usually the tone is that IT projects are just runaway trains and that budget overrun is something that we just have to live with. An important source of this type of messages is the CHAOS series of reports that are carried out annually by Standish. In most of these types of reports one important aspect is systematically overlooked and that is the quality of the original estimate the project started with.

The best way to estimate the cost of IT services

Every now and again I get involved in discussions about what is the best way to estimate the cost of IT services. Should you have a dedicated calculation team that makes all the cost estimates, or should you train the whole project management community and all senior delivery staff to make good cost estimates. It is a question I have been struggling with for the past decade.

The best answer is: It depends. But there are some universal truths on this subject:

1. One estimate is no estimate
2. An estimate always contains uncertainty
3. Don't mix a cost estimate with a price offering

 

A cost model for software in capital projects

A growing number of capital projects, like a motorway tunnel or a specialised MRI scanner, needs software to make it a useful investment. To determine the investments in time, money and resources a number of key cost-drivers is essential:

• Delivery schedule
• Productivity
• Size of the software
• Required resource effort
• Quality

Each of these key cost-drivers has its own merits that should be taken into account to make the right decisions on how to integrate software in capital projects.

Estimating the Functional Size of Oracle eBS applications

For custom developed software functional size estimation method can be done with reasonable accuracy. I have developed an approach, based on NESMA function points, that has proven to be very useful for portfolio sizing.

Estimating the functional size of applications that were built in the Oracle e-Business Suite (eBS) package appeared to be difficult. Available eBS modules contain of a huge amount of functionality that can be used to configure or construct desired functionality for the end-users. But how do you determine the amount of functionality that is available to the end-user?

Factors of influence for approximate COSMIC size measurement

Over the last few weeks I have received much more requests than usual from fellow metrics professionals if I can provide a copy of an article I have written. I have recently discovered that LinkedIn now has the possibility to add publications to my profile. So when I received a request for a copy of the article

Approximate size measurement with the COSMIC method - Factors of influence



that I wrote, together with Theo Prins, for the SMEF 2007 conference, I put that copy on my LinkedIn profile. And it has been downloaded more than a dozen times already. Apparently it is a topic of interest. Why?

Successful outsourcing begins with a contract

Contracts are the key to successful outsourcing. If you don’t define what is being measured for success, or what the expectations are, then you are only asking for trouble with misunderstandings. Where one person might determine an “incident” to be changing a password another might not. How important do you think good contracts are to successful outsourcing? Has the wording in contracts had an impact in projects you’ve been involved with?

Contracts can also be terrific places to create incentives to deliver great quality or beat schedules, by offering bonuses and other inducements. For example, in maintenance agreements it can be a great idea to pay bonuses for smaller number of over-all incidents rather than pay on a per-incident basis. If developers are getting paid for fewer hours worked, it is in their interests to build things right the first time and to take steps to reduce the number of support issues that could arise.

Scope Management : A case that sailed the seas of change

We all hear stories about failed IT projects and how hard it is to manage those projects properly. But we hardly hear why those projects failed. Many IT projects fail because they had to live up to unrealistic expectations. A lot of research has been done about the dynamics of software projects and a great deal about the dynamic behaviour of software projects is already known. All too often we do not use this knowledge and all too often succeeding software projects goes wrong. With the northernSCOPE approach we are able to manage the scope of a software project by making sensible use of experience from the past and what research has taught us about the dynamic behaviour of software projects.

In 2008 I have written a paper that I presented at the SMEF conference that describes the journey of a project across the seas of change, all the way from idea to implementation. In this paper I demonstrate that northernSCOPE is not a complicated academic endeavour, but a straightforward, down-to-earth approach that helps the project manager manage the scope of a software project the same way explorers like Columbus managed their journeys into the unknown.

For each of the twelve steps of the northernSCOPE approach the practical steps that have been taken to navigate the project out of possible danger zones are described. For each step the underlying theory is translated to practical use to the project manager and his customer. Each time the project ran into new requests that were out of scope or added new requirements or constraints to the project, the northernSCOPE approach was used to demonstrate the effect of giving in to these new requirements and of not giving in. It is not a story of a great success with a textbook project, but that of a project that could prove all along the way to deliver value for money for the customer.