Category Archives: Change

To Succeed with Measurement, Choose Stable Measures

The pace of technology advancement can be staggering – new tools, methods, acronyms, programming languages, platforms and solutions – come at us at warp speed, morphing our IT landscape into patchwork quilts of old and new technologies.  

At times, it can be challenging to gauge the results (of change): what were the specific processes /tools /methods /technologies /architectures /solutions that contributed to or delivered positive results?  How can we tell what made things worse?

Defining positive “results” is the first step and measurement can contribute – as long as our measures don’t shift with the technology!

I and countless others have written about Victor Basilli’s GQM (Goal Question Metric) approach to measurement, (in short, choose measures that answer the questions you need to answer so you can achieve the goal of measurement…) but there’s a problem even more fundamental, and goes beyond choosing the right measures:

The key to (IT) measurement lies in stability and consistency:  choosing stable measures (industry standardized definitions that don’t change) and measuring consistently (measuring the same things in the same way.)
– Carol Dekkers, 2016

This may seem like common sense, but after 20 years of seeing how IT applies measurement, I realize common sense isn’t all that common.  There are some in the IT world that would rather invent new measures (thus decreasing stability and consistency) than embrace proven ones.  While I’ve seen the academic tendancy of “tear down what already exists to make room for my new ideas,” I believe that this is counter-productive when it comes to IT metrics.  But, I’m getting ahead of myself.  First, let’s consider how measurement is done in other industries:

  • Example 1: Building construction.  Standard units of measure (imperial or metric) are square feet and square meters.  The definition of a square foot has not changed despite advances in modular design.
  • Example 2: Manufacturing.  Units of measure for tolerances, product sizes, weights, etc. (inches, mm, pounds, kg, etc.) are the same through the years.
  • Example 3: Automobiles.  Standard ratios such as miles per gallon (mpg) and acceleration (0-60 in x seconds) remain industry standards.

In each example, the measure is stable and measurement success is a result of consistent and stable (unchanging) units of measure applied across changing environments.  Comparisons of mpg or costs per square foot would be useless if the definition of the units of measure was not stable.  Comparability across products or processes depends on the consistency and stability of both the measurement process and the measures themselves.

Steve Daum wrote in “Stability and linearity: Keys to an effective measurement system” :

“Knowing that a measurement system is stable is a comfort to the individuals involved in managing the measurement system. If the measuring process is changing over time, the ability to use the data gathered in making decisions is diminished. If there is no method used to assess stability, it will be difficult to determine the sensitivity of the measurement system to change and the frequency of the change…Stability is the key to predictability.”

One of the most stable and consistent measures of software (functional size) is called IFPUG Function Points and as The International Function Point Users Group (IFPUG) is poised to celebrate its 30th year in 2017.  The IFPUG Function Point measure is stable (with hundreds of thousands of projects having been FP counted,) and consistent (it’s been an ISO/IEC standard for almost 20 years!) – and perhaps 2017 is the year that YOUR company should look at FP based measurement.

FPA (Function Point Analysis) provides the a measure of software size under development and can be used equally well on agile, waterfall, and hybrid software development projects.  Yet, despite its benefits, much of the world still doesn’t know about the measure.

See my first post of 2016 here:  Function Point Analysis (FPA) – Creating Stability in a Sea of Shifting Metrics for more details.  FP is certainly a good place to start when you’re looking for software measurement success… why not today?

Wishing you a happy and safe holiday season wherever you live!


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.

Spice Conference


THE process improvement conference YOU need to attend

Spice Conference.

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,

ABZ’s of communication for PM’s and Techies… K: The KISS principle

With communication accounting for over 80% of a project manager’s time, the importance of GOOD communication cannot be overlooked.

K: K.I.S.S.=Keep it simple stupid!

While we can become divided by the fact that English is a common language with many variations, acronyms further complicate things.  Every client I visit is overrun with TLA’s and FLA’s that create barriers to the very communication they intended to make easier.

What is a TLA and a FLA?

TLA is a Three Letter Acronym and FLA stands for Four Letter Acronym. And, to make matters worse, the meaning behind such acronyms is often lost on even the most savvy users – in fact, sometimes even the original words are forgotten by the most frequent users.

Keep your communication clear, concise and easy to understand by avoiding acronyms.  If you must use one, make sure to include the words that make up the acronym in parentheses behind its first use.

Acronym usage is so prevalent in government and corporate environments that many organizations now publish “acronym guides” to explain the various (and often conflicting) words behind the various three and four letter combinations. (The only problem that I find with such guides is that they are specific to a particular industry or government group, and the lists themselves abound with further acronyms.)  For example:

The best advice is to avoid acronyms all together, and if you can’t due to widespread use or industry familiarity – at least make sure to embed its meaning when it is first used.  We can’t stop the spread of acronyms, but we have a duty to make them meaningful to our audiences!

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

John C. Maxwell on Leadership Success and Communication

In light of my current series of postings on the ABZ’s of Communication for PM’s and Techies, my good friend, Hollis Wagenstein, alerted me to a recent post by author and communication expert John C. Maxwell. Here is an excerpt:

Communication—A Leader’s Key to Success by John C. Maxwell

