Project Management Analytics: 3 Tools to Estimate Scope Failure, Cost, and Time

During the last three decades, I have encountered three tools that have left indelible marks in my memory. They have useful, usable, and used in every area of my work life. I share them with the A2 community because I believe that you will enjoy them as much as I have.

The first tool is used to estimate scope failure; it is used to assess risk/exposure to failure of a task. Using a three-point scale, wherein 1=LOW, 2=MODERATE and 3=HIGH, (1) you define a risk event, (2) assign values to the probability of failure and the severity of failure, and (3) multiply the probability by the severity to generate a risk score. This risk score helps you to determine which tasks should receive top priority in preventing failure. For example, suppose you have to prioritize two tasks -- update the payroll system and update the landing radar for the company jet. Let's say that you say that the payroll system has a moderate chance of failure (value=2) and that the severity would be high (value=3; people like to be paid). Hence the risk score would be 6. Let's say that the landing radar has a low probability of failure (value=1) and that the severity would be high (value=3). That risk score would be 3. Therefore, resources would be directed to updating the payroll system. While the failure of either task would be severe, only one was deemed likely to happen.

(Image: ESB Professional/Shutterstock)

(Image: ESB Professional/Shutterstock)

The second tool is PERT -- the Program Evaluation and Review Technique. PERT is a tool developed by the US Navy. It is used to estimate the time needed to complete tasks. The technique follows this formula: ET=(OT+4(MLT)+PT)/6 -- Estimated Time equals the sum of the Optimistic Time plus the product of 4 times the Most Likely Time plus the Pessimistic Time, divided by 6. For example, you want to estimate how long it would take to update the payroll system, and you get three estimates from your technical team. The shortest time estimated is 3 weeks, the longest time estimate is 8 weeks and the most likely time estimate is 6 weeks. The PERT formula is ET = (3+24+8)6; the estimated time is 5.83 weeks. Let's say that the pessimistic estimate was 20 weeks instead of 8, then the estimated time would be 7.83 weeks. Hence while the most likely time estimate has the most influence, the input from the most extreme estimates is not completely ignored; everyone's input receives attention.

The third tool enables one to estimate how much human capital will cost to complete a project. The formula is Estimated Cost = (Projected Hours Needed to Do a Task/Percent of Productive Hours)/Percentage of Time the Resource is Available for This Task)*Hourly Pay Rate. For example, if updating the payroll system would take 40 hours, and the senior developer would be productive 80% of the week to do the work (i.e. -- not taking naps), available 33% of the week, and earned $50/hour, then that resource would cost $7,600-rounded [((40/.8)/.33)*50]. If you increase the developer's availability from 33% to 85% (the other stuff will have to wait) then the cost drops significantly to $2950-rounded [((40/.8)/.85)*50].

In effect, these three tools have shown that:

  • Updating the payroll system is a higher immediate priority vis-à-vis updating the landing radar system.
  • Updating the payroll should take 5 to 6 weeks.
  • The cost of updating the payroll system will decrease as you increase the availability of the senior developer.

I hope that you find these project management analytics helpful. Do you have any special tools that are sharable? If so, then please do!

Bryan Beverly, Statistician, Bureau of Labor Statistics

Bryan K. Beverly is from Baltimore. He has a BA in sociology from Morgan State University and an MAS degree in IT management from Johns Hopkins University. His continuing education consists of project management training through the ESI International/George Washington University programs. He began his career in 1984, the same year he was introduced to SAS software. Over the course of nearly 30 years, he has used SAS for data processing, analytics, report generation, and application development on mainframes, mini-computers, and PCs. Bryan has worked in the private sector, public sector, and academia in the Baltimore/Washington region. His work initially focused on programming, but over the years has expanded into project management and business development. Bryan has participated in in-house SAS user groups and SAS user group conferences, and has published in SAS newsletters, as well as company-based newsletters. Over time, his publications have expanded from providing SAS technical tips to examining the sociological, philosophical, financial, and political contexts in which IT is deployed. He believes that the key to a successful IT career is to maintain your skills and think like the person who signs your paycheck.

Use It or Lose It: Is This the Best Way to Manage Budgets?

Are you getting ready to spend all the money left in your budget so that you don't end up with a smaller budget for 2018? Is that the right way to do things?

Capta: The Data of Conscious Experience

Phenomenological researchers say "capta" is the "data of the conscious experience." Is there room for this kind of data in analytics? How should analytics pros use it?

SUGI Paper on Evaluation and Forecasting
  • 11/9/2017 10:34:08 PM

Re: meetings
  • 11/7/2017 1:42:59 PM

Perfect! I'm not important enough to get a rank of 2 or better for Step #1. No more meetings for me!!!

Re: meetings
  • 11/7/2017 11:23:41 AM

@Michelle, try this please:


  1. Rank your value to the meeting (1=LOW 2=MOD 3=HI)
  2. Rank the meeting's value to you (1=LOW 2=MOD 3=HI)
  3. Multiply the values and rank > 1-3 - Don't go; 4-6 Go but leave early to take a cell phone call; 7-9 Go and stay.

Hope this helps!

  • 11/6/2017 1:59:21 PM

Each of these sounds like a compelling solution. I wonder if one can be adapted to help me determine the potential usefulness of a meeting... :)