12.1.1 The Project Start‐Up Process

Any new work assignment is interesting and difficult. For example, to take over – and run effectively – a project that is already underway and doing well is a difficult task. You have people to meet, many things to learn, yet the project's schedule advances every day, whether you are up‐to‐speed yet or not.

It is, however, far more “interesting” and difficult to start a big engineering project from scratch. Even though every project is different, I believe that there are a set of common themes that need to be addressed when starting a new engineering project. So, in this section, we will discuss how to go about getting a new engineering project started.

Back in Chapter 5, we discussed how to go about writing a winning proposal for an engineering project. Because you were paying attention, you have now actually won a competition for a new engineering project. Congratulations!

How do you go about getting your project started? The project may call for 300 people, but you had only 50 people working on the proposal with you. Furthermore, since you turned the proposal in to the customer for their competitive evaluation nine months ago, 40 of those people have gone off to work on other assignments; only 10 of the people who worked on the proposal with you are still working with you by the day of the announcement that your company has won the competition. How ought you to proceed?

First of all, there are a set of things that have to be selected or created, and somehow brought into being:

• A set of people, and some sort of organization
• Facilities and infrastructure
• A set of processes that define how certain things get done (e.g. who has the authority to purchase something, and how does that get accomplished?)
• Tools and methods, together with instruction and training
• … and many more.

Most of these have to be created essentially simultaneously. But they are not independent; there are likely linkages between them. Here's an example:

• You need to recruit a large number of people to come and work on your project; remember, we said that you have 10 people today, but in just a few weeks, you need to have 300.
• Generally, you recruit people by offering them a particular role on the project. This implies that those roles are already defined. Those people, before they accept the position, probably also want to know something about the organizational structure into which that role fits. This implies that the organizational structure too must already be defined.
• But you need help from other people in order to define all of those roles – you cannot write all those job descriptions yourself – and to define the organizational structure into which all of those roles will fit.
• Furthermore, at times, you will want to create the organizational structure around the skills/weaknesses of a particular person (including yourself!).

This would appear to say that you cannot recruit the people without having already defined the roles and the organizational structure, but also that you cannot define the roles and the organizational structure without having already obtained the services of some of those people. This sounds like a circular dependency, a Gordian knot. How do we break out of this apparent dilemma?

You start by creating a list of topics for which you need plans and initial preparation. Figure 12.1 shows a candidate set of project start‐up topics, which I provide in order to give you an idea of what you might need for your project.

That's a long list. No one can memorize even the top‐level concepts for all of these topics. So, you need to write down your approach for each of these topics. We call such a written document a plan. It doesn't really matter whether you create a separate document for each topic, or combine all of the topics into a single document. On bigger projects, each topic is likely to have a separate author (or a small team), and most project managers find it easier to coordinate the work of preparing and reviewing these plans if the item produced by each author is a stand‐alone document.

Of course, you need people to help you write all of these plans; you can't do it all yourself. But they some need guidance from you: how do you want to organize and operate the project?

Therefore, you and a small cadre of associates need to create – and document in writing – a set of top‐level strategies and approaches for everything. Then you can bring on additional people to start flushing those strategies out into actionable plans. You will need to interact with them almost daily to help them create what you need. I might schedule 15‐minute meetings with plan authors every two days during the early portions of the plan preparation, concentrating on strategy, key decisions, and a few key tables and graphics that capture our emerging decisions.

Most likely, your company actually has a library that can provide you and your authors with outlines for most of these plans, and that library probably also has examples of each type of plan that was produced by a previous project. The outlines are useful; in my view, however, using the previous complete example artifacts can sometimes bog your authors down in too much detail. I prefer that my authors just work from the outlines.

You will need to prepare some of these plans for your proposal, in order to convince your customers that you have a credible approach. Also, the specificity of these plans allows you to develop cost estimates for implementing each of these start‐up activities, which you need for the proposal. But it is likely that these proposal versions of the plans do not cover every topic, nor are they sufficiently detailed. Because of this, your team is likely to need to do some additional planning as the date of the anticipated contract award approaches.

Of course, writing a plan does not finish the job; it is just telling us what we need to set up for our project. Each plan needs to be implemented; the implementation can often wait until after you win and sign the contract.

