Laura Zuber's blog

Laura Zuber's blog

There's No Risk in Software Project Planning

I like listening to audiobooks when I go for a morning run. This month it is a David Baldacci thriller about two CIA professional killers pitted against each other who end up working together to save us all from global catastrophe.  Apparently, there is a ton of planning involved in stealthily hunting a target, making the kill, and then getting away unseen.  That’s because there is a lot of risk.  Timing is critical, down to the split second, and the slightest mistake can end your life.  Discussing the highly complex plan to foil an assassination attempt with his partner, one agent says to the other, “There’s no risk in planning. The risk is in the execution.”

That got me thinking about software development and QSM’s SLIM-Suite estimating, tracking, and forecasting tools.  Do I agree with that statement?  Yes and no.  Let’s look at it both activities – project planning and execution.  


The activity of planning is not risky as far as your personal safety is concerned. You probably aren’t in danger of getting attacked or making a mistake that will cause bodily injury (you may experience emotional trauma or at least endure a minor headache).  It is most definitely risky for software development programs and initiatives, however, because aggressive plans based on poor estimates handicap the delivery team.  Without understanding the dynamics of software development projects or the ability to rapidly compute a range of potential outcomes to identify risky scenarios, planners may inadvertently commit to unrealistic schedule, budget, and staffing goals.  In fact, most plans are “goal based” ― task lists and staffing plans derived to give management or the customer what they want, because there is no solid framework or supporting data to defend against it. 

Data Analytics for Project and Portfolio Estimates

We live in a multi-dimensional world.  We see in three dimensions.  Our brains’ ability to process spatial relations of height, width, and depth are essential for navigating everywhere we go and every task we perform.  The scientific world has used computers and data to generate 3D graphics for years, because it is the only way to understand complex phenomenon and ideas.  I remember the first 3D color seismic map of rock formations underground I saw.  The image told a story the numbers alone could not.  The business world has caught on in recent years.  The wave began with data warehousing and business intelligence and has grown to include data analytics, artificial intelligence, and machine learning.

QSM has brought a scientific approach to software development project estimation and management for over 40 years.  Our SLIM-Suite of tools contain statistics on the largest repository of completed software projects that enable you to model software projects to predict potential outcomes and assess the reasonableness of your estimates and project goals.  They have always provided four common types of Data Analytics1 – Descriptive, Diagnostic, Predictive, and Prescriptive.  SLIM tools now provide more in-depth data analytics using quadrant charts.

Software Project Risk Trend Variance Analysis

Blog Post Categories 
Estimation Data

Trend Based Solutions Generate Reasonable Estimates Fast

Beginning with the release of SLIM-Suite v8.1, two new SLIM-Estimate solution methods were added to let you see what a “typical” project would look like: that is, the resources it would require, based upon historical projects from either the QSM database or your own.  The two methods are:

  • Solve from Trends Wizard
  • Trend Based Solution

SLIM-Estimate provides several different ways to solve the software production equation and produce an estimate.  The solution method you select depends upon the information you have available.  The traditional methods, known as Quick Estimate Wizard and Detailed Method, take inputs of Size and Productivity (PI), and calculate Effort and Time.  The Solve for Size Wizard, perfect for time-boxed estimates, takes inputs of Time, Effort, and PI, and determines the amount of functionality that combination of resources can produce.

The trend solutions require only one input – Size.  Using the specified Primary Trend Group, Time and Effort are read from the average trend line and productivity (PI) is calculated.  These methods extend the capabilities of producing a defensible project estimates very early in the life cycle.  You can determine the feasibility of project goals, assess risk, and manage stakeholder expectations even if all you can estimate is a relative application size, expressed as a “T-shirt” or bin size, as shown in the figure below.

Software T-Shirt Sizing

Blog Post Categories 

Resource Demand Management - Are the Right People Working on the Right Thing?

I am excited about the resource demand management capabilities in our newest SLIM-Estimate release (8.2). Software project estimates can now provide a breakout of Full Time Equivalent (FTE) staffing requirements by role by month. The staffing profile below shows how different roles, or skills, are required at different points in the schedule, based upon a particular development methodology. You can see that 6 FTE Programmers are needed by the month of May. Producing a high-level, scope-based estimate early in the software development lifecycle with detailed resource demand data helps the PMO and portfolio managers determine the best timing for project resource allocation, and setting project start dates that maximize productivity and reduce bottlenecks.

