Category Archives: estimation

Fundamentals of Software Estimating: First See the Elephant in the Room: Part 2

This is the second in a sequence of four posts (and more to come) on BASIC software estimating concepts that address “WHAT IS IT?” we plan to estimate.

Introduction

Whenever I teach project estimating or Project Management 101 (basics) to software developers, we address the fundamental questions about what we plan to do (once called “The Triple Constraint” in project management circles):

What amazes me, is that while these are great questions that need to be answered when we do an estimate, we start out by ignoring the “Elephant in the Room” – that is, what do we mean by the “it” in the questions above.  Sure, for some people “it” may be obvious that “it” is a project, but bear with me for a minute… misunderstandings about terminology and definitions are often the source of major rework when software construction is involved.

What is “it”?

  1. “It” could be the project (and all that the term entails);
  2. “It” could be the resultant product (software and/or hardware);
  3. “It” could be a phase or exploratory R&D effort; or
  4. “It” might be something altogether different...

The question of “what is it?” we are estimating is fundamental to why IMHO (In My Humble Opinion) software projects end up being over budget, late, and out of scope.  If you don’t know definitively WHAT you are estimating, how can any possible estimate be realistic?

This post is Part 2:  “It” is the resultant Product

When the “what” we want to estimate is the time, effort, cost or scope to build a software intensive product, there are different considerations than if we are estimating a project, such as:

  • What is the product – a working, full-scale “system” (multiple interlocking pieces of software plus associated hardware, and glue code for linking it all together, and documentation) or a portion thereof?
  • Are training modules and online guides to be included as part of the product delivery?
  • Does the product include hardware, and peripherals (like printers or scanners)?
  • Will the entire product (or service) be delivered in “one fell swoop” or delivered in separate pieces?  (This could involve multiple projects that may deliver parts of the software, with later projects having to redo/enhance what was delivered in an earlier release.)
  • Do we know what the product will actually be?
  • Are there multiple stakeholders (direct users or indirect ones) whose priorities for product functionality may vary or even conflict?
  • Has a product like this been done before (i.e., do we know what all is needed such as additional software, hardware, etc.)?
  • What else is included as part of the product? (And what is excluded?)

Software intensive systems are often negotiated and estimated as concrete commodities, however, the challenge of deciding “what actually constitutes the software intensive system ” is a key component that needs to be decided before doing any estimating.

Sounds pretty basic doesn’t it:  Know what “it” is you are estimating before you begin estimating…

Unfortunately, as Peter Drucker once said

“It is important to state the obvious otherwise it may be overlooked.”

Know what you are estimating BEFORE doing an estimate… pretty fundamental don’t you agree?

Comments, brickbats, responses welcome…

 

"Scoping" out IT project failure...

According to a 2008 Gartner report, 15% of all IT projects failed that year because of high cost variance, while 18% were unsuccessful because they were substantially late. This means that in 2008, 1 in 3 technology projects failed.

Hmmm… IT project failure based on the fact that the estimates for budget and schedule proved to be incorrect.  Since many IT projects produce unique software products (i.e., never been done in exactly the same way before), is it any wonder that the estimates for scope AND budget AND schedule would be wrong?

Consider what this would mean in other industries if failure was based on having a high cost variance and substantially late (whatever “high” and “substantial” mean):

  • Medicine:  when a doctor “estimates” that a full term baby is due on Oct 15 and the baby is born on October 31 (16 days late) – is that baby a failure?
  • Medicine: when an oncologist “estimates” that a patient has 18 months to live and the patient is still alive 5 years later – is that patient a failure?
  • Survival: when the mining accident happened in Peru and scientists predicted that there would be casualties and all were rescued alive – was that a failure when the time frame exceeded the expectations and all miners were still saved?
  • Hurricanes:  when the scientist in Colorado predicts the number of hurricanes that will form in the Atlantic and how many will make landfall, and the number of storms falls short of his predictions – is that a failed hurricane season?
  • Everyday life: when you go grocery shopping with a list and a preset amount of cash, and you have to make several trips to purchase the items and they cost you more than you anticipated – is your Saturday a failure?
  • Everyday life: when your son makes the basketball team at school and your planned school budget is exceeded after shoes and uniforms – is the school year a failure?