For example, engineering projects need infrastructure:

• Electronic mail
• Directories of project personnel
• Desktop and/or laptop computers, with the appropriate software and network connections
• Security tools
• Financial reporting tools
• Schedule reporting tools
• Tools for other routine aspects of business: timecards, status reports
• Technical tools, for systems engineering, requirements management, software development, etc.
• … and so forth.

You might be able to “inherit” some of this from your company, but likely much of it will need tailoring and adaptation (e.g. your company's email system does not include directories of customers and subcontractors, and in order to protect the company's network against intrusions and hackers, they likely place various limits on the use of these systems by non‐employees), and some of it will be new. Your customer might have requirements in the contract about particular tools that they require you use: they might want you to use LaTex or Open Office for the creation of documents; they might require that you use a particular programming language and a particular compiler for that language; and so forth. Even if your company is going to provide this infrastructure, someone from your team needs to determine exactly in what configuration, how many, which rooms each item is to be installed in, and so forth. This all needs to be planned, items purchased, the financial aspects considered, the appropriate purchasing procedures followed, and so forth. Without some written guidance – the plan we talked about above – it can't be done.

On a big project (or even on a small project inside a big company), every task needs a written process. How do orders for computers get placed with a vendor? How do people record their weekly work time, so that they can be paid properly? Who is authorized to approve which type of expenditures? How do we move and store materials in a way that does not damage them, and is also safe? As you can see, a large portion of the items in Figure 12.1 address this aspect of the start‐up challenge.

You will actually need more than a written process telling you how to do something too. For each work process, you will also need:

• Some sort of training program, so that people can learn about the existence of the process, and how to use it.
• A set of tools for implementing the process. These might be as simple as on‐line forms, or complex software that performs some task relating to the process, or the tools could take many other forms. They might even be hardware tools: wrenches and so forth.
• Some sort of a database: who needs to be trained, who has been trained, and so forth.
• Some sort of an enforcement program; for example, if a process requires that people receive annual training in a subject, you must have some mechanism that verifies this is being done.

Here's an example. If you (or the customer) have a requirement that a particular construct in the chosen programming language not be used (this is actually fairly common), you must:

• Have a policy that documents this
• Have a mechanism to disseminate that policy
• Have a way to train your people about the policy
• Have tools and processes that audit software code turned into the project library for compliance
• Have a process to notify those whose code did not comply, and to track their corrective actions to completion
• Have a mechanism to track how often each person fails to comply, so that you can have a plan for retraining, or even discipline, if a given person is a repeat offender.

Since you are starting the project, you must create/borrow/steal/adapt this process, and all of those supporting steps, into being.

And then, of course, you must do that for every item on your list (e.g. your own version of Figure 12.1).

The list provided in Figure 12.1 is fairly generic, but your project might need some processes or tools that are very specific to the goals of that project. For example, when we built the world's first complete laser weapon, it involved crane operations; many of the pieces were simply too big and too heavy to be moved and placed by hand (Figure 12.2). But some of these heavy pieces had optics, mirrors, and other fragile components, so the crane operations required a balance of capacity, safety, and not over‐stressing the fragile components. This combination, however, was different from what the company's crane operators normally did; they had not worked in the past with heavy parts that also had large, fragile, glass components. We discovered that we had to create new processes and procedures for crane operations on these components. Your project too will likely have some unique aspects that will require such novel processes and procedures.

Good companies should have project start‐up procedures, check lists, and teams of people who will come in on a temporary basis and help you get the project start‐up defined and accomplished (project start‐up teams). To give you an idea of the magnitude of project start‐up, on a big project, start‐up can be a three‐ to four‐month task.

Figure 12.3 depicts an excerpt from an actual project start‐up check list, as used by an actual company.¹ The complete list is 10 pages long; I just want you to get an idea of the level of detail that a good project start‐up check list will include.

12.1.2 The Earned‐Value Baseline: A Special Project Start‐Up Task

We talked about earned value, and the creation of the schedule and cost estimates in Chapter 7. One special aspect of starting a project is the creation of a special version of those schedule and cost predictions, which is called the baseline.

You create, as we described in Chapter 7, an initial version of these predictions during the proposal activity. You use this version to obtain approval from your company to submit the bid to the customer, and of course you also provide this version to the customer as part of your proposal.

