Adaptive Project Management Life Cycle

The Adaptive models are more appropriate for projects involving higher levels of uncertainty and complexity than the Iterative models. In that sense, they fill a void between the Iterative and Extreme models. Adaptive models are more useful than Iterative models in those situations where very little is known about the solution. Keep in mind that solution discovery is still the focus of these models. Each iteration in the Adaptive models must address not only task completion for newly defined functions and features but also further solution definition through function and feature discovery. It is the discovery part of the Adaptive PMLC models that sets them apart from the Iterative PMLC models.

Definition

An Adaptive PMLC model consists of a number of phases that are repeated in cycles, with a feedback loop after each cycle is completed. Each cycle proceeds based on an incomplete and limited understanding of the solution. Each cycle learns from the preceding cycles and plans the next cycle in an attempt to converge on an acceptable solution. At the discretion of the client, a cycle may include the release of a partial solution.

Unlike the Iterative PMLC model where some depth of the solution is not known (features, for example), the Adaptive PMLC model is missing both depth and breadth of the solution. Figure 11-6 depicts the Adaptive PMLC model for projects that meet the conditions of an incomplete solution due to missing features and functions.

Figure 11-6: Adaptive PMLC model

With the exception of using the term “cycles” in place of “iterations,” the Process Group–level diagram for the Adaptive PMLC model is identical to the Iterative PMLC model. But the similarity ends there.

The four Adaptive models you will study here are Adaptive Software Development (ASD), Adaptive Project Framework (APF), Dynamic Systems Development Method (DSDM), and Scrum. All four are in popular use. Except for APF, the other models are used almost exclusively for software development. ASD, DSDM, and Scrum were built for that application. APF was built to be applicable to any type of project. For that reason, I offer a more in-depth discussion of APF. All four models thrive on learning, discovery, and change. In time, and with enough cycles, you hope that an acceptable solution will emerge.

In the Adaptive PMLC model, as with other Agile approaches, the degree to which the solution is known might vary over a wide range from knowing a lot but not all (projects that are a close fit for the Iterative PMLC models) to knowing very little (projects that are a close fit for the Adaptive PMLC models). The less that is known about the solution, the more risk, uncertainty, and complexity will be present. To remove the uncertainty associated with these projects, the solution has to be discovered. That will happen through a continuous change process from cycle to cycle. That change process is designed to create convergence to a complete solution. In the absence of that convergence, Adaptive projects are frequently cancelled and restarted in some other promising direction.

The success of Adaptive PMLC models is leveraged by expecting and accommodating frequent change. Change is the result of learning and discovery by the team and, most importantly, by the client. Because change will have a dramatic impact on the project, only a minimalist approach to planning is employed. Planning is actually done just in time and only for the next cycle. No effort is wasted on planning the future. The future is unknown, and any effort at planning that future will be viewed as non-value-added work. All Quadrant 2 approaches are designed to minimize non-value-added work.

Compared to the Iterative PMLC model, the Adaptive PMLC model requires more involvement with the client. As you will learn in the discussion of specific Adaptive PMLC models, clients have more of a directive role in the project than they do in the Linear, Incremental, and even Iterative PMLC models. Four Adaptive PMLC models are discussed later in this chapter in the order of increasing client involvement: ASD, APF, DSDM, and Scrum. Once you have decided that an Adaptive PMLC model is a best fit for your project, you can choose the specific model based on your expected involvement with the client. Without their meaningful involvement, the Adaptive PMLC model project has little chance of success. To be meaningful, the client must be fully involved in the decisions to go forward with the project and in what direction. I have had projects where the client was the primary decision maker, and I was there to keep the project pointed in the right direction. Some clients have the confidence and leadership skills to assume this role; others do not, and the more traditional role of the project manager is employed.

Scoping Phase of an Adaptive PMLC Model

The Scoping Phase of the Adaptive PMLC model is a high-level activity because not much is known about the solution. The missing functions and features have to be discovered and learned through repeated cycles much like the Iterative SDPM strategy. For the Adaptive PMLC model, the scoping activities merely set the boundaries and the high-level parameters that will be the foundation on which you proceed to learn and discover. As part of the Scoping Phase deliverables, you will document requirements, as you know them; functionality, as you know it; and features, if you know any. In addition, you will specify the number of cycles and cycle length for the first cycle. If you have enough insight into the solution, you might tentatively map out the cycle objectives at a high level. A partial high-level Work Breakdown Structure (WBS) can help complete this exercise.

Planning Phase of an Adaptive PMLC Model

At this point in the Adaptive PMLC model, planning is done for the coming cycle. High-level planning was done as part of the Scoping Phase. Based on the known functionality and features that will be built in the coming cycle, a detailed plan is developed. This plan utilizes all of the tools, templates, and processes that were defined for the Planning Process Group.

Remember that the typical cycle timebox is 2–4 weeks. So the tools, templates, and processes you use to plan a cycle don't have to be that sophisticated. An Agile project I recently managed was a $5M three-year project. I used sticky notes, marking pens, and whiteboards for every cycle plan. The project was completed ahead of schedule and under budget! I could have used a project management software package, but I have found that the overhead associated with their use was like killing mosquitoes with a sledge hammer.

Launching Phase of an Adaptive PMLC Model

The Launching Phase will be the same as discussed in the Iterative PMLC model. The launch activities will include establishing team operating rules, the decision-making process, conflict management, team meetings, and a problem-solving approach. The only difference will be defining the approach that will be used to establish subteams and their work plan to accommodate concurrent swim lane tasks.

Monitoring and Controlling Phase of an Adaptive PMLC Model

As you move from the Iterative PMLC model to the Adaptive PMLC model, there is a marked shift from formality to informality when it comes to this phase. That move to informality makes room for the marked increase in creativity that the team is called upon to deliver. Creativity and formality are not comfortable bedfellows. You need to give the team and the client the best opportunity you can to be successful and that means relaxing the need for status reporting and strict control of the schedule. The nature of these projects is that they are focused on delivering value rather than being focused on meeting time and cost criteria.

The monitoring and controlling functions pertain to the cycle build tasks. A cumulative history of project performance metrics should be maintained. These metrics should inform the project team about the rate at which convergence to an acceptable solution is occurring. Frequency of changes, severity of change, and similar metrics can help. As part of that control function, the team collects whatever learning and discovery took place and records it in the Scope Bank. All change requests go into the Scope Bank as well. No changes are implemented within a cycle. All changes and other learning and discovery are reviewed at the checkpoint. The review results in placing newly discovered functions and features into a priority list for consideration at the next or some future cycle.

One metric that I have found useful is to track the size of the Scope Bank over each cycle. Figure 11-7 shows three trends in Scope Bank size that I have seen in my client engagements.

Figure 11-7: Tracking Scope Bank size

Increasing at an Increasing Rate

This is the trend displayed in Figure 11-7(a). It indicates a client whose involvement has increased over time, and it indicates that the solution is diverging. Changes beget changes, and those changes beget even more changes. Although it is good to have increased client involvement, it comes too late. If you see a pattern like this, it's too late for any corrective action to be taken. Your intervention should have come much earlier so that you would have a chance to work with the client to increase their involvement earlier in the project. The solution would have been to put some trip wires in place as early warning signs that client involvement is below expectations.

Increasing at a Decreasing Rate

Figure 11-7(b) shows that the size of the Scope Bank is increasing at a decreasing rate. That may be a good sign in that the size of the Scope Bank may eventually turn to an actual decrease. That fact that it is still increasing is not good. Like panel (a), it might be indicative that the solution is diverging. I would wonder if it weren't too late.

Decreasing at an Increasing Rate

Figure 11-7(c) is the desired trend. It shows an exemplary level of client involvement and good solution convergence.

Closing Phase of an Adaptive PMLC Model

The Closing Phase produces the typical artifacts: lessons learned, validation of success criteria, and so forth. In addition to those, you might have items left in the Scope Bank that were not included in any cycle build. These are to be documented and held for the next version of the solution.

Characteristics

The characteristics of an effective Adaptive PMLC model are as follows:

• Iterative structure
• Just-in-time planning
• Critical mission projects
• Thrives on change through learning and discovery

Iterative Structure

An Adaptive PMLC model is structured around iterations that are designed to find and complete the solution. Each Adaptive PMLC model finds and defines that solution in a different way.

Just-in-Time Planning

For all of the Adaptive PMLC models, planning is confined to the next iteration. There is no speculation on what might be in the solution and then planning for it. That would turn out to be a potential waste of time.

Critical Mission Projects

Because of the complexity and uncertainty associated with an Adaptive project, these projects are high risk. With that high risk comes high business value. They are undertaken because their successful completion is critical to the enterprise.

Thrives on Change through Learning and Discovery

Learning and discovery sets Adaptive projects apart from Iterative projects. The learning and discovery can come about only with the client being heavily involved in the project. There is an increasing dependence on that involvement as you move across the Adaptive landscape from the ASD Adaptive PMLC model to the Scrum Adaptive PMLC model.

