Excellent knowledge exchange on IT estimating

Last week I had the honour of presenting the opening keynote on the Galorath Conference. Although organised by a vendor of Cost Estimating Software it was an excellent and open knowledge exchange on IT estimating. The conference had a well balanced line-up of speakers who presented different pieces of the puzzle to estimate the cost of different aspects of IT cost estimation. All presentations should be available on the Galorath website soon, but here is my personal impression:


Estimating and Pricing of Application Management in Oracle EBS
Frank Vogelezang, Ordina
My opening keynote combined two topics that are both under discussion in both the IT estimating and in the Pricing communities.
The first one is the observation that Estimating and Pricing are two different disciplines, requiring a different skillset and a different mindset. Estimating is an engineering discipline that results in the best estimation of units (hours, devices, licences, CPU-cycles etc.) to create an IT solution or deliver an agreed level of services. Estimating is about mastering your own skills. Pricing is to offer the solution or service to a customer in such a way that the customer will choose my offer. This is all about knowing what the customer needs, what is important to him and what criteria he will use to choose the best offer. Pricing is all about knowing your customer. At Ordina we have developed a very simple model to keep everyone who is involved in creating a service offering focused on his role in the process.
The second one is about estimating Application Management. The first issue there is about the scope. Application Management can have a very different scope in various organisations. Therefore you need to have a flexible model to estimate Application Management. If you are doing Application Management on Oracle E-Business Suite implementations the challenge becomes a little bit more complicated, since the information we get to do the service offering is insufficient to use regular functional sizing metrics like COSMIC or FPA.
A more independent review of this talk can be found on Dan Galorath's Blog. More details can be found in an earlier blogpost.

The Technical Debt Challenge
Geert-Jan Waanders, CAST Software
CAST Software is specialised in the quality analysis of software. They do not only give analysis results of what aspects of your software are at risk, but they can also express their analysis in terms of technical debt. Technical debt is represented as the cost to repair all the parts of the software that create a risk in either the short run (like unhandled exceptions that can cause immediate crashes) or the long run (very complex code that is hard to maintain). Their software does not only analyse custom-built software in various languages, but can also analyse SAP, Siebel and PeopleSoft.
In the discussion another aspect that can be regarded as technical debt popped up: the innovation not done, or the backlog of enhancements awaiting implementation. For this aspect cost estimation tooling could complement the technical debt analysis.

Estimating SAP HR implementations in Lukoil
Ton Dekkers, Galorath Consulting
Implementing SAP HR in one of the worlds largest companies is a major project and so are the subsequent releases. Since the IT-department of Lukoil is now an independent company both the supplier and the customer wanted to have a solid estimating model for the SAP implementations.
For the size estimation the NESMA indicative approach was used. The result was challenged by creating a sizing proxy based on a keyword count of the documentation. This resulted in a size that could be used as an input to the cost estimation model.

Applied Cost Practices for Software Intensive Projects
Rene Berghuijs, NATO

The NATO Air Command And Control System (ACCS) is intended to combine, and automate at the tactical level the planning and tasking and execution of all air operations. The programme started in 1999 and when it is completed the IT cost (hardware and software) is estimated to have cost 1.5 billion Euro. To estimate the different components of the programme the Cost Estimating and Assessment Guide of the US Government Accountability Office is used as best practice. Since the programme is executed by a sole supplier a good cost estimating and assessment process is crucial to stay in control of the programme's cost. NATO's ACCS Management Agency (NACMA) estimates that their cost practices have saved the NATO budget several hundred million Euro.

Effort Estimation and Risk Management using the CoBRA Approach
Jens Heidrich, Fraunhofer Institute on Experimental Software Engineering
The CoBRA approach is hybrid model between the traditional expert estimation techniques that rely on human expertise and the data-driven parametric models like SEER that rely on experience data. In the CoBRA approach a tailored estimation model can be built for homogeneous groups of projects. In a way it is similar to the approach Ordina has used in building their Application Management model with the knowledge bases that are available within SEER IT. The CoBRA approach is more flexible by using causal models to link various cost drivers.

More Successful IT Projects through Estimation, Planning and Control
Dan Galorath, Galorath Incorporated
Dan was opening with the observation that humans are hardwired to be optimists. At the recent NESMA fall conference we had a presentation from Carolyn Mair about the psychology behind that. Dan's presentation was about the solution: temper the optimism with an outside view by using parametrics. It sounds very simple and from my personal experience I can confirm that in essence it is that simple. Implementing that solution into the way of working of IT companies is usually a demanding exercise. The rewards can be great though if you have proper estimation, planning and control in place.

Using Parametrics in Requests for Proposal
Harold van Heeringen, Sogeti
Customers can ask questions about the supplier's performance in a way that leaves room for interpretation. Both the customer and the supplier will use that room to their own effect. Quite often the result is an unsatisfied customer and a troublesome relationship. Both are unwanted effects and can be avoided if Requests for Proposal contain questions that use SMART defined parametrics.

How to Predict the Maintenance Effort for Software
Eric van der Vliet, Logica
One of the big differences between projects and maintenance contracts is that the latter category usually has a duration that you can observe a learning curve within a single contract. For a proper cost estimation this learning-curve must be part of the estimating process. One of the things Logica discovered was that the predefined values in the knowledge bases of SEER SEM corresponded well with the end situation of a maintenance contract. They identified a number of parameters that changed significantly over the years of the contract and could be used to model the learning-curve.
Their way of modelling the learning-curve, within Ordina affectionately referred to as the hockeystick, fit well of how we modeled corrective maintenance in our Application Management model.