All of these and many more examples in other industries illustrates how an “estimate” is simply a best guess based on history and science.  But life doesn’t follow science (truth can be stranger than fiction but that is another post for another time).  Just as a psychic cannot reliably predict the future (they can only make an educated guess based on intuition and observation), software estimators cannot reliably forecast the life of a project before it begins.  In fact, software estimators often work with even less predictable scopes than those outlined in the examples above.

So, in the context of a software project, what does on-time and on-budget really mean?  Given a set of approximate inputs for the major cost drivers (based on the information at hand) together with historical data for similar projects, an estimate is derived.  Will this estimate be correct?  Never!  It is always only a best guess given “typical” environment and situational characteristics – and an optimistic view of what could happen during the project.

If the estimator is gifted with a solid and complete set of requirements for a piece of software similar to a historical one, s/he might come within a range of accuracy.  Software, however, remains an amorphous product for which good requirements are often ill-defined or are discovered late in the development life-cycle.

IT project failure (in my humble opinion) should be defined based on scope – if the project misses the product requirements or gets them wrong, then the project should be deemed a failure.  Not whether it cost more than the estimator thought (which is a reflection on how good the estimator could predict life) or whether the product was delivered late (also a function of how well the estimate mirrored life).  It makes so much more sense to track project delivery based on scope!  But, wouldn’t that mean we’d have to concentrate on getting the requirements right and then delivering the product right?  That’s a novel thought.

What do you think?

Carol

Share

What comes first - estimates or requirements?

We’ve seen many advancements of late in process improvement, better software estimating models, introducing flexibility and agility into software development, formal project management, limiting work-in-progress, etc. – all which incrementally advance projects forward and promise to reduce costly rework.  However, none of these methods addresses one of the most fundamental questions in software development:  what comes first estimates or requirements?

Chicken or Egg?If estimates come first… It seems like putting the cart before the horse if estimate precede requirements, but that is precisely how a good number of software projects go.  To begin with, someone has an idea or a business problem that software can solve but before any work even one dollar can be spent, the work has to go into next year’s budget and get funded.  This means figuring out some sort of estimate of work that has yet to be scoped out.  “Is it going to be bigger than a bread box and smaller than a football field?” is one way of saying – we need a “rough ball park” (guesstimate) that we can use in the budgeting process. Unfortunately this guesstimate process is clearly flawed because it is based on invisible and ether-like requirements. As such, the guesstimate is prone to + or – 500% or more variance once the real requirements are known.

This is like saying – how much will it cost to build a house for my family, just give me a rough estimate so I can go to the bank and arrange a mortgage.  This would be an absurd behavior – especially when one usually doesn’t get a mortgage in advance, and especially because the cost will vary depending on where, how big, how custom, and how the house will be built.  If  one secures a $500K mortgage amount – it gives an upper limit but doesn’t guarantee that a suitable house can actually be done for that amount.  Yet, we engage in this behavior in IT all the time – we guess(timate) for the budget cycle, the amount gets slashed during meetings, and ultimately the fixed price (based on little information) becomes the project budget!

If requirements come first… then in many companies nothing will ever get built and problems will remain the same forever.  Analysis paralysis is common (especially with shifting new business requirements) which gives rise to the support of agile and extreme programming approaches to requirements.  Many companies shifted their support from the arduous front end heavy “waterfall” methods of software development in favor of “progressive requirements elaboration” whereby requirements are discovered along the way. As such, requirements are always evolving with new user stories emerging only after the earlier ones are delivered in software.  So what happens when requirements are needed to build a better estimate (and thereby make sure the project has enough budget) yet an estimate is required before one can begin to scope out the requirements that will fit the budget?  It is a circular situation akin to the chicken and egg conundrum that has plagued humankind for years.

Pathway to cooperative results…One method that proves to work well with this dilemma is scope management – whereby a business “project” (more likely a program of work) is divided into sub-projects, scoped out at the highest level, quality requirements are thought about, and traceable estimates ensue.  More to come on this topic in the next post…

To your successful projects!

Carol

Carol Dekkers
email: dekkers@qualityplustech.com
http://www.qualityplustech.com/stage/

Carol Dekkers provides realistic, honest, and transparent approaches to software measurement, software estimating, process improvement and scope management.  Call her office (727 393 6048) or email her (dekkers@qualityplustech.com) for a free initial consultation on how to get started to solve your IT project management and development issues.

For more information on northernSCOPE(TM) visit www.fisma.fi (in English pages) and for upcoming training in Tampa, Florida  — April 26-30, 2010, visit www.qualityplustech.com.

Share/Bookmark
=======Copyright 2010, Carol Dekkers ALL RIGHTS RESERVED =======

What's the (function) point of Measurement?

It’s been more than 30 years since “function point analysis”  emerged in IT and yet most of the industry either: a) has never heard of it; b) has a misguided idea of what function points are; or c) was the victim of a botched software measurement program based on function points.

Today I’d simply like to clear up some common misconceptions about what function points are and what they are NOT. Future postings will get into the nuts and bolts of function points and how to use them, this is simply a first starting point.

What’s a function point?

A “function point” (FP) is a unit of measure that can be used to gauge the functional size of a piece of software.  (I published a primer on function points titled: Managing (the Size of) Your Projects – A Project Management Look at Function Points in the Feb 1999 issue of CrossTalk – the Journal of Defense Software Engineering from which I have excerpted here):

“FPs measure the size of a software project’s work output or work product rather than measure technology-laden features such as lines of code (LOC). FPs evaluate the functional user requirements that are supported or delivered by the software. In simplest terms, FPs measure what the software must do from an external, user perspective, irrespective of how the software is constructed. Similar to the way that a building’s square measurement reflects the floor plan size, FPs reflect the size of the  software’s functional user requirements…

However, to know only the square foot size of a building is insufficient to manage a construction project. Obviously, the construction of a 20,000 square-foot airplane hangar will be different from a 20,000 square-foot office building. In the same manner, to know only the FP size of a system is insufficient to manage a system development project: A 2,000 FP client-server financial project will be quite different from a 2,000 FP aircraft avionics project.”

In short function points are an ISO standardized measure that provides an objective number that reflects the size of what the software will do from an external “user” perspective (user is defined as any person, thing, other application software, hardware, department etc – anything that sends of receives data or uses data from the software).  Function points offer a common denominator for comparing different types of software construction whereby cost per FP and effort hours per FP can be determined.  This is similar to cost per square foot or effort per square foot in construction.  However, it is critical to know that function points are only part of what is needed to do proper performance measurement or project estimating.

To read the full article, click on the title Managing (the Size of) Your Projects – A Project Management Look at Function Points.

To your successful projects!

Carol

Carol Dekkers
email: dekkers@qualityplustech.com
http://www.qualityplustech.com/stage/

Carol Dekkers provides realistic, honest, and transparent approaches to software measurement, software estimating, process improvement and scope management.  Call her office (727 393 6048) or email her (dekkers@qualityplustech.com) for a free initial consultation on how to get started to solve your IT project management and development issues.

For more information on northernSCOPE(TM) visit www.fisma.fi (in English pages) and for upcoming training in Tampa, Florida  — April 26-30, 2010, visit www.qualityplustech.com.

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

The "Dog Chasing its Tail" Syndrome in Project Estimating

Software estimating is plagued by dysfunction, not the least of which is estimation based on under-reported historical hours from previously completed projects.  See posting IT Performance Measurement… Time Bandits for a discussion about this problem.

BUT, other problems are prevalent when launching a project estimating initiative which I call the “Dog Chasing Its Tail” syndrome.  It symptomizes dysfunctional project behavior that is established and continues to be reinforced to the detriment of the organization. As a result the pattern repeats and process improvement is seldom realized.

What is the Dog Chasing its Tail Syndrome? It’s a noble goal to increase the predictability and reliability of project estimates – when estimating is based on sound principles.  However, estimating is often a misnomer for what should be called “guesstimating” because the data on which estimates are based is sketchy at best.

Here’s the process epitomized in the “Dog Chasing its Tail”:

1. Incomplete (or preliminary) requirements and sketchy quality/performance requirements. While preliminary (no formal requirements or  use cases are known), it is customary for management (customer or supplier or both) to demand a project estimate for budget or planning purposes. Labelled initially as a “ball park estimate” (a rough order of magnitude (ROM) guess of whether the effort is going to be bigger than a breadbox or smaller than a football field), the sketchy requirements are used as the basis to get the ROM.

