Software project planning for non-trivial projects

We all aspire that our software projects are delivered on time and budget*.  Software is complex and unless we plan for success, it is unlikely to “just happen”.   When Planning Software Projects, fortunately we have the experience of past failures from which we can learn.  We should embrace the learnings from these mistakes so that our projects can avoid the “pathological” route.

What do we mean by a project being late?  Lateness is really about a project being delivered late in relation to expectations, or in other words late vs the estimate.  To avoid disappointment we need to create realistic expectations (estimates) AND we need to perform the activities to avoid problems that could lead to the estimates not being met.

In a study 84 projects from IBM and AT&T, Capers Jones observed that projects that ran late by 6 months or more showed little evidence of being in trouble in the early stages.  The late projects had skimped on many crucial activities, notably:  requirements reviews, inspections, quality control.  All of which are about early attention to quality.

Why were they estimated incorrectly?  Either the estimate was inappropriate or activities that could have kept it on time were not performed well.

Capers cites 10 factors leading to estimate/actual mismatch:

*Some parties benefit from the extra charges generated when a project is extended.

How AI can help

Planning starts early, as you know or as you discover the requirements.  ScopeMaster uses AI to help you get under the skin of the requirements really quickly.  Which leads to better plans.

This article is based on the work of Capers Jones.  We are most grateful for his permission to republish some of his findings here.  If you are interested in learning more, you can find the source here. Estimating Software Costs by Capers Jones

Factors affecting Software Schedule and estimate reliability

Factor Description Schedule Impact Mitigation ScopeMaster

Metrics Errors

Using inappropriate metrics such as Story points or similar will lead to poor estimates Up to 100% Use functional sizing, COSMIC Function Points ScopeMaster automates functional sizing, eliminates most of these errrors.

Technology adjustment

Uncertainty/delay caused when introducting new tools/technologies/techniques Observed impact can cause estimate errors of up to 150% Allow at least a month for new technology to become embedded into use, plan for it

Critical Path Errors

The illusion of progress being on track until the project grinds to a halt by a blocking event Error in schedules of up to 25% Better crtitical path monitoring, proactive technical risk mitigation can minimise these. ScopeMaster prompts early thinking about complexities and integrations, that are common causes of CP problems

Sizing / Scope issues

Mis-underestimating the true magnitude of a project will lead to increase in work and schedule. Requirements quality and completeness are also impact ability to size correctly Error 15-100% Functional sizing and automated completeness checking will help to mitigate this.. Solved by ScopeMaster (even for inexperienced project managers).

Creeping User Requirements

Changing requirements (distinct from missing requirements) will lead to increase in work and schedule. Error rates are bigger on longer projects 2-10% per month This should be planned for, and embraced (Agile). ScopeMaster helps in several ways: improving early requirements quality, better elicitation and volatility tracking

Assignment errors

Failing to allocate appropriate staffing to an activity within a project. Each person performing a given role has a finite capacity to do work, and needs to be assigned at the appropriate time in the project. Error up to 100% Competent managers who understand assignment capacities (see below). ScopeMaster helps by providing a functional size from which assignment scopes can be determined.

Production rate errors

The difference between the expected and actual production rate. 20-100% Realistic and appropriate production rate measures will help, eg. CFP/month for a given team. ScopeMaster helps by providing a functional size from which production rates can be measured, benchmarked and monitored.

Staff build-up

Failing to deploying the right number of staff with the right skills at the right time will cause delays. Likely to impact by weeks or even months. Competent managers should plan appropriately. ScopeMaster helps by providing a functional size from which assignment and scopes can be determined.

Task Selection

Failing to to consider all project activities - not just coding will lead to scheduling errors. Observed up to 1000% Competent managers should plan all activities appropriately.

Exective or Political Interference

Executives decree timelines or other innapropriate constraints which lead to poor quality. Error up to 50% for schedule, 100% for costs Competent managers should push back hard on such interference. ScopeMaster creates functional size estimates from which realistic schedules can be determined and used as defence.

Activity-based Planning based on functional size

Planning Software Projects

The most critical factor in determining the duration of a project is its size.  By size we are referring to functional size.  Functional size is the most reliable means of sizing a software project.   Unlike story points (which are a non-linear, subjective, engineering proxy estimate of effort),  functional size is generally consistent, within a few % regardless of who sizes it.

To determine how much of each activity is appropriate on our project we need to understand both the assignment scope (how much capacity an individual can handle) and their production rate (how much capacity they can address over a given time frame).   These are shown in the table below based on the functional size of the software being worked on in Function Points.

There are two main standards for functional size: traditional  (IFPUG) function points, and COSMIC function points.  We recommend the latter mainly because it deals with incomplete requirements very well, you don’t need to know all the requirements to size a piece of software (which you generally do with IFPUG).

Activity Assignments and average productivity

For activity based planning

Not all of these activities are needed on all projects.  As a guideline, the larger the project, the more of these you will need to perform.

Activity Staff Assignment scope, FP Monthly production, FP

Requirements

333 175

Prototyping

500 150

Architecture

1000 300

Project Plans

1000 500

Initial Design

250 175

Detail Design

250 150

Design reviews

200 225

Coding

175 50

Reuse Acquisition

500 600

Package Purchase

2000 400

Code Inspections

150 150

Independent Verification & Validation

500 125

Config Management

1000 175

Integration

1000 250

User Documentation

1000 70

Unit Testing

200 150

Functional Testing

200 150

Integration Testing

250 175

System Testing

250 200

Field (beta) Testing

1000 250

Acceptance Testing

1000 350

Indpedent Testing

750 200

Quality Assurance

1000 150

Installation & Training

2000 350

Project Management

1000 100

An equivalent table, based on CFP is not available, nevertheless it is reasonable to consider FP and CFP to roughly equivalent when using this data for activity-based planning.

An activity-based approach is particularly useful as it helps us to identify the personnel and skills needed during the project.  Tools such as SRM® from Namcook analytics  SEER for Software from GalorathSLIM from QSM or True Planning from Unison (previously Price Systems) can further help by providing a suitable staffing profile for a given project over time.

This is a condensed version of table 11.4 published in “Estimating Software Costs, second edition” by Capers Jones.  Available to purchase from Amazon here.  Nb, this is just an illustration of activities and their staffing levels, productivity rates (implied costs).  You will find that maintaining your own benchmarks for these activities to be a worthwhile activity.

Early Estimation

If you are looking for help with estimating size, duration and staffing for a project before you know the requirements, then a suitable tool is Software Risk Manager (SRM) from Namcook analytics.  It uses historical project data and various algorithms to give estimates of size, duration, staffing and much more. SRM can be found at the Namcook website.

Conclusion

The key takeaways from this article are:

  • It is possible to create realistic estimates for software projects that are reasonably consistent with what eventually happens.
  • Size (functional size) is the most significant factor affecting effort and duration.  The reliability of the size estimate depends on numerous factors.
  • An activity-based approach based on functional size can produce a reasonable estimate of effort (and therefore cost).
  • Knowing the effort and typical productivity rates, gives us a reasonable estimate for duration.
  • Very large projects will also benefit from a parametric planning tool that can forecast a team size and skill sets over time throughout the project.