The management staff of your group usually initiates a small project. Once the project has been defined in terms of its requirements, it will be assigned to you for implementation. In this case, the management staff is the customer.

The Planning Stage is only a few days at most. Your input requirements consist of some written requirements and likely some verbal direction.

You will generate an abbreviated Project Plan. The schedule will have a start date and a completion date and show intermediate events as line items. The budget will be in labor hours per reporting period and be a sum of the period hours of the individual periods. The budget also contains the labor hours of others to be used in the task. These hours are stipulated in the budget as specific, additional hours and in the schedule as subtasks with start and complete dates or performance periods. After you have completed the Project Plan, you should have the person issuing the task approve it.

At this point, you need to assemble your team to establish that each person knows what his or her role in the overall task is. Simply discussing the role each person plays usually suffices for team training for a project at this level, but may disclose some interesting disconnects. Therefore, you need to have this meeting.

Kickoff is a technicality but nevertheless a real point in the project. Your Kickoff occurs when the Project Plan is approved.

The content of the Execution Stage is determined by the needs of the project as expressed in the task statement and documented in the Project Plan. For a small project, it is likely that you will lead the technical team as well as be the project manager.

The design phase of small projects is usually abbreviated and consists of product details, performance, and final test. Usually for this size project, the design phase consists not of equipment design, but of simple tasks such as listing pin outs and load lists for installation tasks. For small R&D tasks, the origin of the need and all prior work is reviewed and the protocol of the period is determined.

The materiel department normally purchases the items required and then provides these items to the project. The departments may or may not assign a specific person to the task depending on the size and importance of the task.

The Execution Stage is where the entire physical task is accomplished. As stated in the table, installation tasks, small software projects, small R&D tasks, and administrative tasks as well as numerous other similar tasks are performed as small projects. The Execution Stage ends with the Test Period.

The purpose of the Test Period is to confirm that the product meets the requirements. This may mean a physical test in the case of a hardware or software project, but for small R&D projects or an administrative project it may mean an inventory of the results.

The Closure Stage for a small project is simple but still needs to be done. Ensure your customer is satisfied with the completed task. Satisfaction must relate to the scope agreed upon.

Perform whatever handover process is necessary such as signing release papers. Write a simple “Lessons Learned” paper even if this project was the same as others.

The people were not directly assigned to your project, so you don’t need to be concerned about finding jobs for them. However, it is a good idea to visit the people that supported you in this project and thank them; even an e-mail will suffice. It will make it a lot easier to get their support the next time. Most organizations have some performance review system for evaluating how raises and promotions are distributed. I suggest you make notes on each contributor’s performance during the performance of the project. You may be asked for inputs to individual performance reports at a later date, and you’ll be glad you made the notes. Further, it will give you insight into individual performance when the next project comes along. A little effort now saves a lot of head scratching and confusion later.

As you can see, the small task using the project management process is quite simple. But don’t equate simplicity with importance; your task is very important to the overall success of your department and your company. While the process may be simple, performance may or may not be simple. Performing under these conditions will try your leadership skills, abilities, and patience.

An intermediate-level project is usually initiated by your group management in response to their own needs or the needs of another group in the company. Once the project has been defined in terms of its requirements, it will be assigned to you for implementation. The requestor or the requesting group is the customer.

Your Planning Stage starts at the time of project assignment. In this case, your project plan is relatively simple but must include all the elements necessary for a complete project plan. The best plans are those that have participation of team members so they can “buy in” to the conduct of the project. Explaining the needs will put demands on your Communication (10) skills and your Information Management (13) techniques.

Even though the materiel department is responsible for providing materials, you are responsible for overall schedule. This conundrum is typical of these kinds of projects.

For these projects, you need to negotiate for the people who will support your project. Likely you will have to negotiate hard because it is a provider’s market, and all the other project managers want the best people they can get too. You may need to get “up to speed” in Negotiation (40) in a hurry. You should have Quality (21) involved in all these interfaces.

Once assignments have been made and the project plan completed, call the people together for a team training session. This situation will test your knowledge and application of the Training (24) subject area. The training session does not need to be a fancy “dog and pony show” but it must turn the group (or as we used to say, “a column of mobs”) into a team. A team is a group of people working together for a cause higher than their own individual needs.

As the leader of the team, you need to be prepared to start the session off on the right foot. This will test not only your Training (24) abilities, but also your Meeting and Negotiation Skills. The first thing on the training agenda should be the objective of the team. Next, give your team the schedule and any important milestones. Then, your presentation should include the organization—the hierarchy, if you will. The breadth and depth of the organization will vary in accordance with the complexity of the task. If it is not obvious, the charter of each element may also be presented, but don’t tell them their jobs. If they already know them, treat them as professionals, if they don’t know their jobs, send them back to their functional managers. Finally, have each project element stand up and specify the input products they need to do their jobs, who they expect to provide these products, and when.

Document this effort and have each team member sign the input and output sheets that apply to them. Each team member gets a copy of their sheets, and you get copies of all of them. Hopefully, you never need to have a session where you must refer to the sheets. Just going through this process will instill your seriousness in their minds. Besides, if you don’t have these understandings and you have to resolve these interface issues every day, you’ll never get the rest of your job done.

You will likely know what each job is, and after you set up these sessions for a few projects, know them by heart. Your people will be “chomping at the bit” to get on with the job, but make sure they complete the team session first. Remember, just as soon as the job starts, they will be spending your money and consuming your schedule and contributing to your reputation. Make sure everyone understands all the objectives of the training sessions, then get on with it.

Kickoff for these projects can be accomplished shortly after the team session and lasts about half of a day. It is always a good idea to have each group stand up and go through their responsibilities and their schedules.

The Execution Stage is what the project is designed for as far as management and the customer are concerned. You’ve planned your project and trained the team, now is the time to make it work.

At the intermediate level, projects become not only complex but diverse as well. As you saw in Figure 9-4, these projects cover the waterfront. You may or may not have a design phase, but if you do, it is likely you will use a rapid prototype of both the hardware and the software. It is not at all unusual for a project at this level to have several components being addressed simultaneously. For instance, if you have an IT project that requires facility modifications to make room for the final configuration, you will have software and hardware design or prototyping going on at the same time as the physical work of modifying the facility. It will require that you be in several places at one time.

Procurements will “fall out” at several levels and at several times, and control of the situation will tax your understanding of Procurement and Contracts (17). The most important procurements are the so-called long-lead items. These are items that require a long time to produce or are in such demand you have to wait a long time for them. Whatever the reason, they can bring your project to a screeching halt if not ordered in time to get them when and where they are needed. Usually these are subcontracts and either create new products or heavily modify existing products.

The design process will reveal the next series of procurements. The details of each really won’t be known until they are revealed by design need. The final level is the common items that can be purchased “off-the-shelf.” Scheduling the delivery of all procured products is critical because they pace the critical path of your implementation and integration activity. Remember: “For want of the nail the shoe was lost; For want of the shoe the horse was lost; For want of the horse the rider was lost; For want of the rider the battle was lost; For want of the battle the kingdom was lost; And all for the want of a horse shoe nail.”^[1] Criticality was understood even in Ben Franklin’s day.

In this case, implementation will consist of bringing all the elements together into a single system.

Testing will be incremental and consists of compiling the unit tests of each element of the system, the results of subsystem tests, and the results of the final system test. This process is common to all the activities at this level of projects, even construction and administrative projects.

Final testing will draw the entire system together. If there are discrepancies, they must be captured in Discrepancy Reports (DRs) and dispositioned as Action Items (AIs) for closure. Performance errors must be fixed and the final test rerun in its entirety. Whenever all the AIs have been closed, the system should be accepted. Knowing this, you will have run the final test a number of times before the customer arrives just to make sure the system runs properly during the real final test.

The Closure Stage will have begun at final test and the ensuing AIs will have been captured. Final Test is usually a part of the Closure Stage to ensure that the final AIs are closed to the customer’s satisfaction. Then it’s time for handover, the Final Report, and the “Lessons Learned” paper.

Wrap up the project by having the customer sign off acceptance of the system. No matter what your internal procedures are, it is a good idea to have the customer sign off. We said at the outset that a project has a beginning and an end. This is the time for the end. If there is no acceptance that the project is completed, little items could bug you for a long time. Likely you will be graded on the project, and if it never ends, you never get the grade and the recognition you deserve.

Finally, write a Final Report that summarizes the project. The Final Report usually goes to the customer and is filed internally. Additionally, you should write a “Lessons Learned” paper. This paper is an internal document and should not go to the customer. Hopefully, it will be a short paper and should reflect the changes that were made or that need to be made to processes and procedures for future projects. This is a good reference for you and may prove valuable to other project managers who run similar projects.

A Manpower Plan is part of your Project Plan and shows how people are phased into and out of the project. This plan is kept up-to-date to allow the functional managers to adjust their personnel availability for other projects. Even though a project has a beginning and an end, the people are phased in and phased out. To have them all available on day one and to let them all go after the final test would be a disaster. You should be “shedding” people and allowing them to go back to their functional managers all along. Hopefully, at this point, you only have yourself and the senior technical lead left (if you had one at all).

Writing thank-you notes to all who participated in your project is a good idea. If you can get some simple “give-aways” from marketing or sales, the task is that much easier.

Initiation of a large project usually begins with an idea by management that a certain task should be accomplished. That task is then passed on to a committee or group to do the initial planning and justify the need. The output of this group, once approved, becomes the requirements document for the project. A group leader is usually appointed, and this person (or persons) becomes “the customer.” Once the project has been defined in terms of its requirements, it is assigned to you for implementation. Now is a good time to consult previous “Lessons Learned” papers for hints concerning pitfalls or shortcuts that did or did not work on similar projects in the past. If a mentor is available, discuss any concerns you’ve encountered or anticipate.

The Planning Stage starts when the project is assigned to you. A large project includes many tasks, so your project plan must include all the elements necessary for a complete project plan. In a large project, Resource Management (11) drives the Project Plan, and you need to concentrate on that subject area. Resource Management will, in turn, drive how you organize (19).

In the case of the large project, you advertise for, evaluate, award, manage, and receive the materials and subcontracts associated with the project. This can be a large job and is frequently accomplished by one or two persons. One person handles the purchases of standard off-the-shelf equipment and software and another person handles all the subcontracts. The size and complexity of the task determines whether you have one or two people performing this task and whether they are assigned as full- or part-timers. When you start purchasing materials and subcontracts within the project, your job increases significantly. Typically, the technical departments (such as engineering) define the materials and subcontracts necessary and must initiate the specifications for these items. You, the program officer, are responsible for the “Statement of Work” that accompanies the specification, and the subcontracts administrator or manager handles the terms and conditions (Ts & Cs) and the whole procurement package. Subcontracts can make or break a project, and at this level, you must thoroughly understand “Procurements & Subcontracts (17).” Even if you have a subcontracts manager, it will be necessary to manage (not micromanage) this process from the top down.

This is a large project, so you need to Negotiate (40) for the people who will support your project.

Once assignments have been made, call the people together for a training session. This action will test your knowledge and application of subject area Training (24). The training session must turn the group into a team. Use the training session for Team Building (23) to accomplish this.

As leader of the team, you need to start the session off on the right foot. Once again, the first thing on the training agenda should be the objective of the team. Next, give team members the schedule and any important milestones. Then, your presentation should include the organization. The breadth and depth of the organization will vary in accordance with the complexity of the task. As before, have each project element stand up and specify the input products they need to do their jobs, who they expect to provide them, and when. Document the effort and have each team member sign the input and output sheets that apply to them. Each team member gets a copy of their sheets, and you get copies of all of them. I keep harping on this point for a reason. It is the heart and soul of getting your project job done. You can’t, and shouldn’t, do it alone. Every member of the team must be a contributor, and they must all act together as a team. Drive this point home, and then get on with it.

Kickoff for these projects can be accomplished shortly after the team session and will last about a half of a day. It is always a good idea to have each group stand up and go through their responsibilities and their schedules. For large projects, it is usually a good idea to invite management to the kickoff to show you know what you are doing. Obviously, you will want to have several “dry runs” beforehand to ensure that everything goes well.

The Execution Stage is what the project is designed for as far as management and the customer are concerned. You’ve planned your project and trained the team, now is the time to make it work.

As you saw in Figure 9-5, these projects may appear to be similar to intermediate projects but they are larger and more complex. To keep up with the complexity of all of these “goings on,” it is a good idea to employ an Earned Value Management System (18) to understand exactly where you are in terms of accomplishment.

With a project of this size, if it is for hardware or software, it is likely you will have a design. You will likely have a pure design portion and a rapid prototype portion for both hardware and software. It is not at all unusual for a project at this level to have several components being addressed simultaneously. For instance, if you have a project that uses off-the-shelf hardware and software in conjunction with new hardware and software, it will require you to be in several places at one time and changing hats frequently.

As with intermediate projects, procurements will “fall out” at several levels and at several times. The design process will reveal the next level of procurements. The final level is the common items that can be purchased “off-the-shelf.” Scheduling the delivery of all procured products is critical because they will pace the “main line” of your implementation and integration activity.

Implementation consists of bringing all the elements together into a single system. Your people will be working together as a team and need to be evaluated both as individual performers and as team members. Using Personnel Management (22) techniques, you can keep up with individual performance in both these areas. This is important both to you for selecting people in the future and to the company for promotions and recognition.

It is necessary to use the concept of incremental testing due to the complexity of this and the levels that follow.

Final testing draws the entire system together and likely uses operators of the same level of abilities the customer will use. Sometimes the customer will require that the actual operating personnel be used to completely test the system. Also, all the elements of the system are used in final testing to ensure the system operates under the expected operating loads. If there are discrepancies, they must be captured in Discrepancy Reports (DRs) and dispositioned as Action Items (AIs) for closure. Treat AIs the same way as with intermediate systems. Again, run the final test a number of times before the customer arrives just to make sure the system will run properly during the real final test.

The Closure Stage will have begun at final test just as with the intermediate project. It is usually a part of the Closure Stage to ensure that all the AIs are closed to the customer’s satisfaction. Then it’s time for handover, the Final Report, and the “Lessons Learned” paper.

Wrap up the project by having the customer sign off acceptance of the system. Once again, no matter what your internal procedures are, it is a good idea to have the customer sign off for the same reasons as before.

Finally, write a Final Report that summarizes the project. The Final Report usually goes to the customer and is filed internally. Additionally, write a “Lessons Learned” paper. Keeping personal copies of these papers will give you a library of things “to-do” and “not-to-do” in future.

You have phased your people in and out as with the intermediate project, so you should be down to a core team at this point.

In the earlier definition and discussion of the Initiate Stage, I said that a program is subdivided into three periods: the initiation phase, the pursuit phase, and the capture phase. In this case our discussion begins with the initiation phase. The initiation phase is the purview of the customer whether it is a project or a program. The customer creates a need, documents the requirement, and, in the case of a program, puts the requirement up for bid. Marketing has identified and tracked the program, and the program has been qualified as a legitimate bid opportunity. As stated earlier, identifying opportunities is the purview of the marketing department. You may or may not be involved in identifying opportunities.

Once the requirement is issued however, the “troika” is established (see Glossary). As program manager, you assist the assigned marketer in tracking the new program. The marketer is primarily interested in the competition, the schedule for procurement release, the winning price, and the politics of the procurement. The technical manager is interested in the technology involved. If the enterprise has followed the Technology Management (32) plan and provided “on-ramps,” you should be able to slip into this technology easily. If not, you may have a very difficult time or it might be time to no-bid. If the company has all the capabilities, including the technologies needed to perform this program, fine. If not, you may need to gain that knowledge through Teaming & Partnering (37) activity. It is likely that the marketing representative will initiate this activity, but you really need to manage it. This may create some friction, but if you were thorough in your Teaming & Partnering study, you will be able to handle it.

If all these factors are overcome, fine. If not, here is where the concepts of Value Management (27) come into play, and you must understand the positions of management and marketing and how they evaluate the position of this program. Why? Because it is possible that the program will be identified and qualified, and after the tracking process is started, new information is unveiled that makes the program a “no-bid.” This is a very difficult time in programs, because just as soon as a program is identified to be tracked, it gains a personality. People identify with the personality, right or wrong, and don’t want to let it go. You will hear arguments like you’ve never heard before about why you should continue with the bid process. Nevertheless, follow the precepts of value management and do what needs to be done.

When in a bid posture, you are primarily interested in the Statement of Work (SOW), the task to be accomplished, the people involved, the performance schedule, and any unusual considerations of any kind (programmatic, technical, or contractual). Notice that I used the term “primarily interested.” This term is used to recognize the primary focus of the individual, not the overall interest. In fact, you,the marketer, and the technical person will each be interested in all aspects of the entire program.

How long you track the program depends on when the opportunity was identified and when the request will be issued. I have tracked some programs for many months and some for only a day or two. You should track the program long enough to present your capabilities to the customer and to fully understand all the wants and needs of the customer, plus any tidbits that may give you a competitive advantage.

During this time, you will be involved in making tactical alliances and teaming arrangements if necessary. In a classical case, let’s assume you make a teaming arrangement with a small software company that has a unique product that meets a critical need to be included in the request. Your marketer has been clever enough to find this company and conduct teaming discussions. This small company will provide a “software kernel” around which you will wrap some entry and exit paths and imbed this software into the overall software package for the customer. You must monitor the process very carefully because there are implications of infringement into the intellectual product of both that company and the software your program develops. These issues may well test your Legal Considerations (31). You decide the lawyers need to be involved in drafting the teaming agreement. Both the marketer and the technical person agree. Clearly, you have a need for understanding Marketing and Sales (38) and Business Considerations (29).

Now your presentations to the customer involve not only you, but your new teammate as well. You have a new capability set to offer the customer. You continue these interfaces and data gathering until the requirement is issued. Once the requirement is issued, the procurement people get involved, and all contacts go to “arm’s length.” This means that the technical and program people will only talk to you through their procurement people. All these contacts are made “official” and are usually documented. This is the opportunity to understand and put into practice Customer Relations and Satisfaction (36).

Once the requirement has been issued, you are ready to start the proposal. Actually, the troika has been working with the Proposal Center for several months. If this is a very large program, you will be working with the entire proposal core team long before the request is issued.

The Proposal Center must be kept apprised of the requirement and its schedule—that is, the time when the requirement will be issued, when the proposal is due, what the proposal size is to be, and every other detail you can think of. The Finance Office must be kept apprised of the proposal needs as well. Your role will be challenged by how well you learned and applied the Financial Management (25) subject area. In fact, within twenty-four hours of when the request is received, you should be able to issue all the needs of the proposal: the schedule, section assignments, page allocations, the theme, and every other detail necessary to get the proposal published and back to the customer, including who delivers the proposal and when.

Your Proposals (39) training will have shown it is normal to treat a large proposal as if it were a program with kickoff, execution, and closure. For a proposal of this size, you need to have a proposal kickoff. You can assume that a person from the Proposal Center will be assigned as the overall proposal manager and that you will lead the Management Proposal and the Cost Proposal. A person assigned from the Finance Office will provide the support necessary for the financial “boilerplate” and will “crunch” the numbers as they come in. It is necessary for you to make sure the budgets are assigned and the numbers come in on schedule and on budget. They won’t, so you’ll need to stay on top of everyone that owes you cost data. The technical person (now the Chief Engineer) leads the Technical Proposal.

The proposal writing will be in process for some time and include the design of the product to meet the requirement, a review of the design, a costing of the design, a redesign to meet the cost envelope, and all the writing necessary. The drawings will pace the writing and production.

The most critical part of any proposal is the costing process. You need to know how to cost your part of the proposal and understand the cost bases of the other contributors as well. Estimating (33) techniques are required for your costs and for evaluating the cost inputs of others.

Finally, the writing is complete and the proposal will go through editing, rewriting, incorporation of the drawings, and ultimately printing. The marketing representative flies all night to deliver all seven boxes of the proposal to the customer just before the clock runs out.

The proposal phase is different and unique. Even though it is conducted the same as a program, there are numerous nuances that you must learn to conduct a proposal effort. Those details are outside the scope of this book but the seminars mentioned in Chapter 6 provide you with a base for participating on proposal teams until you gain the experience to conduct one of your own.

The customer reviews your proposal and usually has a number of questions to submit to you. This can, and frequently does, happen several times during the proposal evaluation. In some cases, you may be required to give an oral presentation and answer questions posed by the customer’s evaluation team, in real time.

Finally, after iterations of questions and answers, the day comes. The customer representative calls the general manager of your company and tells him or her of the award. If the contract is large enough, the U.S. representative from your district calls the general manager with the news first. Time for another party—no pizza this time!

The time for negotiations has been set. You show up with the marketer, the chief engineer, a finance representative, and a contracts manager. After pleasantries, you get down to business. Then you discover that these guys are serious! How you handle all this depends on what you learned in the seminars you attended for Negotiations (40).

Finally, negotiations are complete, and you and your team return to the office. Exhausted but happy, you take the next day off to get your “faculties back in mind”^[2] and rejoin the human race.

You were lucky. You were a part of the Capture Team, so you know what went on in the negotiations. Still, you need to document the findings of the negotiations just to make sure everyone knows what the program baseline is for Handoff (35).

It’s time to call the core team together and get the planning under way. The functional managers are “chomping at the bit” trying to get you to put the people on the program (meaning on your charge number and not their overhead), and you are trying to hold them off, but at the same time hold on to the people you want. This is going to take some diplomacy and maybe a few lunches. Get started. The objective is to get a Program Plan completed and approved, bring the team on board, provide team training, and have a kickoff for your team and for management as soon as possible.

First, establish your Mission Statement. Convene the core team and use the “Brainstorming Method” (Glossary) to create a Mission Statement with meaning to each and every one of you.

The Program Plan is the written instrument that summarizes and references the requirements of the customer and the requirements of the company to the team. It is the most important document you will create, and it must contain, in a company confidential attachment, the understandings you have with management, such as follow-on sales and profit. These issues will have been covered when researching Management Relations and Satisfaction (43).

Have roundtable meetings with the contracts manager, the finance representative, the chief engineer, and the subcontracts manager; and construct the framework for the Program Plan, then establish the Work Breakdown Structure (WBS) and name the subcontracts involved. Remember, if you have an alliance, that’s the subcontract you want to nail down before anything else.

Then create the Organization Chart. One of the questions for the Organization Chart is where to put the alliance that was created. Are they part of the “voting” organization and placed within the organizational structure? Or are they treated as a subcontractor and placed on an extension below the primary organization chart? These questions have political overtones and will have a bearing on how the overall organization operates.

At this point, you can release the core team to return to their functions and “farm out” various sections of the Program Plan, with specific instructions, just like what was done with the proposal. Each must perform their functions and get back together quickly. Remember, this is the plan and not the actual design or the actual subcontracts. You need to maintain control to ensure the Program Plan process does not exceed its bounds and slip into design or otherwise go off track. Once you have the Program Plan established, together with the WBS and the Organization Chart, you are ready to start bringing the people on board.

For lower-level projects, we used Earned Value Management (18) techniques to understand project performance. We now need to add more refined techniques through the use of Metrics (26).

Larger programs imply more people and a concentrated workplace. Here is where you need to make considerations of Health, Safety, Security & Environmental (28) factors of the workplace.

For training, bring everyone together. For a group this size, I recommend you have a warm-up to get everyone comfortable with everyone else. You can do this and make some progress at the same time by using the Myers-Briggs Type Indicator (MBTI) program as described in Chapter 8.

To get ready for a kickoff for this program, each group must put together all the work packages for which it is responsible. The Work Package has task, schedule, and budget, and should be a line item on the overall program schedule. This is the level that should be presented at the team kickoff. When presenting to management and to the customer, present at the level required by the contract.

It is a good idea for a program such as this to formalize the kickoff meeting. This means giving a stand-up presentation with visual aids. The team presentation is a good preliminary run for the management or customer presentation. By the way, if the management or customer reviews are not required, you should still conduct a full-blown kickoff meeting for a program of this size. In this case, you and the core team are the reviewing authority.

The Execution Stage for these programs includes a number of progressive periods, and some of these periods are subdivided into even finer increments. In addition, there is some overlap between the periods as well as with the phases. To complicate matters even further, you may be going through a design period on one subsystem and the development period with another subsystem. But that’s what keeps program management interesting.

The Design Period will likely be subdivided into subsystem designs and a system design. The system will likely have several design reviews such as a Conceptual Design Review (Concept). The system and each subsystem will have incremental design reviews, such as a Preliminary Design Review (PDR), a Critical Design Review (CDR), and a Final Design Review (FDR). Each is conducted in strict accordance with established procedures. The chief engineer manages the reviews but you must attend them all and be aware of all the details. Each period must have Design & Development (30) considerations, and activities must meet the “gates” established before proceeding any further. As each design review is completed with the customer in attendance, you should have the customer sign an acceptance sheet to attach to the design package for your records. I have found it is essential to either take notes myself or have a very trusted team member take them. These include not only formal action items, but anything helpful in avoiding problems or satisfying a customer. Each subsystem design review must precede the equal system design review. In other words, all the subsystem PDRs must be completed before the system PDR is conducted, and so on. This assumes the subsystems are a part of the overall system. If a subsystem is “outboard” of the main system, its design reviews can be conducted independently. If that is confusing, consider that related systems and subsystems are sometimes collected together under the aegis of one program. That’s what I am talking about here.

With a great number of people with diverse personalities and with different technical and administrative objectives (read: agendas), you are certain to encounter conflict somewhere along the path. This may happen occasionally or frequently. How often it happens may well be a reflection on how well you prepared the individuals as a team. Nevertheless, conflicts will arise, and you must control them with the Conflict Management (41) techniques you learned to be a part of the program.

In one form or another, programs of this size use Prototyping (34) as a method of execution to get the product to market as soon as possible. Prototyping can be a great advantage or can blow up in your face. As program manager, you must stay on top of any prototyping activities that are going on and avoid disasters through forward thinking.

The Procurement Period will begin almost immediately after the contract has been awarded. These procurements are a part of the design in the proposal, and now it is time to get the “Best and Final” proposals from the competitors. It is also time to finalize any Teaming Agreements you may have entered into during the Initial Stage. It is amazing how your leverage increases with subs after you’ve won a contract.

Engineering writes the specifications, the Program Office (that’s you) writes the Statements of Work, and the Subcontract Manager writes the Terms and Conditions (Ts & Cs). Subcontracts then go through the accepted practices of advertising, proposal evaluation, and award for the subcontracts outstanding.

As the design develops, engineering develops a materials list. This is a “living list” and will be updated frequently. The Materials Manager combines all the lists at the appropriate time and order for volume.

Here is where the (in)famous 80/20 rule comes into play. You know, the one that says: “You spend the first 80 percent of the money on the first 80 percent of the program and the next 80 percent of the money on the last 20 percent of the program.” This is the point where it starts to rear its head. Your job as program manager here will be a constant state of “work arounds.” Whatever plan you had yesterday needs to be modified today because something “doesn’t fit right.” This period will try your problem-solving skills, and once again, you and your chief engineer will be living in each other’s pockets.

You are a clever and hardworking person (ahem!) and you will manage to get through even this. Until you are challenged, you can’t really understand what success is.

Testing is progressive, and its importance rises in visibility at this point. The customer is apprised of system test schedules, and you provide the test procedures sometime before the test is to begin. The usual process is to send out the test procedures about sixty to ninety days before system test and allow thirty days for comments. When comments begin to come back, you will find that some of the people who have been sleeping for the last year are suddenly awake. They are asking questions and making comments that are a year old. This is the point where your “diplomatic self” needs to come to the front. Handle these comments as best you can. Refer back to the documentation you have kept throughout the program to show your position. Sometimes even this won’t work, and people become emotional. You need to handle these emotional outbursts on a logical level. To say: “It’s not that we won’t make the changes, it’s just that the change will cost X dollars and Y months in the schedule” is the way you handle these issues. Changes at this point are very expensive. I have seen programs go berserk at this stage, and getting to agreement will test every ounce of diplomatic, psychological, and technical skills you can muster. Don’t be afraid to ask for help.

You have been leading your program team confidently, and when you enter final system test, you are ready. The team is assembled, the hardware and software have been successfully interfaced a number of times. The procedures have been run, red-lined, rewritten, and rerun. The customer is here, and you are ready for the final system test.

Even when everything runs well, there may be some minor glitches that weren’t caught earlier, or the customer suddenly decides he wants to see another aspect of the operation. These call for Action Items (AIs). Document the anomalies or changes and work them off until everyone is satisfied. All this must be kept in scope however. If not, the change may present an opportunity for a contract expansion, Engineering Change Proposal (ECP) (Glossary), or follow-on work.

You are finally here. Now, it’s a mixture of emotions. On the one hand, you’re glad it’s behind you, and it has been a successful program. On the other hand, the team members are going their separate ways. You have developed a close relationship with each of them, and they with you, over the life of the program. Now you have a retinue of folks who will be glad to work with you on any program in the future. That’s a great feeling!

The Closure Stage began during the testing phase to ensure that all the AIs got documented and worked off. And they were. Now is the time for handover to the customer.

There are some formal legal documents to sign for the system and for the security equipment and software. The chief engineer, the contracts manager, and you sign these documents. The system then belongs to the customer.

You have taken care of your people by “shedding” them at appropriate times throughout the program. Early in the program, you released the design engineers who completed their tasks. The Configuration Management (CM), quality, and Reliability, Maintainability and Availability (RMA) people were just brought on for specific tasks, and you won’t need to worry about them. At this point, you should have just enough people to get through the system test and perform the wrap-up. You should be back to the core team again, just as when you started. It’s a good time to have each member of the core team write up their “Lessons Learned” paper and give them to you. Combine and refine the inputs and create a final “Lessons Learned” paper that you turn over to your boss, and of course, keep a copy for yourself. Not only for records purposes but for reminders of changes you can make to processes and procedures when in a position to do so.

Now is a good time to write thank-you letters to all those who participated in the program and letters of commendation for those who did outstanding jobs. If you didn’t do this when it happened, you need to do it now. Little things like photos of the final product in action are greatly appreciated by the people and don’t cost a lot. One of the things that you can use is a “Certificate of Accomplishment” or the like. With today’s computers and ten cents’ worth of certificate material from the local stationery store, you can create a handsome certificate with appropriate lettering to acknowledge a person’s actions. I assure you, people hang these on the wall. This investment will return tenfold on the next program. You can bet these people will be willing to work with you on the next job that comes down the pike.

You met all your cost and profit objectives. The best part is that you have given your customer a good product, you have given the company a good profit, and have created a good reputation for yourself, so you will go up a few notches when the next, larger program comes along. That’s a good feeling, and that’s what it’s all about!

The Planning Stage of this project is critical, even more so than on a normal project or program. The communication and control of the entire project must be thought through before the project is launched and then presented in the Project Plan. The Project Plan must be written or controlled such that it can be available to everyone and yet not expose trade secrets to the competition. One of the best ways I know of to do this is to establish a secure Web site. The level of security should be consistent with the value of the data contained on the Web site. No more, no less.

First, look around. Are there other projects that have been conducted in your company using this method? If so, search out the project plan used for that project and modify it to your needs. You should probably allow for more time than usual to develop your plan and to leave time for more iterations. The most common characteristic of virtual projects is that they are all a little different.

The project plan for a virtual project must be comprehensive, thorough, and thought through (read that sentence slowly). Everyone on the team must know not only what he or she is doing but what every other team member is doing as well. As I said earlier, each function must sign up to their task, and that information must be available to the entire team on the project Web site.

In this case, the team is dictated to you. The team is established and the people and locations apprised of the need for support. Your job begins by convening the group, making a team of them, and getting the job done. This is the time and place for the team to meet and interchange electronically in the same way they would if they were meeting face-to-face.

Training a virtual team is the same and different. It is the same in that each person describes the inputs they need to do their job and the expectations they have of others regarding inputs. It is different in that it is not done in “real-time.” The nature of e-mail is that it is asynchronous—that is, response is not immediate to the question. An exception to this is made by the use of “chat rooms” to get everyone online at the same time. In chat rooms, statements or questions and responses are in near real-time.

Training begins by “broadcasting” all the necessary materials, such as vision, Mission Statement, requirements, and documents to all the team members and asking for comments. Resolve the comments and go on to the team interfacing portion, where each team member states their needs and expectations. A chat room environment is a good tool to use if brainstorming is needed. You can set up a chat room at a time most convenient to all the team members. Sometimes this is very difficult, especially if unions are involved (when it is noon here, it is midnight somewhere else, and overtime may be required), and you must also be sensitive to the observance of different cultural and religious days. This point will test your application of Social Sensitivity (42). At any rate, set up your chat room and get on and off as quickly as possible. Another method to use is a conference call. And finally, a video link can be used. Internet video linking currently gives marginal results, but gets better all the time. Advances in compression technology are refining this mode, so it is a good idea to keep up with the latest available.

Once all the training needs and issues have been met, they should be captured and placed in a reference section of the project Web site for future reference.

You will likely need to provide absolute assurance to your management that your virtual project is ready to kick off. But before proceeding, be sure that management concurs with all the objectives, goals, strategies, schedules, and so on. Conduct your kickoff electronically exactly as you would in a face-to-face situation. Once launched, virtual projects are much more difficult and confusing to change than traditional projects. When the project is launched, announce to the other team members that they may now charge to the Execution Stage of this project.

The Execution Stage of this project is accomplished in a very traditional manner—that is, design is completed before coding begins. The product is tested, and the process iterated as necessary. Granted, your project may not be conducted in this manner but the purpose in this section is to show differences between traditional and virtual project—not to make life harder!

Techniques such as rapid prototyping, build-a-little/test-a-little, peer review, and code exchange should be emphasized to enhance the probability of success.

The major difficulty you will face in the Execution Stage is, once again, communication. In this case (and this is quite common) the coding is done in a “tank” full of people. Your communication is through the local project supervisor only—he or she may be the only one who speaks your language. Using some of the techniques recommended above will help overcome this situation.

Sometimes the gain in labor costs is offset by the cost of rework, so be very careful and most explicit in your directions.

The important part of the Closure Stage is delivering the product and all of its documentation. Further, a final report and especially a “Lessons Learned” paper are in order. This is particularly true if this is the first such project conducted in your company, or the first one you have led, or there was something else unusual about it.

One of the neat things about a project such as this is that the people just fade away. You don’t need to worry about sending them back to their home units because they never left in the first place. However, a few words of caution: Make certain that the product has been accepted by the customer before closing the project. It can be extremely expensive to try to restart a project such as this.

The Initiate Stage follows the same guidelines as for the normal program except that the Initiate Stage is usually longer, a lot longer, and is usually handled primarily by an in-country marketing representative or agent. The expense of international travel is a real factor in pursuing these kinds of programs.

As stated earlier, identifying opportunities is usually the purview of the marketing department, in this case, the in-country marketing representative or agent. The in-country marketing representative usually lives with the customer and understands the cultural nuances as well as the special considerations of the customer’s procurement processes. We will likely not be involved in identifying opportunities.

Once a program has been identified and selected is where the “troika” is established, just as in a regular program. The primary difference is that the marketer will be “in country” or living with the customer, and the program manager and technical manager will stay CONUS (i.e., the continental United States). As program manager, you will assist the assigned marketer in tracking the new program. The marketer is primarily interested in the competition, the schedule for procurement release, the winning price, and the politics of the procurement. You, on the other hand, are primarily interested in the Statement of Work (SOW), the task to be accomplished, the people involved, the performance schedule, and any unusual considerations of any kind (programmatic, technical, or contractual). The technical person is primarily interested in the specification for the product, just the same as in a normal program.

How long you track the program depends on when the opportunity was identified and when the request is issued, but you can expect that the tracking period will be over a long time. How the requirement is conceived and how it develops are two of the unusual things that happen in international programs. If alliances develop, your understanding of Teaming and Partnering (37), Business Considerations (29), and Marketing and Sales (38), as well as a number of other subject areas, will be tested.

Now your presentations to the customer take on a new flair. Your teammate will be involved in your presentations even if by name only. You must be extremely careful with this type of arrangement. The alliance partner will know that he has been demanded by the customer and will likely act accordingly. In other words, you may well lose your prime/sub leverage.

After the requirement is issued, you are ready to start the proposal. This will be a moderately sized proposal but follows essentially the same path as the other program proposals. Sometimes, the price is dictated by the customer, and you need to figure out how to meet the needs of the requirement as well as making the price work. This is called a “design to cost” program. It is necessary for you to make sure the budgets are assigned and the numbers come in on schedule and on budget. Of course they won’t, so you need to stay on top of everyone that owes you cost data.

During this time, the in-country marketing representative will have been working the payment schemes. It is not unusual in international procurements to be paid in the currency of the country with which you are doing business. Now, you may be thinking, “So what? I can exchange dinars or ryals for dollars almost anywhere.” Yes, that’s true, but what if you are being paid in lumber? Specialists will need to figure out the bartering arrangements to get to dollars; it may take several “trades.” When you finally do get to some recognized currency, you will likely need insurance to “hedge” the exchange rate. In some technology areas, the U.S. Defense Department or State Department will have regulations on what technology can be exported or what can not. It’s worth knowing if this is a possible barrier before investing too much. See what I mean about the “nuances” of international programs?

You will likely send the proposal through a recognized international, rapid-delivery service to the in-country marketing representative. The rep will hand-carry the proposal to the customer with some amount of ceremony and a cup of tea. The in-country representative uses this opportunity for another interface meeting. The customer may evaluate the proposal or it may be a fait accompli. After some period of time, you will get a “turn on” for the task.

The negotiation will likely be handled by the in-country marketing representative with questions being sent to you via email or fax. Have the team answer the questions and return the answers using the same medium. Often you will need to convene the support team at unusual times because of the time differences between the host country and the providing country.

Hopefully, you were a part of the Capture Team and on top of the procurement every moment so you know what went on in the negotiations. You need to work with the in-country representative to document the findings of the negotiations just to make sure everyone knows what the program baseline is.

The Planning Stage follows the same general path as a standard program. The objective is to get a Program Plan completed and approved, bring the team on board, provide team training, and have a kickoff for your team and for management as soon as possible.

This Program Plan has a few hard points that need mentioning. The hard points usually are: customer meetings, transportation, drop shipment, port handling, taxes, fees, cartage and drayage, and local labor. Leave plenty of time in your schedule for these activities because very few other countries in the world have the same sense of schedule urgency as the English-speaking countries, with the possible exception of some European countries. Dock waits and customs can be program killers, and you will probably need an in-country agent (frequently different from the marketing representative) to make these things happen.

Have roundtable meetings with the contracts manager, the finance representative, the chief engineer, the subcontracts manager, and the in-country representative, and construct the framework for the Program Plan. Then, establish the Work Breakdown Structure (WBS) and name the subcontracts to be involved. Remember, you have an alliance, and that’s the subcontract you want to nail down before anything else. Then you want to create the Organization Chart. One of the questions for the Organization Chart is where to put the alliance that was created. All this will test your knowledge of Structures (14), Organization (19), Teaming & Partnering (37), and Negotiation (40), at least.

Once you have the Program Plan established, together with the WBS and the Organization Chart, you are ready to start bringing the people on board.

In the case of this task, your major team members will be dedicated but your program will not be projectized.

For training, follow the details of a program.

The kickoff for an international program is handled in the same way as a standard program. If possible, have a customer representative and the in-country representative attend the kickoff and let them understand where the hard spots and milestones are in the program.

As the “honeymoon period” fades, this program will likely have more problems than in a standard program, mainly because of the distance problem. A technique I have used to minimize the distance problem is to provide photographs with the monthly reports to the customer. This gives the customer something “nearly tangible” to hold on to and not feel left out of the process. Nevertheless, as you near the end of the program, the customer realizes he will be accepting this “thing” and will be responsible for it from here on. Questions and comments that should have been asked and answered in the design reviews and status meetings will suddenly take on a new level of intensity. Your position must be to document everything throughout the various periods so that, when this happens, you are ready.

Your design period follows the same sequences and requirements as the standard program.

The procurement period begins almost immediately after. It is also time to finalize the Teaming Agreement. Pay special attention to the international procurements and to drop shipping and trans shipping.

There may be special considerations for the procurements where the products will be produced in one country, shipped here, and integrated into the product that will be delivered to your customer in yet a third country. You and your procurement specialists will have a jolly good time working out all the import/export and use agreements, but this is fun stuff!

The implementation period comes next. When dealing with materials and software that are procured internationally, things that work well alone don’t always interface properly, even when all the design interfaces and Interface Control Documents (ICDs) are followed. Many things happen, and some require significant rework and retest. All that of course takes time.

Your job as program manager here will be a constant state of “work arounds.” Whatever plan you had yesterday needs to be modified today because something “doesn’t fit right.” This period will try your problem-solving skills, and once again, you and your chief engineer will be living in each other’s pockets.

The testing period really goes on throughout the entire program. Component tests, subassembly tests, and subsystem tests have been going on since early in the program. You and the chief engineer will constantly stay in contact with the test engineer to ensure that there is a lineage of tests and they are all accounted for.

Testing is progressive and incremental, and its importance rises in visibility at this point. As in standard programs, you apprise the customer of system test schedules and provide the test procedures some time before the test is to begin.

On international programs, a funny thing frequently happens about this time. The customer representative that was sent to witness the tests has some personal likes of his own. He wants you to change from what was specified to what he likes. This is a time when your “diplomatic self” needs to come to the front. Handle these comments as best you can. Refer to the documentation you have kept throughout the program to show your position. Sometimes even this will not work, and people get emotional. On international programs you may need to make critical decisions at this point. Because there will be political overtones, don’t be afraid to ask for help.

As in previous programs, you have been leading your program carefully, and when you enter final system test, you are ready. The procedures have been run, red-lined, rewritten, and rerun. The customer is here, and you are ready for the final system test.

Document the anomalies or changes and work them off until everyone is satisfied. As before, all this must be in scope.

Now is the time to ship to the customer. It is necessary to get the units to a point of embarkation, on the ships or airplanes and transported to the customer’s country. Now is when the in-country agent becomes worth his weight in gold. You need to move the units from the port to the delivery point. Duties need to be paid, and, in some cases, local contracts and “accommodations” are required. You have been isolated from all this by your agent. The agent does this every day, and it is within his operating methods to do so.

You may send members of your staff to the customer’s country to retest the units and ensure that you are delivering a compliant product to the customer. All is well. The customer is satisfied, and the in-country representative is overjoyed. This gives him something to point to with pride whenever visiting the customer and will likely lead to more business. After all, that’s why we do what we do!

There are some formal, legal documents to sign for the system, usually more than the norm. You, the chief engineer, and the contracts manager (and maybe the security person) will sign these documents, and the system belongs to the customer. Some of the documents must be sent to the Department of State or other high-level agencies to close out the program.

As usual, take care of your people by “shedding” them at appropriate times throughout the program. It’s a good time to have each team member write up their “Lessons Learned” and give them to you. Combine and refine the inputs, create a final “Lessons Learned” paper, turn it over to your boss, and save a copy for your own files for later use.

Now is a good time to write thank-you letters to all those who participated in the program and letters of commendation for those who did outstanding jobs. If you didn’t do this when it happened, you need to do it now. You can bet these people will be willing to work with you on the next job that comes down the pike.

You met all your cost and profit objectives even though it was touch and go for most of the program. You made some real-time judgments that reduced cost without impacting the product. Best of all you have given your customer a good product, you have given the company a good profit, and you have created a good reputation for yourself, so you will go up a few notches when the next, larger program comes along. That’s a good feeling and it will stay with you for a long time.

The big difference between a program and a large-scale program in the Initiate Stage is that the Capture Team for a large-scale program is not only larger but also contains more disciplines. Frequently in a large-scale program, the proposal is nearly finished before the requirement is issued. The requirement may be in the form of a Request For Proposal (RFP) or a Request For Quotation (RFQ), or, in international terms, a Tender. The technical proposal consists of volumes and volumes, the management proposal is large, and the cost proposal goes on forever with costs being presented in at least four different ways. Frequently, everything has classified appendixes.

Every company has its own methods and techniques for identifying opportunities. Usually, large programs, such as this one, are initially identified by a corporate marketing office colocated with a primary customer somewhere. After identification and qualification, the program is usually assigned to a specific division of the corporation.

Tracking opportunities are usually left to the assigned division with the division marketer in the lead and the corporate marketer in attendance whenever you meet with the customer. If you think the feudal system was possessive, just wait until you see how the collocated marketer operates. Sometimes they seem to be more customer than company. They are unusually possessive of their customer because they have other divisions vying for other opportunities and because their raises and bonuses are dependent on how well you interface with “their” customer. Who wouldn’t be possessive under these circumstances?

Most customers operate at “arm’s length.” That means they share with you enough information to get the best they can out of you. You must understand that everything the customer tells you, he has probably told someone else. The federal government, through the FARs, requires this posture. You or a member of your capture team may be able to pick up some critical piece of information that gives you an edge, but the customer won’t usually give you an edge willingly. Tracking is a sophisticated process, and unless you have in-depth knowledge of the process, it is best to leave the strategizing up to the marketer in charge of the program.

Tracking begins once the program has been qualified and continues on through the proposal until award. Truthfully, tracking continues on even after award, because it allows the marketers a different level of access and perhaps more opportunity to find other programs. That’s what they get paid for.

Bidding an opportunity begins with a top-down strategy. What is the strategy to be: best technical or lowest cost (usually it is both), and most frequently, the strategy must be “best value to the customer.” Can we create a winning strategy using our technical and programmatic expertise that other competitors do not have? Do we have leverage through a unique alliance or team? This is serious business. This is the point where a program is won or lost because the proposal will follow the strategy set here. If you’ve got it all together, this is the point to create the Executive Summary for your proposal. A summary before the document is written? The short answer is yes! The tactics of the proposal must follow some direction. That direction is set in the Executive Summary. If you can’t define the winning strategy at this point, try again or no-bid. Proposals are expensive endeavors. Guard the secrecy of this Executive Summary with your life—it’s that important. Limit the availability to just a few people. Chances are, you learned all this and then some when attending seminars that supported Proposals (39).

After the proposal is written, you will update the Executive Summary, and this time, it will be a true summary. However, the strategy you devised at the outset will have been worked into a “Features and Benefits” section, and the rest will be a real summary of the proposal.

“It was the best of times, it was the worst of times . . .”^[3] Not only does this opening establish the literary nature of a proposal, it establishes the trying nature of proposals as well. Proposals open with excitement, sink to despair, and end in trauma. During my first proposal, a friend of mine, Harry Gull, said: “You never get through writing a proposal—you just run out of time and print.” How right he was. During my career, I have written hundreds of proposals, and it seems, no matter how well organized the proposal, there’s always just one more change to be made. You know that the proposal is the lifeblood of the organization, and if you make just one more change it will be the difference between winning and not winning. In the proposal cycle, you never lose, you just don’t win.

The most difficult part of any proposal is costing. You must start your costing early and from the top down, or you will end up with such a mess you’ll never recover. Allocate cost to the various elements and then start arguing. Believe me, you will argue. Keep some dollars in your pocket for reserve and allocate them only at the last minute when you can’t make everything add up. When you get to this point, I suggest you read paragraph 8.2.4 in my book Blueprint for Project Recovery. It offers some insight into how to maintain a risk reserve. Start costing as early as you can and then on a rigorous schedule. You’ll still probably end up short on time. With the use of computers nowadays, costing should be a lot easier, but it really isn’t. The emphasis now is in refinement rather than development.