2. The (Guess)timate becomes the project budget and plan. While management initially understands that an estimate is impossible without knowledge of what is to be done, estimators contribute to the reliance on the guesses by providing them with a feigned level of accuracy (e.g., if requirements span a total of two sentences, the resultant estimate may include hours or dollar figures with the ones digit filled in.  As a result, too often the (guess)timate becomes the approved upper limit budget or effort allowance.  Of course these figures will be proven wrong once the solid requirements are documented and known, but we are now stuck with this project estimate.

3. Changes challenge the status quo budget and schedule. When a change or clarification to requirements emerges (as they always do when human beings are involved), there is often a period of blame where suppliers allege that the item in question is a change (addition) to the original requirements on which the estimate was based, while the customer alleges that it is simply clarifies existing requirements.  Of course, neither one can be proven correct because the requirements on which the estimate was based were sketchy, incomplete and poorly documented. Once the dust settles and it becomes clear that the item will impact the project budget and schedule, the change/clarification is deferred to the next phase (“thrown over the fence” as an enhancement to be done in the next release) where it will be poorly documented but we will estimate it anyways, and so the cycle continues.

Dog chasing its tailIf you’ve ever had a dog – you know that this is similar to a dog-chasing-its-tail whereby the behavior goes on until either the dog gets tired or gets distracted by other things going on (such as food being served).  As smart software engineers we ought to be smarter than dogs!  And, given a scope management approach, we can be!  Break the cycle off dysfunctional estimation and investigate scope management – you and your customers will be glad to move forward rather than facing the insanity of repeating the same process over and over and expecting different results (along the lines of the Einstein quote!)  See www.qualityplustech.com for information on scope management training and resources available to break the “Dog Chasing its Tail” syndrome on your projects

Watch for the upcoming post on the hidden dangers in project hours…

To your successful projects!

Carol

Carol Dekkers
email: dekkers@qualityplustech.com
http://www.qualityplustech.com/stage/

Carol Dekkers provides realistic, honest, and transparent approaches to software measurement, software estimating, process improvement and scope management.  Call her office (727 393 6048) or email her (dekkers@qualityplustech.com) for a free initial consultation on how to get started to solve your IT project management and development issues.

For more information on northernSCOPE(TM) visit www.fisma.fi (in English pages) and for upcoming training in Tampa, Florida  — April 26-30, 2010, visit www.qualityplustech.com.

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

IT Performance Measurement - Don't let time bandits prevail...

Here in FL, Sunday is one of my favorite days to sit outside on the deck overlooking the mangroves (yes, spring break weather is FINALLY here!) – and read the bulging Sunday newspaper.  I am always intrigued by the many topics in Sunday’s edition, and there’s always generalist stories that remind me of something that happens with software.  This week was no exception.

I’ve nevTime Banditser seen the syndicated column called “The Ethicist” by Randy Cohen (syndicated from the NY Times Magazine), but today’s column headline:  “Underreporting hours worked puts unrealistic goals on others” caught my eye… just the title reminded me of one of the biggest problems with IT measurement:  project hours in IT are typically under reported because of unrealistic project budgets, overtime rules, accounting practices, etc.  (In my experience with measurement and productivity work – this is part of what I call the “Dog Chasing Its Tail” syndrome but more about that in another post.)

Back to the Matter at hand… In this week’s column, (originally published in NY on March 11, 2010, and in my St. Petersburg Times March 14, 2010), Randy Cohen is presented with an ethical question:
“As a manager at a large company, I work far more than the required 40 hours a week, but report only 40. If I reported my actual hours I could be penalized financially for letting my projects run over budget.  Company policy states… <snip> … is there a problem with simply declining to mention some hours when I did work?”

The crux of Randy’s answer (as it related specifically to IT Performance Measurement for me) was “By underreporting your hours, you create a false sense of your efficiency.  The company now believes that you are able to complete your weekly tasks in 40 hours. But you are not. Your deception thwarts the company’s reasonable interest in assessing your performance”.  To use a Canadian expression Bang On with your response Randy! (to read the entire article by Randy Cohen, click here.)

This is one of the most pervasive problems when tackling software project estimation – using reported project hours as the basis for new project estimates (when the actual hours are much higher). Most people would see the folly of estimating the cost of a new based on the mortgage of a house down the street (you don’t know how much was the down payment!), but overlook the hazards of doing the same thing when estimating a software project based on under reported hours.  Both fall victim to the wrong foundation for estimating.

Before you embark on a process improvement initiative that targets Predictability and IT project Estimating, make sure that you know all the facts before you waste valuable time or energy compounding the existing problems and ignoring the real status quo.  Become knowledgeable about the issues (call or email me if you need a starting point or resources.)

To your successful projects!

Carol

Carol Dekkers
email: dekkers@qualityplustech.com
http://www.qualityplustech.com/stage/

Carol Dekkers provides realistic, honest, and transparent approaches to software measurement, software estimating, process improvement and scope management.  Call her office (727 393 6048) or email her (dekkers@qualityplustech.com) for a free initial consultation on how to get started to solve your IT project management and development issues.

For more information on northernSCOPE(TM) visit www.fisma.fi (in English pages) and for upcoming training in Tampa, Florida  — April 26-30, 2010, visit www.qualityplustech.com.

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

Crosstalk article on Scope Management

CrossTalk - The Journal of Defense Software Engineering

CrossTalk Jan/Feb 2010 Scope Management: 12 Steps for ICT Program Recovery

by Carol Dekkers, Quality Plus Technologies, Inc.
Pekka Forselius, 4SUM Partners, Inc.

ABSTRACT:
The information and communications technology (ICT) world is “addicted” to dysfunctional behavior and the problem is spreading globally. The sad truth is that the parties in the ICT relationship (the customer and the supplier) are largely co-dependent on a pattern of dysfunction characterized by ineffective communication, fixed price contracts with changing requirements, and eroding trust. This article focuses specifically on the northernSCOPE TM 12-step process for ICT program recovery.

For more information on northernSCOPE(TM) visit www.fisma.fi (in English pages) and for upcoming training in Tampa, Florida  — April 26-30, 2010, visit www.qualityplustech.com.

To your successful projects!

Carol

Carol Dekkers
email: dekkers@qualityplustech.com
http://www.qualityplustech.com/stage/
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 =======

Measuring IT Performance

Quote for those tasked with implementing a sustainable measurement program with positive ROI:

“When we seek generalities we fail.
When we seek specifics it is easier.
When we measure performance, performance increases (Hawthorn effect).
When we measure and record performance, performance accelerates.”

Source: Anonymous.

Where Should one Start when Tackling a Software Measurement Program?

Overheard at a recent IT software conference:

  • “Okay, so I guess the 1st step is to measure function points” (Dekkers’ comment: Sorry, wrong approach. The 1st step is to figure out the Goals that you want to achieve with measurement.  Think of this like going shopping – what do you need to buy – you only make a grocery list of what you need once you know what you want to cook. The same thing goes with software measurement! Deciding your goal (s) is the first step)
  • “It sounds like I need a measurement consultant but how do I choose one and what will it cost?” (Dekkers’ comment: There are more than enough eager software measurement consultants who will tell you their way is the best and only way.  One group touts themselves as the elders of software measurement and holds up their volunteer committee service as their mantra, while many of their consultants are hired guns – that is they are subcontractors who work freelance for the highest bidder.  Make sure to ask for (and check) references and ask those references what their ROI on the consulting group was BEFORE you take the salesman’s word for it!  Buyer beware – there’s some unscrupulous fat cats in the water who will take your money, implement useless difficult measures, and be gone leaving you holding a dashboard that doesn’t match what you wanted to achieve.)
  • “Software metrics sounds easy but the presenters make it sound hard” (Dekkers’ comment:  Software metrics is NOT rocket science or even difficult. Follow Goal-Question-Metrics (GQM) approach, engage a bit of targeted training, and take it one step at a time and you’ll see that you too can be savvy with software metrics and gain performance improvement.  Take a look at the FREE materials on Practical Software and Systems Measurement (PSM) from www.psmsc.com and from CrossTalk (www.hill.af.mil/crosstalk – search for software measurement and from the DACS (www.dacs.com) which are all US taxpayer funded initiatives for a starting point).

Make sure you take advantage of the many free article downloads at www.qualityplustech.com or send me a note at dekkers@qualityplustech.com before you hire a consultant to design a function point or software measurement program you’ll later regret.

To your successful projects!

Carol

For more information on northernSCOPE(TM) visit www.fisma.fi (in English pages) and for upcoming training in Florida, visit www.qualityplustech.com
Carol Dekkers
email: dekkers@qualityplustech.com
http://www.qualityplustech.com/stage/
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 =======