September 6, 2012

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.

August 24, 2012

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

 

May 31, 2012

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.

March 23, 2012

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?

March 18, 2012

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


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?

January 9, 2012

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.

January 2, 2012

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.