What is Project Control?
Project Control focuses on the factors that impact the schedule and budget of your project. It is a key factor in keeping your project running smoothly.
Issues associated with project control are:
- Scope creep – resulting in blow-out of cost and schedule
- Accuracy of estimations
- Optimum team size to maximise productivity
- The decision to employ phased development or single release
- The choice of methodology – will this result in overall lower costs or better quality?
- Impact on quality and schedule when employing higher quality resources
- Is the project suffering from “analysis paralysis”? What is the average time/cost for analysis phase?
These issues are discussed below:
Scope Creep refers to adding features or functionality that are outside of the initial scope of the project, without approval. It is an unwanted, yet common occurrence.
Causes of scope creep can be:
- Users requesting additional features or functionality. These changes are undocumented. It is the balance between delivering what the user wants and delivering what is within the scope. Read more…
- Team members lacking understanding of the initial scope and performing work outside of this.
- Project stakeholders pushing for extra deliverables.
Accuracy of Estimations
To check the accuracy of your estimations, investigate similar projects. These projects should have similar size, duration, methodology, industry and/or language.
Compare project delivery rates. Does your project’s rate lie within the 1st and 3rd quartile (middle 50%) of the rates calculated for other projects? Take into consideration the skills of the team, new technology, environment and customers. It is reasonable to expect a slower productivity if there are a lot of unknowns in the project.
If you want a high-level ballpark estimate, then the Early Lifecycle Software Estimation report can provide a sanity check. See Report Subscriptions for more details.
Consider how the requirement for more resources can impact your project schedule. The question is: how many resources can be added before the delivery rate declines to such a point where the $/FP quoted is no longer valid?
For example, a team size of 1-4 has a median project delivery rate of 7.4 hours/FP, whereas a team size of 5-8 has a median delivery rate of 10.3 hours/FP**. This needs to be considered if the size of the project is growing and requires more resources.
**This information is extracted from the report Team Size Impact on Project Delivery Rate. It is an analysis report on the ISBSG data showing the impact of team size and software size on productivity. See Report Subscriptions for more details.
Examining the amount of effort for each development phase may highlight some critical questions that demand answers.
For example, if your project’s testing effort is 40% of the overall effort and the industry average is only 18%, it is important to ask “why”. Perhaps your application is a real-time process control controlling safety. Hence, more rigorous testing is required.
The Planning Projects – Role Effort Ratio report shows the role ratios for external customer and in-house customer.
The Planning Projects – Phase Effort Ratios report shows the effort ratios for new developments and enhancements. As for the phases of the project, these role effort ratios can provide a cross-check. See Report Subscriptions for more details.
The decision to use a methodology or not can have an impact on productivity. Productivity is slower using a methodology. However, using a methodology has been shown to reduce defects..
For example, for CMM(I) compliant companies: productivity is slower, project duration is increased but defects are reduced.
There are also different development techniques such a prototyping, rapid application development, joint application development and object oriented analysis. All affect productivity, speed of delivery and defects delivered.
Tools such as project management tools improve productivity and have lesser defects according to the projects in the data. The details of the data sample and results can be found at Techniques Tools – Analysis Report. See Report Subscriptions for more details.
It is always a balance between speed of delivery and quality. Depending on the contractual arrangements, defects found within the first 30 days usually form part of warranty and the cost of fixing those needs to be factored into the overall project costs.
There are also defects that are found during development. The cost of fixing those depends on when the defect was introduced and when it was found. Ideally, defects introduced in a phase of development are fixed within the same phase. Obviously the cost of fixing a defect is higher, the earlier it is introduced and not fixed.
The Software Defect Density report can provide some insight as to what other developments have experienced. See Report Subscriptions for more details.