Scope creep is a frequent topic of discussion among project management professionals.  A recent Project Management Institute (PMI)^® i Community Post, Fighting the Dreaded Scope Creep, reported some responses PMI members offered as their weapon of choice.  The various suggestions can be summarized by two general practices:

• Avoid making on-the-spot decisions (uninformed or politically motivated)
• Communicate the impact of the change to stakeholders and let them decide (analyze the cost, schedule, and risk impact)

Regardless of the specific practice, all of the recommended defenses included some process for change control.

I like words.  When I need to understand a topic, I pull the dictionary off the shelf (or access the online version), and look at the basic definition.  To determine why scope creep is such a formidable enemy, I looked up the word “creep”:  2. to approach slowly, imperceptibly, or stealthily; 4. to sneak up behind someone or without someone's knowledge.  A vast majority of results from a general internet search defined scope creep as “uncontrolled change.” 

As more of our clients adopt Agile methods, they often wonder how SLIM-Estimate fits into the Agile planning process? It’s not uncommon for teams to claim that Agile makes estimation obsolete. But regardless of which features end up in a particular release, businesses still need to know how much functionality can be delivered within a given schedule and budget. Because I have been working with more customers to estimate Agile projects, the first Agile planning and analysis practice suggested by Ellen Gottesdiener & Mary Gorman got my attention ‒ Use Three Planning Horizons: Now-View, Pre-View, and Big-View. Simply stated, each level of the view hierarchy represents more fine-grained planning and analysis:

• Big-View – general idea; how the product will fit in with other products
• Pre-View – enough detail to start planning the next release
• Now-View – delivery team analyzes and estimate activities needed

Their statement, "we don’t think of agile as a methodology per se. Rather, it’s a disciplined discovery and delivery framework (emphasis added)" is consistent with QSM's approach to estimating Agile projects. Macro estimation techniques allow the business to allocate resources to product development efforts by identifying the number of releases to be built during the next budget cycle, which corresponds to the Big-View horizon. More detailed release planning is performed later in the process, using the prioritized product backlog to determine delivery goals for each iteration.

SLIM Suite default workbooks contain pre-defined views you can customize to fit your reporting needs.  The Navigation Panel on the left side of the user interface displays the list of views, organized into sections or folders.  Each SLIM tool contains multiple views to facilitate presentation and analysis of the unique metrics it employs.

Figure 1: Navigation Panel

One of the most valuable and flexible objects to include in a view is the Note Panel.  Just as it sounds, it is simply a note pad where you can include descriptive text about estimation assumptions, findings, questions, instructions to SLIM users.... the possibilities are numerous.  QSM uses the Note Panel to provide instructions, tips, and easily customizable project and executive summary reports.  The view below shows the Section Purpose & Operating Procedures view, which describes other views in the folder, along with suggestions for tailoring subsequent charts and reports. 

Figure 2: Note Panel View

You can use notes to document the estimation procedure you want others in your organization to follow.  Use notes to document the special background information that explains why the recommended solution meets the most important project goals and constraints.

I discovered early on that the player who learned the fundamentals of basketball is going to have a much better chance of succeeding and rising through the levels of competition than the player who was content to do things his own way. A player should be interested in learning why things are done a certain way. The reasons behind the teaching often go a long way to helping develop the skill. — John Wooden

John Wooden is regarded as one of the greatest college basketball coaches. He believed that after talent, courage, and character, fundamentals built successful teams. Successful software projects result from knowing and practicing fundamentals as well, and it begins with estimation.

I thought it would be fun to see if Coach Wooden, by way of noted quotes, could help simplify a few SLIM core concepts.

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: