5
Hybrid Project Planning and Structure
Hybrid projects require up‐front thought and planning to structure them appropriately. By structure I mean determining the development approach you will use for each deliverable, the life cycle phases, and how you will integrate adaptive and predictive approaches in your project. You will also need to consider which elements should be in your project management plan and how detailed they need to be. Deliverables usually have various reviews and sign‐offs. You can record this information plus milestones and key delivery dates in a project roadmap.
In this chapter we will cover fundamental concepts in project planning. These concepts apply throughout the project, regardless of the development approach you are using. We will review common elements in a project management plan and discuss how to tailor them. Then we we'll describe a project life cycle and project phases. We'll demonstrate these concepts by showing how this information would be applied to the Dionysus Winery project. Last, we'll introduce a project roadmap and show how it provides a high‐level structure for the project.
PLANNING FUNDAMENTALS
There are two fundamental truths in project management:
- You can't know everything at the start; and
- You have to balance competing demands.
We'll start by looking at a planning technique that accounts for the uncertain nature of projects.
Progressive Elaboration and Rolling Wave Planning
Once you have a project vision statement and/or a project charter, you can start planning the project. There is usually some degree of planning at the start of the project and then varying degrees of planning as the project progresses.
As discussed in Chapter 2: “Choosing a Development Approach,” projects with evolving scope don't need a lot of up‐front planning. With this type of project there isn't a lot of certainty about the scope, and therefore it doesn't make sense to spend time estimating resources, duration, and budget in detail at the start of the project.
For projects with well understood and well‐defined scope, there is more planning up front, but not everything can or should be planned out in detail at the start of the project. This is because while the resources, schedule, and cost estimates may be fairly certain for the first 90 days, once you get too much past that, things become more uncertain. Risks and issues can occur, stakeholders can change their minds, there could be schedule delays, changes in team members, and so on. Therefore, even with waterfall projects, we expect to continually provide more detail to plans and estimates as a project progresses. This concept is known as “progressive elaboration.”
Progressive elaboration is a fact of life on projects. Even though we would love to be able to accurately predict exactly what will be happening on day 210 of our project and how much of the budget we will have spent, it is just not possible.
One way to balance the uncertainty associated with projects and the desire for predictability is to use rolling wave planning. Rolling wave planning ensures that the time spent planning is appropriate for the point of time in the project. Some people use a 90‐day horizon—meaning that information for the next 90 days is documented in detail. This can include schedules with activities, dependencies, and defined durations. The cost estimates have a tighter range, and resources are committed. Information from 90–180 days is planned in less detail. Schedules may have less detail, and the cost estimates may have a wider range. The necessary skills may be identified, but some of the activities may not have specific individuals assigned yet. Work that will take place more than 6 months in the future is held at a milestone level with rough estimates for costs.
Depending on the project, you may have shorter planning “waves.” For projects with fixed scope that are shorter than 90 days, you can usually do a reasonably complete job of planning at the start and merely fine‐tune your estimates along the way.
Progressive elaboration doesn't mean you ignore the milestones and summary level budgets from the charter. It means you don't spend a lot of time trying to get into the low level of detail for the entire project at the start. You elaborate and refine the detail as you progress through the project.
Competing Demands
There's a project management saying: “You can have it good, you can have it fast, or you can have it cheap. Choose two.” Said another way, “Scope, schedule, or cost—which is most important?” Scope, schedule, and cost have been referred to as the “iron triangle.” While that is a powerful mental image, it doesn't tell the complete story.
To be certain, those are three important constraints in projects, but they aren't the only constraints we need to be aware of. Let's look at a few examples using a project to build a custom home.
Scope and quality are different: Let's say the customer wants tile floors. You can go to the local hardware store and pick up tile that costs $5 for each 12 by 12 tile. But that $5 is a very different quality from an Italian marble that is $20 for the same size tile. The scope of having tile floors may be met, but it may not meet the quality the customer was hoping for. In this example there needs to be a balance between the constraints of quality and budget.
Cost and duration are dependent on resources: In a perfect world team members with the skills you need are readily available, and all the materials you need are local and reasonably priced. We all know that while this is possible, it is not guaranteed. Sometimes team members are on other projects, and sometimes there are supply chain issues that delay schedules and increase prices. This demonstrates the need to balance resources with schedule, budget, and perhaps even scope and quality.
Risks can affect any aspect of the project: Even if you have all the resources you need, a realistic schedule, agreed‐upon quality requirements, and sufficient budget, there is no guarantee that a risk, issue, or problem won't come along and negate everything.
Therefore, I consider that every project is subject to at least the following six constraints:
- Scope;
- Schedule;
- Cost;
- Quality;
- Resource; and
- Risk.
In addition, most projects are subject to regulatory constraints that are specific to an industry or profession. And let's not forget stakeholders. Stakeholders are the reason projects exist. Therefore, throughout the project when we are balancing our competing demands, we should also consider stakeholder satisfaction among our constraints.
Thus, beginning with planning a project and continuing throughout, we are always balancing and rebalancing competing demands. This takes constant attention and good judgment in order to deliver your project successfully.
THE PROJECT MANAGEMENT PLAN
A governing document for waterfall projects is the project management plan (aka project plan). The information in the project management plan and the level of detail is dependent on the project and organizational guidance. Developing the project management plan can be a time‐consuming and rigorous process for large complex projects. However, the process of developing the plan surfaces valuable information and can help the project run smoothly.
A project management plan usually has a description of the life cycle and phases and several subsidiary plans for key elements of the project. It also describes the necessary key reviews.
Subsidiary Plans
Subsidiary plans address how specific areas of the project will be planned and managed. For example, many projects have a risk management plan that outlines how the team will identify, analyze, and respond to risks.
Table 5‐1 provides a description of common subsidiary plans and their contents.
TABLE 5-1 Subsidiary Plans
| Plan | Content |
|---|---|
| Scope management plan | Guidance for how scope will be defined, documented, verified, managed, and controlled;Instructions for gaining formal acceptance and verification of project deliverables;Process for controlling changes to the project scope. |
| Requirements management plan | Describes how requirements will be collected, tracked, and reported;Describes the configuration management plan for requirements;Defines requirements prioritization criteria;Establishes a requirements traceability structure. |
| Schedule management plan | Describes the scheduling methodology;Identifies the scheduling tool;Sets the format for developing the project schedule;Establishes criteria for controlling the project schedule. |
| Cost management plan | Defines the precision level of estimates;Defines the units of measure; Establishes cost control thresholds. |
| Quality management plan | Identifies quality management roles and responsibilities;Defines the quality assurance approach;Defines the quality control approach;Defines the quality improvement approach. |
| Staffing plan | Outlines roles, authority, and responsibility;Sets the project organizational structure;Describes staff acquisition and release processes;Identifies training needs. |
| Resource management plan | Identifies how physical resources will be estimated;Defines how and when resources should be acquired;Outlines information for resource logistics (delivery, storage, management). |
| Communications management plan | Describes the type of information that will be distributed: level of detail, format, content, and so on;Identifies the audiences for each communication;Outlines the timing and frequency of distribution;Documents a glossary of terms. |
| Risk management plan | Outlines roles and responsibilities for risk management;Identifies budgeting and timing for risk management activities;Describes risk categories;Provides definitions of probability and impact;Provides a probability and impact (PxI) matrix;Describes quantitative reporting methods if used. |
| Procurement management plan | Outlines procurement authority, roles, and responsibilities;Documents the standard procurement documents;Identifies contract types;Documents selection criteria. |
| Stakeholder engagement plan | Identifies the current and desired level of stakeholder engagement for categories of stakeholders;Describes actions to engage stakeholders effectively;Identifies relationships and interdependencies among stakeholders. |
| Change management plan | Identifies how change requests will be submitted;Documents process for evaluating change requests;Defines the membership of the change control board;Outlines the authority for approving changes. |
Of course, there are other plans that may be appropriate for projects, such as a logistics plan, configuration management plan, and safety plan. For some projects more detail than what is outlined above is appropriate; for other projects less information is appropriate.
Tailoring the Project Management Plan for Hybrid Projects
Leading hybrid projects requires you to tailor the project management plan even more than for a waterfall project. Below are some examples of how you might need to tailor components of your project management plan.
- The scope management plan may have information on which deliverables will use predictive methods for scope development and which will use more evolutionary methods.
- The schedule management plan may indicate that certain deliverables will be scheduled using a Gantt chart and others with a task board. The schedule management plan will also describe how the task board work will be integrated and shown on the overall project schedule.
- The staffing plan may address different roles and responsibilities for the team, such as the scrum master, project manager, sponsor, and product owner. There are different certifications for roles in Agile projects than there are for waterfall projects, so any certification or training requirements would be documented in the staffing plan.
- The communications plan generally documents various types of meetings used to communicate status. The types of meetings used on adaptive projects are different than those in a predictive project. Therefore, the expectations for which types of meetings, the frequency, and who is expected to attend would be documented in a communications plan.
- The change management plan may identify which deliverables need to go through a change management process and which are considered evolving.
These are just a few examples of how you might tailor a project management plan to meet the needs of a hybrid project.
PROJECT LIFE CYCLES
A project life cycle is a series of phases that a project goes through from inception to completion. Project phases are specific to the type of work being done. For example, in Chapter 1 we showed a sample life cycle for a construction project as shown in Figure 5‐1:
FIGURE 5‐1 Construction project sample life cycle.
Obviously, you would not use the same series of phases for a project to develop a research and development (R&D) project. For R&D a more appropriate life cycle might be similar to the one shown in Figure 5‐2.
FIGURE 5‐2 R&D project sample life cycle.
In this sample life cycle for an R&D project, if the team is using an adaptive development approach, the plan, develop, and test phases would likely be happening iteratively and at the same time. In a waterfall approach the phases would happen sequentially, or possibly overlap. Therefore, the nature of the product influences the development approach, and the development approach influences the life cycle.
Project phases represent the type of work being done. I think it is useful to have a brief description of the work that will be done in each phase and the criteria for advancing from one phase to another. Table 5-2 shows an example of the life cycle I used for writing this book. In addition to listing the phases, it describes the type of work performed in each phase and the criteria for advancing to the next phase.
TABLE 5-2 Life Cycle Phases for Publishing a Book
| Phase | Work | Advancement Criteria |
|---|---|---|
| Proposal |
|
|
| Write |
|
|
| Edit |
|
|
| Layout |
|
|
|
| |
| Market |
|
|
You can see by reviewing the table above that the phase descriptions are brief. They provide just enough information to indicate the activities happening in each phase and what needs to happen to move into the next phase. In many projects there may be overlapping phases. For example, there may be some overlap in the edit and layout phases and in the print and market phases. In that case you may have phase completion criteria rather than advancement criteria.
A hybrid project that has different development approaches may have a life cycle with phases that run in parallel. There could be a start‐up phase for the overall project and then multiple phases where development takes place depending on the type of work. For example, you might see phases for requirements → develop → test for a software deliverable running in tandem with phases for engineering → build → finish work for a construction deliverable. This type of life cycle adds a level of complexity because of the need to coordinate different types of work and deliverables across the project.
KEY REVIEWS
Projects often have reviews at key points in the project. They may occur at the start or end of a phase or when a critical deliverable is complete. The purpose of a review is for relevant stakeholders to review the work, ask questions, see a demonstration (if possible), and ensure that certain criteria (such as advancement criteria or acceptance criteria) have been met.
Examples of key reviews include an integrated baseline review, preliminary design review, and engineering peer review. The descriptions below provide a general idea of what to expect with key reviews.
- Integrated baseline review (IBR): An IBR is used to confirm that the project is planned well. The review assesses at least the following:
- A robust risk assessment has been conducted, and risks have been addressed;
- The scope, cost, and schedule baselines are in alignment;
- There are appropriate control systems in place;
- The project management plan is complete and sufficient to move forward.
- Preliminary design review (PDR): A PDR confirms that the project can move forward with detailed planning. This review assesses at least the following:
- The preliminary design meets all the requirements;
- The project is able to meet the cost and schedule baselines;
- Technical risks are acceptable and have adequate responses in place;
- All interfaces have been identified;
- Verification methods have been identified.
- Technical peer review: A technical peer review is not attended by management; rather, it is an opportunity for peers to review the work. It is generally used in engineering projects. These reviews are often held in the development phase of a project and may be used to review product components or completed products.
As with everything, reviews depend on the nature of the deliverables and the project. Small projects may have a single review before transitioning to operations. Large projects may have as many as 7–10 reviews that are multiday affairs with clients, contractors, and subcontractors.
A review at the end of a phase is often called a phase gate. A phase gate is used to determine if a project is ready to advance to the next phase. Usually this means that the completion criteria for a phase have been met. Sometimes a project will advance, even if there are one or two items that are still in progress or need to be revised. In rare occasions a project will be terminated at a phase gate because the need for the project no longer exists, because it is clear the project can't meet the objectives, or other reasons.
PROJECT MANAGEMENT PLAN FOR A HYBRID PROJECT
We'll use the Dionysus Winery project to demonstrate how to tailor the components in the project management plan to meet the needs of the project. We'll start with documenting the development approach and life cycle, then discuss which subsidiary management plans would be useful, and finish up with key reviews.
Development Approach
Different deliverables will have different approaches. The construction and renovation will do well with a predictive approach, while the management system can be developed using an adaptive approach.
Tony has met with the project team, and they have documented the development approach for each deliverable along with a brief explanation on why the approach will be used.
TABLE 5‐3 Development Approaches for Dionysus Winery Project
| Deliverable | Development approach | Comments |
|---|---|---|
| Boutique hotel | Waterfall | The requirements for the hotel are well understood and are not likely to change. Much of the planning can take place at the start, and the plans can be baselined and followed. |
| Restaurant | Waterfall | The requirements for the restaurant are well understood and are not likely to change. Much of the planning can take place at the start, and the plans can be baselined and followed. |
| Tasting room | Waterfall | The requirements for the tasting room are well understood and are not likely to change. Much of the planning can take place at the start, and the plans can be baselined and followed. |
| Renovated wine production facility | Waterfall | The requirements for the wine production facility are well understood and are not likely to change. Much of the planning can take place at the start, and the plans can be baselined and followed. |
| Renovated wine storage facility | Waterfall | The requirements for the wine storage facility are well understood and are not likely to change. Much of the planning can take place at the start, and the plans can be baselined and followed. |
| Winery management system | Agile | The management system can start with a list of prioritized features and requirements. Different aspects of the management system can be developed by different teams at the same time. The teams can use the same timeboxes and demonstrate working software at regular intervals. As the stakeholders see how the system is evolving, they can make modifications, change the priority, and add new features. There is the option to release increments of the software while continuing to add functionality. |
| Hired and trained staff | Iterative | Hiring and training staff can use an iterative approach because each of the main functions (winery, hotel, restaurant, etc.) will have their own requirements and their own timing for hiring and training. However, the deliverable won't be considered complete until all functions are staffed and trained. There may be opportunities to learn and adapt hiring and training processes along the way. |
| Wine club | Incremental | The wine club can use an incremental approach by starting with a minimal set of benefits for members and adding and adapting benefits based on feedback from members. |
| Grand opening event | Waterfall | The grand opening will need to be planned up front because some of the activities, such as entertainment, will need to be booked in advance. The requirements can be defined at the start, and while there may be minor adjustments, there shouldn't be significant changes. Additionally, the grand opening event has a hard end date; it is not expected to evolve. |
Life Cycle
Due to the hybrid nature of the project and the different development approaches, the project will have a start‐up and then three main branches each with applicable phases for the type of the work that will be done. Tony has developed a table (Table 5‐4) for Tessa that identifies the phase name, work, and completion criteria for each phase.
TABLE 5-4 Life Cycle Phases for Dionysus Winery
| Phase | Work | Completion Criteria |
|---|---|---|
| Start‐up |
|
|
| Contracting |
|
|
| Architecture/ engineering |
|
|
| Construction |
|
|
| Renovation |
|
|
| System development |
|
|
| Staffing and training |
|
|
| Wine club |
|
|
| Grand Opening |
|
|
After reviewing the table, Tessa asks to see a graphic depiction of how the phases will flow and interact. Tony shows her the information in Figure 5‐3.
FIGURE 5‐3 Dionysus Winery life cycle phases.
Subsidiary Plans
Tony and his team spent several hours discussing how best to manage the project. They evaluated the necessity for control for some deliverables, balanced with the need to be flexible with others. Ultimately, they determined that the project could best be served with the following subsidiary plans:
- Scope management plan;
- Schedule management plan;
- Cost management plan;
- Staffing plan;
- Training plan;
- Construction management plan;
- Safety plan;
- Logistics management plan;
- Communications management plan;
- Risk management plan;
- Procurement management plan;
- Stakeholder engagement plan;
- Change management plan;
- System testing plan;
- Grand opening plan.
Key Reviews
Tessa and Tony met to determine at which points in time Tessa and other members of the management team should review project progress and sign off for advancement. They decided that four reviews would be sufficient.
Integrated baseline review (IBR): The IBR will be used to ensure all the plans are complete, integrated, and incorporate sufficient risk responses. This will take place once the general contractor and key subcontractors are onboard. The review will include construction scope, schedule, and cost baselines along with an integrated risk register. When the IBR is complete, the project will advance into the architecture and engineering phase.
Construction readiness review (CRR): The CRR will give senior management an opportunity to review and approve all blueprints, along with any updates to schedule and cost estimates. Once the CRR is complete, the construction of the hotel, restaurant, and tasting room can begin, along with the renovations to the wine production and wine storage facilities.
System readiness review (SRR): The SRR will be used before taking the inventory, vineyard, wine club, and winery management system live. Because an Agile development approach will be used, stakeholders will see the features as they are developed. The SRR will allow stakeholders to see the entire system integrated and operating in a test environment.
Operational readiness review (ORR): The ORR will include a walkthrough of each venue, a dinner at the restaurant with wine (of course), and a presentation by the managers of each function (hotel, restaurant, winery, facilities, HR, etc.). This review will take place two weeks before the grand opening. This will assure management that all the systems are in place to welcome guests and transition the project to operations.
ROADMAP
The project management plan defines the life cycle that shows the general flow of work. It also identifies key reviews. The charter often has key milestones and lists deliverables. However, to get a high‐level view of all the summary information, you turn to a roadmap. In addition to the phases, reviews, milestones, and other key information, it often includes key deliverables, phase gates, and a timeline as well.
Figure 5‐4 shows a roadmap for the Dionysus Winery project.
FIGURE 5‐4 Dionysus Winery roadmap.
You can see how this roadmap allows the team, senior management, and other key stakeholders to get an overview of the project work and see when major events are planned. Roadmaps come with a legend to identify milestones, phase gates, key reviews, and deliverables.
SUMMARY
In this chapter we identified progressive elaboration and rolling wave planning as key tenets of planning. We described competing demands and how to balance the various project constraints.
We identified elements in the project management plan and described the need to tailor or customize subsidiary plans to meet the needs of the project. We described how the project deliverables influence the development approach, which in turn influences the life cycle phases. Then we covered project reviews. The elements of the project management plan were demonstrated with the Dionysus Winery project.
A project roadmap was introduced as a way of allowing key stakeholders to get an overview of the project work and major events. A roadmap for the Dionysus Winery was shown to demonstrate the usefulness of a roadmap.
Key Terms
- phase gate
- progressive elaboration
- project life cycle
- project management plan
- project roadmap
- rolling wave planning
- subsidiary plan