A recent series of posts by Karl Wiegers eloquently discusses the "reality of tradeoffs" software professionals deal with every day, going beyond the typical success drivers (time, cost, and quality) to include product features and staff. He shares inspiring practical information by making distinctions between constraints, drivers, and degrees of freedom, each representing the amount of flexibility the project manager has to adjust a key factor.

SLIM-Estimate has modeled the non-linear interdependencies of these metrics for over thirty years. It accounts for Wiegers’s five project success factors explicitly, showing the tradeoffs between them in real time. I have mapped Wiegers’s Five Dimensions to SLIM-Estimate’s parameters to show how you can use SLIM-Estimate quantify the trade-offs Wiegers describes.

I have been enjoying Alan Cohen's A Deep Breath of Life. I read it every morning with pen in hand, never failing to find at least one or two profound sentences to be my watch-words for the day. One of the July writings contains this quote: "Only infinite patience begets immediate results."  David writes about the perils of rushing through life, and how a lack of patience can causes us to create unnecessary chaos in our daily rounds. He writes, "Rushing never improves the quality of our life or the results we seek; to the contrary, it muddles our vision and causes us to make errors that cost us twice as much time and energy to repair."

One of my first thoughts was about my work at QSM, and how SLIM-Estimate demonstrates the power of patience in software development. Is it possible to exercise patience when there are important business objectives and profit margins to achieve? The Putnam software production equation, backed by 30 years of industry data, shows that relaxing the project schedule gives the best “bang for your buck” to produce value for your customers.

I am often asked this question during SLIM Training classes.  I remember wondering about that myself.  It is a logical question since SLIM-Estimate workbooks are often imported into SLIM-Control to create the baseline project plan.  The answer is ‐‐ they are not directly related, because uncertainty ranges, probability curves, and control bounds are designed to perform different tasks.  This post is the first in a series looking at risk associated with an estimate, risk of your project plan, and handling deviations from the plan.

What are we talking about?

The first thing we need to do is define some very important terms that are often misused (I am the first to admit I have been guilty!).  I went to good old Dictionary.com and looked up the following:

A colleague of mine recently sent me a blog post explaining the difference between project contingency and padding.  The blogger made the distinction that padding is what often gets added to an individual’s estimate of the effort required to perform a task (in her example, a software development task) to account for project ‘unknowns’.  The estimator determines the most likely required effort, then pads it with a little more effort in order to arrive at an estimate to which he or she can commit.  Thus, padding represents an undisclosed effort reserve (and implied schedule reserve) to buffer against potential risk.  Contingency reserve, she explains, is “an amount of money in the budget or time in the schedule seen and approved by management.  It is documented.  It is measured and therefore managed.”  Ms. Brockmeier is correct in promoting contingency as the better management tool.  The challenge is having a method to measure and document this contingency and the known unknowns it is buffering.

Implicit Risk Buffer

Padding is a natural result of bottoms-up, effort-based estimation techniques.  Estimating low-level WBS elements creates more opportunity for padding, because the number of unknowns grows with the task list.  The estimator is consciously or unconsciously assessing the risk of each task, considering its dependencies and complexities.  What is being implied in the effort estimate is: 1] an assessment of product size and complexity, and 2] a productivity valuation.

After being away from QSM and the software world for three years, I was blown away by SLIM v8.0's dynamic product integration. I knew it was coming, yet I was still impressed by the simplicity and power of analysis promoted by real-time data and tool links across the SLIM Suite that frees managers to focus on the important program issues.

SLIM-MasterPlan is the center of the SLIM Suite product integration.  It improves upon previously existing program management features of aggregating multiple SLIM-Estimate projects and ancillary tasks with two new capabilities: 

• Linking SLIM-Control workbooks to provide real-time project tracking and control at the program level 
• Performing What If analysis at this higher management view to consider a wider range of potential outcomes.

The What If analysis feature is what I want to highlight.

A good personal development coach knows the "power of the question."  Questions lead to discovery, innovation, and action that brings about positive change.  Better questions lead to better answers.  SLIM's power and distinction has always been fast and easy evaluation of the impact of change, and exploring the realm of possible outcomes.  That's what we are doing when we ask ourselves "What If…?" (or our boss asks us - and we better know the answer!).  SLIM's solution logs make it easy to compare estimates, plans, and forecasts to alternative solutions, QSM trends, and your historical project database.

Have you ever been excited to discover a new use for something familiar, like learning that lighter fluid can be used to remove ink stains from your clothes?  I recently discovered a way to leverage the tie between SLIM-Estimate and SLIM-DataManager that I was previously unaware of.  

My limited view of SLIM-DataManager as a tool for historical data and SLIM-Estimate as a tool for software project estimation limited my creativity in applying the rich set of capabilities in the entire SLIM tools suite.  I recently observed a more experienced SLIM user use both tools to model a history project where very little data was available, using both applications.  Here is a description of the situation.

Scenario: 

You have gathered metrics from a completed project to serve as the basis of estimation for your next project.  Software size, lifecycle effort, lifecycle duration (phases 1-3), and defects are known, but you do not have a break out of individual phase data.  How can you best model this project and capture the results in SLIM-DataManager?

Solution A: