Part 2 of a 3 part series
[Editor’s note: read the first article in this series,
The Build versus Buy Decision.]
Have you ever heard of a critical business issue (CBI)? Many employees
believe there is something that might get them fired or put in jail if they
screw up again.
For most IT managers, inaccurate estimates constitute a CBI. Why are accurate
estimates so important? There are basically two reasons:
- Inaccurate estimates cause overcommitment. Have you ever
worked in a place where 10 percent of 10 projects got done instead of 100
percent of one project? Ultimately, nothing is accomplished and everyone is
totally stressed out. Inaccurate estimates cause overcommitment of time, yet
not much gets done.
- Inaccurate estimates cause bad decisions. “Inaccurate”
usually means “too low.” When this happens, the return on investment (ROI)
calculation shows the project as “worth it” when it is not.
How can you stop wasting your company’s resources on projects that are not
worth corporate time? Hewlett Packard (HP) gave us the answer over a decade ago
in Robert Grady’s book, “Practical
Software Metrics for Project Management and Process Improvement.” In it,
Grady provides a few insightful rules of thumb that are backed up by real
numbers, such as:
Six to 8 percent of software project time is spent in the requirements
and specifications phase.
This is based on statistics from numerous software projects at HP, so the
percentage at your company may be different. The good news is that for projects
of a particular flavor, you will find that the percentage usually doesn’t vary
widely, so you can use it to predict all project efforts required for
completion.
Example #1: New Application Roll Out
XYZ Corporation, a large organization, has a group of IT projects. XYZ’s
IT shop likes to write special applications on a regular basis (rather
than be slaves to SAP or Oracle) and they’ve discovered all projects
have the following phases:Requirements. What the
internal client wishes XYZ would do.
Specifications. What XYZ is actually going to do.
Design. How XYZ is going to do it.
Coding. XYZ writes the application.
Testing. XYZ tests that it works internally.
Rollout. XYZ puts it into production.
Debug. XYZ does the first 90 days of maintenance.
After tracking time accurately on seven projects of this flavor,
XYZ’s CIO finds that 6 to 15 percent of engineering hours are spent on
the first two phases; taken together they average 10 percent. |
| |
Example #2
Now a new project comes up, the wiz-bang application integration
project. It has the same flavor as the seven projects in example #1; and
three engineers spent 100 man-hours on the requirements and
specifications phases.
How long will it take them to complete the entire project? Somewhere
between 667 hours and 1,667 hours with 1,000 hours being the most likely
number. Why? Because rounded, 6 percent of 1,667 is 100; 15 percent of
667 is 100; and 10 percent of 1,000 is 100. In other words, you can
predict overall project length from the time spent in the earliest
phases.
Estimates of function point counts, lines of code, and number of
connections to other IT systems can also be used as metrics to
corroborate the estimate produced from timesheet data. For example, if
you estimate this project at 10,000 lines of code and your IT shop
produces 10 lines per hour on average, this is then a 1,000-hour
project. Does that estimate agree with the timesheet estimate or not?
|
Never Underestimate the Value of Accurate Estimates
There are important advantages to be gained when working with
accurate estimates:
- Over commitment is reduced. Instead of completing half of two projects,
you don’t even start one of them until you finish the other.
- Your credibility as a manager increases with both employees and
executives.
- Your employees won’t suffer from burnout.
- You save your company money.
Don’t underestimate how much money can be saved by never starting projects
that you know won’t get finished. If your IT shop has 100 engineers and they
each cost the company $100,000 per year, that’s a 10,000,000 dollar annual
budget. For many companies, that number is doubled. When IBM instituted the
RS-Plan project in AIX development in the 1990’s to reduce the start of
“unfinishable” projects, it discovered that 30 percent of projects started
required resources that they didn’t have. Once they worked out a system to
just not start them in the first place, they saved more than $90 million;
every year.
Look around. You’ll probably find you’ve got a similar kind of waste going on
in your company. Tracking employee time is the first step to fixing it.
[Editor’s note: Coming up in part 3: how to spot profitability leaks and
cost overruns in IT projects way before your peers – and then fix them.]
About the Author
Curt Finch is the CEO of Journyx,
a provider of web-based software located in Austin, Texas, that automates
billing, payroll & project management by tracking time, expenses and mileage.
Curt can be reached at curt@journyx.com.