Category Archives: The IT Measurement Compendium

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 =============