Strengths

The strengths of the Adaptive PMLC model are as follows:

• Does not waste time on non-value-added work
• Avoids all management issues processing scope change requests
• Does not waste time planning uncertainty
• Provides maximum business value within the given time and cost constraints

Does Not Waste Time on Non-Value-Added Work

One of the biggest wastes in the Linear and Incremental PMLC models is the creation of a complete project plan that will change several times before the project is complete. Table 10-1 in Chapter 10 gave a hypothetical example that showed how easy it was to waste 10 percent of the project time constantly repeating the rescheduling of tasks in the outer part of the schedule. The Adaptive PMLC models do not suffer from this waste. These PMLC models plan what is known to be in the solution, and they do that planning just in time. There is no wasted time. In fact, if a project could be done twice — once using a Linear PMLC model and once using an Adaptive PMLC model — the one using an Adaptive PMLC model would always finish sooner and deliver a better solution at less cost. No exceptions.

Avoids All Management Issues Processing Scope Change Requests

In the Adaptive PMLC models, there is no formal scope change management process. What otherwise would have been a scope change request in a Linear or an Incremental PMLC model is simply a note to the Scope Bank in the Adaptive PMLC models. That item is considered and prioritized along with other functionality and features yet to be integrated into the solution. Best of all, it does not take time away from the team's work. It is imbedded in the planning time spent between cycles.

Does Not Waste Time Planning Uncertainty

No one can know the future, so why waste time guessing what it might be and then planning for it? I have encountered many project managers who have a project that clearly fits an APM model, but they force-fit it to a TPM model. If that has been your practice in the past, stop it right now. You will save yourself many heartaches and project failures. Spend your time planning the certainty part of the project, and leave the uncertainty to the future (you will discover it in good time).

Provides Maximum Business Value within the Given Time and Cost Constraints

At the completion of each cycle, the entire project team will consider what is still missing from the solution and how it might be discovered and integrated. Those missing pieces should be prioritized based on business value and their discovery should be investigated. So, every cycle ends with a more complete solution than the previous cycle, and the new solution has maximum business value at that point in time. If the project should be cancelled for any reason, the client will walk away with the best that could have been done for the effort, time, and money expended. That is not the case with any project that uses a Linear PMLC model and most projects that use an Incremental PMLC model.

Weaknesses of the Adaptive PMLC Model

The weaknesses of the Adaptive PMLC model are as follows:

• Must have meaningful client involvement
• Cannot identify exactly what will be delivered at the end of the project

Must Have Meaningful Client Involvement

You know that the Iterative PMLC models benefit from client input. That is a passive type of input. You show the client something, they give it thumbs up or down, and you go on to the next iteration. In an Adaptive PMLC model, that involvement changes from passive to active. The entire project team collaborates on the current solution. The responsibility for suggesting the next version of the solution is shared equally among the client members and the developer members of the project team. Clients must be fully engaged and must accept responsibility for the project along with the development team. Client involvement increases across the Adaptive PMLC models in the following order: ASD, APF, DSDM, and Scrum. In the Scrum Adaptive PMLC model, there is no project manager. The development team is a self-organized team. If you are more comfortable having a named project manager, the closest in a Scrum project is the client. A client is called the Product Owner in a Scrum project. Each Scrum project has a Scrum Master assigned to the project. For now consider the Scrum Master as a project administrator and compliance officer. See the “Scrum” section later in the chapter for a more thorough discussion of the roles that are represented on the Scrum team.

Cannot Identify Exactly What Will Be Delivered at the End of the Project

The Linear and Incremental thinkers have a real problem with not knowing what will be delivered. In the early days of Agile projects, I vividly remember prospective clients saying, “You mean I am going to give you $500,000 and six months, and you can't tell me what I am going to get?”

“That's right,” I said, “but you are going to get the most business value that you and I can deliver for that money and time. You came to me with an unsolved problem that had to be solved, and we are going to do our best to solve it with the money and time you are willing to invest.”

Types of Adaptive PMLC Models

There are four Adaptive PMLC models that I would like to bring to your attention. There are others, but these four are more popularly used. Three are used primarily for software development: ASD, DSDM, and Scrum. The fourth is APF, which I developed for use on any type of agile or extreme project. I've ordered my presentation of the four based on the extent to which meaningful client involvement is needed. They all require meaningful client involvement, but I put ASD at the low end and Scrum at the high end.

Adaptive Software Development (ASD)

The first Adaptive model I want to take a look at is the ASD PMLC model. ASD is fully described in a book by James A. Highsmith III titled Adaptive Software Development: A Collaborative Approach to Managing Complex Systems (Dorsett House, 1999). The description in this section is a brief adaptation of his presentation.

ASD has three phases, as shown in Figure 11-8: Speculate, Collaborate, and Learn.

Speculate

The Speculate Phase is nothing more than a guess at what the final goal and solution might look like. It might be correct, or it might be far from the mark. It really doesn't make much difference in the final analysis because the self-correcting nature of ASD will eventually lead the team to the right solution. “Get it right the last time” is all that matters. All of the tools, templates, and processes of the Scoping Process Group are used as part of Project Initiation. A preliminary guess at the objectives of each cycle is recorded in this phase as well.

Collaborate

After the Speculate Phase has been completed, it is time to take stock of where the team and client are with respect to a final solution. What great discoveries did the team and the client make? All tools, templates, and processes of the Launching Process Group and the Monitoring and Controlling Process Group are typically used during Concurrent Component Engineering.

Learn

What was learned from the just completed phase, and how might that redirect the team for the next phase?

Figure 11-8: The three phases of ASD

You might have noticed in Figure 11-8 that each of these three phases encompasses different activities. The following list takes a brief tour inside each of these three phases and explains the activities that go on there.

• Project Initiation — The objective of the Project Initiation Phase is to clearly establish project expectations among the sponsor, the client, the project team, and any other project stakeholders. This would be a good place to discuss, agree upon, and approve the Project Overview Statement (POS). For a project of long duration (more than six months), it might be a good idea to hold a kick-off meeting, which might last two to three days. During that time, requirements can be gathered and documented and the POS written.
• Adaptive Cycle Plan — Other deliverables from the kick-off meeting might include the project timebox, the optimal number of cycles and the timebox for each, and objective statements for each cycle.

  Every cycle begins with a plan. These plans are high-level. Functionality is assigned to subteams, and the details are left to them to establish. This is at odds with TPM, which requires organized management oversight against a detailed plan. ASD is light when it comes to management processes.

• Concurrent Component Engineering — Several concurrent swim lanes are established for each functionality component. Each subteam is responsible for some part of the functionality.
• Quality Review — This is the time for the client to review what has been completed to date and revise accordingly. New functionality might emerge and is reprioritized for consideration in later cycles.
• Final QA and Release — At some point, the client declares the requirements met, and there is a final acceptance test procedure and release of the product.

Adaptive Project Framework

The Adaptive Project Framework (APF), which I developed in 2003-4, unlike most of the approaches in Quadrant 2, is not limited to software development. Although it is beyond the scope of this book to discuss this in detail, APF is equally at home with software development, process improvement, product development, and research and development projects. APF was first used on product design and process design projects. The interested reader can see my book on the topic, Adaptive Project Framework: Managing Complexity in the Face of Uncertainty (Addison-Wesley, 2010).

The fundamental concept underlying APF is that scope is variable, and within specified time and cost constraints, APF maximizes business value by adjusting scope at each iteration. It does this by making the client the central figure in deciding what constitutes that maximum business value. At each iteration, the client has an opportunity to change the direction of the project based on what was learned from previous iterations. This constant adjustment means that an APF project's course is constantly corrected to ensure the delivery of maximum business value in the eyes of the client. In other words, change is embraced, not avoided. Planning takes on a whole new meaning in APF. Initial APF planning is done at a high level and is component-based or function-based, as opposed to initial TPM planning, which is activity-based and task-based. APF planning at the micro level is done within iterations. It begins with a mid-level component-based or function-based WBS and ends with a micro-level activity-based and task-based WBS. I like to think of it as just-in-time planning. The underlying strategy to APF planning is not to speculate on the future — it's a waste of time. When in doubt, leave it out! At each iteration, plan for what you know to be factual. So, planning is done in chunks, where each chunk represents work that will only require a few weeks, and it will be completed in the next cycle. Like a production prototype, APF produces a partial but workable solution, so even if the project is terminated prematurely, business value is generated.

What Is the Adaptive Project Framework?

For businesses that have only recently realized the pain of not having a project management process in place and are struggling to adapt traditional practices advocated by the SEI and PMI to nontraditional projects, I say, “Stop wasting your time!” It's time to pay attention to the signals coming from the business environment and discover how projects can succeed in the fast-paced, constantly changing, and high-quality demands of the new business model. This is definitely not your father's project management. I don't even use the word management. APF represents a shift in thinking about projects and how they should be run. I like to think of APF as the infrastructure upon which you build and continuously revise the recipe for managing your project. Here are a few observations on APF:

