• 20.1 Purpose
• 20.2 Operation model
• 20.3 Development methodology
• 20.4 Life cycle
• 20.5 Procedures
• 20.6 Plan
• 20.7 Tasking
• 20.8 Support
• 20.9 Using the operations model
• 20.9.1 Managing operations
• 20.9.2 Practical considerations

Operations covers how people on the team organize the work of building the system.

I introduced the basic ideas of operations in Section 7.3.5. In that section, I model operations as five parts: life cycle, procedures, plan, tasking, and support. In this chapter I go into more detail about each of these parts. The material in this chapter is based in part on the needs analysis reported in Appendix A.

This chapter details out the model for operations in general, without recommending specific solutions.

Note that this chapter is focused on the operations directly involved in building the system. An organization has other things that fall under business operations; I defer to others to address that broader topic.

20.1 Purpose

Operations is about organizing work, in the form of tasks. It is complementary to team and artifacts, which I discussed in previous chapters. Operations ensures that people know what tasks they should be doing, similar to knowing what they should be producing (artifacts) and who they do it with (team).

I leave “task” largely undefined, relying on its colloquial meaning. It should be taken to mean some unit of work to be completed.

Operations organizes the work so that:

1. The right tasks are done at the right time by the right person. Each task is performed by the person with the right skills to do it, and who has an appropriate role in the team. This is accomplished with tasking based on the plan.
2. Everyone does their work in compatible ways. Each team member has a single common model for how to do their work. The rules are documented clearly and understandable by the whole team. People understand what steps will be coming up after they perform a specific task. Team members communicate so that they all work with the same information and can raise issues when found. These conditions lead to people having confidence in what others are doing, and they allow detection and correction of problems. This is accomplished with the life cycle and procedures, as well as by team structure.
3. The work is done efficiently. The team avoids work that is not actually relevant to the system being built. They minimize work that is a dead end, re-work due to quality problems, waiting time because of dependencies, and overhead for operations. Operations allows detection and correction of problems, including accountability and feedback on schedule. This is accomplished with procedures and plan, especially in how they account for uncertainty and risk.
4. The work is of high quality. The team thinks through needs before moving forward, allowing for controlled exploration or prototyping. Work is checked independently to catch flaws, and steps do not fall through the cracks. Work is coordinated so system parts fit together, and flaws are detected and fixed. This is accomplished with procedures and tasking.
5. The work meets deadlines and budgets. The project can project forward the time and resources required to reach milestones, allowing for uncertainty. The work is actually possible for the team to complete. Project management can detect and resolve potential problems by adapting the plan, changing system objectives, or getting more resources. Progress is visible to project management, funders, and the organization. This is accomplished with plan and tasking, especially flexibility in planning.
6. Adapts with need. The project gracefully handles requests for changes in purpose or regulation. The project gracefully handles learning more things about the system as work progresses. The operations support people making decisions that change the plan. This is accomplished by building points where things are checked into the life cycle, and using procedures to deal with change.
7. The project supports its customer and funder. The project’s execution fits with acquisition and funding processes. This is encoded in life cycle and possibly procedures.
8. The project has a future by maintaining the information that others will need later for maintenance or system evolution. This is also encoded in the life cycle.

Each project will work out its own approach to operations. The list above provides objectives against which an approach can be measured.

20.2 Operation model

The model operations in Section 7.3.5 has six parts:

The development methodology is the general philosophy for how the team will tackle work—how to break up work and what to prioritize, for example.

The life cycle is the overall pattern of how the project works, with phases and milestones.

Procedures are the checklists or recipes for performing key tasks.

The plan is an evolving understanding of the path forward for the project.

Tasking is the assignment of tasks to people, and figuring out what tasks each person should do next.

Support maintains tools and information needed to do the other parts.

I have ordered the parts of this model by rate of change and at which decisions are made. The development methodology and life cycle are established early in the project and change slowly after that. Procedures change a bit more frequently, but not often. The plan is updated on a regular cadence, while tasking is continuous. Support activities go on throughout the project.

20.3 Development methodology

Each project will at some point choose a development methodology to follow. There are several popular methodologies, such as waterfall development, spiral development, or agile development, along with a great many variants of each.

The operations model I have presented can support any of these methodologies. The methodologies affect the life cycle patterns, how the plan is structured, and how tasking is done.

Waterfall development is characterized by developing the system linearly, starting with a concept and working through design and implementation of each of the pieces, then integrating those pieces together to form the final system. The life cycle pattern for waterfall development will reflect this linear ordering, and plans will follow the life cycle pattern.

Spiral development is organized around a set of intermediate milestones. The system becomes a bit more complete at each of these milestones (or iterations). Each milestone adds some set of capabilities to the system and the system, or some part of it is integrated and operable at each. The life cycle pattern for spiral development will define the way each spiral or iteration proceeds. The plan will reflect how the team will reach each of the upcoming milestones.

Agile development is organized around short cycles (called sprints in some versions of the methodology). Each cycle typically lasts a few weeks, and adds a small number of capabilities to the system. The system is expected to be integrated and operable at the end of each cycle. Unlike spiral development, the objectives for each cycle are typically decided at the beginning of the cycle based on the set of tasks that are ready to execute, and priorities for each task. This means that agile development is primarily about tasking, and it relies on a plan that defines what all the ready tasks are. Agile development can be complemented by a life cycle pattern that imposes discipline on the order of tasks—such as doing specification and design before implementation, or setting a review and approval step to ensure work quality.

In practice, most projects end up using a combination of methods.

The cost or difficulty of changing a decision usually drives a project to combine methods. The easier it is to change a decision, meaning undoing the work of some tasks already completed, the more agile the methodology can be. The more costly it is, the more care that should be taken to ensure that changes downstream are unlikely. (I discuss this further in Section 23.10, using the idea of reversible and irreversible decisions [Bezos16].)

The cost of change is significantly lower near the beginning of a project, when there is less work to be redone and when one change will not cause a cascade of changes to other work already completed. As work progresses, a particular change will become increasingly costly.

The cost of change also depends on the kind of work involved. Software and similar artifacts are malleable. The cost of changing a line of software source code or changing one line in a checklist is, in itself, tiny, though a change in the software may cause a cascade of changes in other parts of the system and may cost time and effort to verify. Changing a built-up aircraft airframe, on the hand, is costly in itself—in both materials and in effort.

These differences in the cost of change lead to differences in life cycle patterns and planning related to potentially-expensive decisions. For example, the NASA family of life cycles [NPR7120] follows a linear pattern in its early phases so that key aspects of the project can be worked out before the agency commits to large amounts of funding, especially for building aircraft or spacecraft hardware. Parts of some of these projects follow a more agile process after they have passed the Critical Design Review milestone (Section 24.2.1).

20.4 Life cycle

A project’s life cycle[1] is the set of patterns that define the big picture of how the work unfolds. It encodes ideas like the system going through phases: development, deployment, update, retirement. It can define phases within those. Within development, for example, there can be concept development, specification, initial design, detailed design and construction, integration, and acceptance.

The idea of a life cycle can apply to the whole system project, or to specific parts of the work. Each component in the system, for example, can have a life cycle for its development or for an update to the component. The life cycle can apply recursively to subcomponents.

In general, life cycle patterns define when one step of work should be done before another, when steps can proceed in parallel, and the conditions that define when a step is ready to start or when it is complete.

In this way, a life cycle can be viewed as an abstraction of the steps a project or a part of a project will go through. It is expressed as a set of patterns that guide how people do the work: the order in which steps are planned and performed. The actual sequence of events in the project may not match the pattern exactly, but the patterns give people a way to talk about what should happen and compare actual work to the ideal. The life cycle is not a schedule. It is a set of patterns that guide the team as they work out a plan and schedule tasks that achieve that plan.

I use the term life cycle patterns in this text to emphasize that these are ideal sequences of events, simplified to help people organize the work they do. Some of the patterns can be used repeatedly during a project, such as using the life cycle pattern for building each system component

The life cycle is not specific to a particular system project. A life cycle pattern can be more or less well suited to a project depending on attributes of the system being built—most especially how often there are irrevocable or expensive-to-reverse decisions. An organization can build up a library of patterns, improving them with experience and sharing the learning among many projects.

A project’s life cycle patterns help team members understand how the work they are doing fits with other work. It provides guidance on what they should expect from work that others are doing that will lead into work they will do. It helps people work out who is doing work related to their own, and who to talk to about that work. It helps people understand what steps will be coming up after they perform one step.

The life cycle approach is not in itself a methodology; nor does it imply a particular diagraming model or formal semantics. It is a technique for working out how the project will order its work that has evolved from a combination of examining several different life cycle standards, observing how teams use Gantt charts for scheduling, and the common practice of sketching things out on a whiteboard. I use an informal diagramming notation that is inspired by the diagrams used in NASA documents.

I introduce the general idea of life cycle here, without advocating for any particular patterns. I discuss specific examples and guidelines for building a life cycle pattern in Chapters 23 and 31.

Model of life cycle patterns. A pattern generally consists of:

• A set of phases or work steps that the work can go through.
• A set of milestones or checkpoints associated with each phase.
• Conditions that should be true before starting or ending the phase.
• Dependencies between phases.

In other words, the life cycle can be viewed as a directed graph of phases, with annotations on each phase. (Because the dependencies are time-like, the graph is also acyclic.)

For example, a simple life cycle pattern might say that a project must start with a phase where it works out and documents the customer’s purpose for the system before proceeding on to other work. That purpose-determining phase would conclude with a milestone where the customer reviews and agrees on the team’s purpose documentation. The next phase would involve developing a general concept for the system. This phase would include review milestones, checking that the concept will meet the customer’s purpose and that it can likely meet the organization’s business objectives. After those reviews, there might be a milestone where the organization makes a go-no go decision about whether to proceed with the project.

A life cycle pattern can be coarse-grained or fine-grained. A coarse-grained pattern would have phases that apply to the whole project at once, and take weeks or months to complete. The NASA family of life cycles [NPR7120] is coarse-grained: it is organized around major mission events like approval to move from concept to design, or from fabrication to launch. Fine-grained patterns might apply to a single component at a time, such as a component being first specified, then designed, then implemented, then verified, as a sequence of four phases with review checkpoints at the transition between phases.

Some life cycle patterns have phases that used many times in parallel in a project. Consider a fine-grained life cycle pattern that applies to each component. The general pattern might be:

Note that this pattern is closely related to the artifacts related to one component. The purpose phase, for example, produces artifacts on the component’s stakeholders, needs, and concept; the specification phase produces requirements and related artifacts.

A project might apply this pattern to each component being built. When multiple components are being developed in parallel, multiple instances of this pattern will be proceeding at the same time, and different components may be at different points in their cycle.

Iterative development methodologies. Many development methodologies build components iteratively rather than in one pass. Iterative development means stepping through the life cycle pattern for a component multiple times, once for each iteration. Each iteration will have different goals—different functionality to add, for example. The final iteration not only adds the last functionality but also performs final reviews and checks to ensure that the component is actually complete.

Iterative development methodologies often perform iterations that include multiple components, co-designing and implementing a set of related parts. When this happens, the iterations step through the life cycle patterns for all the components involved.

Non-linear progress and rewinding. The project’s life cycle patterns do not necessarily imply one-way linear progress; real work does not actually happen perfectly linearly.

While someone is working on the specifications for a component, they may well be thinking of design approaches. Following the four-step pattern above, the design thinking falls into a phase later than the specification work. Until the specification is final (and the specification phase is completed), any design work must be considered conditional: it might be made irrelevant as new specifications are worked out. Making the phases explicit helps people understand what work can be relied on as baselined (Section 17.4.3).

A project or the work on one part of the system can potentially move through a phase, progress to another, and later rewind back to the earlier phase. A project might rewind to a design phase when a flaw is discovered. Some implementation work has been done and might still continue while the design is reworked, as long as there is someone to do it and parts of the implementation are unlikely to be affected by the redesign.

The dashed line in the following diagram shows how work proceeds on one component. It proceeds through specification and design into implementation, with accompanying reviews ensuring that both the specification and design are complete. During implementation, the need for a design change arises, and work reverts back to the design phase. Once the redesign is done and reviewed, work goes back to proceeding with implementation.

Rewinding can happen informally or as explicit tasks. In the example, if the design change only involves fixing obvious typos, this can be done quickly and informally—though the life cycle pattern requires that the typo fixes get an independent review. This ensures that the typos really were typos and not intentional, and that the corrections are themselves correct. On the other hand, if the design change is substantial then it should be treated as tasks to be done and included in planning and tasking. This way the effort can be accounted for and any side effects can be handled, such as needing to allocate someone’s time to do a more thorough review of a design change. The difference between handling informally or as explicit tasks depends generally on whether the amount of new effort is negligible or not.

20.5 Procedures

Procedures define how specifically to do actions or tasks defined in the life cycle. They often take the form of checklists or flow charts.

Procedures are related to the system being built, but are generally portable between similar projects.

Having implemented clear procedures will:

• Let new team members know how to do steps that they might not know how to do correctly on their own.
• Help all team members do steps that aren’t performed often, where people haven’t learned the steps through frequent execution.
• Ensure that key steps aren’t missed.
• Build in ways to check quality.
• Provide a way for the team to learn and improve: when a procedure isn’t working well, the team can revise the procedure.

Having common procedures for the whole team makes key work steps less matters of opinion and more based on shared fact. This can improve team effectiveness by removing a source of conflict between team members.

A project can realize these benefits only when the team members know what procedures have been defined, when they can find and understand the procedures, and when the team uses those procedures consistently.

Three steps help team members know what procedures are defined. First, the procedures should be defined in one place, with a way to browse the list of procedures as well as a way to find a specific procedure quickly. Second, the life cycle should indicate when one procedure or another is expected to be used. For example, when the life cycle indicates that an artifact should be reviewed, it should reference the procedure for performing the review. Finally, new team members should be shown how to find all this information for themselves.

Understanding and using procedures depends on the procedures being actionable: they should indicate the specific conditions where they apply, and provide a list of concrete steps for someone to perform. This is especially true for procedures that will be used when someone someone is under stress, such as in response to a safety or security accident. I have often seen “procedures” that say things like “contact the relevant people”—which is unhelpful. The procedure needs to list who the relevant people are (or at least their roles) so that a person in the middle of incident response can contact the correct people quickly.

20.6 Plan

The project life cycle and procedures define how people should get work done in the abstract, before any work actually gets done. Now I turn attention to how the actual work is organized in the plan and tasking, using the life cycle patterns and procedures as structure.

The plan is a record of the current best understanding of the path forward for the project. It contains the foreseeable large steps involved in getting the system built and delivered, and getting it to external milestones along the way. It guides the work, as opposed to people working on tasks at random.

The plan:

• Guides the work being done, showing which tasks should be done sooner and which can be deferred.
• Helps people ensure that all needed work gets done, and that important work does not fall through the cracks.
• Helps people find and address situations where some work might be blocked waiting for other work to complete, improving efficiency of the work.
• Supports forecasting the progress the project will make and the resources involved, showing whether key milestones can be met and prompting re-planning if they cannot. This supports desires from the organization, customer, and funder to know how soon they will have a working system.
• Communicates to the team how each thread of work fits into the whole.
• Provides a framework for adapting project execution when changes are needed and as people learn more about the work ahead.

Plans versus schedules. I differentiate between a plan and a schedule.

A schedule is a “plan that indicates the time and sequence of each operation”.[3] In practice, a schedule is treated as an accurate and precise forecast of the tasks that a project will perform. People treat the timing information it provides as firm dates, and will count on things being done by those dates. Schedules are often part of contractual agreements. Because people outside the project use a schedule to plan their own activities, a schedule is hard to change.[4]

Schedules are appropriate when the work to be done can be characterized with sufficient certainty. In most construction projects, for example, once the building design is complete, the site has been checked for geologic problems, and permits have been obtained, the remaining steps to actually construct the building are generally well understood and the time and effort involved can be estimated with confidence. However, before the site has been inspected one might not be able to create an accurate schedule because there could be undiscovered problems in the ground (perhaps an unmapped spring or an unstable soil layer).

The plan, on the other hand, is not a detailed schedule. It is a general indication of the steps to be taken, along with as much information about time required for different steps as can be estimated. It will reflect varying degrees of certainty about the steps and timing, from fairly certain in the near term to highly uncertain later in the work. It provides guidance, but it does not represent a promise of dates or exact sequencing of events.

A plan is dynamic and constantly changing, as it is a reflection of where the project currently stands.

At the beginning of a project that requires innovation, the team is just beginning to work out what the system will be, and so they cannot build a schedule because there are too many unknowns. As the project works out the customer needs and basic concept, the flow of work becomes a little clearer but most of the work ahead is still unknown. People will continue to learn more and more about the system, and at each step there will be fewer unknowns and the certainty of plans can improve. Even so, the exact schedule is not known until the very end of the project—when there are no places left that could hide surprises.

To some degree, the difference between a schedule and a plan is an attitude. A schedule is something people treat as a contract, and so it does not accommodate uncertainty well. It includes a lot of detail; if that detail is uncertain, people will be constantly updating that semi-fictitious detail. A plan is a flexible current best estimate that doesn’t promise much except to accurately reflect what is known, and avoids information that might appear accurate but in fact is not certain. A schedule is useful to someone writing a contract to get something done. A plan is about an honest accounting of where the project stands and where it is going, and thus more useful to the people building the system.

Making and updating the plan. The plan starts at the beginning of a project, and is continuously revised until the project ends.

Assembling an initial plan starts with knowing the status of the project and working out the destinations. At the beginning of a project, the status is that the project is largely undefined beyond a general notion of what customer problem the system may solve. The endpoint might be delivering a working system, or it might involve expecting to deliver a series of systems that grow over time.

Initial plan for a new project.

If the project is already in progress, one starts on the plan by working out what is currently completed and in work.

Example initial plan with milestones filled in.

The next step is to fill in major intermediate milestones and work steps. The project’s life cycle patterns should provide a guide to these. For a new project, the life cycle might indicate that the project should start with a phase to gather information about customer needs. As the first phases progress, the team will begin to develop a concept for the structure of the system. If the customer or funder has required some intermediate milestones, those can be laid in to the plan, along with very general work steps for getting ready for each of those milestones.

Example life cycle pattern for the overall project.

It is normal for the plan to have large work steps that amount to saying that somehow the team will get something completed or designed or whatever. In the example above, “implement system” is completely uncertain when the project starts. When one does not know how part of the system will be designed, or how to implement some component, or even how some part of the work should proceed, it is better to put in a work step that accurately reflects the uncertainty. Being accurate about what is known and not known prompts people to find answers to the unknowns, gradually leading the plan toward greater certainty.

The plan then grows according to the system design. As the team works out the components that will make up the system, each new component creates a stream of work to be done to specify, design, implement, and verify that component, as specified by the life cycle. All these add new work steps into the plan, along with dependencies from one step to the next.

Example pattern for developing a component (linearly).

The plan should be revised regularly. It will change whenever there is some change to the likely structure of the system and as each component proceeds through its specification and design work. Many components will require some investigation, such as a trade study or prototyping, before they can be designed. The plan will evolve as those investigations generate results.

Part way through building the system, the plan will typically become large and show significant parallelism. This is also normal and desirable, because it reflects the true state of development. Mid-project there usually are many things that people could be working on. The plan should reflect all these possibilities so that those managing the project know the true status of the work and can make decisions with accurate information.

Example plan in progress. Some steps are complete, some are in progress.

The life cycle patterns a project uses provide building blocks out of which people can construct parts of the plan, but they do not dictate the plan entirely. Maintaining the plan is not simply a mechanical process of adding a set of work steps each time someone adds a new component to the design. There are three more factors to consider, and these make maintaining the plan a task requiring some skill.

First, the various components will be integrated into the system. The steps to put the components together and then verify that they interact correctly adds more work steps.

Second, a component does not necessarily proceed linearly through specification to design to implementation. Often the design will require investigation, perhaps a trade study to compare possible alternatives. In many cases it is worth building a simple prototype of one or more of these alternatives to learn more about the component before settling on a design. This turns a design step into several steps. Sometimes the outcome of an investigation is that the whole approach to designing a set of components is wrong and design needs to be revisited at a higher level. (This is the rewinding discussed in the section on life cycle above.)

Third, many system development disciplines, such as agile or spiral development, do not proceed linearly with developing a component from start to finish in one go. They often focus on building a simple version of a component or of a collection of components first, and then adding features over time.

Each project will have its own style for addressing these factors, and this will be reflected in the specific work steps included in the plan. For example, when a project follows a spiral development methodology, the plan for developing a part of the system might have several internal milestones: first a simple version of the components that can do some minimal function, then another version or two with increasing function. There might be design, implementation, and verification steps for each component involved for each milestone.

A project should document what methodology it has chosen, so that team members know what to expect and so they can plan consistently.

20.7 Tasking

Tasking is about the day-to-day management of what tasks people are working on and what tasks are ready to be worked.

The choices of what tasks are ready is based on the plan, along with bugs that have been found, management tasks that need to be done right away, and ongoing tasks that do not show up in the plan.

Tasking builds on the plan. The plan should be accounting for which tasks need to be done sooner than others in order to meet deadlines or to avoid stalling because of a dependency between tasks.

The objectives for tasking are:

• To keep everyone on the team productively busy;
• To keep everyone on the team informed of what they can work on, and who will be working on related tasks;
• To make task assignments that fit with team members’ roles (Section 19.2.4);
• To help detect when a task is not going as expected and lead to a response to address problems;
• To focus on higher-priority tasks; and
• When a task involves multiple people, they are all available together.

One can treat tasking as a decision or control process that works to meet those objectives. Other scheduling disciplines, such as job-shop scheduling and CPU scheduling, can provide useful ideas for how to make choices about who should work on what.

There are many different choices about when, who, and how much. Each project will need to define its own approach, usually following whatever development methodology the team has selected. The approach should be documented as a procedure that the team follows.

Decisions about tasking can happen at many different times. It can happen reactively, when one task is completed, when a task someone is working on is stalled waiting for something else to happen, or when some urgent new task arrives (such as a high-priority bug or an external request). It can also happen proactively or periodically, putting together a set of tasks for someone to do ahead of time.

Tasking can be done by different people as well. In the teams model (Section 19.2.4), the authority to make tasking decisions is a role that can be assigned. One person can have a scheduler role and make these decisions. A group can divide up tasks by discussing and reaching consensus. Each person can take on tasks when they are ready for more. Combinations of these also work.

Finally, tasking decisions can occur one task at a time, or they can focus on giving each person a queue of tasks to perform.

A large project will have a very large number of tasks—potential, in progress, and completed—to keep track of. Using a shared task tracking tool of some kind is vital. Without one, tasks will be forgotten, or there will be confusion about how they have been assigned. The tracking tool is another one of the tools that the project should maintain (Chapter 18).

Each task must be defined clearly enough that the person doing the work can properly understand what is to be done, and so that everyone can agree when the task is complete.

20.8 Support

The decisions made in planning and tasking need supporting information.

Risk and uncertainty affect choices of what should be done sooner or deferred. I have often chosen to prioritize work that will reduce risk or clarify uncertainty, in order to make the project more predictable down the road. Many projects maintain a risk register, which lists matters that could put the project at risk. These risks are often programmatic, such as the risk that a delayed delivery from a vendor will cause the project to miss a deadline. I have on some projects maintained a separate, informal list of the technical uncertainties yet to be worked out; for example, how should a particular subsystem work?

Project management will also need to manage budgets. Programmatic budgets, most often funding, affects how the project execution can proceed. Technical budgets, such as mass, power, or bandwidth, are aspects of the system being built. For both types of budgets, the amount of the resource that has been used and the amount left need to be tracked. The project will need to estimate how much more of them will be needed to finish the project. If there isn’t sufficient resource left, then the project management will have a decision to make—whether reallocating resources, reducing demand, or finding more resources.

Almost every project will need to report on how the work is progressing, relative to deadlines and available resources. The plan mechanisms should help people obtain and organize this information.

20.9 Using the operations model

20.9.1 Managing operations

Managing operations has much in common with managing the team structure (Section 19.3.1). The approach to operations is defined early in a project, leads to habits that the team uses, and is maintained as the project moves along. Operations fits into the control system model proposed for teams.

The team decides on its initial approach to operations when the project starts. The initial approach might be simple and worked out on the fly, appropriate for a project that must first sort out what kind of system it is going to build, as happens in a startup company. Other projects will inherit an existing approach to operations based on the organization they are part of or from the team’s previous experience.

A team establishes habits of how to do their work early on in a project. People mostly act on their internalized understanding of how they are expected to work, not by referring to documents or by working out what they should do from first principles. When these habits match the behaviors needed for the project to meet its objectives—such as those listed in Section 20.1—then the project can proceed smoothly. If there is a mismatch, then the project will have problems.

This implies that a project should establish its operations approach early, meaning the life cycle patterns and procedures it uses, along with assigning roles to handle plans, tasking, and support. The earlier that a project makes these decisions, the sooner the team can learn them and begin building habits around the intended approach. I have supported projects that prioritized writing code over working out operations; when those projects later tried to confront the operational problems they were having, they were unable to get people in the team to change the habitual and dysfunctional behaviors they had worked out in the absence of direction.

At the same time, no approach to operations will be perfect, and a project’s needs often change over time. A well-functioning project has people responsible for watching how well project operations are working, detecting when there are problems, and adjusting the life cycle, procedures, or assignments from time to time. The control system approach introduced for teams is helpful for thinking about how to maintain a project’s operations.

20.9.2 Practical considerations

Some people will look at the life cycle and procedure parts of this operations model and say that it is “process”—a term that has acquired a negative connotation. Yes, the life cycle and procedures do define processes that are supposed to guide the team. Process, when done well, helps a team work more effectively and more happily. Such process is simple: it is a guide for how to do common sequences of events, or tasks that are critical to be done a certain way. It provides a checklist to make sure things get done and aren’t missed. It encodes checks to make sure technical work is done correctly.

I have outlined the advantages that life cycle patterns and procedures can bring to operations in Section 20.1 above.

In my experience, the potential disadvantages, and the reasons people have come to dislike the idea of process, arise from three misuses of operations: making it too heavy, making it too complicated, and defining something the team is unwilling to use.

As an example, a colleague told me about a project they had worked on where getting approval to order a fairly simple part (for example, a cable) took multiple approvals and potentially weeks to complete (heavy process). Indeed, nobody was even sure exactly how to go through the process to get an approval to get the part ordered (complicated process). The processes were, presumably, put in place to ensure that only parts of sufficient quality were used and to manage the spending on parts acquisition. In practice the amount of money spent on people’s time far outweighed potential cost savings, and the amount of work required for people to review an order over and over meant that the reviewers did not have the time needed to perform meaningful quality checks.

A “heavy” life cycle or procedure is one that takes more effort or more time than is warranted for the value it provides—meaning it subtracts from the value of the project. This works against the objective of doing work efficiently. Each part of a life cycle pattern or procedure should have a clear reason for being included. The effort and time involved should be compared to that reason, and the procedure or pattern should be redesigned if the comparison shows it is too heavy. To avoid this, each procedure and life cycle pattern should be scrutinized to eliminate any steps that are not actually needed.[2]

A complicated life cycle or procedure is one that involves many steps, often with complex conditions that have to be met before some step can proceed. In the example from my colleague, nobody on the team could figure out all the steps that needed to be done. This can be avoided by, first, ensuring that procedures are as simple as possible, and second, by documenting them and making that documentation easy for people on the team to find and understand.

Teams are generally willing to follow procedures, as long as a) they know what the procedures are; b) they understand the value of following them; and c) following procedures has been made a part of the team’s norm. This means that the life cycle patterns and procedures should be documented, and their purpose or objectives should be spelled out. Normalizing following the procedures, however, is not something that can be accomplished by just writing something down. This has to be practiced by the team from the start, with leadership setting examples (see Section 19.3). Involving the team in setting up the life cycle patterns and procedures can help people understand and buy into the process.

Bear in mind that when a project adopts a particular life cycle pattern, the project is making an implicit commitment about staffing. If the pattern indicates that certain reviews must happen before key events happen, like ordering an expensive piece of equipment or beginning a complex implementation effort, then the project must ensure that there are enough people with enough time to perform those reviews. If the project does not staff enough, people on the team will quickly learn the (correct) message that the project or its organization does not actually care about the reviews and will begin to work around the pattern.

How all of this is handled for a particular team depends a lot on the team’s size. It’s common for a project to start with simple life cycle and planning when it is small and the project is uncertain. The project will need to shift strategies at times as the team grows, as the work becomes more complex and interconnected (see team growth in the previous chapter).