The problems of software projects are concentrated in three areas: schedule, cost, and quality. These problems have accompanied software development from the beginning, so they are not new. Nor have they been ignored. Huge amounts of thought and effort have been focused on them with unfortunately modest results. Improvement efforts have been concentrated on management technique (think PMO), process improvement (CMMI, for example), and better tools. These are all good things, and I can’t imagine embarking on a development activity of any magnitude without them. However, they have not significantly reduced the incidence of schedule, budget, and quality problems. Since the problems remain, obviously these remedies have not effectively addressed the root causes of schedule and cost overruns and poor quality.
So, what are the sources of these problems? Schedule and budget are leadership decisions made before a software project begins. They will either help or hinder the proposed project. When schedules and budgets are empirically based, the project has a good chance of succeeding. Empirically based means taking into account such things as past organizational history, modeling the proposed project with a parametric tool, and determining optimal schedule and team size based on the magnitude of what is to be developed and its complexity. All too often, budget and schedule decisions are based on group-think or wishful thinking and the vicious cycle of unmet schedules, cost overruns, and poor quality is perpetuated.
Consider for a moment how different things would be if business leadership were trained in how software development actually works and embraced that knowledge in their decision making. They would understand that optimal schedules and staffing plans that deliver quality software at reduced cost can and should be developed empirically. They would understand that schedule and cost/effort aren’t interchangeable: that, in fact, the relationship between them is profoundly non-linear. They would understand that project scope increases over time and account for scope creep in their plans rather than attempting to manage it away (or worse, ignore it altogether). When setting goals for improvement, they would base their plans on demonstrated levels of performance. And they would never, ever take a best case scenario and call it a project plan. Perhaps most important of all, they would recognize the limits of their control and manage within them.
Better tools, improved management technique, and process improvement cannot solve problems for which they were not designed. The new frontier of software improvement requires a focus on leadership: their proper emphasis should be on influencing decisions made by leaders and managers who establish a project’s framework before it begins. Significant improvement in quality and performance to plan can only occur when leadership bases its decision-making process on proven performance and a strong understanding of schedule/budget tradeoffs rather than hopes and desires.