That initial version of the schedule and cost predictions is good enough for those purposes, but is seldom detailed enough actually to use in order to manage the project. Since at the time you prepare them, you don't know yet if you are going to win the competition or not, it may not be worth the effort and money to create them at that level of detail during the proposal. You probably don't have enough people available during the proposal to create schedule and cost estimates at that level of detail, anyway.

Therefore, right after you win the competition and sign the contract, you have to create a second version of the schedule and cost predictions, one that this time will be sufficiently detailed to use in order to manage the project. We call this second version – the one that we will actually use to manage the project, following the procedures of Chapters 10 and 11 – the baseline. We use that term because it is the base set of values and measurements against which we write the schedule and cost variances described in Chapters 10 and 11.

There is another reason to create this second version too: as discussed in Chapters 7 and 10, the schedule and cost predictions are worthless if each little piece is not created (and psychologically “owned”) by the actual cost‐account manager who is responsible for that piece of the work. But many of these people do not show up until after the contract is signed; remember, we discussed how the team that writes the proposal is likely much smaller than the team that will actually do the work, once we win the competition. So, it is important to allow the actual cost‐account managers to prepare the schedule and cost predictions that will be used to manage the project (which will be accomplished using the methods described in Chapter 10).

But what if these new predictions are different from the previous predictions? After all, your company actually signed a contract based on the proposal version of those predictions. Well you, as the project manager, have the challenge of trying to negotiate with the actual cost‐account managers to try to get the baseline version of these estimates to fit within the constraints of the proposal version. You may not succeed, in which case you will be starting the project “in the hole” in schedule and/or cost.

Since each cost‐account manager must “psychologically own” the result, they must generate bottom‐up estimates in which they believe, while “noticing” the top‐down guidance that you have provided (in the form of the prediction for that cost account from the proposal version of the predictions). You must therefore negotiate with each of them, clarifying/reducing scope, so that they end up as close as they can to your top‐down guidance … while still believing in the baseline predictions to which they commit.

Some cost‐account managers will meet your top‐down guidance, some will not. You must try to make it all balance at the project level. But do not “force” them to agree to numbers in which they do not believe! That always leads to later failure.

So, you and the team get to do the schedule and cost predictions all over again – and in far more detail – right after you win (in order to create this baseline version).

It is often the case (and always the case if your contract is with the US Government) that people from outside your project team will actually come in and audit your new baseline, to see if you and the team did it right; that is, that your baseline is both procedurally correct and faithfully represents the requirements for the project as defined in the contract.

Passing this audit is often both a company and a contractual requirement. Your financial staff will know how to pass this audit. Not passing the audit the first time is a sure way to annoy your customer and your management. My advice is to ask for help from corporate personnel that have done this before!

Note that when you pass the audit, you likely will “pass with findings.” This means that there are some things that the auditors think are incorrect or non‐compliant in your baseline, but the auditors also believe that these can easily be fixed. In this case, you fix those items, write a memo describing what you did for each, and submit that memo to the auditors. If they are then satisfied, they will send you a letter saying that you have now resolved all of the issues that arose out of audit, and your baseline is approved. This counts as passing the audit the first time.

Even if your contract is not with the US Government, you probably still have to conduct and pass this audit. This is because many non‐US‐Government contracting agencies have adopted similar audit requirements, and also because many companies now require such an audit, even if the contracting authority does not.

In Chapters 10 and 11, I described a process by which we update the schedule and cost predictions every month, and write variance analyses in which we compare the set of recent schedule and cost predictions from the previous several months (so that we have a time series) to our baseline. In Chapters 10 and 11, I did not describe the process which created the baseline; you may have thought that the baseline was the version of the schedule and cost predictions that was created during the proposal. In the discussion above, however, I have now made it clear that the proposal‐time version of the schedule and cost predictions is not the baseline, but instead the baseline is that version created immediately after you win the competition and sign the contract. You are usually allowed three or four months after the award of your contract to establish the schedule and cost baseline, and to pass the audit; this deadline will likely be specified in your contract, or in your corporate policy manuals.

Of course, you cannot execute the process described in Chapters 10 and 11 – of doing monthly updates to the baseline schedule and cost predictions – until after you have established the baseline. So, you don't actually start the processes of Chapters 10 and 11 until after you complete the baseline.

