-> Improving Project Estimates

Save. Share. Connect.

Wednesday, July 26, 2017

VOLUME -26 NUMBER 5

Publication Date: 05/1/2011

Advertisements

Front Page News

Tech-Op-Ed

Tech Watch

People in the News

Business News

Management

Electronic Mfg. Services

Electronic Mfg. Products

Production

Partnering

Distribution

Special Features: Components and Distribution

Product Preview: EDS

New Products

Hi-Tech Events

Calendar

Archive > May 2011 Issue > Management >

Improving Project Estimates

By Curt Finch, CEO, Journyx, Austin, TX
Project estimation is extremely difficult without the right data, yet doing it effectively is one of the only ways to ensure the success of the project (and, by extension, the business). Unfortunately, many project managers find themselves unable to answer critical questions like:

How long will the project take?
How many resources will it consume?
What is the appropriate amount to bid on/budget for this project?

Without this information, the project manager can never be sure that the schedule and budgets are accurate. The good news is that the requirements gathering phase of a project can actually provide insight into the length and scope. Here is an example of how this method works and how it can be implemented into any company.

The Wrong Way
In 1992, while working for a consulting company called The Kernel Group (TKG), our team's task was to port Tivoli's software from Sun's Solaris operating system to IBM's AIX operating system. The project was to be done under a fixed bid, so estimating the effort required to port the code was of paramount importance.

Our team examined the code thoroughly. Some members thought that the million or so lines of code could be ported in about two days. Others thought it would take at least a week, maybe even two. The team jointly decided that we should estimate for three weeks, just to be safe. As a result, our project bid was $325,000.

Once the project began, we discovered how inaccurate our project estimation was. The porting schedule expanded to exceed our original estimate and we consumed not only all of the $325,000, but much more on top of that.

The Right Way
TKG employees were required to track time on a per-project basis, and every project was broken into phases: requirements/specification, design, coding, testing, debugging, documentation, training, etc. The project for Tivoli was no different.

There is a very useful book by Robert B. Grady called Practical Software Metrics for Project Management and Process Improvement. Grady believes that the

requirements/specification phase generally takes up 6-8 percent of the time it will take to complete the entire software project. He uses this formula to estimate total project size, meaning that if it took 60 hours to do the specification, one can infer that the total job will take 1,000 hours. Since the specification always comes first in any project, one can get some pretty reliable estimates from this method alone.

After the huge mistake on the Tivoli project, our team learned its lesson. When the next project came around, we used Grady's ratio to predict overall project size based on the length of the requirements phase. This time, we came up with a very accurate project estimate and continued to use the process to our advantage for all of the subsequent fixed-cost consulting work we did for Tivoli. Due in part to the strength of the solution and how well it ran on IBM's AIX operating system, Tivoli was able to eventually sell the company to IBM for $743 million in 1995.

Measuring Progress
So how does a project manager know when they've reached their goal for estimation process improvement? One way is to use a key performance indicator, which measures progress towards a strategic business goal. A key performance indicator is "key," which means that the KPI has to be one of a very small number of things believed to make a huge difference to the business long-term that the company is going to measure. If a company has 100 KPIs, it is not going to be able to use any of them to drive organizational behavior because the company doesn't have 100 strategic goals. Ten KPIs can be effective, five KPIs are better, and one KPI is ideal.

For example, one might use the formula [(EA)/E], where "E" represents estimated hours to complete the project and "A" represents actual hours spent to complete the project. It is important to keep this KPI value as close to zero as possible, which indicates that the projects are bid more accurately. One can obtain the necessary data to calculate this from any timesheet system, including a paper one. Automated timesheet systems, however, can actually provide reports to calculate the KPI figure.

Improving adherence to the estimate can be difficult for some companies until they understand the ratio concept described above. A company's magic number may not be 6-8 percent like Grady suggests, but once a company determines its own ratio for specification to total project length, it can be used again and again.

"Percentage of projects profitable" is a KPI that can really affect a business in a positive way. As an analogy, a large oil company created a strategic vision which they termed "no dry holes". Drilling for oil and not finding it is expensive. Rather than try to make up for all the dry holes by finding an occasional gusher, the company decided to try to never have a dry hole in the first place. Changing the attitude that dry holes were an inevitable cost of doing business fundamentally changed their culture in very positive ways.

Some companies also have dry holes — projects which lose money for the company. Due to an inadequate understanding of costs, many of these go unnoticed. If a strategic goal is set for a company of "no unprofitable projects," it will change the nature of discussions in the business. For example, it empowers frontline employees to legitimately push back when a project is being taken on for political reasons. Conversely, having the attitude that the winners will make up for the losers doesn't do this. Getting direct per-project cost data is easy. Correctly applying indirect data (such as sales or accounting time) to the direct costs is a bit more complicated. Connecting all of this to revenue data shows per-project profitability. Once this data is in hand, the KPI of "percentage of profitable projects" can be maximized. The formula for this KPI for a given time period (usually a quarter or a year) is:

# of profitable projects/# of projects

This number should be as high as possible. Even if a company is willing to lose money on a few strategic projects in order to enter a certain market, the company should determine how many projects it is willing to do that on, and keep the losses around that area reasonable.

Using the length of the requirements gathering phase to predict total project length is an effective technique that will enable any company to start producing laser sharp estimates immediately. Checking the progress with a key performance indicator will let a company know when it has succeeded, and the benefits will keep coming.

Contact: Journyx, 9011 Mountain Ridge Dr., Ste. 200, Austin, TX 78759

512-837-5493 fax: 512-834-8858 E-mail: curt@journyx.com Web: http://pr.journyx.com

Add your comment:

Full Name:
E-mail:
Subject:
Comment:
Type the code from the image