• It is a new mind-set — one that thrives on change rather than one that avoids change.
• It is not a “one size fits all” approach — it continuously adapts to the unique character of the specific business situation as it learns more about that business situation.
• It utilizes a just-in-time planning approach.
• It adapts tools and processes from TPM and Extreme Project Management (xPM) to the special needs of APF.
• It is based on the principle that you learn by doing.
• It guarantees “if we build it, they will come.”
• It seeks to “get it right” every time.
• It's client-focused and client-driven.
• It is grounded in a set of immutable core values.
• It ensures maximum business value for the time and dollars expended.
• It is a framework that has squeezed out all of the non-value-added work that it possibly could.
• It meaningfully and fully engages the client as the primary decision maker.
• It creates a shared partnership with shared responsibility between requestor and provider.
• It is a framework that works — 100 percent of the time! No exceptions!

Do I have your attention? APF is new. APF is exciting. APF works. APF has been adopted as the de facto standard in several client companies. I urge you to step outside the comfort zone of Traditional Project Management and try APF. Be assured that I have not abandoned TPM. As discussed in Chapter 10, there are many projects for which TPM is a good fit. It has several tools and processes that make sense even with the type of project for which APF was designed. Many of those tools and processes have been incorporated into APF.

APF Core Values

You might have noticed that one of the characteristics of APF mentioned in the previous section is that APF is grounded in a set of immutable core values. This means that APF is more than just a framework — it represents an entirely new way of thinking about clients, how best to serve them, and how to add significant business value to the enterprise at the same time. Through its core values, APF establishes a collaborative environment within which the client and the development team can work effectively to create business value for the enterprise. This way of thinking is embodied in the following six core values:

• Client-focused — The phrases “walk in the shoes of the client” and “always do what is right for the client” express what it means to be client-focused. This is the most important of the core values. The needs of the client must always come first as long as they are within the bounds of ethical business practices. This can never be compromised. More than simply keeping it in mind, being client-focused must be obvious through your interactions with one another and with your clients. And this doesn't mean a passive acceptance of whatever the client might request. Client-focused also means that you have clients' best interests at heart, obligating you to challenge ideas, wishes, and wants whenever you believe challenge is called for. As a project manager, you need to do the right things for the right reasons and to always act with integrity.

  How you and your team relate to the client will be different depending on the client's understanding and comfort with the tools, templates, and processes you use. Some will be very comfortable based on your prior project experience with them. Others will need to be led along the way. You have to be ready to be adaptive. Always!

• Client-driven — Engage the client in every way that you can. You want them to have significant meaningful involvement, to have the sense that they are determining the direction that the project is taking. Remember, it's their money, and they have the right to choose how it will be spent. At the extreme, this would mean having the client take on the role and responsibilities of the project manager. This will not happen very often, but you should look for opportunities to make it happen. The more likely situation will have co-project managers — one from the client and you. In this effective arrangement, a clear and established co-ownership exists, and you both share equally in the success and failure of the project. Research tells me that this is a key to successful implementation. I maintain constant vigilance on keeping projects client-driven and have based my 20+ year consulting practice on this core value.
• Incremental results early and often — Deliver a working application to the client as early as possible, especially in cases where the real solution for the client has not yet surfaced despite all best efforts. The functionality of the first iteration of the application may be very limited, but it should deliver business value and give the client an early feel for what the final deliverables will be. Giving the client an opportunity to work with something concrete is always better than asking them to react to some vague concept described in a complex specification document. If you can put something in front of the client early in the project and repeat it often, they get a sense of belonging and ownership — they become engaged in the project. You should clearly sense the degree to which they are engaged very early in the project. That's an important part of your strategy to grow and sustain their meaningful involvement. In later iterations, you can lengthen the cycle and not risk losing the client's interest.
• Continuous questioning and introspection — When you build a solution iteratively, you have more chances for creativity and more opportunity to adjust as better and more valuable features or functions are discovered. The client and the project team should always be looking for improvements in the solution or the functionality offered both as the cycle build proceeds and as they look back at previous cycles. All of this learning and discovery comes together in the Client Checkpoint Phase, where the client and the project team propose, discuss, and approve changes in a spirit of openness. Neither party should be afraid to offer or challenge an idea or the real value of some present or future deliverable. Teams and clients should understand that if any one of them has an idea and doesn't share it, it's dereliction of their responsibility to the team.
• Change is progress to a better solution — One of my colleagues is often heard saying: “You're always smarter tomorrow than you are today.” He is referring to improving estimates over time, but his comment applies to APF as well. APF starts with the client and you agreeing on a definition of what is needed and what will be delivered. Your efforts will be good and in earnest, but remember that all you have done to this point is take the best guess you can as to what will be done. This guess might turn out to be very good, but that is not important. What is important is that working with the deliverables from the first cycle gives both parties a better picture of what should be delivered and, because of their experiences with early deliverables, makes them smarter as they move to uncover the solution going forward in the next cycle.
• Don't speculate on the future — Someone once said: “If you don't know the future, why waste time planning for it?” APF strips out all non-value-added work. Planning is done just in time. It focuses on what is known about the solution, not on what is not known. It discovers a new function or feature, and then plans how to build and integrate it into the solution. When in doubt, leave it out. APF is designed to spend the client's money on business value not on non-value-added work.

Figure 11-9 is a graphic portrayal of how the APF is structured. The next five short sections dig deeper into each of the five phases of APF shown in the figure: Version Scope, Cycle Plan, Cycle Build, Client Checkpoint, and Post-Version Review.

First note the basic structure of APF. There are four StageGates denoted by the decision diamonds at the right side of each phase. These are decision points that allow passage to the next phase. They are as follows:

• StageGate #1 — Approval to begin planning the project
• StageGate #2 — Approval to plan the first cycle
• StageGate #3 — Approval to conduct the client checkpoint
• StageGate #4 — Approval to close the project

Version Scope

The Version Scope (Figure 11-10) is the kick-off of an APF project. A rough idea of the needs is documented, and a high-level plan is constructed as to how the project will go forward. The Version Scope might be completed in a matter of hours, or it might take several days. It all depends on the level of complexity and uncertainty present in the project.

There are two major parts to Version Scope: a defining part and a planning part. The defining part can effectively be completed by two parties: a requestor and a provider. These may each be single individuals or small groups that represent the two parties. In either case, the critical factor is that they not only represent their constituency, but they speak for and can make decisions for their constituency. The planning part is not unlike the early stages of TPM planning. It should be attended by the stakeholders and core project team. The difference here is that the version plan is not a detailed plan. It does not provide a detailed definition of the work to be done or of a schedule to be followed. Those details are part of the cycle plan.

Figure 11-9: Adaptive Project Framework

There are eight deliverables from Version Scope, as listed here:

• Conditions of Satisfaction (COS)
• Project Overview Statement (POS)
• Requirements Breakdown Structure (RBS)
• Prioritized scope triangle
• Prioritized functions
• Mid-level Work Breakdown Structure (WBS) and dependencies
• Cycle timebox
• Number of cycles

Figure 11-10: Adaptive Project Framework (Version Scope)

The result of generating the COS or RBS is the input to the decision as to what PMLC model will be used: Linear, Incremental, Iterative, Adaptive, or Extreme TPM. For this example, I have already decided that Adaptive PMLC model is the choice, so the next step is to write the POS. The five components of the scope triangle along with the known functions are prioritized. The next deliverable from Version Scope is a prioritization of the variables that define the scope triangle (time, cost, resources, scope, and quality). This prioritization will be used later as an aid to decision making and problem solving during the Cycle Build Phase.

The next deliverable from Version Scope is a prioritized list of the functionality that has been requested and agreed to in the COS or the RBS. Both you and the client recognize that this list may change but at this point in the project the list reflects the best information available.

The next deliverable from Version Scope is the mid-level WBS. For planning purposes, a mid-level WBS is one that shows a one-level decomposition of each functional requirement. Generally such a WBS would have a two- or three-level decomposition. The number of levels is not important. What's important is that you have at least one level of decomposition for each functional requirement. At this point, any more WBS detail is not considered useful. The reason for that will become clear in the Cycle Plan Phase. The traditionalist would have a problem with this because the entire foundation of traditional project planning and scheduling is based on having a complete WBS. I contend that the time spent creating a complete WBS at this stage is largely a waste of time. Why plan for the future when you don't know what it is? In this case, the piece that is missing is you are not exactly sure how you are going to deliver the functionality. You do know what functionality has to be delivered and are using that firm information to generate the mid-level WBS, but not the complete WBS. The complete WBS will eventually be generated when you know enough to do so. That will happen as the result of several iterations of Cycle Plan Cycle Build Client Checkpoint. You will generate the WBS when you need it and not before, but when you do generate it, you will know that it is correct and not a guess.

The next deliverable from Version Scope is a prioritized list of the known functions and features of the current partial solution. Business value is the typical choice for the prioritization variable. This criterion would say that high business value has the highest priority and low business value has the lowest priority. Why is that? From a business perspective, this criterion makes perfect sense. Get the most business value into the solution ASAP and start to reap some of the benefits.

