Category Archives: estimating models

Overcome CHAOS with scope management...

“Don’t waste even one heartbeat on things that don’t matter.”  Anonymous

 This quotation should be the mantra of software development – if only we could figure out what “in the customer’s eyes” doesn’t matter!

The Standish Group’s 2009 CHAOS report certainly didn’t bring any celebratory words:  After steady increases from a dismal 17% project success rate in 1996 to the 34% (a doubling!) rate in 2006, this year’s study reported a decrease to a mere 32% of projects being declared a success.

 What’s going on? With 60-99% of defects attributable to poor requirements, and 45% of development effort spent on rework, it is clear that somehow the customer side of the house and the development side are out of whack.  Worldwide, we could declare software development as a problem of epidemic proportions – especially as software pervades every aspect of our daily lives.  If we can casually launch a team of scientists to fix an ailing space station on a moment’s notice, and announce medical breakthroughs, surely the brains in software development should make strides in this area.  Take rework for example, currently hovering at an astounding 40% of software development effort – this means that while we do great work Monday to Wednesday every week, the remaining two working days are spent fixing and redoing the very work we just completed. The old adage – “if you don’t have the time to do it right, when will you find the time to do it over?” —  doesn’t seem to hold much water does it when almost half of every week is spent doing costly rework?

Here’s the crux of the situation – it’s not a matter of incompetence!  It’s a matter of the customers not being able to fully articulate what they actually need – and a matter of the suppliers not being able to deliver to requirements that are as sketchy as clouds.  BUT, there’s a solution that’s been successful in Finland and Australia called Scope Management – and I’ve mentioned this many times in the past… stay tuned for more information in the coming posts. And Scope Management training is coming to Tampa, FL in just a few weeks.  More to come!

For more information on northernSCOPE(TM) visit (in English pages) and for upcoming training in Florida, visit

To your successful projects!


Carol Dekkers
Contact Carol to keynote your upcoming event – her style translates technical matters into digestible soundbites, with straightforward and honest expertise that works in the real world!
=======Copyright 2010, Carol Dekkers ALL RIGHTS RESERVED =======

Managing program scope - an evolutionary approach

One of the most daunting challenges with software intensive systems development centers around ensuring that customers and suppliers speak the same language about the amorphous technology solution needed by the customer.  When the product is a tangible product such as a building or a road, there is far less ambiguity in the requirements and the number of projects that need to be worked.

Most customers can envision what a road looks like and what its construction will entail.  However, when software intensive systems are involved in the solution – this is hardly the case!  While the customers knows that their business problem needs a solution that will involve technology and hardware/software, most often the exact business problem is not yet articulated.  That’s the role of the first phase of the project – figuring out what the project(s) will be and what the floorplan(s) are that will be involved —- but in a systems way of thinking.

Customers know that the cost of such technology intensive solutions generally exceeds the initial budget (without knowing exactly why) and thus want to corral such costs with a “not-to-exceed” fixed price budget.  This is similar to wanting to develop a piece of land to satisfy a particular need, but asking for a fixed price before such buildings and/or projects are defined. Ludicrous you might say!  Premature at least!

What normally happens at this point for software intensive systems projects is that a contrived fixed prices guesstimate is drawn up by various suppliers (software developers) based on customer insistence.  It will always be wrong because no one can predict the cost of something that has not yet been seriously discussed.  The cost to build a house before a floor plan is developed will obviously be wrong – because the cost depends on what the house will include and how big it will be.  As such – a unit price per square foot could be used (based on history).

This is exactly what Scope Management is all about – figuring out and subdividing the business solution into a number of pieces (a new system, data migration, etc), and the getting unit prices for their development (cost per FP or other metric).  The customer wins because they only pay for the work that they direct, and the supplier wins because they get paid for the work they are directed to do.

Certified scope managers (CSM) are professional practitioners trained in the northernSCOPE(TM) approach to concrete scope management.

Workshops to become a certified scope manager (CSM) to aid customer groups are now scheduled for April 27- May 1, 2009 in Tampa FL.  See for further details and to register.

Let’s work together to make software intensive systems development successful – through scope management. It’s the right thing to do and takes advantage of the best-practices we already know and use!

Have a nice week!

Carol Dekkers
Carol Dekkers email:

Contact Carol to keynote your upcoming event – her style translates technical matters into digestible soundbites, humorously and forthright.

View also Carol Dekkers’ general blog at ============Copyright 2009, Carol Dekkers ALL RIGHTS RESERVED ============= Posted by Carol Dekkers Labels: ,

Function Points are NOT an Estimating Model

It continually amazes me that there is such confusion in the marketplace and in industry about function points (FPA) and their role in estimating the cost or effort associated with a software development project. First and foremost, Function Points are NOT an estimation model.

(Note: for a basic primer on IFPUG Function Points, send me an email and I’d be happy to send you a copy of my article “Requirements are the Size of the Problem”.)

Function points (unadjusted and the “functional size”) strictly represent the size of a piece of software based on its functional requirements. The allocation of “points” to the functions performed by the software is based on assigning a standard ordinal number to a “function” that the software must perform (a unit of work). Currently, the most popular methods of function point sizing based on the International Software Benchmarking Standards Group (ISBSG) productivity database are the International Function Point Users Group (IFPUG) method, and the Finnish Software Measurement Association (FiSMA) function point method.

The function point (or functional) size is similar to the square foot size of a building’s floor plan (or square m) – it is one measure of size – and it works well as part of determining many things.
BUT size is not the same thing as estimation OR AN ESTIMATING TECHNIQUE!

Function point size can be used (along with MANY other factors) to determine work effort to develop (build) the software. Productivity factors or delivery rates (FP/hour) are derived by taking the FP size of a piece of software, together with the work effort hours it took for a team to build it (based specifically on the TYPE of software, the requirements for QUALITY (reliability, accuracy, functionality, usability, etc), the skills, and WHAT TASKS WERE INCLUDED!

Here’s the crux: FUNCTION POINTS DO NOT EQUAL WORK EFFORT HOURS OR COST. While size is a major driver (in the same way that a larger house takes more time to build), the relationship between FP and effort or cost is NON-LINEAR! There are many more factors that just raw size involved in determining the cost and effort to build software.

It may be helpful to consider an analogy (again one based on construction – which is not a perfect analogy but one that serves to illustrate). If I need a 1000 square foot building – can you tell me how long it will take to build? And what can I anticipate will be the cost of that building? The answer is that it depends on MANY factors (such as location, pre-existing structures, type of building: anufactured, or custom or prefabricated or whatever), and many other things. Builders might provide me with an average delivery rate based on STANDARD characteristics (like a standard home with 2 bedrooms and a living room, kitchen and bathroom in the US midwest), and an average effort based on what similar buildings have taken to build IN THE PAST HISTORY. However, there is not ONE rate for all structures – it varies based on location, type of construction, building codes, labor costs, etc.)

The same is true when we consider function point size and the effort and cost it will take to build a piece of software. Consider the aforementioned example applied to software development: How much cost and how much effort will it take to build software that is 1000 FP? The appropriate answer is that it depends on the characteristics of the software, labor costs, methods of construction, AND its functional size. The software measurement and development industry has developed rates of FP / hour and cost per FP for projects with “standard” and similar characteristics (recall the “average” price per square foot or average rate to build?) Note that any “average” rate is BASED ON PAST PROJECTS (that took “x” amount of hours to build a particular size, type, and similarly constrained by quality, system – but there is not a one size fits all rate!

New Book available to explain these and other concepts about Function Point sizing: I am proud of the new book I co-authored with Manfred Bundschuh (formerly the measurement coordinator for AXA Insurance in Germany). It was published in Sept 2008: The IT Measurement Compendium – Estimating and Benchmarking Success with Functional Size Measurement (the Amazon link is featured together with reviews by Capers Jones, and also by Peter Hill (Executive Officer for ISBSG at

The book outlines and explains in clear English these concepts and presents all five of the ISO/IEC conformant Functional Size Measurement Methods including the aforementioned two: IFPUG and FiSMA, as well as NESMA from the Netherlands, Mark II from Britain, and COSMIC by the COSMIC consortium.

Have a great week, and please let me know what you think of this and other postings here.

p.s., To all of you who attended my webinar on December 3, 2008 “The Certified Scope Manager (CSM) – A New IT Job Role) sponsored by CAI – thank you! If you missed it, send me an email and I’ll put you in touch with the site that has options to listen to the recording.

Best regards,

Carol Dekkers email:

Contact Carol for your keynote and speaking needs – she translates technical subjects into easily digestible soundbites – in a humorous and forthright manner. See for details of topics and opportunities.

View also Carol Dekkers’ general blog at

============Copyright 2008, Carol Dekkers ALL RIGHTS RESERVED =============