You do not, however, need to wait until you pass the audit to start the processes of Chapters 10 and 11. Those monthly updates can start as soon as you have a baseline, even while you are preparing for and conducting the audit, and correcting any deficiencies found during the audit.

12.1.3 Preparing to Operate at a Large Scale

One of the biggest challenges of running a big engineering project is operating at a large scale. You have people who must be recruited, trained, and aligned (Chapter 13). You have tasks and deliverable products. You have a complicated activity network that represents the schedule. You need processes and plans. You have stakeholders that have opinions, and demand attention. You need an organizational structure that makes it clear what each person and each subteam is responsible for. You need a way to monitor progress, and to notice if someone is falling behind. You need a way to help those people who are having trouble or falling behind. You need to know on what you need to spend your own time, and what you must delegate. All of this requires planning and thought, and ends up being documented in project procedures, processes, policies, and directives, and implemented via tools and training. The project start‐up procedures described in this section are intended to establish the infrastructure that will get you ready to operate at such large scale.

A special aspect for you, as project manager, on preparing to operate at large scale is the question of what tasks you should spend your own time on. We answered a portion of that question in Chapter 11: you participate in the periodic management rhythm.

But a large portion of your time is not so determinate. People will want and/or need to see you, both because of planned, but also because of unplanned, occurrences. Your daily calendar will be scheduled in 30‐minute meetings, for the entire 10‐hour work day. Most of these people will be asking for a decision. You must learn when to decide on the spot, and when to say “let me think about this for a day or two,” so that you can gather some additional data, consult with others, and just think about it. You cannot dither, but you must make good decisions. In addition, it can be valuable to instill (through your example) in your team members the notion of thinking carefully before deciding.

What you will learn is that often, your only decision variable, your only degree of freedom in making such a decision, is “who can I assign to go and fix this problem?” So, you need to build up a list of people you consider trustworthy … and be constantly on the look‐out for new people you can add to the list. This is a big part of the social benefit of the periodic management rhythm process that we described in Chapter 11; you get to see members of your staff in action, and can figure out who is ready to become one of your set of problem‐solvers. You should make it clear through actions that successful problem‐solvers are rewarded, both financially, through recognition, and through promotions and choice assignments.

12.1.4 Summary for Starting a Project

• Starting a project is fun, interesting, stressful, and a lot of work.
• You have great freedom to design the project's operations to be the way you want.
• All projects require plans, infrastructure, and processes; on big projects, the scale of these items is very significant.
• As the project manager, you have to see to the creation of all of these items.
• A special task is the creation of the schedule and cost baselines, and getting through the corresponding auditing process.
• You will need a start‐up checklist, and a set of people whose full‐time job is to get all of those start‐up tasks completed.
• Your company likely has outlines and example artifacts of the plans that you will need to create.
• Projects usually operate at a large scale, and the start‐up process is where the foundations for the capacity to operate at a large scale are developed.

12.2.1 The Benefits

There are good reasons for this: software turns out to be a mechanism by which we can implement desirable functionality into our systems. It also allows us to improve our systems after we deploy them, by loading new and (presumably) improved software onto them. We can even add functions to our system that we did not envision when we built the system. Think of all those useful applications on your phone: many of them did not exist when the phone was designed and manufactured.

12.2.2 The Problems

What comes, however, to the mind of many engineering project managers when they think about software is software as a source of problems. When an engineering project is late or over budget, it is all too frequently the case that software is the portion of the work‐breakdown structure where these problems arise. It is not unheard of for projects that entail a large amount of software development to end up taking three times as long as originally planned – and be five times over budget. Some projects without software can have larger schedule and cost over‐runs too, but projects with large amounts of software seem especially at risk for this problem.

We might be tempted to say that this must be a problem with the original estimation of schedule and cost for the software. No one apparently even tried to create a methodology for estimating the schedule and cost of software until the 1970s, when Dr. Barry Boehm of TRW (now at the University of Southern California²) started working on creating systematic methods for estimating the magnitude of a software development effort, both in terms of time (schedule) and cost.