After the proposal has been submitted, the customer’s team will evaluate it. There will be questions and answers and maybe even oral presentations. Your job is to keep up the momentum, keep the people happy and creative and ready for the next round of questions. They will likely return to their operating positions at this point, so your job of keeping them happy will be a tough one.

The customer will go into what seems like hibernation (actually they are working just as hard as you did on the proposal) and for what seems like a long time. Other business will occupy the team members in the meantime. Your job is to pull the required members of the proposal team back together, brief them on the current situation, and respond to current needs. Most likely, you will need the team members more than once to answer questions that arise during proposal evaluation and then during negotiation. These questions must be answered immediately.

As stated earlier in this chapter, there is a balancing act between the marketing representative and the program person. Cost is the issue, particularly if you are still competing. You’ve got to win, but you’ve got to run the program too. Good luck! That’s the subject for several more books.

It is your job to ensure that good minutes are kept of the negotiation so that a “data trail” exists between the proposal and the final contract. When negotiations are over, everything should be documented and made ready for handover.

If there has been execution team representation during the pursuit and the proposal, handover should be relatively easy. If there is a gap, it will be difficult. The execution team must know exactly what it’s up against when running the program. You may be asking yourself right now, “Why doesn’t the execution team just read the contract?” Although this sounds easy, it may not be. There are likely nuances that were uncovered during negotiation that contribute to the changes made from the proposal to the contract. The execution team needs to know these nuances. Unfortunately, there may have been off-line agreements made and not documented. This happens all the time. Remember when I talked about how the colocated marketer operates? The execution team needs to know about these agreements.

If handover has been properly conducted, the capture team should be able to fade away, and the execution team begins its “ramp-up” by starting the Planning Stage.

The core team will already be identified, as will the critical program managers. The directors will be in place. The remainder of the staff, however, must be phased in as required. Training will be complex and ongoing for this program. The kickoff meeting will be formal and last for several days.

The Program Plan for this program will be significant. The Program Plan is developed first as an executive-level plan, and then a separate plan for each Subsystem Program Office (SPO) is developed. The core team for each subsystem develops an SPO program plan for their respective subsystems. The volumes of the Program Plan however are ordered by the way the organization is structured—that is, each program manager has their own program plan, and each of these plans will “roll up” into the overall program plan. Sort of a giant WBS.

This is an important point. The schedules presented in each of the program plans must contribute to the overall plan. An enterprise-oriented scheduling application must be used to accommodate all the various parts of the overall Master Program Plan. Even though individual inputs are allowed by the application, all inputs in this case are made by a central scheduling office to ensure consistency.

Now it is time to assemble the team. The overall team is defined in the proposal for the purposes of costing. It is likely that only the critical positions are named and resumes provided for them. The others appear simply as proposed levels and numbers. The levels indicate the cost of each position. It is not unusual to change the team composition after award as you gain insight into what must be done and reality is upon you. It has been months and months since the proposal was submitted, and some of the people have left the company and some have been consumed by other duties. If this is a cost plus program, you may need to report the new organization to the customer. The core team and the management team should remain constant, however, unless something dramatic happens during negotiation.

The complexity of this task will keep the personnel director and staff working overtime. Personnel will be taken from other divisions and from the outside. It is not unusual for a program of this magnitude to “draft” people from other divisions. Of course, this creates problems in the other divisions because the new program drafts the best from the divisions. Sometimes this process involves you negotiating releases with other vice presidents or general managers in the company. Sometimes this will stall and must be elevated to the next level for resolution. You must be prepared with the Scarlet O’Hara speech. You know: “Rhett, if I don’t get the dress, it’s curtains!” Only this time it’s “If we don’t get so-and-so, the program will fail, and you (the authority) won’t make your numbers!”

Training in this program is different from training for smaller programs and projects. Not just because it is larger, but because programs of this size develop the leadership for subsequent programs.

For training, first bring the core team and the staff together. This includes the directors and all the SPO program managers. Again, I recommend you use the Myers-Briggs Type Indicator (MBTI) program (see Chapter 8) as an opener. Follow this up with the training necessary for the program. This training includes the Mission Statement, the customer, the organization, and the requirements.

The several SPOs also have their training that will follow the same general outline as the staff.

This is the recommended, up-front training package for all the participants. Later in the program, you will want to expand the training, especially for the staff, remembering that these are the people the company will promote to higher levels in the near future. The Ned Hermann Brain Mapping Program, Situational Leadership, Targeted Selection, Managing Winning Proposals, and a host of other training programs are desirable for selected people on the program.

Each level of kickoff for this program lasts all day. There are three levels of kickoff—SPO members to SPO leaders, staff to management, and staff to the customer. Before each of these meetings, have practices and dry runs. For a program of this size, this is not “gilding the lily,” it is a necessity. The program is long and complex, and everyone must know their individual roles and the objectives of the team. Remember, the kickoff covers the Execution Stage and Closure. Everyone must agree on what constitutes closure, or you may as well not start.

The kickoff meeting should include a requirement for each presenter. The core team should indicate the contents of the presentation, the contributors (responsibilities), and the target audience for each presenter.

The Execution Stage for a large-scale program is essentially the same as for a program, but the large-scale program is considerably larger and more complex. This is a good time to fine-tune your program plan.

The design period follows the same outline as did the program before. Because this is most likely a federal government contract, you will be confronted with a myriad of Mil Standards, Mil Specifications, and other required and specific documents, processes, and procedures. Each design review is conducted in strict accordance with MIL-STD-1521.^[4] The chief engineer manages the reviews, but you must attend them all and be aware of all the details. Customer sign-off at all levels is essential for a program of this size.

The procurement period follows the same outline as the program did.

Each subsystem is developed on its own schedule. Indeed, some of the simpler subsystems can be completed far ahead of the others. It’s your decision whether to proceed with all subsystems at once and put them into storage until the Final Integration Test (FIT) or to delay the start of each so that they all finish at the same time. Of course, there are advantages and disadvantages to each approach—that’s why you get the big bucks!

Each subsystem program manager here is involved in a constant state of “work arounds.” Whatever plan was established yesterday needs to be modified today because something “doesn’t fit right.” This period will try your SPO PM’s problem-solving skills.

You and your chief engineer must stay on top of all these subsystem issues and project any impacts on FIT.

The testing period follows the same outline as all the previous projects and programs. It is very complex and very demanding.

Other than the normal elements of closure, the closure of a program of this magnitude may well be different. If you have been able to create other programs as spin-offs, you will handle the people in one way. If not, you must handle them as if this is a normal, phased-down program. At this point, I hope you have learned all there is to learn about project and program management. From here you will either go on to another large-scale program or take over an operation or a division. Whatever it is, you need to get ready for the next one.