Category Archives: certified scope manager (CSM)

Navigating the Minefield... Successful Estimating Before Requirements are Complete

Free webinar…. Wed June 10, 2015 – 11 am – 12:30 pm EDT.

Register by following this ITMPI link.

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.


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…


Trust and Verify are the (IT) Elephants in the room

As a party involved in some aspect of software development, why do you think projects are so hard?  Millions of dollars in research work to solve this question, with the result being new models, agile approaches and standards, all intended to streamline software development.

What do you think is the core reason for project success or failure?  Is it the people, process, requirements, budgets, schedule, personalities, the creative process or some combination?

Sure, IT (information technology) is a relatively new industry, plagued by technology advances at the speed of light, industries of customers and users who don’t know what they want, budgets are preset, schedules are imposed, scope is elusive, and, ultimately computer scientists and customers still speak their own language.  Some people argue that it boils down to communication (especially poor communication).  After all, isn’t communication the root cause of all wars, disputes, divorces, broken negotiations, and failed software projects?

I disagree.

I believe that TRUST and VERIFY are THE TWO most important factors in software development

These two elements are the IT elements in the room (so to speak!) I could be wrong, but it seems like the commonly cited factors (including communication) are simply symptoms of the elephants in the room – and no one is willing to talk about them.  Instead, we bring in new methodologies, new tools intended to bring customers and suppliers together, new approaches, and new standards – and all of these skirt the major issues: TRUST and VERIFY.

Why are these so critical?

Trust is the difference between negotiation and partnership – trust implies confidence,  a willingness to believe in (an)other, the assurance that your position and interests are protected, and the rationale that when life changes, the other party will understand and work with you. A partnership means that there is an agreement to trust in a second party and to give trust in return.  Trust is essential in software development.

BUT… many a contract and agreement have gone wrong with blind trust, and that is why VERIFY is as important as trust. Verify means to use due diligence to make sure that the trust is grounded in fact by using knowledge, history, and past performance as the basis.  Verify grounds trust, yet allows it to grow.

President Ronald Reagan coined the phrase “Trust, but Verify” – but I believe it is better stated as “Trust and Verify” because the two reinforce each other.  This also suggests the saying:  “Fool me Once, Shame on You… Fool me Twice, Shame on Me.”

Proof that Trust and Verify are the Elephants in the Room

Software development has a history of dysfunctional behavior built on ignoring that Trust and Verify are key issues. It is easier for both the business (customers) and the engineers (suppliers) to pretend that they trust each other than address the issues once and for all.  To admit to a lack of trust is tantamount to declaring war and accusing your “partners” of espionage.  It simply is not done in the polite company of corporate boardrooms.  And so we do the following:

  • Fixed price budgets are set before requirements are even known because the business wants to lower their risk (and mistrust);
  • Software development companies “pad” their estimates with generous margins to decrease their risk that the business doesn’t know what they want (classic mistrust);
  • Deadlines are imposed by the business based on gut-feel or contrived “drop dead” dates to keep the suppliers on track;
  • Project scope is mistakenly expressed in terms of dollars or effort (lagging metrics) instead of objective sizing (leading metrics);
  • Statements like “IT would be so much easier if we didn’t have to deal with users” are common;
  • Games like doubling the project estimate because the business will chop it in half become standard;
  • Unrealistic project budgets and schedules are agreed to to keep the business;
  • Neither side is happy about all the project meetings (lies, more promises, and disappointment).

Is IT doomed?

Trust is a critical component of any successful relationship involving humans (one might argue that it is also critical when pets are involved) – but so too is being confident in that trust (verify).  Several promising approaches address trust issues head on, and provide project metrics along the way to ensure that the trust remains.

One such approach is Kanban (the subject of this week’s Lean Software and Systems Development conference LSSC12 in Boston, MA).

Kanban for software and systems development was formalized by David Anderson and has been distilled into a collaborative set of practices that allow the business and software developers to be transparent about software development work – every step of the way.  Project work is prioritized and pulled in to be worked on only as the volume and pace (velocity) of the pipeline can accommodate.  Rather than having the business demand that more work be done faster, cheaper and better than is humanly possible (classic mistrust that the suppliers are not working efficiently), in Kanban, the business works collaboratively with the developers to manage (and gauge) what is possible to do and the pipeline delivers more than anticipated.  Trust and verify in action.

Another promising approach is Scope Management (supported by a body of knowledge and a European based certification) – a collaborative approach whereby software development effort is done based on “unit pricing”.  Rather than entertaining firm, fixed price, lose-lose (!!!) contracts where the business wants minimum price/maximum value and the supplier need to curtail changes to deliver within the fixed price (and not lose their shirts), unit pricing actually splits a project into known components can are priced similarly to how home construction can be priced by square foot and landscaping priced by the number of trees.

