The initial team becomes the nucleus of the project. Anyone who does not ‘‘fit’’
into the nucleus must be replaced for the organization to evolve smoothly, and in harmony with the manager and with each of the other members. The organization and its team harmony (or lack of it) can make or break a budget. The initial team is easy to control because the span of control is small. It allows for the role of the manager-architect to be the teacher of the team in the implementation methodology and process, while at the same time laying out the vision of the architecture of the project and the organization.
5.8.1 The Initial Team
The required members of this team:
Project Manager/System Architect (Manager-Technical Principal) Assistant Architect/Systems Engineer for the functional domain Administrative Assistant
Business Manager Chief Technical Writer The required products of this team:
The Level I Systems Architecture
Project Implementation Plan (first draft, plus organization charts) Functional Requirements Document (first draft)
In this initial phase, the manager has many pressures to contend with. As is frequently the case, if the sponsor is managed by a ‘‘bean counter’’ with little technical or managerial experience, he will consider the financial burn rate as the pri- mary objective and is irritated by under-running. What this means is that he measures, at least initially, all progress by how fast money is being spent. It usually means that he will force, or try to force, the project manager to staff up fast to meet the monthly burn rate forecast. If the project manager acquiesces, he is in trouble, because there is no way that he can possibly know what he needs to do or what the architecture will really look like once the dialectic process is completed and presents the sufficient and acceptable reality for the next step. Nor is the conceptual organizational structure or architecture completed. If the staffing is done too fast, with little thought for skill fit, level of experience, and manageability of those being hired, there is real trouble ahead. Misunderstandings, infighting, and undermining of authority will start.
The task of the initial team is to work out thea prioriLevel I architecture of the system. This requires the help of the Chief Technical Writer, who is also the Systems Engineer for Standards and Specifications, in selecting the appropriate standard to be followed in expressing the architecture and organization for implementation. The team
STAFFING UP: THE INITIAL TEAM 69
then prepares an implementation plan, which will contain the work breakdown struc- ture as well as the first cut at the staffing requirements.
The staffing requirements are of utmost importance, for they contain the job descriptions for each identified position to be filled. At a minimum, these include the statement of work to be accomplished by that position, the academic qualifica- tions needed for that job, or the equivalent in years of technical experience in that type of work. There is the need to show examples of work done on past projects. In the software industry, this means looking at programs written by an individual (and the comments on the code), as well as documentation he has prepared in the past.
Finally, referencesmustbe carefully checked out.
It is very important to match a person’s maturity and experience level to the posi- tion to which he is assigned. The academic qualification is a small but important part of the required skills, except in the case of hands-on programming in specia- lized areas. At this level, the Ph.D. is the ‘‘knowledge worker.’’ This is the level where all of the critical technical work is done, whether developing new propel- lants, engines, or aerodynamic forms for aircraft. These positions require high tech- nical expertise gained in the classroom, such as required in the design and programming of instruments to be flown on a spacecraft. One key indicator of the experience level of an individual is the number of projects completed, the size of each task, and its complexity. An average task and project is approximately three years in duration. If the individual has left a project prior to that without having completed his task, he does not get credit.
What this thorough preparation does is to lay clear the path for meritorious, qua- lification-based, unbiased selection of staff members.
Poorly written and vague job descriptions guarantee great troubles. The interview for a vague job description is based on personal likes and dislikes, and subjective value judgments on part of the interviewer. The interviewer may or may not be a good judge of human character, and may or may not know the greater details of the technical aspects of the job. Indeed, it is nearly impossible for managers to keep pace with all of the latest hardware and technical advances taking place. The effort put into the job descriptions will also keep one from hiring one’s friends and those people one likes who may not be the best qualified for the job, or even qualified at all.
As an aside, it is interesting to see how this lack of insight affects everything:
success or failure, cost and budget. For example, a board may pick a project manager or program manager based on academic credentials and achievements though the individual has never delivered a system of any size or managed a credible organization in a large effort to completion. One would think that project managers, or managers of large administrative organizations, would be selected on experience or substance as opposed to form.
5.8.2 Phase One Team Expansion
The additional proposed members of this team:
Systems Engineer for the Project Functional Domains (e.g., ground system) Systems Engineer for Design Standards and Specifications
Systems Software Senior Design Engineer/Senior Programmer
Common Software Services Senior Design Engineer/Senior Programmer Communications Software Senior Design Engineer/Senior Programmer Hardware Senior Design Engineer
Applications Software Senior Design Engineer/Senior Programmer Software Test Engineer
Software Librarian
The required products of this phase:
The Functional Requirements Document (final draft) The Project Implementation Plan (final draft) The Software Requirements Document (final draft) The Software Design Document (final draft)
The Software Interface Specifications Document (final draft) Common Software Services Subsystem (initial operating capability) Communications Subsystem (initial operating capability)
The Phase One team expansion now acquires the next level of engineering staff, whose special qualifications in software-intensive systems are key to the mission and project success. With the Level I architecture completed, and with the job descriptions completed, the key positions are filled for the development of the Level II architecture.
In my case, I select first and with great care the systems design engineer/senior programmer, who happens to be the expert on the operating system and computer platform we will select. Then we select with great care the common software ser- vices senior design engineer/senior programmer who will design and program the
‘‘abstraction layer’’ on top of the operating system. This is a very important posi- tion, because this position is first among equals on the team. This individual enforces the coding conventions to be followed by the subsystem senior design engineers and programmers. On the design team chaired by the manager-architect, and participated by all members of the technical team, the conventions are enforced. Only after thorough examination of the circumstances and a rigorous evaluation of alternatives are exceptions made to this rule. The common software service layer provides the layered and modular aspect of the architecture, which will allow the seamless replacement or repair of components and subsystems without forcing a costly redirection of work.
This is followed by the selection of the software senior design engineer/senior programmer for communications, who will immediately become the technical lead on the network design, the selection and use of communications, and file transfer protocols for the project. This position is especially important when there are many nodes to a system.
STAFFING UP: THE INITIAL TEAM 71
Before any subsystem designs start, the common software layer and the commu- nications layer should be up and running. Then the other subsystems will have from the start a working functional base to interface and code to.
With a small design team, control is excellent and productivity is very high. All the while, the feared ‘‘burn rate’’ imposed by the sponsor, who may be a number cruncher or administrative type with little hands-on management experience, will be under-running the budget. Don’t worry, however; the technical and leadership or organizational problems that are inherent in any project will cause enough bud- get problems that you will be happy that you under-ran up front, early on. To my mind, unless there is a very critical reason, like a launch window imposed by pla- netary configurations, being over schedule but still on budget is a forgivable flaw in implementation.
5.8.3 Phase Two Team Expansion
The additional proposed members of the team:
Database Senior Design Engineer/Senior Programmer User Interface Senior Design Engineer/Senior Programmer Computer Graphics Senior Design Engineer/Senior Programmer The products required of this phase:
Software Test Plan (master, final draft)
Software Test Plans (for releases 1.0, 2.0, and 3.0)
Software Operators User Guides (for releases 1.0, 2.0, and 3.0) Software Maintenance Manual
Applications software, all subsystems (releases 1.0, 2.0, and 3.0)
The Phase Two team expansion fills out the team for the completion of the Level III and Level IV architectures. Understand that these are not set rules. The database senior design engineer/senior programmer on my projects in the past has been there at the start. This was necessary because at the time, relational databases were in their infancy and we had much work to accomplish on them to make them work for us. As I will discuss in a later chapter, the user interface senior design engi- neer/senior programmer was also among the first on the Phase One team. There was also a variation in the organization, imposed by a very short schedule and a very limited budget. I had to do an architecture that I called ‘‘inferential’’, used where there are no formal requirements, and no time to document such a huge system. I combined the position of subsystem senior design engineer/senior pro- grammer with the user interface senior design engineer/senior programmer. That system, GDSS, is still very much in use by Military Airlift Command, and I shall discuss the implementation of it in Chapter 14 in detail.
The main thing that a manager must always keep in mind is that a large design team is difficult to control and orient, and to oversee. The organization, no matter
what the expertise of the members, must learn to work together on a small scale first, and expand carefully, as the scope of the project unfolds. Those who are not team players must be gotten rid of quickly. This doesn’t mean that they are not good people, but that they just do not fit into that particular organization.
This has happened to me often in the past. In fact, there is a term called ‘‘person- ality conflict’’ that is very real and must be taken seriously. It can destroy a budget.
It is not the fault or the culpability of any one person, but it can create chaos, conflict, and lack of cooperation; it lowers team morale, and makes good people quit, resign, or just stop producing. It is one of the most costly problems in an organization. The tough-minded manager is aware of it and deals with it instantly.
In government organizations, where firing people from a project is next to impossible, it can be easier and cheaper to sideline a troublesome individual where he cannot cause problems, rather than keep him on the team. Pay the salary, even if there is no work in return, rather than have an entire subsystem lag behind and produce poor-quality work.