Source : http://www.compaid.com/caiinternet/ezine/putnam-effectivemanagement.pdf
The modern corporation evolved in a manufacturing environment. If you wanted to increase production you added another assembly line, a second shift, or increased machine speed to reduce assembly time. It was relatively easy to quantify the outcomes. You knew what to do and how to implement it. In contrast, software is often a discovery process. Initial requirements are at a functional rather than an implementation level. The higher the level of the requirements the more time and effort is spent determining what to do and how to do it. Adding additional staff (a second shift in the manufacturing metaphor) will contribute little to defining what needs to be done and how; but will increase the cost and degrade the quality of what finally is delivered. The more abstract the requirements, the newer the development tools, the more unfamiliar the development team is with the business and the environment, the greater the time and effort required to determine what to do and how to do it.
The modern corporation evolved in a manufacturing environment. If you wanted to increase production you added another assembly line, a second shift, or increased machine speed to reduce assembly time. It was relatively easy to quantify the outcomes. You knew what to do and how to implement it. In contrast, software is often a discovery process. Initial requirements are at a functional rather than an implementation level. The higher the level of the requirements the more time and effort is spent determining what to do and how to do it. Adding additional staff (a second shift in the manufacturing metaphor) will contribute little to defining what needs to be done and how; but will increase the cost and degrade the quality of what finally is delivered. The more abstract the requirements, the newer the development tools, the more unfamiliar the development team is with the business and the environment, the greater the time and effort required to determine what to do and how to do it.
For all of the time, money, prestige, and effort that are tied up in a software development project, it is nothing short of scandalous that many companies do not record, analyze, and use the schedule, cost, and quality data that all projects generate. This data forms a composite picture of how an organization develops software. With it, strengths and weaknesses can be identified, estimates can be grounded in reality, and achievable targets set for improvement. What you measure you can rationally manage; what you don’t measure … . Capturing summary information for each project: how long it took, how much effort was expended, how many defects were recorded during development, and what it produced should be a task in project close-down for every project. “Industry” data can be useful for comparisons; but it cannot tell you about your organization and how you produce software. Most organizations have a very discernible pattern to the way they produce software; but if project history is not kept, very valuable information about your organization remains unknown and you will not know if a QSM Page 3 of 6 particular schedule is feasible, a staffing plan appropriate, nor whether a quality standard is attainable. KEEP AND USE YOUR PROJECT HISTORY.