Category Archives: function points

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

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

2010 - new year, new advances in software development?

As 2009 draws to a close, we’re left with an “interesting year” where budget cuts in early year gave rise to reduced program deliveries, but by midyear the customer demands for more functionality gave rise to a resurgence of development activity. 2009 saw the CHAOS report (www.standishgroup.com) declare a reduction in the percentage of successful projects, the first year in memory when success rates have decreased – not a good report card for the IT industry!

There’s hope however, and scope management (often the topic of this blog) continues to amass followers and successes in Finland. Yet another government department has embraced scope management processes in their procurement and software development, bringing to almost a dozen the number of federal government departments in the Scandinavian nation for which unit pricing, measurement based progress reporting, and formal change management has become a standard.

For information about the northernSCOPE(TM) approach to scope management on software intensive projects, visit www.fisma.fi and select the English tab.

Workshops will be offered in Q1 2010 for Certified Scope Managers (CSM) including the examination by the European Certificates Association by Quality Plus Technologies (www.qualityplustech.com).

Wishing you success in 2010! What will you do differently to make YOUR project succeed?

To your successful projects!

Carol

Carol Dekkers
email: dekkers@qualityplustech.com
http://www.qualityplustech.com/stage/
http://www.caroldekkers.com
Contact Carol to keynote your upcoming event – her style translates technical matters into digestible soundbites, humorously and forthright. View also Carol Dekkers’ general blog at http://caroldekkers.wordpress.com/ The Dekkers Report
=======Copyright 2009, Carol Dekkers ALL RIGHTS RESERVED

Scope Management is the new Green...

Recycling, planning for the future, saving the environment for future generations is all part of the new “green” movement – and it is common sense for our planet and the future.  In a similar manner, scope management is common sense for software development in that it saves time, puts planning and solid communication up front in the lifecycle, and saves time on costly rework down the road.  By following solid scope management principles, both the customer side and the development side agree at the beginning of the software and systems requirements phase exactly what is the unit pricing for each part of the program/project they work on.  As the project progresses, baseline sizing, progress reporting, change management (using documented and agreed upon procedures), and good communication are part of the approach, and once the project is complete, the award fee (in $$$) is paid to the contracted developers based on functionality and quality delivered.  Lessons learned are captured and quantified according to solid project management principles so that future projects can be run even better. 

None of this is rocket science, however, unit pricing, subdivision of programs into projects and subprojects,  unit pricing by type of work, baselining size, tracking and control based on functionality delivered, and change management based on unit pricing,and final delivery payment based on agreed upon requirements are seldom all brought together in a single project – unless scope management has been applied.

For more information on northernSCOPE(TM) visit www.fisma.fi (in English pages) and for upcoming training in Florida, visit www.qualityplustech.com.

To your successful projects!

Carol

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

Contact Carol to keynote your upcoming event – her style translates technical matters into digestible soundbites, humorously and forthright. View also Carol Dekkers’ general blog at http://caroldekkers.wordpress.com/ The Dekkers Report
=======Copyright 2009, Carol Dekkers ALL RIGHTS RESERVED =======

Last Minute Seat Sale on Certified Scope Manager (CSM) workshops: Tampa, FL Apr 27-May 1, 2009

Dear colleague,

A few months ago I conducted a series of webinars on Scope Management and the Certified Scope Manager (CSM). Now our scheduled training is fast approaching, and because you’re a blog reader we’re having a seat sale for our loyal fans!

In just over 2 weeks, (April 27-May 1, 2009!) we are conducting Certified Scope Manager workshops in Tampa, FL. As a blog reader, you are entitled to a 20% discount for any single or multiple workshop – so register today! (Simply indicate “BLOG” beside your name on the registration form and we’ll adjust the total for you.)

Please visit http://www.qualityplustech.com/stage/CSM_training.html to register. Purchase orders and payment arrangements can be made for this seat sale. Register today and make a difference in your organization and your career!

We hope to see you in Tampa April 27- May 1, 2009.

Have a nice week!

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