Dr. Boehm likes to tell a story about how he came to work on this problem. In the early 1970s, TRW was getting ready to submit a proposal to a customer to build a satellite. At the final review of the cost before submitting the proposal, the experts from each segment – structure, power generation and distribution, sensors, and so forth – stood up and presented the estimation methodology for their segment of the project. The software team stood up and said “this is our estimate,” but had no rationale for how they arrived at the numbers, or why that might be a credible estimate or not. Dr. Walquist, the executive reviewing the bid, pulled Dr. Boehm aside after the meeting and said “I don't want ever to have to make a bid that includes software again until we have a credible method to estimate the schedule and cost of that software. Go and create such a method.”

Certainly, having no systematic method for estimating the time duration and cost of a software project is not a happy situation for a company that must make a bid for an engineering project that includes large amounts of software. Thanks to Dr. Boehm (and to the others who have since created similar estimation models for software), we now have estimation models, but like all other models and estimates, they are imperfect. The desire to win the bid, of course, always creates a temptation to be optimistic in these estimates, which probably reduces their credibility even further.

Having read Chapter 2, you can provide a more sophisticated, additional answer about why software projects are often late and over budget: with so many lines of code, the opportunity for unplanned dynamic behavior is very large. Having read Chapter 9, you can then improve this answer by pointing out that the entries on the project's risk register about what could go wrong with the software development are often superficial. And having read Chapter 8, you can conclude by pointing out that the measurements and analysis that we use to monitor the technical performance of the software are subject to all of the errors and misinterpretations that we discussed in that chapter.

12.2.3 Lessons Learned for the Project Manager About Software

Your team will want to be optimistic in their estimation of schedule and cost for the software; they want to win the bid. You must drive them to realism, by grounding the estimates in past rates of software productivity. You do this with the top‐down parametric estimation techniques discussed in Chapter 7, under the heading “Injecting realism into our estimates.”

In today's systems, software is where most of the adverse unplanned dynamic behavior (discussed in Chapter 2) comes from. This is, in my experience, where most of the schedule and cost problems for software originate; optimistic and unrealistic original estimates are only the second most important contributing factor. This is why I focus so much on the goodness of the design, and provide you with tools and methods both to create better software designs (Chapter 2) and to monitor the risk (Chapter 9) and progress (Chapters 10 and 11) of the software development effort within the project.

Software gets behind schedule and over cost to a shocking degree; often not just a few percent, but actual entire multiples (2×, 3×, 5×, 10×, and more). The two main causes are those cited above: (i) adverse unplanned dynamic behavior and (ii) unrealistically optimistic initial schedule and cost estimates.

Software has the ability to multiply its adverse effect on schedule and cost too. If your software is late, you may have to keep other project personnel around until the software team finishes. If you are building an airplane, if the software is years late, you have to keep the hardware designers, the engine designers, the testers, the human factors personnel, the safety personnel, the project finance personnel, and many others around, so that they can participate in integration, testing, and training after the software is finally delivered. Therefore, not only do you have to pay for the extra costs of the software, you also incur additional extra costs in order to keep your access to all of these other personnel. This multiplicative aspect – sometimes called the marching army effect – is often overlooked.

It is very tempting to your team, and to the customer, to expect that you can reuse existing software from other projects on your project. Of course you can, but experience repeatedly shows that this reuse seldom works nearly as well as expected. This reused software can require subtle adaptations in order to be suitable for your project, and it is easy to underestimate dramatically the complexity, difficulty, and therefore the time and expense of making these modifications. This is a place where looking at your company's historic archive of project activities will be helpful: you will discover that many previous projects suffered significant schedule and cost over‐runs as a result of problems with their planned level of software reuse. You can use these data to lessen your project's predictions of credible software reuse to more realistic levels.

It is also very tempting to buy software products on the market that seem to be able to perform some significant aspect of your project's mission. There is a significant risk in this, however: there is often a major discrepancy between the capabilities and levels of performance claimed for these products, and those actually provided. By all means try to make use of purchased software components in your system design, but never depend on the claims of the manufacturer. Always get the software and experiment with it yourself before committing to it in your design. Benchmark its capabilities and performance yourself; do not depend on data from the manufacturer. Try out the interfaces, data‐importing, and data‐exporting capabilities. Set up a test bed that mirrors your operational conditions, and measure achieved performance rates under those conditions. For software, seemingly small differences in operating conditions can result in a 10× (or more) difference in performance and capacity!