For my whole life, I have opened my car door by inserting a metal key into a physical lock. Now, I can unlock the doors and start the car at the push of a button. It seems like magic to me, but it’s actually a simple application of science.

Keyless entry and keyless ignition are made possible when a transmitter within your key fob communicates with a radio receiver inside the car. Two conditions are necessary for this communication to take place: 1) the transmitter must be set to the same frequency as the receiver, and 2) the transmitter must send a uniquely coded message which the receiver has been programmed in advance to recognize.

Communication acts as a leader’s “keyless entry” into relationships. It can open the mind of an employer, the wallet of investors, and the hearts of loved ones. Talented communicators seem magical when they weave their words together. However, much like the concept of keyless entry, great communication depends on two simple skills—context and delivery. Context attunes a leader to the same frequency as his or her audience. Delivery allows a leader to phrase messages in a language the audience can understand…

Maxwell continues to expound on how important communication is to relationships and leadership in the rest of the post. Click here to read the entire post.

To better communication and more successful projects!

CSM – The Real Estate Agents of Software Development

CSM stands for Certified Scope Manager.

I just returned from Japan where I attended ISO software and systems engineering meetings in Niigata, guest-lectured at the University of Niigata, and spoke at a special event convened by the Japan Function Point Users Group (JFPUG) to discuss northernSCOPE and scope management.  Present were over 50 software professionals representing some of the most prominent and influential Japanese companies including Hitashi, Mitsubishi, IBM, and others.

Carol with executive board members of JFPUG

Carol with executive board members of JFPUG

It continues to become more and more clear how scope management and the new job role recognized by the European Certificates Association called “Certified Scope Manager” fills in the missing links in today’s software development. As I’ve stated before, I believe that the supplier side of the customer/supplier relationship does a fine job in developing software when the customer is engaged and there are good requirements.

Software developers and project managers do excellent work – and I stand by my assertion that the Project Management Body of Knowledge (PMBOK) and the Capability Maturity Model Integration (CMMI) approaches have done much to advance us to a better, more professional state.

BUT, the fact remains that there is a gap between the customers (who often abdicate requirements and planning to suppliers) and the software development team! And the gap hasn’t gone away despite advancements in business analysis (BABOK) and other professional endeavors.  We need what the home building and buying industry has had for years – Real Estate Agents! (Note that real estate agents represent a buyer in terms of knowing the best neighborhoods, cost per square foot competitive values, are aware of building codes and zoning, know how to navigate the mortgage and title industries, and can also represent a seller.)

This is where the Certified Scope Manager (CSM) fits in:  s/he is the Real Estate Agent of software development. Certainly there are bits and pieces of this work that are picked up by project managers, business analysts, metrics specialists, cost estimators, etc. but to-date there has been no solid single job role that works as the Customer Advocate AND performs all the tasks of a Scope Manager.

Here’s a short list of functions a Certified Scope Manager performs on a typical software intensive systems project:

Works with the customer or business unit upfront to articulate and document high level functional and non-functional (quality and product performance) requirements;

Works with the customer to subdivide the work into manageable projects (Note: often what the business considers to be a project is actually a program of projects that are managed separately. This is similar to doing site selection, building, and landscaping in a home construction project. Each piece is a separate project.);

Works with the customer to create RFPs (Requests for Proposal) for each sub-project as defined above, and solicits bids to come in with unit pricing (e.g., $ per Function Point for new development, $ per hour for data migration, etc) for each;

Works with the customer to evaluate the bids and select the best value suppliers;

– After the requirements phase is completed between the customer and supplier, baselines each project size using Function Points or other sizing measure (as applicable to the type of project);

Works with the supplier to report progress and completion (percentages) by delivered feature/function as the projects progress, and produces progress reports for the customer;

Works with both supplier and customer to analyze proposed changes and assesses the cost impact based on unit pricing (same as for the awarded contracts);

Updates project delivery (and baseline) based on approved changes;

Identifies issues (earned value) during the project and works with the customer to discuss such issues with the supplier;

Figures out the final bills for work delivered based on unit pricing and product delivery;

Captures lessons learned (and too often forgotten) on each project into an experience database for use on later projects.

The Scope Manager is an octopus of sorts; a swiss army knife; a jack-of-all trades in the areas often neglected in customer advocacy on software intensive systems projects.  And he/she accomplishes all of this in a matter of 2-3 days per project.

Let me know if you’d like articles with more details on the subject, and if you’d like me to talk to your management about how scope management can improve your software intensive systems projects.

The Japanese attendees were fervent in their support and now will discuss how to make northernSCOPE and the Certified Scope Manager job role a reality in Japan.  The first hurdle (and the biggest) is translation – after that, it’s working to change the flawed firm-fixed-pricing mentality that prevails throughout the world to one of unit pricing – especially when requirements are not well-known.

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

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 Dekkers

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 ( 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 (in English pages) and for upcoming training in Tampa, Florida  — April 26-30, 2010, visit

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

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 ( 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 (in English pages) and for upcoming training in Tampa, Florida  — April 26-30, 2010, visit

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 Dekkers

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 ( 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 (in English pages) and for upcoming training in Tampa, Florida  — April 26-30, 2010, visit

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