Finally, a preliminary decision on cycle timebox length and number of cycles gives some structure to the entire project.

You are probably wondering why you would want to do this or even what it means to prioritize the scope triangle. First, recall the scope triangle, originally introduced in Chapter 1 and shown again in Figure 11-11.

Figure 11-11: The scope triangle

Prioritization Approaches

Before I leave this topic, I need to discuss what the prioritization of the scope triangle looks like. There are three variations I have used extensively. They were introduced in Chapter 3 but are repeated here to reinforce their importance in APF decision making. They are briefly described in the following sections by way of examples.

Forced Ranking

The first approach is called Forced Ranking. This approach is best explained by way of an example. Suppose there are six functions and a panel of four managers to rank the functions. They can use any criteria they wish, and they do not have to describe the criteria they used. The results of their rankings are shown in Table 11-2.

Table 11-2: Example of a Forced Ranking

The individual rankings from each of the four managers for a specific function are added to produce the Rank Sum for each function. Low values for the Rank Sum are indicative of functions that have been given high priority by the managers. For example, Function 2 has the lowest Rank Sum, so it's the highest priority function. Ties are possible. Ties can be broken in a number of ways. I prefer to use the existing rankings to break ties. For example, taking the tied function with the lowest rank score and moving it to the next lowest forced rank breaks a tie.

Paired Comparison

Paired Comparisons are a bit more labor intensive. Table 11-3 shows an example of six functions that are to be ranked. To do that, each function will be compared to every other function. For example, say you are comparing Function 2 (designated by row 2) to Function 3 (designated by column 3). If you think Function 2 is more important than Function 3, place a 1 in row 2 column 3 and place a 0 in row 3 column 2. In this example, Function 3 was more important than Function 2. Add the scores across the columns to calculate the Sum for each Function. The highest Sum is the highest Ranked Function. So in this example, Function 4 has the highest rank, and Function 6 has the lowest rank.

Table 11-3: Paired Comparison

MoSCoW

The third prioritization is called MoSCoW. You may not be familiar with the acronym, but you are familiar with the rule. It's your “Must Haves,” “Should Haves,” and “Wouldn't It Be Nice to Haves” categories. It's your A, B, or C bucket. Here there are four buckets, where M stands for Must Haves, S stands for Should Haves, C stands for Could Haves, and W stands for Wouldn't It Be Nice to Haves. Every function is assigned to one and only one bucket. Be careful with this one because there is a temptation to make everything a “must have.” To prevent that from happening, you might put a rule in place that every bucket must have at least 20 percent of the functions in it. Adjust the percentage to suit your taste.

Scope Triangle Ranking Matrix

However you decide to prioritize the five variables in the scope triangle, you should represent them in matrix form as shown in Table 11-4. This ranking tells the team what the client is willing to sacrifice or do if a problem occurs. In the example in Table 11-4, the most critical variable for this project is time. There is something compelling the client to get the solution ASAP, so time is least likely to be a negotiating point for resolving a problem. Cost, on the other hand, is the variable most likely to be a negotiating point for the client. Their first point of departure from the current plan would be to increase the budget.

Table 11-4: Scope Triangle Ranking Matrix

Every project will have its own matrix. It is important that you collaborate with the client on what their rankings are for this project. Do this during the Version Scope Phase and revisit it during the Client Checkpoint Phase. Changes in the business climate could affect this matrix.

You have probably guessed by now that more than one version of the solution is expected. In this version, the solution is constrained to the maximum business value that can be delivered within the time and cost constraints. If the client is willing to spend more money and give you more time and feels that additional business value can be created, you will do a second version. However, that doesn't pertain to this version, so any future versions of the solution don't need to be considered at this point. Information will be gathered during this version that will inform management about any further enhancements they might want to consider in future versions. These are the normal releases you see in products, services, and systems.

Version Budget and Timebox

In APF, the budget and timebox are fixed by the client or senior management. Because of the volatility of an APF project, I would try to keep a version timebox to less than nine months, which is less than your fiscal year if funding decisions are of concern. Any longer and you invite many of the problems that plague the traditionalist. There are no rolling schedules. There is no going back to the well for another budget increase. One of the objectives in an APF project is to maximize business value under fixed time and cost constraints. Period! The business validation of your proposed project is based on those two constraints. This is a very different approach to the project than the traditionalist would take. As long as the client is satisfied that the maximum business value has been attained for the time and dollars expended, the project was successfully completed. If the client and the project team pay attention, this result can be achieved every time. No exceptions! Unfortunately the maximum business value they attained may not meet the success criteria, but that is an issue for the client to deal with and should not determine the success or failure of the APF approach. Whatever didn't get done in this version will have to be left for the next version or not be done at all. Hence, you have another reason for keeping the project scope to a feasible minimum and the timebox to less than nine months. That will reduce the need to extend schedules or obtain more dollars. It will also reduce the financial loss to the organization as compared to the traditional approach. With APF, you can kill a bad project much earlier than you can with the traditional approach, and that accounts for the dollar savings.

Write the Project Overview Statement

The negotiated COS agreement provides the input you need to generate the POS. You learned about both of these in Chapter 3. Recall that the POS is a short document (ideally one page) that concisely states what is to be done in the project, why it is to be done, and what business value it will provide to the enterprise when completed. It should be signed by the requestor and the provider.

Generate the RBS

If the project passes the first StageGate, you will be authorized to plan the project. Generating the RBS is the key to what kind of planning will be needed. If you are comfortable that the RBS is relatively complete and there will be few if any scope change requests, you can use all of the Planning Process Group tools, templates, and processes to build a complete project plan. If you are not sure or if frequent change is expected, you need to tailor the Planning Process Group tools, templates, and processes to accommodate your chosen PMLC model.

Generate the Mid-Level Work Breakdown Structure

The mid-level WBS identifies the functionality that is known and that will be built in this version. It does not show what tasks have to be done to build that functionality. To complete the WBS down to that level would be to define work that might never be done. In APF, you don't know enough about the future to spend the time creating the full WBS to that level of detail. Over the course of all of the cycles, you may end up generating the complete WBS, but you don't know that for sure. In APF, you will build the WBS detail when you need it. However, at this point, you simply decompose the WBS to a level where you can reasonably estimate the time and resources needed for each piece of functionality. These are not top-down estimates, nor are they bottom-up estimates. You simply need a reasonable guesstimate.

In some applications, my clients have used the mid-level WBS to temporarily assign functionality to cycles. Although this is a best guess at this point, it does give the client useful information on release strategies.

Determine the Number of Cycles and Cycle Timeboxes

This can be as simple or as complex as you care to make it. You don't need to make a lifetime project out of this step, so for a first pass I suggest that you think in terms of four-week cycles and simply compute how many of them you can fit into the version timebox. Later on, when you assign functionality to each cycle, you may want to adjust cycle length to accommodate the build process. If you want to be a little more sophisticated, take a look at the durations of the prioritized functionality and determine cycle length from that data. In this approach, you may vary cycle length so as to accommodate functionality durations of varying lengths. If you want to get even more sophisticated, take a look at dependencies between pieces of functionality and sequence the development effort across cycles with those dependencies in mind. There are a number of ways to proceed here, so it would be counterproductive to give you a formula.

I have found that cycle length is driven more by the client's need for delivering business value sufficient to release cycle deliverables to the end user for implementation. In any case, it will be a balance between meeting client needs consistent with technical needs.

Assign Known Functions to Cycles

Using the established priorities, simply map the functions into the cycles and then step back and ask the following questions about what you have just done:

1. Based on the dependencies between functions and the resources available, does this assignment make sense?
2. When we finish the first few cycles, will we have a working version of part of the final solution?
3. Can we improve on this assignment if we vary cycle length for the early cycles?
4. Does this assignment fully utilize our resources in the early cycles?

There is no substitute for common sense, and you always want to do what is right for the client. Don't plan the details out to the last cycle. You really have no idea what will take place in the next cycle, let alone the late cycles. Focus on the first few cycles and do what makes sense for them. You can worry about the later cycles in due time.

Write Objective Statements for Each Cycle

These objective statements are more for the benefit of the client. If possible, you should tell them what they can expect at each cycle. They need to know that these objectives are not cast in stone. There are so many variables that this list will surely change. The objectives have to make business sense, and that means you may need some further modification of the assignments to each cycle as a result of the client's reviews and comments on your plan so far. You also want to make sure that the client can do something productive with the deliverables from each cycle. Those deliverables are your key to further modifications of the version scope that will be discussed at the client checkpoint at the end of each cycle.

Cycle Plan

The Cycle Plan (Figure 11-12) will be repeated a number of times before this project finishes. Each Cycle Plan begins with a decision as to what items from the prioritized Scope Bank will be developed during the coming cycle. Many of the Planning Process Group tools, templates, and processes are used to develop the Cycle Plan.

Figure 11-12: Adaptive Project Framework (Cycle Plan)

Develop the Micro-Level WBS for the Cycle Contents

Extract from your mid-level WBS the functionality that will be worked on during the coming cycle. It is that part of the WBS that will become the basis of your Cycle Plan and which you will decompose down to the micro-level.

Micro-Managing an APF Project

Remember that every activity that you define in the micro-level WBS must be managed. That opens up the possibility of micro-management. You want to ensure that the final decomposition isn't at such a granular level that you are forcing yourself to be a micro-manager. You should understand at the outset that micro-management is the bane of an APF project. Best APF practices suggest that you manage an individual's work down to units of one week.

Consider this scenario. Harry is going to work on an activity that will require 10 hours of effort. The activity is scheduled to begin on Monday morning and be completed by Friday afternoon. Harry has agreed that he can accommodate the 10 hours within the week given his other commitments during that same week. Now, Harry's manager (or the project manager) could ask Harry to report exactly when during the week he will be working on this 10-hour activity and then hold him to that plan. What a waste of everyone's time that would be! Why not give Harry credit for enough intelligence to make his commitments at the one-week level? No need to drill down into the work week and burden Harry with a micro-plan and his manager with the burden of managing to that micro-plan. The net result of this micro-management may, in fact, be to increase the actual time to complete the activity because Harry has been burdened with the need to comply with the unnecessary management overhead brought upon him by his manager. The exemplary APF project manager will place more confidence in the team member knowing that the processes are in place to ensure plan attainment. Harry, being the good team player that he is, will report daily on status and let the project manager know if there are any issues or concerns regarding his meeting his commitments for delivery. It is more valuable to the project to have the APF project manager spend time encouraging that behavior from Harry than it is to waste the time micro-managing Harry. If it should happen that Harry doesn't deliver against the commitment, the project manager will certainly have a conversation with him about future assignments and how his progress will be monitored. As you can see, APF defines a structured framework that gives maximum latitude to the team members.

Once the micro-level WBS has been deemed complete and all activity durations have been estimated, print the unique name of each activity and its duration on a separate sticky note. For added efficiency, you might color-code the sticky notes. Each function gets a different color. You will see the value of this later in the phase. If you are still using project management software, enter the name of each activity and its duration into the package. Print the PERT diagram, which will produce a columnar display of the activities because no dependencies have been specified. You can then cut out each activity node and tape each one to a sticky note. You will then be at the same place in the planning exercise as the sticky-note folks.

The cycle planning effort might go something like this:

• Extract from the WBS the functions to be built in the coming cycle and any features or other decomposition you have for them.
• Complete the extracted WBS down to the task level using the WBS completion criteria from Chapter 5.
• Establish the dependencies among these tasks and build the dependency network diagram.
• Partition the tasks into independent meaningful groups and assign teams to each group.
• Each team will develop a plan and schedule for the completion of their tasks within the cycle timebox and budget constraints.

Note that this planning effort is low-tech. Software is optional. There is no critical path to calculate and manage. The traditionalist would have a problem with this. Their approach is based on managing the critical path. You could certainly calculate one here, but I believe that is overkill. The cycle is so short that too much planning and analysis leads to paralysis. You don't need to clutter the cycle with non-value-added work. The only tools you should need are whiteboards, sticky notes, and marker pens. The team war room should work fine. The team can post their plans, work schedules, issues lists, and so on, and have their daily 15-minute updates, weekly status meetings with the client, and problem-solving sessions here. APF, and the other Agile approaches, place more responsibility on people and less on process. I am much more comfortable giving people their assignment and letting them figure out the best way to accomplish it. If process is needed, they can make that decision. This is not reckless abandon, but because you have created a mid-level WBS, prioritized functionality, and built a Cycle Plan, this is a well-structured approach.

The Cycle Plan Phase works best as a team event, but I realize that some project managers might have taken just a few team members aside and built the Cycle Plan. For that reason, I have left the remaining details of the Cycle Plan for this phase. Building the Cycle Plan is definitely a team event. You completed the Cycle Plan Phase with a first pass at the cycle build schedule. You start the Cycle Plan Phase by completing the last details of the schedule. The variables that you have to factor into the schedule are the specific team members you will have and what their schedules look like. For a typical APF project, the team members are assigned full-time to the project. For that reason, the scheduling problems should be minimal.

Create the Micro-Level Schedule and Finalize Resource Assignments

To finish scheduling the cycle build activities, you need to factor in the specific availabilities of the team members as well as the dependencies that exist between tasks. To continue building the cycle schedule, first lay out the color-coded sticky notes on a scaled time line and be mindful of the dependencies between the tasks. You will need this in order to continue with scheduling and resource assignment.

Before you continue creating the low-level schedule, check to see if the initial schedule and resource assignments will allow the team to build the functionality assigned to this cycle within the cycle timebox. You can do this by inspecting the scaled time line you just created. If the current schedule doesn't fit within the cycle timebox, look for alternative resource assignments that will bring the schedule inside the cycle timebox. Look for resources that are not assigned for periods of time. They can either take over a task or help another resource complete a task earlier than currently scheduled. Adding a resource to the task assumes the work of the task can be partitioned to accommodate multiple resources. What you are doing is resource leveling in a way that makes more sense than the approach taken by most software tools.

At another spot on the whiteboard, prepare a grid that shows the time line on a daily basis across the columns and has one row allocated to each resource. Show all seven days on this grid. In a crunch situation, you may need to schedule work on the weekend. Next, superimpose the calendars of each resource on the grid. For any workdays or half-workdays that a resource will not be available for cycle build work, indicate this unavailability in the corresponding cell or half-cell. Half-day units are the smallest unit of time that you are going to build your plan around. Smaller units just create non-value-added work and begin to border on micro-management. After you have done this, you end up with your resource calendar for this cycle.

Once you have met the cycle timebox constraint, you are ready to move the information to the grid. For each resource, simply transfer the information to the grid that shows what task that resource is working on, what day they expect to start it, and what day they expect to end it. Take care that you don't violate any dependency relationships between tasks. Every morning you will have a team status meeting at which time you compare what was completed the previous day with what the grid had scheduled for that day. Any adjustments to the plan are made on the grid. Resources can be moved to meet schedule delays. You still have the sticky note network diagram on the whiteboard, so you will be able to see if schedule delays will cause any other delays downstream in the plan and adjust accordingly. Figure 11-13 gives an example of what these grids might look like.

Figure 11-13: A resource-loaded cycle schedule

The example is a two-week schedule for a cycle that has seven tasks. All of this information can be put on a whiteboard and changed as needs arise. It is simple, but it conveys all of the information that you need for a real project. It can be scaled upward for larger projects. The dependency diagram is scaled to the time line shown in the grid. This is a useful representation because it allows you to plan without the fear of violating any of the dependencies between sub-functions. The legend that I have used is fairly intuitive. The grayed out days or half-days are days when the resource is not available or days that are not workdays.

Let me point out a few important points about Figure 11-13. First, when scheduling a resource, try to keep that resource busy for consecutive days. This makes it easier if you need to replace an individual on the team. Second, notice when a resource is not busy. For example, Duffy is available for a half-day on Thursday of the first week. Even though this is early in the cycle, it may provide a resource that can help either Ernie or Fran or help the team recover from a slippage or a problem. Finally, note that in the second week, Duffy and Ernie are available to perhaps help Fran complete c2 when Fran is unavailable on Wednesday afternoon. If that can be scheduled, c3 may be able to be completed early. This means that the cycle would be completed ahead of schedule. Alternatively, that staffing adjustment might provide a way to make up for earlier slippages.

This grid should be permanently displayed in the team war room. It will be the focal point of daily team meetings. As status is being reported, the team can refer to this schedule and make any changes to the latter parts of the schedule. The most important benefit is that this is visible and accessible to the team. The only negative that you have to worry about is there is no backup for this approach. The fact that the team war room is reserved for the exclusive use of the team and is secure will mitigate most of the risk, but not all of it. I have made it a practice to have one of the team members, when he or she is not otherwise busy, update an electronic version of the war room or take a digital photo of the schedule and any other irreplaceable information. Because this is only for backup, it doesn't need to be saved in a high-powered software application. A word processor, spreadsheet package, or electronic whiteboard will do just fine. I have even used Visio on occasion.

The reason that this approach works is that the cycle length is short. The example cycle is only two weeks long, but even if it were three or four weeks long, the same approach will work. Even though I have used project management software packages extensively, I still find this low-tech approach to be far more intuitive than any software display. The entire team can see what's going on and can see how to resolve scheduling problems in a very intuitive manner. Most important of all is that the maintenance effort is negligible. Try it. This would never do well in TPM. For one thing, the network diagram would take up too much real estate and is generally not available from the software package. Not because it can't be generated. We all know that it can, but the labor to create it just doesn't justify it. Resource balancing is the other side of the coin. On the whiteboard, it is easy. In a software package, who knows what will happen when you try to level resources. I want to see the problem, and most software packages just don't measure up.

Write Work Packages

By inspection, you will be able to identify the critical tasks. The aficionados will want to use a software tool to locate the critical path. That's fine, but don't let the tool do the thinking for you. The cycle is so short that you could probably generate the critical path manually in less time than it takes to input the data, extract the pertinent data, and transfer it to your working format. Your choice. For every critical task in the cycle plan, it is a good insurance policy if the person responsible for the task develops a brief step-by-step description of what he or she plans on doing to complete the task within the allotted time. If you lose that person or have to reassign the task, the person who takes over can read the work package and hopefully can continue working on the task with minimal loss of time. You might also want to create work packages for high-risk tasks or tasks for which there is little experience among the team members. I have tended to write work packages for tasks that require a scarce resource. If I lose that resource, perhaps I can replace it with less-skilled resources and depend on the work package to help them over the tough spots.

Cycle Build

The functionality to be built in this cycle is input and a detailed plan put together for the cycle. It is usually a whiteboard, sticky note, marking pen type of plan. The Cycle Build ends when the timebox expires, not before and not after. Any tasks not complete are reconsidered and reprioritized in the next Cycle Plan. See Figure 11-14.

Detailed planning for producing the functionality assigned to this cycle is prepared. The cycle work begins, work is monitored throughout the cycle, and adjustments are made as necessary. The cycle ends when its time has expired. Any functionality not completed during this cycle is returned to the Scope Bank and reprioritized for consideration in a later cycle. No changes are allowed within a cycle. This is a real strength of APF. During a cycle, the team is focused on the planned deliverables. There are no distractions. All changes and ideas for adding functions or features to the solution are saved in the Scope Bank for consideration along with other functionality during the Client Checkpoint.

During the Cycle Build Phase, I recommend that you review how the team is working and how the APF Adaptive PMLC model is working. Real teamwork is a critical success factor in APF. There is a lot of worker empowerment threaded throughout APF. I think if you count the frequency of the use of the word “I” as compared to the use of the word “we,” you will have a pretty good metric for measuring team strength. The formula would be as follows:

Team Strength = number of We's/(number of I's plus number of We's)

Figure 11-14: Adaptive Project Framework (Cycle Build)

Ideally, this number should be hovering around 1. The APF team needs to work in an open and honest environment for this to happen. This means that every team member must be forthright in stating the actual status of their project work. To do otherwise would be to violate the trust that must exist between and among team members. The project manager must ensure that the working environment on the project is such that team members are not afraid to raise their hand, say they are having trouble, and ask for help. To do otherwise would be to let your teammates down.

Build Cycle Functionality

Work is now underway to build the functionality prioritized for this cycle. Even though the cycle is short and the build is not very complex, things will not go according to plan. About this time, the APFist is thankful that not a lot of time was spent planning and takes the unexpected in stride. Something unexpected is sure to happen. A person gets sick or leaves the company, a vendor is late in shipping, ships the wrong hardware, or goes out of business. These are the same kinds of risks that the traditionalist faces, but for them the results are far more catastrophic than they are for the APFist.

Monitor and Adjust the Cycle Build Schedule

The team will have team status meetings every morning — no exceptions. The meeting should not last more than 15 minutes. Everyone is standing, and everyone gives their status. If they are behind schedule, they should briefly state their get-well plan. Major issues are posted to the Issues Log and are taken offline by the affected persons so as not to waste the time of the entire team. Those who are ahead of the planned schedule become a resource for the others.

Ending the Cycle

A cycle may end for any of the following reasons:

• The timebox expires.
• All swim lanes complete early.
• A major problem occurs.

Timebox Expires

This cycle build ends when the timebox expires — not before, and not after. Any tasks not complete are returned to the Scope Bank for re-prioritization for consideration in a later cycle.

I hear task managers pleading: “If we only had two more days, we could complete our tasks.” You will be tempted, but you must resist giving in. While you are using an Adaptive model, some rules are inviolate. Other task managers will have finished their assigned work. Should they take a few days off while waiting for the delinquents to catch up? I don't think so.

All Swim Lanes Complete Early

No reason to let the clock run out here. Go to the Client Checkpoint and solve any scheduling problems that early cycle termination might have caused.

A Major Problem Occurs

These are showstopper problems. The competition has just introduced a product that surpasses what you are trying to develop. A business decision is needed: to go forward anyway or to abort the project and go back to the drawing board.

Depending on the severity, the APFist will either finish the current cycle or for the really major problems, he or she will terminate the current cycle and immediately move into the Client Checkpoint and plan for the next cycle. In rare cases, the project manager may jointly decide with the client to cancel the version and start all over, if at all. Note that the minimum amount of time and money was wasted in the APF approach as compared to the traditionalist approach.

Client Checkpoint

The Client Checkpoint (Figure 11-15) is really the heart of APF. It is here that the team and the client spend valuable time looking at what was done, reflecting on what was discovered and learned since the last checkpoint, and planning the Integrative and Probative Swim Lanes for the next cycle. As you will see, this introspection with the client and project team fully engaged is a very thorough process. If properly done, it is unlikely that anything significant will be missed.

Figure 11-15: Adaptive Project Framework (Client Checkpoint)

One of the greatest benefits from this approach is the meaningful and continuous involvement of the client. They are the decision maker in all going-forward activities, and they are doing it with full knowledge of what has taken place to date. They understand where business value can be achieved by changes in functionality, and they are in a position to take action. APF allows the client to engage in the project even to the level of operating as a co-project manager. They will be a constant reminder to the team of the business aspects and value of what they are doing and what changes should be made to protect that business value. This is a very important point to remember. It ensures that what is eventually built will meet client needs.

Because cycle length is so short and is so controlled, there is little that can go wrong that is not discovered quickly and easily corrected. Within the cycle itself, not even a day goes by that the team doesn't take stock of where it is compared to where it planned to be and adjusts accordingly. Because of the structure of APF, few dollars and little time will be wasted.

Following the completion of the previous cycle, there are several inputs to consider as the client and the team look forward to the next cycle. They are as follows:

• Functionality completed in the previous cycle
• Functionality planned but not completed in the previous cycle
• Functionality originally planned for this cycle
• Functionality planned for all the cycles beyond the next one
• All learning and discovery that took place in all previous cycles
• Any changes that took place in the business environment during the previous cycles
• The extent to which the current solution is converging on the final solution
• The current contents of the Scope Bank

The entire project team should spend whatever time they need in frank and honest conversation considering all of these factors and then agreeing on what will be done in the next cycle. Do not underestimate the value that can come from the sharing of learning and discovery. That will be your most important information as it helps both parties understand what this solution is really all about and what should be offered as a final solution. This is no trivial task.

The Updated Contents of the Scope Bank

The updated Scope Bank is the cumulative depository of all the ideas and proposed changes that were generated during the previous cycles. Some of these ideas and/or changes were incorporated in later cycles, and some were not. In any case, the current contents are all of the items not previously acted upon. There may be cases where any ideas learned or discovered in all previous cycles but not yet incorporated in the solution may now be viable.

Armed with the updated Scope Bank, the project team can now identify the contents of the next cycle. The following steps are suggested:

1. Review the COS and make any adjustments to solution requirements.
2. Prioritize the items in the Scope Bank.
3. Identify and prioritize Probative Swim Lane contents.
4. Identify and prioritize Integrative Swim Lane contents.
5. Select the items to be developed in the next cycle.
6. Determine the next cycle timebox.

During the cycle build, both the client and the project team would have benefited from several discovery and learning episodes. Variations to the version functionality would surface, alternative approaches to delivering certain functionality would have been suggested, and the client would have learned how best to proceed with the further definition of the solution. All of this is recorded in the Scope Bank and must be considered along with the functionality that had originally been assigned to the coming cycle. The result is a revised prioritization of the deliverables assigned to the coming cycle. The most important thing to remember is not to speculate on the future. I don't dismiss this planning task as being an easy exercise. It definitely isn't that.

• Integrative Swim Lanes — These swim lanes are designed to integrate additional functions and features into the current solution.
• Probative Swim Lanes — These swim lanes are designed to discover and learn about potential functions and features that might be integrated into the solution in a later cycle.

Consider for a moment the balance between Integrative Swim Lanes and Probative Swim Lanes in a single cycle. The decision to spend team members' time on Probative Swim Lanes instead of Integrative Swim Lanes isn't at all an obvious decision. It will be a subjective call in any case. You need to compare the marginal value of adding another Probative Swim Lane against that of adding another Integrative Swim Lane. This comparison will obviously be very subjective. To help make that decision, you might consider the relative sizes of the candidate lists for those two swim lanes. Remember that the Probative Swim Lanes are what feed the Integrative Swim Lanes. You need to maintain a healthy balance between the sizes of the two lists. If you know very little about the solution, the Probative Swim Lane list should be long relative to the Integrative Swim Lane list. This will occur in the early cycles of the project, and priority will be given to including Probative Swim Lanes over Integrative Swim Lanes in the next cycle. In later cycles, the Integrative Swim Lane list should grow larger than the Probative Swim Lane list. This is indicative of the project converging to the final solution. Priority will be given to the contents of the Integrative Swim Lane list. Figure 11-16 gives some examples.

