Risk Management

Risk Management

Bringing Transparency into Project Contingency Buffers for Schedule and Cost

The application of contingency buffer, more commonly known as “padding” or “management reserve” is the final step in any project estimation process.  The most common practice is for the estimator to use an intuitive multiplier which is added to base estimate.  Unfortunately, everyone has a different multiplier which is shaped by their own personal bias about risk and it is hidden in their head.  This creates a fundamental problem with transparency and consistency within most organizations.

Fortunately, there's a better way.  One solution is to define and configure agreed upon standards that are matched to specific business risk situations.  These should be collaboratively agreed to by all the stake holders in the organization.  Then they can be codified into a configuration that can be selected at the time when contingencies are typically applied to an estimate.  This helps solve the consistency issue.

Project Risk Buffer

To attack the transparency issue, you can use a technique of overlays to visualize the contingency in comparison to the base estimate. 

Project Risk Buffer

Using Business Analytics to Set Realistic Customer Expectations

I was recently reading an article by Moira Alexander titled “Why Planning Is the Most Critical Step in Project Management” and I was stuck by her observation that one of the primary reasons that projects fail is because they commit to unrealistic expectations.  In my 35 years of experience, I believe this is the number one reason projects fail.  Yet it is competence that few organizations or product owners ever get good at.

 Today there are good simulation tools that make it simple to establish realistic project boundaries.  The results can be used effectively to communicate and negotiate expectations with clients.  

For example, imagine that you are a product owner planning out your next release.  Your team of 10 people has been working on a 5-month release cadence.   A backlog refinement has shown that there are approximately 100 story points to be completed in this release.  The project plan is shown in the figure below.

Agile Uncertainty

However, there are some uncertainties and we need to deal with them in a realistic way.  Since the schedule and the team size are fixed, the only area that can give is the functionality.   Simulations are a great way to quantify uncertainty.  In our case, we are confident in our team’s productivity and labor cost, but we are somewhat more uncertain about the new capabilities in this release.   It is easy to adjust the uncertainty settings and run a business simulation.  The uncertainty slider bars are in the image below. 

Blog Post Categories 
Estimation Risk Management

Roots Run Deep: The Journey to Software Application Estimation and Risk Management

The story of QSM and software application estimation begins during my time in the Army. I was assigned to Sandia Base, NM to research methods for protecting soldiers from the effects of nuclear explosions.  I had to do several calculations to determine the impact of an explosion (blast calculations) on soldiers using a slide rule, which was very tedious.  Sandia National Laboratory was next door to my office, and they had just gotten the biggest and best engineering computer available at the time.  They offered computer time for anyone needing it and even offered to teach me programming, so I decided to take a course in FORTRAN programming over my lunch hour so I could do my blast calculations quicker. These lessons aided me in completing my work at Sandia and followed me to my future assignment at the Pentagon. 

For my tour at the Pentagon in the 1970s, there was not a lot of need for my nuclear experience so I was assigned to the Army’s computer program. We had to defend our program budget to the Department of Defense (DoD) budget review authority (OSD). One system, SIDPERS, the Army enterprise personnel system, had been in development for five years and after having a peak staff of 110, we were projecting 93 people for the next five years. The analyst looking at the budget asked what should have been a simple question, “What are these people going to do?” I did not have a good answer, and later, going back to the project team, neither did they. Because of this we lost $10M in our budget.

Blog Post Categories 
Estimation Risk Management

Cut the 'Madness' Out of Software Estimation

The time has come, once again for QSM’s annual March Madness tournament.  As we enter our 6th year of friendly office competition, I looked back at some of my previous strategies to help me figure out how I wanted to go about completing my bracket this year.  In doing this, I realized that many of these concepts can be applied towards IT project management.

Three years ago, I built my bracket around an emotional desire for my preferred team to win.  I paid very little attention to their previous performance that season, or any of the other teams for that matter.  Needless to say, I did not do as well as I had hoped that year.  Unfortunately, this strategy is applied fairly frequently in software estimation, with stakeholders committing their teams to unreasonable schedules and budgets for projects that are “too big to fail.”  Committing to a plan based off of the desired outcome does not produce a good estimate, and often results in cost overruns and schedule delays (or in my case, quite a bit of ridicule from the Commish).

Blog Post Categories 
Data Estimation Risk Management

Are Late Software Projects a Victim of 'The Planning Fallacy'?

Software Project Planning FallacyToo many projects are late, over-budget, under-delivered, or a combination.  The problems continue despite widespread awareness and improvements in project management knowledge, tools, and process maturity.  

A recent piece in the Washington Post business section identified a likely culprit: “the planning fallacy”.  Princeton psychologist Daniel Kahneman and Amos Tversky of Stanford describe it as “the tendency to underestimate the time, costs, and risks of future actions and overestimate the benefit of those actions”.  The results are time and cost overruns as well as benefit shortfalls.  The concept is not new: the pair coined the term in the 1970s and has been researching it since.

According to the Post, cognitive biases such as optimism bias (the tendency to expect positive outcomes from one’s actions) and overconfidence can be causes of the planning fallacy. There is a growing body of evidence, collected by researcher Bent Flyvbjerg at Oxford University, that optimism bias is an important bias affecting the quality of forecasts in project planning. 

