An excerpt from Chapter 1 of Five Core Metrics: Intelligence Can Guide Us
. . . metrics can tell us that we are doing things right. Metrics provide and enable the following:
~ dependable estimates of project effort, schedule, and reliability
~ control of the project during its course
~ ability to replan an errant project along the way
~ master-plan the assignment of resources to all projects within the organization
~ monitoring process improvement from year to year
Furthermore, an organization can apply these same metric capabilities to the oversight of development subcontractors and outsourcing contractors.
But first we must ask, What do we mean by doing things right? We mean that fundamentally, we are turning out software products in less development time, with less effort, at a better reliability level. What are those "things" we are trying to do right? If we do some "thing" and then make some measurements, the metrics tell us whether it was the right "thing" to do. Moreover, advancing metrics confirm our confidence in the value of continuing to do that "thing."
By now enough organizations have done some "things" and tracked favorable metrics as a result that we have a pretty good idea of what the "things" are. In fact, the "things" plus the metrics to measure them constitute the "intelligence" behind successful software management. What are the most important of these "things"?
Process. At a minimum a software organization needs a process that it can repeat the next time. Repeatability lies at the heart of estimating and bidding. More importantly, it enables a project to meet the expectations of its own and the client's management. Beyond repeatability lie two more stages. The first is the employment of guides to improve the process, such as specifications and the Capability Maturity Model. The second is the move to a process standard, such as the Unified Software Development Process (described further in Chapter 3).
Standardization. We hesitate to bring the dread word, standardization, into play. Many software people regard the writing of code as more an art than a science. Indeed, at a certain point, there is indeed art in it. But Shakespeare did write in the English of his day, then an emerging standard. Artists of software can work in standards intelligible to other artists, as well as to their other co-workers, managers, and certain of the client representatives. One of these "standards," dating from as recently as 1997, is the Unified Modeling Language. It gives developers a "drawing" medium to work in. It enables them to recall their own work months later. It enables developers to read each other's work. It provides a permanent record of the work accomplished.
Software tools. An important outgrowth of standardization is software tools. When everybody does his own thing in his own way, you can't reduce that proliferation of half-formed methods to tools. Tool builders have to have a large market (in other words, some degree of standardization) to support their cost of development and marketing.
The software product. Before management can intelligently assign staff to a project and forecast the schedule it will take, it needs a clear grasp of what the product is to be. That preliminary task itself takes some staff and time, so people in a hurry sometimes bid before they have product functionality, commonly known as "size," as the basis for a more reliable bid. In other words, an effective software process provides for certain phases before formal construction under a bid (or other costing arrangement) begins.
Risk. A software product of some size and novelty involves risk:
~ Critical risks: elders determine that the product is within the current state of the art and within the capabilities of the project organization available;
~ Significant risks: elders establish that the project can surmount these risks within the schedule and effort planned.
These "things" and the metrics that measure them are what we mean by "The Intelligence Behind Successful Software Management."