Figure 11-16: Probative versus Integrative Swim Lane size over time

The size of the two lists is a simple concept, but there is a lot of information here and a lot of guidance for future cycle content.

Figure 11-16(a) can be interpreted in either of the following ways:

• The solution is nearly complete except for the remaining function and feature integrations.
• The solution is not nearing completion, and there are very few ideas forthcoming as to how to further define the missing parts of the solution.

Figure 11-16(b) paints a different picture and can be interpreted as follows:

• Both lists are decreasing and the solution may be very near completion, so few new Probative Swim lanes are needed.
• The solution is not nearing completion, and there are no new ideas forthcoming.

Figure 11-16(c) is the sign of a healthy project. The list of functions and features to be integrated is growing as is the list of ideas for future function and feature exploration. The Probative Swim Lanes are producing good results.

Figure 11-16(d) has the following two interpretations:

• The solution is nearing completion, but the missing parts continue to be elusive. The increasing number of ideas is not producing any meaningful additions to the solution.
• The project may be spinning out of control. Few ideas are producing any tangible results.

Post-Version Review

In the Version Scope Phase, you and the client developed measurable business outcomes that are the rationale on which the project was approved in the first place. These outcomes are, in essence, the success criteria defined in the POS in that the project is considered a success if, and only if, these outcomes are achieved. This is not at all how TPM measures project success. There is more than just meeting the triple constraints. Client satisfaction must be at the top of the list. All other constraints are of lesser importance. In many cases, these outcomes cannot be measured for some time after the project has been completed. Take the case of the project impacting market share. It won't happen next Tuesday. It may happen several quarters later, but the time frame is part of the success criteria statement as well.

Accordingly, the main focus of the Post-Version Review is to check how you did with respect to the success criteria; to document what you learned that will be useful in the next version, such as how well APF worked on this project and how well the team used APF; and to begin thinking about the functionality for the next version (see Figure 11-17).

The budget and/or time allotted to this version have been spent. Some functionality that was planned to be completed in the last cycle may not have been completed for this version. The Scope Bank is not empty.

In summary, the following three questions are yet to be answered:

• Was the expected business outcome realized?
• What was learned that can be used to improve the solution?
• What was learned that can be used to improve the effectiveness of APF?

Figure 11-17: Adaptive Project Framework (Post-Version Review)

Was the Expected Business Outcome Realized?

The business outcome was the factor used to validate the reason for doing the project in the first place. If it was achieved, chalk that one up on the success side of the ledger. If it wasn't, why not? Can something further be done to achieve that outcome? If so, that will be input to the functional specifications for the next version. If not, kill the project right now. No need to send good money after bad money. There is also a lesson here for all project managers. If projects are limited in scope and they fail and there is no way to rescue them, then you have reduced the dollars lost to failed projects. The alternative of undertaking larger projects is that you risk losing more money. If there is a way of finding out early that a project isn't going to deliver as promised, cut your losses. The same logic works from cycle to cycle. If you can learn early that a version will not work, kill the version and save the time and cost from the later cycles. The traditional approach would find out after all the money was spent and time used up and then have a great deal of trouble killing the project. After all, with so much money tied up in this project, the traditional approach would mean you would be reluctant to just kill it. You would want to try to save it. How pitiful and futile. TPM is structured so that it isn't until very late in the PMLC that you discover the project won't yield the expected results. Even if the project is killed at that point, most of the dollars will have already been spent, not to mention the time that was lost pursuing a losing cause.

Just as the traditionalist conducts a post-implementation audit at the end of the project, the APFist conducts a Post-Version Review at the end of the current version (Figure 11-17). There are a number of similarities, but there are also differences. The traditionalist is looking for final closure on the project while the APFist is looking for ways to further increase the business value of the solution. In other words, the APFist is never looking for final closure but is always looking for more business value. The version just completed is just another step toward increasing business value. In that sense, APF is quite like the production prototype in that it consists of a never-ending cycle of repeated solution improvements. The only ending that is ever encountered is to stabilize the solution as the best that can be achieved. At least for the foreseeable future, the solution will be the one used. In time, there may be reason to retire the solution altogether.

What Was Learned That Can Be Used to Improve the Solution?

You know that learning and discovery were very important parts of the Client Checkpoint Phase because it led the client and the team to adjust the cycle plans going forward. Similarly, in the Post-Version Review Phase, the client and the team consider all discovery and learning experiences with a view toward the next version's functionality (assuming that there will be a next version). This information is the major input to the Version Scope Phase for the next version. The analysis of this information will be the major part of the business validation of that next version.

What Was Learned That Can Be Used to Improve the Effectiveness of APF?

So far the lessons learned have focused on the solution (a.k.a. product) of the just-completed version. The other type of lessons learned focuses on the process that was followed to create the solution, answering such questions as “How well did APF work?” and “How well did the client and the team follow APF?” In answering these questions, the client and the team will offer suggestions for improvement of the process and the practice of the process. As you can see, APF has a built-in, continuous, quality-improvement process.

Adapting APF

As its name implies, APF is adaptive. You have seen that in several ways: specifying the number of cycles, determining cycle length, changing functionality priorities at each client checkpoint, and building in changes (add new, modify existing, or delete) in functionality at each client checkpoint. I have also shown how APF not only anticipates these adaptations but expects them. But APF is far more adaptable than just the situations I have enumerated. There are three adaptations that I want you to be aware of, and these are the topic of this short section.

You will probably find other reasons to adapt APF. Feel free to do that. APF is not a rigid structure to be followed without question. For me the bottom line has always been to do what is right for the client. It's all about organized common sense. If you are asked to do something that flies in the face of some established process or procedure, you need to take a serious look at the process or procedure. It may not be serving your needs.

Adaptation: Proof-of-Concept Cycle

There will be situations where the business case has not been sufficiently made to get approval to build the first version. Much like you have used prototyping to help with client definition of functionality, you can use the same concept by making the first cycle of APF a proof-of-concept cycle. That could entail the creation of a prototype, a feasibility study, the writing of use cases, storyboarding, or any other activity to demonstrate business value. It is very important that you not drag this activity out too long. Client interests and the interests of the approving manager will wane. You need to strike quickly while the iron is hot.

Adaptation: Revising the Version Plan

There will be situations where the initial Version Scope missed the mark. That will be evidenced by a significant number of discoveries and lessons learned coming in the first few cycles without much in the way of tangible results being produced. These can create a big disconnect between the original direction of the project and the corrected one that is now indicated. In other words, to continue on the course suggested by the current Version Scope is a waste of time and money. Remember that you built a mid-level WBS and are making your cycle plans around that WBS. Too many changes brought on by learning and discovery may render much of the WBS out of sync. The need to revise the version plan is clearly a subjective decision. I would err on the side of revision rather than sticking with a plan that may be heading in the wrong direction. The APFist is hard-pressed to do anything that may be a waste of the client's time or money. The APFist would conclude that the plan is off course and should be abandoned immediately. The correct action is to revise (or even replace) the current version plan and basically start over. At this early point in the project, do not be afraid to kill the plan. In almost every case I can think of, you will be making the correct decision.

Adaptation: Embedding APF in Other PMLC Models

APF can be embedded in other PMLC models. For example, suppose the solution is completely known except for one module. You can use a Linear PMLC model for the project except for that one module. That module will require using APF. Build the WBS treating that APF module as a task for the time being. Execute the Planning Process Group to develop a project schedule. From that schedule, you can determine the earliest start (ES) and latest finish (LF) timebox for the APF module. Within that module, execute the APF project to find the missing solution. I've had the occasion to use this approach with a few clients, and all I can say is that it works!

Implementing APF

There are two approaches to implementing APF: bottom-up or top-down.

Bottom-Up Approach to Implementing APF

Don't expect your management to enthusiastically embrace APF. You will most likely have to stick your neck out, take a chance, and prove that it has business value. Any strategy that I can envision will be a grassroots initiative. You will be putting yourself in harm's way! You will have to take the risk, so pick a demo project that you have great confidence you can bring in successfully. Make sure the team and the client are on board with you, too. If you can get a sponsor who has respect and clout in the organization, that will help considerably. It will be your only chance to convince senior management that APF has a place in your organization. If you fail, you can forget about APF for a while.

For some project managers, implementing APF will require a leap of faith. I often hear comments like: “You mean you don't know what solution you are going to deliver to the client until the project has ended?” Although that is partially true, the real payoff is that what is delivered is what the client decided they needed, and to the best of the client and the team's ability, what is delivered has maximum business value for the time and money expended. Furthermore, the client decided to be actively involved in the project from beginning to end. Is there some other way that could have happened other than through APF? I don't think so.

Top-Down Approach to Implementing APF

When the pain the organization is suffering from failed projects reaches some threshold and all previous corrective action plans have failed, senior management is ready to listen. Two recent clients came to me for this very reason. If this book had been published at that time, it would have given them a roadmap to understanding the contemporary project management landscape.

