on target

Who is the villain? Measure how much users are responsible for the overrun

Overrun and delays are usual in IT projects and are a major cause of attrition between users and IT staff. Whenever such situations occur IT staff try to find causes and reasons that seldom persuade users.

Wouldn't be great if we could exactly quantify why the estimate was wrong and who is responsible for that? Let's see how to use Function Points, that were presented in a previous post, to compute this number.

First of all, let's see what usually happens. Here is a typical situation shown as a Venn diagram showing the original scope of application compared with delivered version X.

 

What actually occurred is an escalation of functionalities from original requirements to implementation. During that period users discovered new needs: extra functionalities required to operate the application,additional validation, more configuration options... The result is a system quite larger that the original one. Users also realized that something they originally asked was deprecated (would not make sense any more). This is represented by the light blue area of our diagram (requirements not covered by implementation).

Well, we all know that things run usually that way, but how can we prove that our delay or overrun is due to the fact that our users changed their mind?

The trick is to measure FP at several stages of life cycle or iteration if you employ an iterative development method (agile, SCRUM ...).

Manually counting FP can be expensive, and, if you really decide to employ FPA, I suggest some kind of automated tool. An automated extractor can be run weekly and will provide extra information like delivery rate and the exact evolution of each single functionality (newly introduced, in development, implemented, deprecated...) This is the kind of evidence your users will ask when big FP discrepancies will result from compare.

I will cover, in a future post, a free automated tool to extract and compare FP from requirements, use cases and source code. Stay tuned!

And now, supposing we only have two counts (requirement and implementation) let's see how to separate overrun due to moving requirements (user responsibility) from technical overrun (IT responsibility).

We will use a typical example for an application that was estimated to be delivered in 84 days but take 120 days thus a 42.86% overrun.

[A] FP count extracted from original requirements = 240 FP

[B] FP count extracted from source code at delivery time = 387 FP

[C] Planned elapsed time = 84 days

[D] Planned delivery rate = 240 FP / 84 days = 2.86 FP/day

[E] Requirements increase = [B] - [A] = 147 FP

[F] Moving requirements overrun (user responsibility) = [E] / [D] = 147 / 2.86 = 51.45 days

[G] Actual elapsed time = 120 days

[H] Total overrun = [G] - [C] = 36 days

[I] Technical overrun (productivity, poor estimate) = [H] - [F] = -15.45

Yes, Technical overrun is negative, this means that it is not an overrun but a gain! If the original productivity estimate were kept the project would have been 15.45 extra days late. From villains to heroes with some simple math!

Interested in partnership?

Would like to try or coach this technique with your clients, do you need any additional or technical detail? Please let me know! Component Bases Solutions has great interest in partnership with consultants. We can help you automate your proposed solutions in a very short time. We can also help to increase your visibility through links from many management tools we make freely available on the Web. Please contact for more detail.

Did you like this post?

Please, spend a few seconds and click on button below to socially bookmark it or tweet it. It will help to promote this blog and improve its content, Thank you!

Posted at 12:40AM Jan 22, 2009 by admin in IT  |  Comments[1]