Other explanations of the fallacy include possible intentional and deliberate considerations on behalf of the planner - such as incentives, organizational pressures and strategic deception. 

Blog Post Categories 
Risk Management Project Management

Making Project Decisions Early is Risky Business

At QSM, we have one of the largest industry databases in the world of completed software projects. The data comes from our clients with their permission and this data has been the backbone of our software estimation business for over 35 years. We can see what is reasonable on software development projects as it relates to cost, team size, effort, duration, size, and reliability. Because of our experience we are often asked about risk factors and estimation accuracy early in the project lifecycle. We explain that increased accuracy comes with having historical data and good sizing information.

But what happens on the early estimates when clients don’t have history and detailed sizing information? Can they still generate scope level estimates so they can make good business decisions? The answer is yes. Risk management techniques can be applied and project uncertainty can be calculated so organizations can plan effectively. This is very important because big business decisions are often made early. Decision-makers need to know if they should move forward with a project and they need to know how much time and effort to allocate.

We use SLIM-Estimate, which is a leading estimation tool that leverages the Putnam Model. It generates reliable estimates based on QSM’s time-tested forecasting models and historical data and it also provides scope level estimates when project information is hard to find. It will allow you to see the chance you have of hitting your project goals and it will allow you to factor in your uncertainty.

Blog Post Categories 
Risk Management Estimation

Managing Project Risk through Early Defect Detection

Managing Software Project RiskWith the most recent spurt of inclement weather, there is really no denying that winter is here.  After awaking to about 4 inches of snow accumulation, I begrudgingly bundled myself up in my warmest winter gear and proceeded to dig out my car.  Perhaps the brisk air woke me up faster than usual because as I dug a path to the car, I began to think about software testing, specifically how effective early testing can reduce the chances of schedule slippages and cost overruns.  Allow me to explain.

Being an eternal optimist, I was grateful that the snow I was shoveling and later brushing off my car was light and powdery.  Despite the frigid temperature and large quantity of snow, I realized that it was good that I had decided to complete this task first thing in the morning.  At the time the snow was relatively easy to clear, and had I waited until the afternoon, the sun would have melted enough of the snow to make this task significantly more difficult and time consuming.

From Proposal to Project: An Interview with Larry Putnam, Jr.

In the software project management field, projects go badly about 43% of the time and fail completely 18% of the time. While there are several reasons for this, and plenty of blame to go around, one of the easiest ways to reduce the risk is to start at the beginning – with the proposal. In a recent interview with Cameron Philipp-Edmonds of StickyMinds, Larry Putnam, Jr. talks about the importance of the proposal when executing a successful project. He identifies five key questions that should be answered before any project starts and how software estimation ties into the proposal process.

Read the full interview transcript here!

Modeling Uncertainty in Software Development Projects

I am a professional software project estimator.  While not blessed with genius, I have put in sufficient time that by Malcolm Gladwell’s 10,000 hour rule, I have paid my dues to be competent.  In the past 19 years I have estimated over 2,000 different software projects.  For many of these, the critical inputs were provided and all I had to do was the modeling.  Other times, I did all of the leg work, too: estimating software size, determining critical constraints, and gathering organizational history to benchmark against.  One observation I have taken from years of experience is that there is overwhelming pressure to be more precise with our estimates than can be supported by the data.  

In 2010 I attended a software conference in Brasil.  As an exercise, the participants were asked to estimate the numerical ranges into which 10 items would fall.  The items were such disparate things as the length of coastline in the United States, the gross domestic product of Germany, and the square kilometers in the country of Mali: not things a trivia expert would be likely to know off hand.  Of 150 participants, one person made all of the ranges wide enough.  One other person (me) got 9 out of 10 correct.

Blog Post Categories 
Risk Management Estimation

Seven Steps to Software Project Failure

In spite of 30 years of structured programming, CASE tools, OO development, 4th GL languages, CMMI, and PMI, the failure rate for larger projects has failed to respond to all of this love and attention. We normally think of failure as a negative thing; but it can have its upside. Saddling a competitor or enemy with a doomed project could stain their career or at the very least inflict a high level of pain on them. A CEO about to retire, or whose focus is on near term stock options, may be able to boost quarterly profits by continuing to add staff to a doomed effort:  one for which the customer pays for the added staff, of course.

Since failure is a constant, here is a management guide on how to assure failure. While any one step in the process can be overcome, taken together they create the perfect software project storm.

Step 1: Start work as soon as you can

Come on. You don’t really need to spend all that time in requirements meetings and documenting assumptions. Real projects take the ball and run.  Be sure to begin coding as quickly as possible. Call it prototyping if you will; but do get started. You can always circle back to tweak things if needed.

Step 2: Estimation is overhead

Nothing is more frustrating and time wasting as having to go to some external group who know nothing about your project and have them tell you how long your project should take, how many people should be on it, and what the trade-offs are. What can their mathematical models possibly know about your project? A good end run around this situation is to create a project plan and call it your estimate. Make sure that it is very detailed and contains decimal points, since these will make it more difficult to challenge.

Blog Post Categories 
Risk Management Program Management