Value of APF to Organizations

The value is obvious: time is saved and costs are avoided. Additionally, the solution is the best that can be attained given the constraints.

Dynamic Systems Development Method (DSDM)

DSDM is what the Linear PMLC model would look like in a zero-gravity world. Feedback loops are the defining features that separate DSDM from the Linear PMLC model. DSDM is an Iterative model, but it can be used in situations where even less of the solution is specified than in other Adaptive PMLC models. The feedback loops help guide the client and the project team to a complete solution. The business case is included as a feedback loop so that even the fundamental basis and justification of the project can be revisited.

The following is a list of the nine key principles of DSDM as indicated in Jennifer Stapleton's DSDM: Dynamic Systems Development Method (Addison-Wesley, 1997):

1. Active client involvement is imperative.
2. DSDM teams must be empowered to make decisions.
3. The focus is on frequent delivery of products.
4. Fitness for business purpose is the essential criterion for acceptance of deliverables.
5. Iterative and incremental development is necessary to converge on an acceptable business solution.
6. All changes during development are reversible.
7. Requirements are baselined at a high level.
8. Testing is integrated throughout the life cycle.
9. A collaborative and cooperative approach between all stakeholders is essential.

Note that the characteristics in the list are quite similar to those I have previously identified as good practices.

Figure 11-18 is the Adaptive DSDM PMLC model.

The distinguishing feature of the DSDM is the incremental release and implementation of a production system at the end of each cycle. Note that repetition of the Design & Build and Functional Model iterations all follow an implementation phase. DSDM delivers business value to the client as part of its overall process design. Other approaches might do the same as a variation, but DSDM does it as part of the design of the approach itself.

Figure 11-19 shows that DSDM maps directly into the Adaptive PMLC model.

DSDM cycles can begin anywhere in the model. Even after implementation, the client may decide that the solution doesn't deliver the needed business value. Some other solution approach is needed, so another idea is entertained, starting with a feasibility study. Essentially the project is started over by following a different direction to seek out an acceptable solution. Repeating the feasibility study requires extensive client involvement.

Figure 11-18: Dynamic Systems Development Method

Figure 11-19: DSDM mapped into the Adaptive PMLC model

Scrum

Scrum is a term taken from rugby. A scrum involves the team as a unit moving the ball downfield in what would appear to be a chaotic fashion. Of all the Iterative approaches, Scrum would seem to define a chaotic development environment. The Scrum software development team is self-directed, operates in successive one-month iterations, holds daily team meetings, continuously offers the client demos of the current solution, and adapts its development plan at the end of each iteration. For a complete discussion on Scrum and software development, refer to Agile Software Development with Scrum by Ken Schwaber and Mike Beedle (Prentice Hall, 2001).

Of all the development models discussed in this book, Scrum is clearly the most client-driven approach. It is the client (called Product Owner in Scrum terminology) who defines the functions and features that the team prioritizes into phases and builds a phase at a time in 30-day cycles. In a Scrum project the Product Owner is the closest person on the team to being a project manager. The process allows the client to change functions and features as more of the solution depth is uncovered through the previous iterations. Depending on the working definition you are using for Scrum, it might be a strict application of the Iterative approach as defined herein or it might border on the Adaptive approach.

The Scrum process flow is shown in Figure 11-20, and the sections that follow explain the parts of the flow.

Idea Proposed

The original idea for the system might be vague. It might be expressed in the form of business terms. A function-level description can be developed as part of the Scoping Phase, but not to the depth of detail that the client requires. It is not likely to be expressed in system terms.

Developing and Prioritizing a List of Functionality

The Product Owner is responsible for developing this list, which is called the Product Backlog. It helps the team understand more detail about the idea and helps them form some ideas about how to approach the project.

Sprint Planning Meeting

This is an eight-hour meeting with two distinct four-hour parts. In the first part, the Product Owner presents the prioritized Product Backlog to the team. This is the opportunity for the team to ask questions to clarify each piece of functionality. In the second part, the team commits to the functionality it will try to deliver in the first Sprint. The team then spends the remaining four hours developing the high-level plan as to how it will accomplish the Sprint. The work to be done is captured in the Sprint Backlog. The Sprint Backlog is the current list of functionality that is not yet completed for the current Sprint.

Figure 11-20: Scrum

Demo Sprint Functionality

At the end of the Sprint, the team demos the solution to the client; functionality is added or changed; and the Product Backlog is updated and reprioritized for the next Sprint. This entire process continues until the Product Backlog is empty or the client is otherwise satisfied that the current Sprint version is the final solution.

Scrum has often been characterized as a methodology that does not require a project manager. In fact, the position of project manager does not exist, but the role does. It is subsumed primarily into a self-directed and self-organized team with some oversight responsibility resting on the shoulders of the Scrum Master. The Scrum Master simultaneously functions as coach, advisor, mentor, at times as an administrator, and finally as compliance monitor for the Scrum Team. Scrum has been characterized as organized chaos, and it does seem quite disorganized at first glance.

Figure 11-21 shows how Scrum maps directly into the Adaptive PMLC model.

Figure 11-21: Scrum mapping into the Adaptive PMLC model

Scrum is rapidly becoming popular among software developers. Developing software using Scrum fits the psyche of the senior developer. To the casual observer, it looks like chaos, but out of that chaos comes working systems. The developers are free to choose from the Sprint Backlog whatever chunk of the solution they would like to work on next in the cycle. Once a chunk of the solution is being worked on by one of the team members, it is removed from the Sprint Backlog. All team members agreed during the four-hour Sprint planning meeting to build all of the functionality that was allocated to the current Sprint. Senior developers are motivated by the challenge to do so. The Product Owner just has to stay out of their way. The Scrum developers are senior-level professionals and do not need supervision.

Scrum offers the professional an opportunity to be creative, which is one of its major strengths.

When to Use an Adaptive PMLC Model

Even if you are convinced that an Adaptive approach makes the most sense, you need to be confident in that decision. Here are three questions that might help you confirm your decision:

• Have you or a trusted colleague had successful Adaptive project experience with this client before?
• If this is the first Adaptive experience for this client, are you confident that they will be meaningfully involved throughout the entire project?
• Has the client appointed a qualified and respected co-project manager for this project?

Has the Client Had Successful Adaptive Project Experience Before?

If yes, get a debriefing from any of your colleagues who have had direct experience with that client on an Adaptive project. What are the strengths and weaknesses of the client? What works with them and what doesn't work? If it was experience with you, then go back and relive past projects with them in as much detail as you can recall. The project notebook (you did keep one, didn't you?) will be a great help in bringing back experiences long forgotten. There may be some clues in their behavior. You might learn about things to do and things not to do. You need to understand the client and how they behave in as much detail as you can possibly gather.

If no, then you need to prepare the client for their role and responsibility in the project. First, as co-project manager they share equally with you in the authority and responsibility over and for the project. This may be a strange role for them but it is a necessary role. You may have to sacrifice some old habits and ways of doing business. Relinquishing or sharing authority is a big step for you, but you have to do it if you expect to succeed.

Will This First-Time Adaptive Project Client Be Meaningfully Involved?

The first Adaptive experience for a client is a big step into the unknown for them. Perhaps for the first time in their careers, they will have a shared project responsibility, and that will be strange turf for them. You need to understand this and prepare them for it. I have built a model to do just that, which I share with you here.

Review the Six Questions from Chapter 2

Here they are again in case you have forgotten them:

• What business situation is being addressed?
• What do you need to do?
• What will you do?
• How will you do it?
• How will you know you did it?
• How well did you do?

I use these as the foundation for every client engagement. They are nonthreatening, they make sense, and every client can relate to them. Once upon a time, I did some pro bono work for my church. I volunteered to manage the annual church bazaar. That was a real learning experience for me. I was able to use my project management skills, but I did not use any technical terminology. Some of the team members had been doing the same thing for the bazaar for 20 years. Telling them they need to do it differently doesn't work. (Try volunteering sometime if you really want to test your abilities!)

Provide a Brief Overview of the Adaptive PMLC Model

If you have chosen a specific model already, share it and the reasons you have chosen it for this project. How will the client be better off from the project team having used it? Take a clue from the preceding subsection and don't use any project management jargon unless you know your client will be comfortable with it.

Continuously Review the Model during the Project

Repetition is a good teacher. Don't assume the client will remember and understand what you said way back at the beginning of the project. Lead them through the use of each tool, template, and process on a just-in-time basis. Examples taken from other projects in your organization may also be helpful.

Has the Client Appointed a Qualified Co-Project Manager?

Despite all you have done to plan and orient the client team, the wrong choice of a co-project manager can kill the project. The person must be respected in their business unit so that people will believe and listen to him or her. Don't depend on the manager of that business unit to make the right choice. Brief the unit manager on your needs and the importance of making a correct decision on the position. If possible, review candidates with the unit manager and jointly arrive at a decision.