« The 12 Attributes of an Effective Project Manager
It Is Your Job to Protect the Project Scope! »

Project Estimation Using “Use Cases”

July 5, 2010 | Author: PM Hut | Filed under: Cost Estimating, Scheduling

Project Estimation Using “Use Cases”
By Samuel Prasad

As a technology executive and a passionate software engineer I am disappointed at the high rate of project failures in the software industry. According to the 2009 report from the Standish Group, almost 68% of the projects were canceled, delivered late, did not meet product specifications or were over budget. I find this appalling. Is it because many workers in the software industry are incompetent? Well, my guess is that most technology managers tasked with estimating the cost of a project have no experience or training in the use of formal methods based on empirical research to compute the time, cost and resources required by a software project.

We all know that most manufacturing industries are able to control cost, schedules and quality most of the time. If they can, why cannot the software industry? The Standish Group states that project delays and cost overruns seem to account for almost 44% of all software projects.

One of the process that has worked quite well for me is “Estimation Based on Use Cases”. I am a fan of Alistair Cockburn and strongly believe that “use cases” are one of the best ways of describing software requirements. According to Mr. Cockburn, a use case describes the system’s behavior under various conditions as it responds to a request from users. The user initiates an interaction with the system to accomplish some goal. Different sequences of behavior, or scenarios, can unfold, depending on the particular requests made and conditions surrounding the requests. Use cases in their most primitive forms are basically representative of what the user wants from a system.

How can we estimate the time, cost and resources required by a software project from “use cases”? I have used the following approach quite successfully in many of my projects.

  1. Identify all the use cases that make up the system. Assign weights to them based on the technical complexity of implementing each use case. My suggestion is to keep it simple and assign weights of 3, 2 and 1 for user cases of difficult, average and simple technical complexity which are used to compute the Technical Complexity Factor (TCF) of the project.

    For example, assume that a project has 100 use cases, where 20, 30 and 50 uses cases are of simple, average and difficult technical complexities respectively.

    TCF = (20 * 1) + (30 * 2) + (50 * 3) = 230

  2. Similarly, identify the various users (actors) of the system and assign weights. For example, a user that interacts with a screen is assigned a weight of 1. Other types of interactions (also known as interfaces) between software components are assigned weights of 2 and 3 depending on the nature and whether the interactions are with internal or external software components respectively.

    In our sample project which was made up of 100 use cases, let us assume that there are 30 uses cases that describe screen interactions, while 40 and 30 use cases respectively have interfaces with internal and external components respectively. We can now compute the Actor Complexity Factor (ACF) of the project as follows:

    ACF = (30 * 1) + (40 * 2) + (30 * 3) = 200

  3. Assuming a contingency and management risk of 15%, the final effort of the project in work units (WU) is:

    WU = TCF * ACF = ( 230 * 200 ) * 1.15 = 52,900 work units.

  4. The number of work units that a person can complete in a day is obviously dependent on the person’s skills and technical expertise. If we assume that an average person can complete 10 work units per day then the total number of person days required to complete the project is WU / 10 = 52,900 / 10 = 5,290 days.

  5. Assuming a team size of 20 (i.e., a team velocity of 200 work units per day) and allowing for a 40% path concurrency the project will most likely be completed in = (5,290 / 20) * 0.6 = 159 person days.

Try it out and let me know if this methodology works for you.

Dr. Samuel Prasad is a renowned global technology manager with a 15-year track record in helping companies on their implementation of strategic plans and programs related to technology projects for major media, entertainment, data warehousing and financial companies in the U.S., China, Europe and India. His domain expertise extends into areas of financial transaction processing, mobile, wireless, RFID, online media, casual gaming and business intelligence. Sam is a certified Project Management Professional (PMP) and a Certified Software Quality Engineer (CSQE). Sam has a Ph.D. in Robotics & Computer Science from the Stevens Institute of Technology (USA), and a master’s degree in Computer Science from the Indian Institute of Technology. Dr. Prasad can be reached at Intelligent Software Systems. Blog: http://blog.prasads.com/ - Email: blog@prasads.com - Telephone: 631-368-8130

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

This entry was posted on Monday, July 5th, 2010 and is filed under Cost Estimating, Scheduling. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

3 people have left comments

I don’t think it’s a fair to draw a comparision between a manufacturing process and a software project.

Software vendors can control cost and quality when producting their shrink wrapped software products.

A fairer comparision could be between construction projects and software projects. Both build something unique from scratch to specific requirements and every project is different.

However the construction industry maintains very good historical cost analysis of unit rates for different types of work and employes teams of experts to manage the cost information.

In an IT project the cost is often set before the plans are defined and so it’s very eaasy to get it wrong. its also very hard to describe to a business owner why the feature they want for their IT project is more akin to adding a whole new storey on a building than a change in paint colour.

Construction projects often have major overruns as well like discovery of unstable soil in the building site. IT projects often have similar assumptions that may or may not be apparent to the project team and the customer.

John Tailby wrote on July 5, 2010 - 11:10 pm | Visit Link

Construction projects often have major overruns as well like discovery of unstable soil in the building site. IT projects often have similar assumptions that may or may not be apparent to the project team and the customer.

Simple way to describe yhe bill of qty n Estimation should be in the clear module according to the labour management

omprakash.G wrote on July 9, 2010 - 1:37 am | Visit Link

For the following calculation from above:

3. Assuming a contingency and management risk of 15%, the final effort of the project in work units (WU) is:

WU = TCF * ACF = ( 230 * 200 ) * 1.15 = 52,900 work units.

Where did you get the 1.15? you said assume 15%?…

5. Assuming a team size of 20 (i.e., a team velocity of 200 work units per day) and allowing for a 40% path concurrency the project will most likely be completed in = (5,290 / 20) * 0.6 = 159 person days.

In this calculation, you said allow 40% path currency. so where the 0.6 came from?..

Tedpre wrote on October 19, 2010 - 6:05 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories