Category Archives: outsourcing

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

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 and from CrossTalk ( – search for software measurement and from the DACS ( which are all US taxpayer funded initiatives for a starting point).

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

To your successful projects!


For more information on northernSCOPE(TM) visit (in English pages) and for upcoming training in Florida, visit
Carol Dekkers
Contact Carol to keynote your upcoming event – her style translates technical matters into digestible soundbites, with straightforward and honest expertise that works in the real world!
=======Copyright 2010, Carol Dekkers ALL RIGHTS RESERVED =======

Overcome CHAOS with scope management...

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

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

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

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

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

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

To your successful projects!


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

Offshoring Onshore - 9 Critical Lessons for Multi-Cultural Contracting

Recently, I had the unusual (for my company at least) experience of working for an India-based, US domiciled corporation on a short term contract. It was a great learning experience in many ways, and I’d recommend that the following lessons learned are critical to success when working with cultural differences:

  1. Get everything (everything!) in writing -especially verbal promises – before the contract starts;
  2. Be prepared to reduce your fees (negotiate down) as a part of doing business (some cultures are not satisfied unless they feel they are getting everything at a bargain price);
  3. Keep track of all names and their role – and ask for correct spelling of all names, their position, their company (multiple connected companies with strict legal dividing lines is common), their role on the contract, work and mobile phone numbers and their personal (individual rather than collective) email address;
  4. Realize that a single gender team is typical (you may work with an all male group by design) depending on the culture;
  5. Don’t ignore your intuition – it is culturally independent (usually) and is your best ally;
  6. Know that gender and ethnicity biases do and will occur – just be aware and watch for these on both sides. Be slow to react to anything that might appear strange to you at first glance. Silence is golden in many cultures (as opposed to we, North Americans, who need to fill silence gaps with words);
  7. Not everyone will be as receptive as you to a diversity of team members – even here in the “melting pot” of the USA.
  8. General rules of US business are not necessarily followed by foreign-run companies domiciled in the US;
  9. Obtain an advance for expenses and other fixed costs (or you may wait 45 days or more for reimbursement of your sunk expense costs).

Lesson #1. I was retained as a subcontractor to perform measurement consulting for an India-based company associated with a large US-based prime contractor. Because I had completed successful engagements previously for the US corporation, I neglected to perform due diligence with the new company. This led to lesson #1 above – “always get everything in writing!”

The client for the India-based organization SYSSYS wanted to set up a sustainable software measurement program that would meet the needs of their CIO and use six sigma to do so. The assignment was allocated a total of 10 onsite person days of consulting to start.

Lesson #2. The first cultural difference happened right away when the SYSSYS contracting officer insisted that the client would need a fee reduction to my billable rates. While this also happens in the US when a volume of work is involved or the consulting budget is really tight, I now know from research and colleagues that it is part of the Indian way of doing business. The line “this is an outstanding opportunity for future business” was a standard one issued verbally to imply a volume of work to come. Lesson #2 – “Be prepared to reduce your price.”

Lesson #3 and Lesson #4. The next culture shock came once the work commenced. Meeting after meeting (all by conference call) was held before I ever saw a contract (a full billable day was spent) – all involving more foreign names from multiple companies who would be involved in this two week onsite project. I was the lone North American and the only female out of approximately 10 persons who got involved including subcontract administrators, managers, my Indian teammate (from CA), the onsite consultant, and various others who I never learned their role. Here it was a US based client for a US consulting project and I was the sole North American. My instincts told me that the US based client in the upper Northeast might not know (or care?) about this imbalance. I wrote down most of the names and email addresses, but it was not easy to follow who was always involved in the phone meetings. Lesson #3 – “Keep track of all names and numbers,” and Lesson #4 – “All male teams are not uncommon”.

Lesson #5. When we first met with the client (by conference call) in advance of the onsite work, the client team manager laid out a set of expectations for the work. My intuition kicked in full gear as I realized that the timeline and 10 days of onsite work was far too ambitious to succeed. I overrode my instincts based on assurances from the contracting organization that my fears were unfounded. My Indian colleague (a six sigma black belt) would set the scene and do the first two days of onsite six-sigma training, and then leave me to complete the work and deliver the results. Again, I supressed my intuition that told me this was a risky project with lots of potential for miscommunication. I still had no written contract – just a verbal commitment to pay me for 8 billable days plus expenses in an expedited manner, and I booked and paid for my flights to the client site on verbal assurances and the reputation of the US parent company. Lesson #5 – “Listen to your intuition.”

Lesson #6 and Lesson #7. The two days of onsite training were stuffed full of content and case studies, but syncopated by frequent attendee questions of “what did he say?” whenever the Indian pronunciation of a word left listeners with puzzled looks. The client frustration with the culture, language barrier, and communication escalated and by the end of the third day, the contract was abruptly terminated. While this is rare, it does happen whenever the client expectations are unrealistic or if there is a mismatch of understanding and needs. Off the record, one of the client managers confessed that the language issue, the mismatch of the case studies to their needs, and the lack of more North Americans on the contract were contributors to the termination. Lesson #6 – “Gender and cultural biases can and do occur” and #7 – “Not everyone will appreciate foreigners”.

Lesson #8. At this point, I had just received and signed the subcontract agreement (after the work commenced) and it had issues that I had not foreseen: the committed 8 billable days had been changed to client approved and signed off days. By this time it was too late to change the contract. I sent in the first invoice immediately to recover the sunk expenses and work done to date, but was told by one of the SYSSYS managers that the client would not be invoiced – implying that I might not be paid. Lesson #8 – “Rules of business in the US are not necessarily endorsed by foreign companies domiciled in the US.”

More Lesson #1. Thirty days following my invoice, another company official called to tell me that I needed to complete forms to claim both expenses and fees for work performed and that they needed to be approved before I could submit the invoice that was now 30 days old. Lesson #1 – “Get EVERYTHING in writing before the contract starts”.

Lesson #9. Since the onsite visit in August, I’ve submitted five invoices and a set of forms (previous copies all got “lost” in email in-baskets) – and it is over 75 days since the work was done. A glimmer of hope came this week when the subcontract manager emailed me asking for my mailing address (it is on every invoice) so they could MAIL OUT the checks. Lesson #9 – “Get an advance to cover expenses”.

Conclusion. I love to experience different cultures and have spoken in 25 countries (including India), but a few precautions must be taken to protect oneself when contracting with other cultures. I hope these lessons learned can save you some headaches and allow you to enjoy the diversity of working and learning from other cultures here in the USA.

Have a good week.