To some extent, this is true for anything that you buy: what the manufacturer promises, and what the product actually delivers, may be different. But the magnitude of the discrepancies between promises and delivered capabilities seems generally to be larger for software than for other purchased components.

Another, related problem is that when you buy software, you cannot control when problems get fixed, which ones get fixed first, and which ones get deferred. Neither can you control when new features get added, and in what order. Vendors who build software are often serving gigantic markets, and are often unwilling to adapt their plans to the needs of a single customer, even for a single customer as large as the entire US Government. My experience is that the large software vendors will not adapt their plans at all, in response to requests from even a large customer. Beware! They may say that they will be responsive to your needs, but unless such commitments are spelled out explicitly in your purchase order with that vendor, they have the ability to ignore such promises.

There is another, often under‐utilized source of software: something called open‐source software. Open‐source software is, as its name implies, software where the source code is made available to customers. You may not realize this, but when you buy software from a commercial vendor, almost all of the time you get only executable software code, not the source code. Not having the source code of the software that you buy means that you have no ability to diagnose problems, to correct those problems, or to add new features to that software; only the manufacturer can do that. It may even be illegal⁴ for you to try to do so. With open‐source software, since you are provided with the source code, you do have the ability to diagnose problems, correct those problems, and add new features (and the ability to decide when to do these things). You can also analyze that software. For example, you can analyze it for security vulnerabilities. When you buy commercial software, you have little to no ability to analyze that software; again, it may be illegal even for you to try to do so.

Note that when you use open‐source software, you may be required to contribute any improvements that you make back into the open‐source library. This will allow other organizations, even your competitors, to be able to benefit from those improvements! Open‐source software is not for everyone.

Open‐source software is often free, or priced very low, compared to commercial software. As I said, it may not be the answer for every software development need, but in my experience, open‐source software is often overlooked as a resource for your project. Just to give you the perspective from some actual data, at one point in time, my former company used on average about 100 open‐source packages (some large, most small) in every software‐intensive system that we delivered.

Software is intellectual property, and therefore comes with intellectual property and license provisions, whether it is commercial software or open‐source software. Beware: the specifics of these provisions vary fantastically from case to case. Never make assumptions about what the license terms for software are likely to require. Always have your legal staff review these provisions before you purchase commercial software, or before you decide to adopt open‐source software.

Since you are likely to be using both commercial and open‐source software on your project, you need to have someone keep careful track of these intellectual property and license provisions, keep appropriate records, and make sure that your project's planned use complies with the intellectual property provisions and license terms.

Just because the customer asks you to do something, that does not make it either possible or legal. I have seen government contracts that required the delivery of source code for all software, even purchased software. As noted above, when you purchase software, you almost never get the source code, so of course you cannot sign a contract that obliges you to deliver that source code. Similarly, I have seen contracts that required a particular piece of open‐source software be used, even though the license terms for that open‐source software prohibited such use.⁵ You cannot sign a contract that requires you to violate the terms of a license agreement; even the government (at least, not in the United States) cannot authorize your company to do that.

For that matter, your company probably creates intellectual property and licensing provisions on the software that your project develops and delivers to your customers. These need to be in compliance with the terms of your contract too. Do not overlook the potential for intellectual property and license provisions to be a potential competitive differentiator in a competition to win the contract for an engineering project; at times, customers react very positively to offers that provide them with generous intellectual property and software licensing terms.

Patents are treated slightly differently. If your contract is directly with the US Government, you may have a clause in your contract that provides for a patent indemnity. This type of clause basically says that if, in the course of the project, you infringe a US patent owned by some other entity, it will be the US government, rather than your company, that will be liable for any damages. This is not a “get‐out‐of‐jail‐free” card; your company may still be sued by the patent holder, and you may incur costs to defend that suit, but in the end, if you lose, the government will pay the damages (but perhaps not all of the costs). Some software – but not nearly all software – is covered by patents. Much software is not covered by patents, but instead covered by trade‐mark law, and by its licensing provisions. In any case, this is a complicated area, and you should have your legal staff (and specialized patent counsel – not all lawyers are knowledgeable about patent law) look into these matters and advise you.