In Scope Management (see and for more details or send me an email and I’ll send you articles), the business retains the right to make changes and keep the reins on the budget and project progress and the supplier gets paid for the work that the business directs to be done.  Project metrics and progress metrics are a key component in the delivery process.  Again TRUST and VERIFY are key components to this approach.

What do you think? 

Please comment and share your opinion – are TRUST and VERIFY the IT elephants in the rooms at your company?

P.s., Don’t forget to sign up for the SPICE Users Group 2012 conference in 2 weeks in Palma de Mallorca, Spain. See for details!  I’m doing a 1/2 day SCOPE MANAGEMENT tutorial on Tuesday May 29, 2012.

Jeopardy for IT projects... the answer is July 15

JeopardyIn the popular television game show Jeopardy, contestants are given short phrase answers and are challenged to pose the associated question.  The half-hour show has been a mainstay on prime time television for many years and boasts millions of viewers.

While Jeopardy provides great no-risk entertainment for contestants and viewers, a real-life “game” of Jeopardy plays out daily in corporations throughout the world, only it’s called something else: Date-driven-estimating!

Here’s how it typically plays out:
Business executive:  “July 15.”  (The Jeopardy style answer)
Contestant / CIO (pondering): “Is that the date you announced that the software would be ready?”
Business executive:  “Correct!  Now make it happen.”

Poor project estimating is one of the pervasive issues in software development – and the situation doesn’t seem to be getting any better despite process improvement models such as the Capability Maturity Model Integration (CMMI(R)) and formal project management.

It doesn’t seem to matter how advanced or mature is the IT organization – good project estimation is elusive.  When a project does come in according to schedule, it is often a matter of coercion – that is the project manager has cajoled, manipulated or somehow morphed the project schedule to match an often arbitrary end date.

Author Steve McConnell once coined the phrase “Date-Driven-Estimating” and stated that it was the most prevalent estimating method in use today.  In Date driven estimating, management announces the project delivery date and then the project team works backwards to the current date.  The worst-case (and not unlikely) result is when the project can make the date ONLY if it was started several months ago.  The schedule is then retrofitted by piling on more resources along the timeline until everything is included between the start and end dates.  Somehow, such artificial manipulation transforms the impossible schedule into one that can work…

In engineering projects where physical and scientific constraints are fixed (such as the days required for concrete to cure), it is easier to see that such practices are prone to create outright project failures before the project even gets started.  For example, a road construction project cannot be sped up by adding too many resources – physical limitations of engineering construction prevail and building codes govern project progress.  Not so in software development.  In fact, just this evening I met someone from a major financial services company who told me of a software project where the coding commenced within two weeks of the project start – even before they had documented the requirements.  (No, it was not an agile project!)

What can be done when there is a pre-set budget or firm schedule set before any requirements are documented?  From an investment point of view, customers want to curtail costs during the development and still get the software they need to improve their business.

From a supplier point of view, the goal is to get paid for the hours expended delivering the correct solution while being flexible to the inevitable changes that will happen along the way.

The two approaches seem at odds with one another – customers want to be fiscally responsible for curtailing costs, and suppliers want to be responsive to their customers yet get paid for the work they are directed to do.  Firm fixed price projects (even before requirements are known) have been the solution preferred by customers to minimize the risk of budget overruns but all the risk is assumed by the supplier – especially before requirements are known.  But as in any partnership there is no such thing as a win/lose partnership – if the customer wins and the supplier loses – both sides ultimately lose.

So, what can be done to avoid such a dilemma and achieve a win/win scenario?  One solution is to deliver bite sized, incremental 2-week software releases using Agile Methods (scrums) .  A two-week timeframe is easier to manage and gain an accurate estimate than is a long-term development project.

Another approach is unit pricing…. Unit pricing is based on working with a cost per function point (software sizing) and is a promising and realistic option to reach success.  This approach plus other evolutionary steps are contained in the northernSCOPE model – already successful in Finland, Australia, and other countries.

Watch this space for more about the northernSCOPE approach and upcoming US training workshops.

Meanwhile here’s a couple of earlier posts on the topics:

Isn’t it time we changed the channel and stopped playing IT Jeopardy?



EU nations receptive to Scope Management

Greetings from Copenhagen

Bo Balstrop, Carol Dekkers, Morten Korsaa
Bo Balstrop, Carol Dekkers, Morten Korsaa

I have to confess that Europeans are much more progressive and receptive to evolutionary ideas such as northernSCOPE and formalized unit pricing ($/FP) on public tendering of IT projects than the U.S.  Just this week, I met with four different groups and presented the highlights and gains to be made from adopting formalized scope management, and I am hopeful that we (Delta Axiom of Denmark, my company Quality Plus Technologies, and 4SUM Partners of Finland) can begin to offer Certified Scope Management (CSM) training courses in Denmark in the not-too-distant future.  The approach is straight-forward and minimizes the lose/lose risk that accompanies firm fixed pricing of software projects when the requirements are not well-known.

