I set a Schedule Constraint of 24 months. Why does the Solution Panel show a 22-month schedule for the life cycle?

There are several reasons this could be happening, but the most likely cause is that you entered a target probability of more than 50% for the Schedule constraint. For example, if you enter a time constraint of 24 months at a target probability of 90%, you are asking SLIM-Estimate to calculate a risk-buffered solution that provides a 90% probability that the project will not exceed 24 months: in effect, a risk-buffered solution.

The difference between the expected solution of 22 months (50%) and your constraint of 24 months (90%) represents the built-in risk buffer that protects you against possible size growth, lower than estimated productivity, staff availability issues, or other facts that may affect the delivery date. The size of this risk buffer is determined by the uncertainty range around the estimated size, PI, and manpower buildup.  The Solution Panel always displays the 50% solution because it is the work plan.

If you want your solution to correspond exactly to your input constraint values, use desired probabilities of 50% for those constraints.

What is the difference between the Base Size Unit and the Function Unit?

The Function Unit is a measure of software size, which represents the project scope or the amount of work to be done.  It makes sense to dscribe a book as a collection of chapters, or a building by the number of floors or rooms it contains.  The Function Unit allows us to describe a system as a group of functional or logical components, e.g., Function Points, features, reports, or interfaces.

The QSM database contains thousands of projects sized in different Function Units.  Without a common reference point it would be impossible to make meaningful size comparisons between a project sized in Function Point to one sized in User Stories.  The Base Size Unit represents the most common, elementary programming steps being  performed.  Historically, that was writing lines of code and labeled Source Lines of Code (SLOC).  With the introduction of modern development tools, a more generic term, Implementation Unit (IU) was added to account for tasks such as configuring packages or using a GUI interface to build a cloud infrastructure.  To normalize the Function Units to the Base Size Unit so project data can be used in scatter plots for comparison and to create statistical trend lines, we need a conversion, or Gearing Factor that tells us how big components are relative to each other.  For example, a common Gearing Factor for Functions Points is 50 IU/FP - on average it takes 50 programming steps to implement 1 Function Point.

The Base Size Unit is set by going to Tools | Customize Global Options.  Choose the acronym that reflects the work being performed - typically IU or SLOC.  The Gearing Factor of the Base Size Unit is always 1 - it cannot be set the the user.

The Function Unit is set by going to Tools | Customize Project Environment, Project Environment tab.  In the Product Construction area, select the Function Unit that matches the data available or the development method.  In the Agile-Story-Pnt Estimation template installed with SLIM-Estimate, the Function Unit has been set to Story Points with a Gearing Factor of 85 (IU/Story Pnt).  This allows all charts and reports to display the Effective and Total Size in Story Points, which is great for communicating with the Agile community.

Setting the Function Unit to the Base Unit makes it possible to use any number of component types or size units to measure all or parts of the system.  For example, QSM's Package Implementation template contains a Sizing by Decomposition method based on RICEF objects, using different gearing factors for each object type.  This method captures component complexity by supply appropriate gearing factors for simple, average, and complex components like reports and conversions.

If you need help determining an appropriate gearing factor, visit the Function Point Gearing Factors page on the QSM web site, download our Gearing Factors whitepaper, or contact QSM for assistance.

How do I set Phase Start dates?

Phase start dates, duration, and effort settings are used to configure the lifecycle model to your development methods and practices.  Select Estimate | Solution Assumptions from the main menu, then select the Phase Tuning tab.  The start date for the first phase included in the project is the project start date specified on the Solution Assumptions Basic Info tab or via Solution Wizards.

Subsequent phases can be set to begin at:

• Ratio - a specific percentage of the prior phase’s duration (most common)
• Fixed Overlap - a specified number of months into the prior phase
• Specific Date - a specific date.

Select Tuning Factor History... to use phase tuning data from select completed projects loaded in your SLIM-Estimate workbook.

What options are available for sizing projects in SLIM-Estimate?

The Size Calculator offers a variety of sizing techniques that may be used individually or in combination. A common and flexible technique is Sizing by Decomposition, which allows you to break the system down into individual components such as epics, stories, features, RICEF objects, or your custom components, each of which can have its own gearing factor (IU/component). The individual component estimates are rolled up into a total size estimate, which will be posted back to the Solution Assumptions screen.

Instructions for using the Sizing Calculator and descriptions of each sizing method are available in SLIM-Estimate NetHelp.

QSM's Software Size Matters Infographic also provides a great general resource for which sizing unit to use at each point in the software lifecycle.

