In Part 1, I began the discussion on the managing and monitoring software development. Part 2 continues with necessry criteria.
Product Quality & Stability
If projects are to meet established productivity targets, there must be a clear definition of what products have to be delivered. It must be determined for every project what quality means based on the program objectives.
A defect is defined as an instance where the product does not meet a specified characteristic. Defects should be tracked formally at each project phase or activity. It is more economical and more effective to find and fix defects before they are discovered during testing. Inspections can detect potential defects and focus corrective action toward the work product itself as well as processes that produce the work product.
Here are the main reasons why defect removal costs increase as the project progresses:
- The ripple effect of changes throughout the system,
- Repeating past tasks in the project to correct observed defects, and
- Notifying people on the project and users of changes.
While some degree of rework is a factor in all estimates, late defect removal is costly and time-consuming.
Inspections can be performed to improve the defect detection efficiency of any process. Inspections are a more rigorous and formal process than walkthroughs. Inspections differ from more classical reviews in several respects:
- Statistical quality control on the document;
- Statistical process control of producing organization;
- Emphasis on earliest possible defect detection;
- Emphasis on immediate and controlled correction;
- Trained and certified inspection leaders (moderators);
- Moderator leadership (chief moderator concept);
- Specialized roles to increase defect total find rate for team;
- Specialized checklists for each document type;
- Formal entry criteria for inspections start-up;
- Formal exit criteria for inspection completion;
- Measurable criteria for repeating bad inspections;
- Pareto analysis: identifying error-prone components;
- Experiential optimum rates of work enforced;
- Specific devices/techniques for avoiding individual blame;
- Author does not lead, read, explain or defend documents;
- No discussion of defect-assertion allowed;
- Only author has control over correction;
- All important documents are subject to inspection;
- Peer inspection - everyone learns new things on the job; and
- Maximum meeting: two hours (tiredness factor).
The purpose of an inspection is to identify as many potential defects as possible. The author of the work product being inspected has final determination of which potential defects are actual defects. Data captured from inspections can be used to identify patterns in defect detection and prevention. See Figure 2:
Staff members who participate in the inspection process should be trained in the process and in the facilitation skills essential to the success of inspection-based techniques. While it may appear that inspections will take more time, they can actually reduce overall project time by as much as 15 percent.
One of the easiest metrics to track against the plan is the actual number of staff performing the work. If this deviates more than 10 percent from the initial plan, immediate steps need to be taken to correct the over/under staffing. Figure 3 is an example of tracking the actual staff against the plan.
The equalizer in adjusting productivity projections to unrealistic constraints is for management to focus on the management of teams. According to the second edition of Peopleware by DeMarco and Lister:
- The best people outperform the worst by about 10:1.
- The best performer is about 2.5 times better than the median performer.
- The half that are better-than-median performers outdo the other half by more than 2:1.1
Most managers manage as if technology was their principal concern. Managers that focus on team management take pains to partition the work into pieces and make sure that each piece has some substantive demonstration of its own completion.
The essence of successful team management is to get everyone pulling in the same direction. One of the hardest management challenges is to provide strategic rather than tactical direction. Team-based management is focused on network, not hierarchy.
Managing to productivity targets has been a challenge facing software project managers for many years. There is little argument that while the dimensions and characteristics of the problems have changed, this core set still applies to projects today. Applying the processes and techniques provided here can help program managers more effectively bring projects to a successful completion.
Tom DeMarco. Peopleware: Productive Projects and Teams. Dorset House Publishing: 1987.
Dan Galorath is a recognized expert in project estimation technology. He authored Software Sizing, Estimation and Risk Management, Auerbach Publishing, 2006. He founded Galorath Incorporated over 20 years ago to address this specific industry issue. Galorath has lectured internationally on a wide range of project management topics, including software cost, schedule and risk analysis, software management and software engineering.
For more information on related topics, visit the following channels: