The case for the project. Preparation includes getting funding or approval to begin pursuing the project. This usually includes developing an initial pitch for what the project might be about, who will benefit, and roughly what level of resources will be needed. This initial case for the project will evolve from a vague notion at the start to whatever is needed to get approval and funding.

I have found two guides useful for making this initial case. The so-called Heilmeier Catechism [Heilmeier24] is a set of questions originally developed to guide people pitching project ideas to the US Defense Advanced Research Projects Agency (DARPA). (Appendix B lists the questions.) It consists of eight questions that prompt one to articulate the what and why of the project, along with what it will take to do the work. The second is the CSP project startup document template [Wilkes90], which was developed at the Concurrent Systems Project at HP Labs in the 1990s to guide people to think through what they mean to do in a new project. It is organized around the scientific method, and is phrased in terms of a research investigation; however, it is just as useful for other kinds of projects. There are variations on these guides that add questions, such as: How might the result of the work be misused?

In practice the people starting the project will not begin with answers to these questions. They will have some general ideas for a system project, and their job during the preparation phase is to investigate those ideas to work out answers to the questions. As anyone who has tried to form a startup knows, the system that eventually gets built usually is different from the first ideas—and it is the process of investigating answers to these questions that will find the final answer.

These efforts to work out the project’s case naturally include identifying stakeholders (Section 16.2). They also include some of the work to define the system’s purpose (Section 28.3).

Project operations. Project preparation also works out how the project will operate. This includes:

• The life cycle pattern and development methodology to be used for the project;
• Procedures for each phase, especially for review and approval of work (Section 20.5);
• How planning and tasking will be done (Section 20.6 and Section 20.7);
• What kind of team is needed, in terms of capabilities and numbers;
• Team management processes (Section 19.3);
• Team organization, scopes of authority, and communication patterns (Section 19.2);
• The kinds of physical space the team will need, such as offices or lab space;
• The kinds of artifacts involved in making the system (Chapter 17); and
• The tools and infrastructure to be used to support the work (Chapters 18 and 32).

Decision point. At some point during preparation, a decision must be made whether to pursue the project or to stop, based on the case for the project and a general understanding of its costs. The decision should be included as an explicit milestone for the preparation phase, or immediately after, so that people on the team are reminded to take the time to think through whether the project makes sense before more resources are committed.

It may seem that the decision can be left implicit when the project needs no external resources—but in practice the resources used always represent an investment and there is an opportunity cost if the team could be working on something more useful.

Outputs. The preparation phase results in many document artifacts, which the team uses later as they execute the project. The documents record the many decisions that people make during preparation.

People will use these artifacts in a number of situations:

• When someone joins the team, and needs to learn how the team operates;
• As reference material while executing some step in the project; or
• As input to developing the system concept.

Timing. Bearing in mind that as the project and team are systems that bear careful design and implementation of their own, working out how the project will run is a process that takes time. Most projects start small, with just a few people and a general approach to how the project will operate, and develop additional details over time. Project preparation thus usually overlaps the beginning of development.

Progress on developing the project’s operations plans is balanced against the project’s progress on getting started and working out the system concept. Bear in mind Section 8.1.5—Principle: Team habits: the team will develop habits based on the procedures and organization they are working with, and changing those habits is hard. If the project leadership takes too long to develop team organization or life cycle patterns and procedures, it can become expensive and error-prone for the team to change behavior. On the other hand, if the project leadership rushes to develop these procedures and organization and gets them wrong, the team can end up in a similar situation.

The resolution to this dilemma depends on judgment by the project leadership; I know of no recipe for getting things exactly right. A few principles can help:

• Openness with the team about how much of the project’s procedures and structures have been worked out, and what is still in development. This can keep the team from developing false confidence in how they understand the project to work; it prepares them for changes to come.
• Work out parts of procedures, patterns, and organization before they are needed. If the team is going to start developing a component, have the general life cycle pattern worked out for component development. Sometimes a team can try out a prototype life cycle pattern while developing one component before accepting the pattern for general use—but the trial usage should be done and the pattern should be decided on before many people begin doing that kind of development. This means that project leadership is monitoring the team’s progress and anticipating what is needed.
• Make the time to work out things that are needed. This principle follows from the previous: it takes time and effort on the part of project leadership to be prepared before the team needs organization or procedures. I have too often seen leadership end up overworked and managing by crisis, only taking the time to work out procedures when the need is blocking someone on the team (or later, after someone has used some kind of workaround). This is an indication of project leadership that is in trouble, and should be a sign that the project is trying to move faster than it is in fact able to move at the time. At times the best course is to slow down parts of the team so that the project organization can be worked out. Attempts to move a project faster than this, in my experience, do not in fact work out; projects that do this end up with problems that delay the system development in the long run, even though they make something look good temporarily in the short term.
• Include the team in developing procedures and organization, so that they have a stake in the result. The people in the team are the ones who will be using most of the procedures and life cycle patterns that the project works out. As I have mentioned earlier (Section 8.1.6), they need to know about and understand procedures, and they need to have confidence that the procedures will provide a positive benefit to the project. While the team members in general may or may not be responsible for developing organization structures or life cycle patterns, getting their suggestions and feedback improves the chances they will accept and work with the organization once it is adopted.

Completion. Project preparation is complete for the most part when the project is set up to execute. This includes having funding or approval to do the project, as well as having team structure, life cycle and procedures, artifact management, basic tools, and resources are worked out.

Preparation is never truly complete, however. Many of the things worked out in preparation will need to be revised as the project goes on. For example, a team’s organization usually needs to change as the team grows from a few people who can collaborate informally to a large team who need more formal organization (Section 19.3.2). The project may also need to change the focus of the system based on funder or customer needs; changing the system may mean changing how the project runs.

Milestones. There are no milestones intrinsic to project preparation in general. The principle of working out how some part of the project will work before the team needs that information applies, but that is not a milestone in itself.

Other stakeholders may impose milestones on project preparation. For example, getting funding from a funder or approval for the project from the organization may be required.