“I don't think you can really manage software projects. It's just like going off a diving board — you just have to hope.”
Many senior executives share that feeling with the vice president of a steel company who used it to describe his view of software.
But the analogy is apt in two ways, and it indicates in fact that management of software projects can be a highly developed skill.
First, because we know there is a vast difference between the rank amateur whose venture off a high board is at best chancy, or the natural athlete whose innate capabilities enable him to dive relatively well, or the Olympic champion who supplements his basic skills with constant concern for improvement and application of technique. Talents, attitudes and efforts might vary among these three — but they are in fact controllable and directable towards specific goals.
Second, our diving analogy points up the single most important factor in managing software: people. Unlike other forms of production which have a variety of elements to control, software production is exclusively rooted to the output of people.
In this paper, then, we will consider some of the structures, styles and techniques by which senior managers can improve their performance off the software management high board.
It Starts With An Attitude:
Mature and Informed
Sufficient millions of lines of code have been written so that it no longer should seem remarkable when a program is written and works well. Software has matured as a discipline and as such is as manageable as any other production system. Yet our observations indicate that many senior managers, like the steel company executive, are still ambivalent about that fact. Their ambivalence often conveys a subtle but de facto standard to the software staff — that miracles are still possible.
A preferred attitude is one in which performance to stated standards is expected, and that deviation from those standards is a cause for concern and not an expectation.
A component of developing such an attitude is for senior executives to be well-informed. Software is a technical activity which requires management with the technical ability to establish appropriate initiatives and monitor activities in a knowledgeable fashion. Experienced management can quickly sense problems, lay down and adhere to “no surprises” guidelines, appreciate what is (or is not) being done, and lead the way in new directions.
This level of being informed is not nearly as difficult to reach as it might seem. We have been amazed at the number of senior managers who have come from non-computer backgrounds into positions of responsibility for software projects and within several months have been fully able to manage effectively a large and complex software activity.
These executives have brought two attitudes to their new responsibilities — a commitment to active participation in their new role, despite the learning-curve problems implied by it, and a basic experience in applying conventional management techniques to the software problem. Active participation is a self-generated attribute, but the application of management techniques does require some modification in terms of software projects.
What are some of these modifications, and how can a senior executive structure and apply them to his area of responsibility?
There are basically five stages in the execution of software projects, and in each there are many opportunities for management control. These five stages include:
- The systems plan
- Development of functional specifications
- The systems design stage
- The detailed design stage
- The implementation stage in which coding, testing and conversion to production is completed.
Let's look at each stage from the viewpoint of a senior manager, and isolate those factors in each which enable management to exercise its maximum control.
The Systems Plan:
A Product is Developed
This is the first step in creating a productive software entity. It is necessarily broad — establishing overall targets, the major application to be developed, the stages of that development, and the allocation of personnel and equipment resources to get the job done.
This is the first opportunity for management control, and demands maximum participation to understand, from the user department's point of view, what is needed. In this stage, management can match resources to need, set priorities and authorize resources. Too often, however, systems plans are developed as a “general understanding” among various people, rather than as a specific document. If your systems plans exist in such a manner, you can be certain that different people have different “understandings,” with predictable consequences.
Insure from the start that the product to be developed is clearly defined, with specific understanding by all concerned of the purpose and use of the system. In developing a written plan, be sure, too, that it is reviewable. That is, insist that it has built into it sufficient clearly identifiable milestones that progress can be reviewed objectively on a regular basis. Such milestones imply development in major phases, and within each phase, sufficient detail to allow management to make good decisions based on complete information. Without cost, time, staffing and progress details, the senior executive is stymied, for he cannot review and decide on the basis of facts.
The precept of creating reviewable work plans extends into every other stage as well:
□ Functional Specifications
This stage defines the system from the user's point of view, and includes outlines of inputs, outputs, major processing steps, and files. It must also include definition of both the development and operating requirements which the user will accept.
□ Systems Design
This is the stage at which the user's specifications are converted to structures which can operate within the computer's capabilities. Details of the input, output, file structure and processing techniques are established, and the software techniques selected. It also sets forth the detailed schedule, and the equipment needed for system operation. In a sense, the systems design stage is the counterpart of an architect's design for a building after the basic structure has been approved. It sets forth the details and limitations within which the user and computer must work.
□ Detail Design and Implementation
Just as the architect prepares engineering drawings and construction planning details, the systems designers must develop detail file designs, program flow charts, and perform coding, unit testing of finished programs, and finally testing of completed and integrated programs. These steps take place in the detail design and implementation phases. And it is usually at this point that improper planning starts to show up. If you have to add an additional floor to a half-completed building, you are bound to have problems. So it is with software development. Only computer systems are not as tangible as brick and mortar, so the problems are often elusive.
The Management Key:
Minimize Uncertainties
As work progresses, there are numerous opportunities to anticipate and manage problems. One such opportunity is in the area of testing. There is a rule-of-thumb that states that 90 per cent of the processing requires 10 per cent of the code, and 10 per cent of the processing requires 90 per cent of the code. If your software testing seems to be progressing well, it may be that it is only “mainline” testing — of the broad ten per cent which is routine. Insure that unit and final testing covers the acute problem conditions of the system; if this is done, and tests out well, a major problem area will have been minimized.
Another control element is continuous and careful documentation as work progresses. This not only minimizes personnel fluctuations, but insures development of the proper blueprints before the bricks, boards and bulldozers arrive at the construction site.
Milestone Reporting:
Memos Make It Easy
At each stage of development, if a careful systems plan was developed, there will be numerous milestones indicated. To simplify management review, a system of regular reporting on accomplishment of these milestones should be established and adhered to. Often, a system of memo reports can cover most of the minor milestones. More elaborate reporting is suggest for major achievements in which complex integrations are involved.
The goal of documenting and reporting on small-unit achievements is to make systems development as people-independent as possible.
In establishing detailed project plans, then, it is vital to have schedules and budgets that are realizable, and measurable against reality. Bar charts, network charts, and numerous other methods are used for plotting progress.
By breaking tasks into identifiable segments — no one of which represents more than 2-4 per cent of the total — you can avoid the trap of thinking that because 80 per cent of the budget has been expended, 80 per cent of the work has been done.
Anticipate the User's Situation
This is the most critical step in systems development. User expectations and needs will evolve, especially in projects which require lengthy development or involve numerous departments. Thus it is crucial that the data processing department finds out exactly what the user wants, specifies it to his satisfaction, and gives it to him.
In this process, user involvement is mandatory. Have him review specifications, look at sample outputs, and stay informed. Too many organizations attempt to develop a system based upon preliminary user information which they then shape and project as they see it, only to find when the job is completed that it is not at all adequate or desirable for the user department.
In this process, it is important to remember that the user frequently does not know or is unable to specify exactly what he wants — just as an architect's client is often unable to define the elements of the building he desires.
The challenge for software project management, then, is to help him translate his needs openly, to support him as he does so, and to establish from the very start a workable, manageable, reviewable program to which he and the systems developers can commit. Without such sensitivity and planning, the process of software development becomes an expensive and sterile exercise.