Software Resource Demand Management

Once the estimate and resulting project skills allocation plan has been approved, resource demand management has not ended. Tracking actual staffing at the skill and task level for in-flight projects not only ensures the right people are working on the right things, meaning that product development is on track, it also allows timely resource plan adjustments to address unforeseen staffing needs.

Avoid Process Improvement Failure with Pacing that Promotes Mastery

Software process improvement efforts often fail because we try to accomplish too much too soon.  Aside from the cultural and organizational obstacles to change, people need time to learn and assimilate new ideas and skills.  “Human memory and comprehension are limited, and it is easy to design processes that are beyond peoples’ capacities,” says Watts Humphrey  (Humphrey, 1989).  This is true in any situation, but I think it is compounded in the software world because time is always a scarce resource.  The pressure is high in every organization to justify process improvement dollars and increase capabilities.

Establishing and maintaining software best practices requires that you design clear processes and plan a pace of implementation that promotes lasting change.  A key component is accommodating human learning and skill development challenges.  Borrowing from a training class I developed 14 years ago (yes, implementing best practices is still a challenge), let’s follow a team of water bugs as they progress through Watts’ four stages of Human Methods Adoption to understand what good pacing requires.

Software Process Improvement

Blog Post Categories 
Process Improvement

How Does Uncertainty Expressed in SLIM-Estimate Relate to Control Bounds in SLIM-Control? Part III

In the previous articles in this series I presented SLIM-Estimate’s use of uncertainty ranges for size and productivity to quantify project risk, and how to build an estimate that includes contingency amounts that cover your risk exposure.  In this post I will identify the project work plan reports and charts that help you manage the contingency reserve.  You will see how to use SLIM-Control bounds and default metrics to keep your project on track. 

Understand the project work plan documents.

In our example so far, you have estimated a project to deliver a software product in 11.7 Months, with a budget of $988,223.  This estimate includes an 80% contingency reserve, or risk buffer, on both effort and duration.  Your work plan is based upon SLIM-Estimate’s 50% solution; 11 Months and $755,400.  Thus, the uncertainty about size and productivity are accounted for; it is built into your plan.  The probability that you will meet the project goals is driven by many factors ‒ too many to measure.  You can only manage what is within your control, and escalate issues so they can be resolved in a timely manner.

Managing the project well begins with a solid understanding of the detailed project plan.  SLIM-Estimate provides several default and customizable charts and reports that document the plan.  Here are a few key reports1 to study in order to identify the core metrics you will want to monitor closely.

Blog Post Categories 
SLIM-Control SLIM-Estimate

How does uncertainty expressed in SLIM-Estimate relate to Control Bounds in SLIM-Control? Part II

Several months ago, I presented SLIM-Estimate’s use of uncertainty ranges for size and productivity to quantify project risk.  Estimating these two parameters using low, most likely, and high values predicts the most probable effort and time required to complete the project.  This post shows you how to use SLIM-Estimate’s probability curves to select the estimate solution and associated work plan that includes contingency amounts appropriate to your risk.

Begin with an unconstrained solution

The default solution method used for new estimates, whether you are using the Detailed Method or another solution option, is what we call an unconstrained solution.  Just as it sounds, no limits have been placed on the effort, schedule, or staffing SLIM-Estimate can predict.  It will calculate the resources required to build your product (size) with the capabilities of your team (PI).  Assuming you have configured SLIM-Estimate to model your life cycle and based your inputs on historical data, you have produced a reasonable, defensible estimate.  

Solution Panel

Blog Post Categories 
SLIM-Control SLIM-Estimate

Project Metrics Are the Best Defense in the Battle Against Scope Creep

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.” 

Blog Post Categories 
Sizing Metrics

Agile's Focus on Disciplined Discovery Aligns with SLIM Suite

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.

Blog Post Categories 
Agile SLIM Suite

SLIM Note Panel Simplifies Reports, Documentation, and Guidelines

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.

Navigation Panel
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. 

Note Panel View
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.

Blog Post Categories 
SLIM Suite Tips & Tricks