Also interesting was the fact that those most interested in learning more about the method are not even from customer or developer groups that outsource (tender) their software development, but rather companies that do development in-house.  It wasn’t a hard sell at all – the audiences in all four presentations were receptive, open to discuss how northernSCOPE might work in their organizations, and optimistic about how it can succeed in Denmark.  After all, if we can create the demand for Certified Scope Manager (CSM) services with the public or private sectors, then training is the natural next step to create CSM’s to satisfy such demand.

Representatives from one of the nation’s largest government departments that governs taxation, the equivalent of the IRS in the US, were on-hand and expressed interest in knowing more.  I’m not sure why, aside from the “not-invented-here” characteristic (that plagues more than just the US), scope management has not raised anything more than a passing glance in the US.  With all the major expenditures on software intensive systems projects underway with our public administration and Department of Defense, together with rework figures hovering around 40%, you’d think that formalized Scope Management (aka northernSCOPE) would be of interest.  While the economy definitely plays a role to cut interest in training and consulting overall, it is still a question mark in this author’s mind why there is little interest despite ample presentations and workshops I’ve done at technology conferences throughout the US over the past few years.

No worries though… as long as some part of the world sees value in the method today – it matters not where the demand is rising.  It will be interesting to watch as more CSM’s are certified in Europe to see if it peaks any interest in my home continent.

Best wishes for healthy, productive projects.

p.s., Want to know more about northernSCOPE and the Certified Scope Manager (CSM) designation?  Email me for a copy of our northernSCOPE brochure and our CSM training information.



Ever had this problem in Software Development?

software development videoHave you ever felt that the business side of software development just doesn’t understand what’s involved?  Watch the short video I created (just click on the “photo” above) and let me know if this is anything like what you’ve ever experienced.

It’s no wonder that so many projects end up over budget, behind schedule and delivering a product that just doesn’t fit.  One solution is scope management.  Call or email me today for a free white paper about Scope Management (

I know the video is tongue-in-cheek but I’d like to hear your comments!

Have a good day,

"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?



Soft skills and IT - the weakest link?

It’s been said that effective communication is one of the most important and critical skills that a software developer can have today.  The Project Management Institute’s Project Management Body of Knowledge professes that communication takes up over 80% of a project manager’s time.

Yet, what percentage of your training in college or as an IT professional is devoted to soft skills and communication?  It is critical to project success and a core pre-requisit to discovering your customer’s expectations. Yet soft skills and communication are often considered to be a natural skill of technical professionals. No so!

When I speak to technical audiences, most share my viewpoint that few people go into engineering or computer science professionals with people skills in mind – yet those are the most crucial to project success.  Certainly technical prowess is important, but no more so than effective negotiation, communication, empathy, understanding, presentation skills, and the ability to speak in business terms.

At CoolTech (a Tampa Bay Technology Forum event) lastweak link week, Disney luncheon speaker Frank Furness stated, “Don’t let technical people talk to non-technical people.”  In today’s technologically advanced world, it is unfortunate that this is still the norm (technical people predominantly talk techno-talk).  I believe that that poor communication is the weakest link in software development today! Just as a chain is only as strong as its weakest link, so too is software development only as strong as IT’s weakest link!

Many of the required soft skills are part of the Certified Scope Manager (CSM) training program coming to Tampa, FL in late August 2010. Here’s a short list of the soft skills we cover:

– Talking to customers and non-technical users about their functional requirements for software;

– Talking to customers and non-technical users about their quality and performance needs for software product(s);

– Negotiating with customers about how to write a “good” Request for Proposal;

– Communicating with suppliers about unit pricing of software projects;

– Communicating with suppliers and customers about the progress of projects to-date;

– Communicating the baseline sizes of the software at the end of requirements phase(s) to both suppliers and customers;

– Communicating the impact of proposed changes (in size, schedule and cost) with customers and suppliers;

– Collecting, analyzing, and storing lessons learned in a corporate knowledge base for use on future projects.

Very communication and soft skills intensive!  Why not consider attending one or all days of Certified Scope Manager (CSM) training August 23-27, 2010 in Tampa, FL.  Send me an email at for further information or visit our website at for a training brochure and registration information.

To your successful projects!


Carol Dekkers

For more information on northernSCOPE(TM) visit (in English pages) and for upcoming training in Tampa, Copenhagen, Dusseldorf, Helsinki and other locations in 2010, visit
=======Copyright 2010, Carol Dekkers ALL RIGHTS RESERVED =======