Contact Carol to keynote your upcoming event – her style translates technical matters into digestible soundbites, humorously and forthright.
View also Carol Dekkers’ general blog at http://caroldekkers.wordpress.com/
============Copyright 2009, Carol Dekkers ALL RIGHTS RESERVED ======================

Function Points are NOT an Estimating Model

It continually amazes me that there is such confusion in the marketplace and in industry about function points (FPA) and their role in estimating the cost or effort associated with a software development project. First and foremost, Function Points are NOT an estimation model.

(Note: for a basic primer on IFPUG Function Points, send me an email and I’d be happy to send you a copy of my article “Requirements are the Size of the Problem”.)

Function points (unadjusted and the “functional size”) strictly represent the size of a piece of software based on its functional requirements. The allocation of “points” to the functions performed by the software is based on assigning a standard ordinal number to a “function” that the software must perform (a unit of work). Currently, the most popular methods of function point sizing based on the International Software Benchmarking Standards Group (ISBSG) productivity database are the International Function Point Users Group (IFPUG) method, and the Finnish Software Measurement Association (FiSMA) function point method.

The function point (or functional) size is similar to the square foot size of a building’s floor plan (or square m) – it is one measure of size – and it works well as part of determining many things.
BUT size is not the same thing as estimation OR AN ESTIMATING TECHNIQUE!

Function point size can be used (along with MANY other factors) to determine work effort to develop (build) the software. Productivity factors or delivery rates (FP/hour) are derived by taking the FP size of a piece of software, together with the work effort hours it took for a team to build it (based specifically on the TYPE of software, the requirements for QUALITY (reliability, accuracy, functionality, usability, etc), the skills, and WHAT TASKS WERE INCLUDED!

Here’s the crux: FUNCTION POINTS DO NOT EQUAL WORK EFFORT HOURS OR COST. While size is a major driver (in the same way that a larger house takes more time to build), the relationship between FP and effort or cost is NON-LINEAR! There are many more factors that just raw size involved in determining the cost and effort to build software.

It may be helpful to consider an analogy (again one based on construction – which is not a perfect analogy but one that serves to illustrate). If I need a 1000 square foot building – can you tell me how long it will take to build? And what can I anticipate will be the cost of that building? The answer is that it depends on MANY factors (such as location, pre-existing structures, type of building: anufactured, or custom or prefabricated or whatever), and many other things. Builders might provide me with an average delivery rate based on STANDARD characteristics (like a standard home with 2 bedrooms and a living room, kitchen and bathroom in the US midwest), and an average effort based on what similar buildings have taken to build IN THE PAST HISTORY. However, there is not ONE rate for all structures – it varies based on location, type of construction, building codes, labor costs, etc.)