Please contact QSM Support for help creating your size estimates.

How can I change the unit for Total system size in the Balanced Risk and other solution wizards? Currently it is set to IU, but we use Function Points.

Solution wizards that require a size estimate assumption use the Sizing By History technique to obtain an initial "ballpark" estimate based on the statistical size ranges, or t-shirt sizes, in your project's associated trend group(s).  This technique uses the Function Unit and Gearing Factor in the Project Environment settings.  Most of the templates installed with SLIM-Suite have the Function Unit set to the Base Size Unit, either IU or SLOC.  

To change the Function Unit to Stories, Features, Function Points, or other size unit, select Tools | Customize Project Environment from the menu. On the Project Description Tab, there is a Function Unit list box.  Select Function Points or other unit, then enter an appropriate Gearing Factor to represent the average number of Base Size Units (elementary programming steps) contained in your selected  Function Unit (ex.: a gearing factor of 50 represents 50 Base Size Units per Function Point).  

If you need help determining an appropriate gearing factor, visit the Function Point Gearing Factors page on the QSM web site, download our Gearing Factors whitepaper, or contact QSM for assistance.

Though we provide "starter" skills allocation for both new workbooks and QSM templates, the skills breakout is turned off by default because the skill categories, labor rates, and skills allocation data are most meaningful when they are configured to match the roles and practices actually in use on your projects. We recommend you create a template or two that represents a typical project resource requirement schema for your organization, then tailor it for individual projects as necessary.  

The Configuration Options tab of the Refine Resources/Costs/Skills dialog contains a field where you can specify a maximum percentage of fixed personnel for each time period.  If you enter a “50”, SLIM-Estimate automatically scales back the fixed resources to comply with specified percentage.  In this case, the total number of fixed personnel in a given month will never exceed 50%.  For each time period, the max resource effort hours are subtracted from the total effort for that time period, then percentage-based skills allocation settings are applied to the remaining monthly effort.

The planned MTTD value shown on my graph for the final month of phase 3 is not the same as the value reported in the Project Profile report and the consistency report for my Phase 3 MTTD. It appears to be slightly higher in the reports.  Why?

The value displayed on graphs is the average MTTD rate for the final month of phase 3, but the MTTD value reported in the reports represents the planned MTTD at the end of phase 3. You should expect this value to be somewhat higher than the average value for the entire month, because the theoretical MTTD is always improving (getting larger) as time progresses.

I changed my runtime environment from 5 days to 7 days. I would have expected my MTTD value to get smaller because I am running the system longer. Why did my MTTD value get larger?

The MTTD value is simply the reciprocal of the monthly defect rate. Suppose the expected defect rate is 100 defects found during the last month of phase 3. This is a theoretical monthly rate number based on an average runtime environment. The MTTD for this month is therefore 1 month/100 errors or .01 months between defects. 

Because it is difficult to think in terms of .01 months, you can specify a more intuitive MTTD time unit.  If you select days, then .01 months is the same as .01 * 30 (roughly) or .3 days between defects (assuming you are running 7 days a week). However, if you are running only 5 days a week, then .01 months converts to (.01 * 20) or .2 days.

The Solution Panel says my peak staff value is 10.3, but the Average Staffing Rate charts and reports show a peak staff of 10.1. What is causing this inconsistency?

The theoretical Rayleigh curve used to derive the values on the Solution Panel is a smooth curve resulting in different staffing numbers at each point along the x-axis. In drawing the Average Staffing chart, this smooth theoretical curve is approximated by a series of discrete staffing rates (with one bar, or average staffing rate value, per month).

The graph and solution panel values won't always match exactly because the graphical peak staff is always taken mid-month for any internal month while the solution panel always shows the highest peak staff point on the staffing curve (regardless of when it occurs). Usually the theoretical curve does not peak exactly at mid-month, so the true peak shown on the solution panel will not match the one on the average staffing charts unless the theoretical peak happens to fall at mid-month.

On large projects where a longer schedule allows a natural smoothing of the staffing curve, the theoretical peak staff will usually be close to the average staff rate value. On shorter projects, you can expect to see larger discrepancies.

Sometimes the effort data points on my Life Cycle Sensitivity to PI graph have values that do not always increase (or decrease); e.g., there are small dips in the data.

Remember that the time and effort shown on these graphs are life cycle values. The most likely cause of slight variations in the expected behavior of the data is caused by variation in the effort for phase 4. Staffing projections for phase 4 are dependent on the staffing rate at the end of phase 3. Therefore, differences in the final phase 3 staffing rate can result in variations in the total effort for phase 4. You can check to see if this is the case by making the solutions in question the current solution, then comparing the phase 4 effort in the solution panel of the staffing view.

