3.4 Development Risks

The management of risks associated with the development of the objective products is the emphasis in the next section of this note. Here, the focus is on some of those things that engender risks, but that are not directly aimed at the specification or SOW for the objective products. These are specific risks experienced in start-up situations.

3.4.1 Communications
One of the first risk situations facing such a team is that it invariably requires additional staffing. When new people are hired some of the negative aspects are that the collective awareness of the nuances of the program is diluted, and people start making decisions with less than complete understanding of the nuances of the program, the company or the customer. The one and only and simple solution is communicate, communicate and communicate. Regular staff meetings are a must. Also, the Program Plan, the SEMP, the TEMP and other planning documents are of course elements of effective start-up communications.

The purpose of such communications is to impart missions, functions, goals, priorities and other guiding information to all team members as soon as possible, particularly new team members. Every new employee should be given a "catch up" kit that contains all information about the program . (This approach ensures the quality and accuracy of the understanding by each employee.) This kit can include the RFP, the proposal and any planning that has been accomplished in at least draft form (program, system engineering, test, verification, staffing, training, logistics, etc.).

It is also recommended that each new employee get a through introduction to the roles, personalities and functions of all support organizations: contracts, tech pubs, quality, safety, computer services, manufacturing, cleanroom, test lab, shipping and receiving, etc. Where the quality lab is located and the fact it has an Arbor Press is not something every newly hired stress analyst will know, but it is information that can get a quick and dirty compressive strength test performed if necessary.

Another recommendation is to instil the use of meeting and discussion forms to reduce the risk of misunderstandings. These forms are no more than one page summaries of all key meetings (including telecons and videocons). The recommendation is that a form should be prepared for the following situations:

* All meetings with customers, users and consultants.
* All meetings with company elements outside the program per se.
* Meetings within the program that have impacts outside the organizations represented in the meetings. (For example, if thermal design and structural design chiefs meet and make decisions, the results should be transmitted to weights, system engineering, stress, etc.)

Typically, the M&D forms are sent to function, specialty and discipline managers who are responsible for distribution within their areas of responsibility. On occasion, the forms are shared with customers.
The forms should include participants (and e-mail address, phone numbers), date, place, issues discussed and key results (decisions, actions or closures).
The M&D can be implemented as e-mail, but an archive should be established since these forms provide one of the best briefing packages for newly hired personnel.

A special dividend of the M&D is that significantly less time will be spent in staff meetings providing background materials. The key aspects of almost every issue will have been previously communicated.

3.4.2 Engineering Data Base
Start-up organizations created to perform major new programs always suffer from the lack of a mature and pervasive engineering data base. Individuals bring applicable materials to the effort, but the organization as a whole does not have a common data base of materials, suppliers, standards, reports, handbooks, etc. from which to synthesize solutions to problems. This fact significantly impacts the effectiveness of the organization as the necessary assembly and dissemination of data and information is accomplished. Typically, a major scratch start-up requires about six months to a year before the useful data base exists and has become effectively disseminated within the program.

An aggressive data management function can accelerate the necessary diffusion of information and data (formal and informal).

3.4.3 Program Plan
The purpose and scope for a well-founded program plan is described elsewhere on this site. The risk of concern here is that the Program Plan is often confused with the Program Management Plan (PMP). The Program Plan is an executive level document whereas the PMP is at the level of configuration management, quality and system engineering plans. Too often, Program Managers fail to formulate and promulgate a succinct, but definitive plan for their programs. The result is that lower tier plans often set goals and priorities at odds with the overall mission.

A program plan needs to be produced to provide a summary with respect to the following aspects of the program:

* Concise Description of Program
* End Items & Major Interfaces
* Major Goals & Priorities
* Customer & Users
* Performing Organization & Key Personnel
* Schedule & Primary Groundrules
* Technical Approach
* Verification Approach
* Facilities

Typically, the Program Plan should be prepared within a month or two of the start of the program (assuming a multi-year effort). For short efforts (say two years), the plan should be a kickoff document.

3.4.4 Concurrent Engineering Trick
There are simple ways to avoid some of the risks of concurrence. Assuming that a program is organized with a PM, primary functional managers, and key support managers within the parent organization, one way to promote concurrence is to simply have all major documents (formal and informal) approved by all functional and support manager. This process is normally implemented as formal approval by the manager(s) of the producing department(s) and other managers sign in concurrence. In effect, every manager reviews all major documents. (Of course, the reviews are normally delegated to subordinates, but the managers are held accountable.) As a minimum, the following managers must review all documents: design, system engineering, software, program management (PMS), test, manufacturing, contracts, subcontracts, etc.

A reciprocal process is to have all incoming materials routed to the same managers for review for (initial) impact assessments. "No impact" is an acceptable response, but the response is required.

A recommended procedure is to have the data management function be responsible for accomplishing the necessary grunt work to get these procedures accomplished.

Risks that can be avoided include:

* Erroneous data sent to a customer
* Conflicting information provided to different elements of the customer organization.
* Technical managers for subcontracts making errors with respect to scope and priorities for subcontracts. ( A couple of errors seemingly reserved for young engineers overseeing their first subcontract.)
* Lack of communication between organizational elements.