The same is true when we consider function point size and the effort and cost it will take to build a piece of software. Consider the aforementioned example applied to software development: How much cost and how much effort will it take to build software that is 1000 FP? The appropriate answer is that it depends on the characteristics of the software, labor costs, methods of construction, AND its functional size. The software measurement and development industry has developed rates of FP / hour and cost per FP for projects with “standard” and similar characteristics (recall the “average” price per square foot or average rate to build?) Note that any “average” rate is BASED ON PAST PROJECTS (that took “x” amount of hours to build a particular size, type, and similarly constrained by quality, system – but there is not a one size fits all rate!

New Book available to explain these and other concepts about Function Point sizing: I am proud of the new book I co-authored with Manfred Bundschuh (formerly the measurement coordinator for AXA Insurance in Germany). It was published in Sept 2008: The IT Measurement Compendium – Estimating and Benchmarking Success with Functional Size Measurement (the Amazon link is featured together with reviews by Capers Jones, and also by Peter Hill (Executive Officer for ISBSG at http://www.qualityplustech.com/stage/books.html).

The book outlines and explains in clear English these concepts and presents all five of the ISO/IEC conformant Functional Size Measurement Methods including the aforementioned two: IFPUG and FiSMA, as well as NESMA from the Netherlands, Mark II from Britain, and COSMIC by the COSMIC consortium.

Have a great week, and please let me know what you think of this and other postings here.

p.s., To all of you who attended my webinar on December 3, 2008 “The Certified Scope Manager (CSM) – A New IT Job Role) sponsored by CAI – thank you! If you missed it, send me an email and I’ll put you in touch with the site that has options to listen to the recording.

Best regards,
Carol

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

Contact Carol for your keynote and speaking needs – she translates technical subjects into easily digestible soundbites – in a humorous and forthright manner. See http://www.caroldekkers.com/ for details of topics and opportunities.

View also Carol Dekkers’ general blog at http://caroldekkers.wordpress.com/

============Copyright 2008, Carol Dekkers ALL RIGHTS RESERVED =============

The Economy and Software Measurement...

Every day I ponder just what power we, as individual homeowners and workers, can do about the mess our economy is in. As the owner of a small business who is reliant on having a steady stream of consulting and speaking clients, business is predictably UNpredictable. Entrepreneurs (like me) get used to the ups and downs of the business and its idiosyncracies and the dysfunctional behavior of corporate leaders.

For example, when the economy is good and business is up, companies will invest heavily in training and process improvement efforts. Yet, when the economy lags or economic growth slows, these same corporations cut out training as an excess “expense”, and drop the non-mandatory (so called optional) programs such as process improvement! This is the opposite of what we do in personal life: when our income drops or the future looks less than positive, we typically start to look for a second job, cut back on non-essential spending, and go back to school for retraining. We certainly don’t stop looking for ways to eliminate waste, find ways to improve, or to do things more effectively – we know that to survive we need to do just the opposite!

Yet business acts uncharacteristically to our personal lives, and does so over and over – each time anticipating different results. (Einstein called this “insanity” — doing the same thing over and over and expecting different results!) Software measurement – the process of gauging and reporting just how well your IT department is performing in order to determine how much better we can do (through process improvement opportunities) – is perceived as “unnecessary overhead” and “not real work”. Yet it is this very evaluation and measurement process that will uncover wasteful processes thereby saving the corporation time and money in the long run. Doesn’t it seem like a downturned economy is the perfect time to determine where there is waste and rework hidden in your systems and software process?

I ask you this, what is a better time than today to figure out how to do things better? When our companies are losing money and squeezing workers ever harder to perform better, wouldn’t that be the ideal time to figure out what NOT to do? It seems logical that major corporations need this information even more urgently in today’s downturned economy. Companies NEED to know how to leverage those processes they do well on — across the corporation, and cease doing (or change how they perform) those processes that result in underperformance and rework.

Everyone is talking about how the bleak outlook on our economy harkens back to the Great Depression, yet a few realists are actually talking about “opportunities” – acan you imagine? The optimists with an outlook toward positive change and opportunities are going to survive and thrive in this new “economy” and will lead the way in showing the remaining majority how business should be done!

Could it be that this is the perfect time to do things right – and focus on getting our corporate houses in order through measurement and comparison of methods? I believe that there has been no more POSITIVE time than now to invest wisely in software measurement rather than spending money the same way we have always done. There is a saying “If you always do what you’ve always done, you’ll always get what you’ve always gotten.” Isn’t today the first day of an improved corporate life?.

Call me (727) 393-6048 office or email me dekkers@qualityplustech.com if you’d like to talk further about how we can work together to improve the bottom line of your IT business. Stay positive, remain resilient, and live for today – and somehow, someway in the silence, common sense and sane solutions will emerge. Software measurement is one of these!

p.s., My newest book was published last week in Germany and is now available in the U.S.! Visit www.qualityplustech.com/books.html to read reviews and link to Amazon.com to order The IT Measurement Compendium: Estimating and Benchmarking Success with Functional Size Measurement.

Best wishes for resiliency and success,
Carol
http://www.qualityplustech.com/stage/
http://www.caroldekkers.com/
Carol Dekkers, PMP, CMC, CFPS, P.Eng.
International software and systems industry expert on ISO standards, estimating, IT measurement. Consultant, Workshop leader, Speaker, Author.

———–COPYRIGHT 2008 Carol Dekkers ALL RIGHTS RESERVED————————