The 50% solution is based on the expected value (the solution with a 50% probability of achieving the same or better values for schedule, effort, cost, and reliability). Each of the inputs to an estimate - size, application complexity, and productivity - has some uncertainty associated with it. If any one of your input parameters (size, for instance) increases significantly from the original estimate, it makes sense that the actual outcome will vary from the estimated outcome.

To manage this uncertainty, SLIM-Estimate employs the concept of a risk-buffered solution. The estimate or “work plan” is a 50% probability solution. If the project is managed to this 50% solution, the risk charts should reflect alternative delivery dates at various levels of assurance. You can decide which date to promise to the customer based on your risk tolerance and your assessment of the amount of uncertainty in your inputs.

Essentially, the time difference between the 50% delivery date and the 90% (or whatever assurance level you choose) delivery date represents the amount of schedule buffer needed to account for the possibility that one or more of your input parameters will vary significantly from the estimate.

The alternate outcomes on each risk chart are based on the assumption that the 50% solution represents the work plan for the project. If the project is worked to another plan (the 70% assurance solution, for instance), the values on the risk charts will change.

When I change the Person Hours per Person Month field on the Accounting tab of the Solution Assumptions dialog, there is no change to the total schedule and effort for the project. Why is this?

Many SLIM-Estimate and SLIM-Control users have asked why their overall schedule does not change when they change the value of the "Person Hours per Person Month" field,  Solution Assumptions screen, Accounting Tab.

The number of Person Hours comprising a particular organization's Person Month is not used to calculate total effort.  If your chosen effort unit is Person Months, the hours per month setting is not used at all. If, on the other hand, your effort unit is weeks, days, or hours, your hours per month will be used to convert the estimated total effort (in Person Months) into your chosen effort unit.

At first, this may seem counter-intuitive. Shouldn't an increase or decrease in the number of Person Hours in a Person Month be reflected in the final estimate?

The number of staff hours in an organization's staffing month is more relevant in the accounting world than it is in software estimation. It attempts to account for items such as vacations, meetings, and administrative activities but in most cases, it is merely an estimate or average.  It may tell how many hours will be charged to a particular project, but has nothing to say about how much is actually accomplished during those hours (or even how many actual hours were worked). The productivity index, or PI, is where actual work produced is measured.

The Productivity Index, or PI, reflects a number of environmental factors such as:

If you are using a PI calculated from your past projects, your user-specified PI already reflects the conditions in your working environment. Holding other factors constant, organizations which have high "administrative overhead" will tend to have a lower calculated productivity index than organizations which maximize time spent working on the most productive project tasks.

SLIM-Estimate® is a macro model based on the software equation described in Measures for Excellence. The SLIM software equation is designed to estimate consistently across a broad spectrum of working environments and accounting standards. For this reason, the effort parameter was originally calculated in Person Years, which are converted to Person Months in SLIM-Estimate. Once the total effort in PM has been determined, it can be converted into your chosen effort unit for display on charts and reports.  But what if you have no historical data and are using the PI suggested by the QSM database? SLIM estimating and project control tools will still give you a good first estimate that you can continue to refine as more project data becomes available. As projects are completed, SLIM tools will calculate the project PI's from your historical data. These PI's can be used to calibrate new estimates to the unique conditions in your development environment.

As you begin to compare and analyze PI's from completed projects, you can spot and eliminate bottlenecks as well as identify successful strategies that you can repeat to improve productivity. Storing project metrics in a useful and accessible form and analyzing them to identify trends is the key to process and productivity improvement. Consistent use of SLIM tools results in increasingly accurate estimates and will help you build a repository of historical data for future analysis and benchmarking.

What is the purpose of the gearing factor?

Gearing factors are used to convert projects with many different sizing units (objects, modules, or use cases for example) back to a common sizing unit: the Basic Work Unit. The Basic Work Unit represents the smallest sizing unit that is common to all projects.

This conversion is important for two reasons. First, it allows us to apply the same family of PIs (or Productivity Indices) to all projects. Second, it allows you to compare your project, whether it is sized in tables, screens, or any other sizing unit, to QSM’s industry – or your own custom - trend lines, which can be sized in a variety of size units.

In our research, we have found a strong correlation between system size and important metrics like PI, schedule, effort, and defects. For more information on gearing factors, download our free whitepaper.