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.
Factors affecting Software Schedule and estimate reliability
| Factor | Description | Schedule Impact | Mitigation |  |
|---|---|---|---|---|
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 Galorath, SLIM 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. 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.
