Chapter 1. Overview of the Adaptive Project Framework

It is a mistake to look too far ahead. Only one link of the chain of destiny can be handled at a time.

—Winston Churchill

There is no data on the future.

—Laurel Cutler, Vice Chairman, FCB/Leber Katz Partners¹

¹ Quotations at the heads of chapters are from Lewis D. Eigen and Jonathan P. Siegel, The Manager’s Book of Quotations (New York: AMACOM, 1991).

We have reached a crossroads in our journey to make a better world through our project-management efforts. Before we go any further, I want to ask you to stop and give some thought to how we should proceed on our journey. What I want to share with you is new, and is my conclusion after having been on this journey with you for the past 40 years. I’m not advocating the overthrow of the project-management world, but rather asking you to stop and think about what has been happening and how you have reacted to it. It’s time to pay attention to the signals coming from the changing business environment and learn how to adapt to the fast-paced, constantly changing, complex, and uncertain demands of today’s business world, and how best to manage the projects that support it. It’s time for the renaissance project manager. It’s time for a new project-management process model. The new model should not be a static one, but rather one that is very dynamic—one that must adapt to the changing project characteristics, environment, and culture within which the project is to be done, to the team and its external support staff, and finally, to the clients (who always seem to be changing their minds). And even these are likely to change from the time the project starts until the time it ends. Therefore, an effective project-management approach must be one that constantly assesses the total project environment and adapts to changing conditions and situations. The renaissance project manager is an outside-the-box thinker—one who instills creativity and courage into the development team and the client team.

The effective project manager I envision is more like a chef than a cook. A cook follows a recipe and is not trained to make exceptions to the recipe. As long as things progress according to the recipe, everything is fine with the cook. The chef, on the other hand, is trained to create recipes, and can adapt any recipe in order to meet a changing set of circumstances and a changing set of constraints. I assume you are already a cook. In this book, I will give you the tools you need to be a chef!

The Fundamentals of the Adaptive Project Framework

Let’s face it: The world will not stand still just because you are managing a project. So the challenge is to adopt and adapt an approach to managing your project that anticipates constant and unexpected change and can adjust with minimal disruption to the project, the team, the client, the enterprise, and the market.

Client or Customer?

Let’s first clear up some vocabulary. To me, a customer is someone to whom we are going to sell a product or service. A client, on the other hand, is someone with whom we are going to collaborate in order to solve a problem or take advantage of an untapped or new business opportunity. For an APF project, client is the correct term, and is the term that I am using throughout this book.

The APF Project Team

The APF project team is composed of a client team and a development team. For some APF projects, the client team may be a single individual with decision-making authority. For larger APF projects, the client team may have several members in order to cover the business processes or functions involved. Client-team membership may change over the life of the project. The client team should have a single member in charge with decision-making authority. This person will serve as co-manager for the entire project, along with the development-team leader. The development team comprises the technical professionals who are responsible for producing the deliverables. Development-team membership will most likely change over the life of the project, although there is usually a core development group that stays with the entire project. The development team will have a single individual in charge with decision-making authority. This person serves as co-manager of the project along with the client-team manager.

The two co-managers share equally in the success or failure of the project, and they both must have decision-making authority with respect to this project. Your APF project would be seriously handicapped if the client co-manager had to get approval from company management all through the project. This project-manager model is unique to APF and is a critical success factor for such projects. The most important characteristic of this management model is that both parties are equally vested and responsible for the project.

The APF project team is a very special team. Its members are mostly senior-level professionals who can work without supervision. The project they are undertaking is complex and filled with a great deal of uncertainty, so they must be creative people as well, if they are to find an acceptable solution. Creative people are generally very independent and may not make good team players. This will present challenges to the co-managers of the project. Along with creativity comes the need to be independent and unfettered by organizational constraints and rigid processes.

I’ll refer to the development team or client team when that specificity is required. When I use the term project team, I am referring to the single team formed by the client team and the development team.

First Look at APF

The project strategy you will explore in this groundbreaking book is what you already know I am calling the Adaptive Project Framework (APF). This is definitely not your father’s project management. It’s new. I don’t even use the word “management” to describe it. It is a framework within which effective management takes place. If I had to choose a term, I would prefer “leadership,” not “management.”

As you will discover, APF represents a shift in thinking about projects and how they should be run. For one thing, it eliminates all of the non-value-added work time that is wasted on planning and re-planning activities and tasks that are never performed. Why plan the future when you don’t know what it is? You certainly shouldn’t base your project plans on guesses about what that future might be. What a terrible waste of time and money that would be. Furthermore, the impact on project risk could be substantial. In APF, planning is done just-in-time. That sounds like an oxymoron, doesn’t it? The plan is based on only what we know or have learned about the solution since the last plan was built. So, APF planning is incremental.

APF demands a creative mind-set—one that thrives on change rather than one that avoids change. A characteristic of every APF project is that the complete solution is not known at the start of the project; it must be discovered and learned during project execution. The process of discovery will require a new set of tools not present in any other agile approach. This means the APF project management process must have within it the provision for learning and discovery. The resulting learning and discovery is turned into added functions and features in the solution. So the solution grows cumulatively until the project ends. This cumulative building of the solution is common to all agile approaches. In APF, the learning and discovery process is structured. In other agile approaches it happens by chance.

In an APF project, you start out with an incomplete definition of the solution. You may know a lot about the solution or very little. The less you know about the solution, the higher the risk of not finding a solution that has acceptable business value. One characteristic common to all APF projects is that the best solution will be found, within the given time and cost constraints, through the creative and collaborative energies and expertise of the client members of the project team and the development members of the project team.

Providing mechanisms for learning and discovery introduces something into your project-management process that does not exist in the traditional approaches—nor, as a matter of fact, in any other agile approach. In collaboration with your client, you have to experiment with possible additions to the solution that has been defined at that point in time. I call these initiatives probative swim lanes, and they are discussed in detail in Chapter 3: How to Plan an APF Cycle. The probative swim lanes create the learning and discovery. When a probative swim lane is successful in identifying another part of the solution, that part is integrated into the solution in a later cycle, in what I call an integrative swim lane. These two swim lanes define a unique relationship in APF not present in any other agile approach.

APF is obviously not a one-size-fits-all approach. Rather, it continuously adapts to changing business conditions and project status as it learns and discovers more of the solution through each cycle. APF is based on the principle that form follows function. APF adapts tools, templates, and processes from traditional linear and extreme approaches to fit the needs of the project at the precise moment in time when the need arises. APF is a framework based on the principle that you learn by doing, and one that guarantees, “If you build it, it is what they need and they will come.”

Unlike an xPM project, which seeks to get it right the last time (and so it should), an APF project seeks to get it right every time. Each cycle produces a working version of the solution as it is known at that moment in time. This is very similar to creating production prototypes. Whenever an APF project is terminated, there is always business value to deliver from the then-current solution.

APF is client focused and client driven, and is grounded in a set of immutable core values discussed later in this chapter. APF ensures maximum business value for the time and dollars expended. APF is efficient: It has squeezed out all of the non-value-added work that it possibly could have. APF is a framework that meaningfully and fully engages the client as the primary decision maker. APF creates a shared partnership with shared responsibility between requestor and provider. APF is a framework that works, 100 percent of the time. No exceptions!

Finally, APF projects are high-risk projects. That isn’t the result of the process; it is the nature of the project itself. These are projects whose successful completion is critical to the enterprise but whose solution has so far avoided discovery. Maybe that is because the problem is unsolvable, or maybe it is because no one has been able to successfully find a solution that waits to be discovered. If it can be discovered through effective project management, it will be discovered using APF.

Goal, Solution, Functions, and Features

As already stated, APF is designed for those projects whose goal is clearly stated and documented but whose solution is only partially known. Figure 1.1, a version of which also appeared in the Introduction, shows where APF is positioned in the project landscape. APF can be used on any project in the Agile Project Management (APM) quadrant (clear goal, unclear solution), and is an adaptive PMLC model.

Figure 1.1 The Project-management Landscape

Many situations fit this profile. These range from the simplest, where perhaps only minor parts of the solution are not known, to the most complex, where very little of the solution is known. Perhaps the solution is simply an algorithm for assisting with a decision. At the other extreme would be a solution that is almost entirely unknown because the problem is a first-time problem about which little is known, or is a recurring problem whose solution has so far been elusive. APF addresses the entire range of solution uncertainty. In some cases, APF can also be used when the goal is not clearly specified and an extreme approach is not available.

The extent to which the solution is known is expressed objectively in terms of the functions and features that define each requirement. These are the building blocks of the Requirements Breakdown Structure (RBS), which is discussed in detail in Chapter 2: How to Scope the APF Project. Requirements are the first-level decomposition of the goal in the RBS, functions are the second level, and features are the lowest level of decomposition, as shown in Figure 1.2.

Figure 1.2 The Requirements Breakdown Structure

You may have noticed the similarity between the RBS and the deliverables-based Work Breakdown Structure (WBS). Essentially, the RBS answers the question, “What are we going to deliver?” The WBS expands the RBS and answers the question, “How are we going to deliver it?” Therefore, the deliverables-based WBS includes the RBS as a subset. In other words, beginning with the RBS, you can continue its decomposition, and at the lowest level of decomposition create the deliverables-based form of the WBS. There are of course several other architectures that the WBS can follow. Refer to my book Effective Project Management: Traditional, Agile, Extreme² for details on WBS architectures and how to build a complete WBS.

² Wysocki, Robert, Ph.D. Effective Project Management: Traditional, Agile, Extreme, Fifth Edition (New York: John Wiley & Sons, 2009).

If the client team and the development team are certain that the solution is completely described by the RBS, then the traditional project management (TPM) category is the correct choice, and some traditional linear or incremental approach would probably be chosen. It is only when the RBS is not complete, or suspected to be incomplete or unstable in the sense that change is likely during the project, that it will be appropriate to use an APM approach such as APF. The missing parts of the RBS could be one or more features (which would result in a straightforward application of APF), or the missing parts could be one or more functions (which would result in a more-challenging application of APF).

Unfortunately, if the RBS is not complete, you and the client may not be aware of that. Most project-management pundits would agree that to generate a complete RBS at project initiation is not possible. If you align with that thinking, it would be wise to adopt some agile approach such as APF for all your projects. In the extreme, a requirement could even be identified during the course of the project. As long as the goal is clearly defined and documented, APF will be the approach of choice. It will no longer be necessary for the project manager to cobble together some hybrid version of a linear or incremental approach in the hopes that it will work. APF can even be used in cases where a TPM approach could have been used. We’ll discuss that situation later. What sets APF apart from every other project management approach is that APF is guaranteed to work—100% of the time. The fact that about 65 percent of all projects fail³ doesn’t even affect APF project managers, because they are using a failure-proof project-management approach!

³ Standish Group, Chaos Report 2007: The Laws of CHAOS (Boston: Standish Group International, 2007).

Traditional Project Management (TPM)

As we have already discussed, a TPM approach requires a complete and clearly defined RBS. The reason why TPM variations require complete requirements is so that the complete WBS can be generated and the complete project plan created. A complete WBS will identify all of the work that has to be done to meet specifications and scope.

There are reasons why one would want a complete plan. These include

• To be able to document exactly what will be delivered

• To estimate the human-resource requirements

• To develop the project budget

• To build a complete project work schedule so resources can be committed

It is nice and comforting to have such a list at the beginning of a project. However, that rarely occurs. What happens more often than not is that changes are requested, and if they are approved, then resource requirements may change, and the project plan may need to change as well. Do you begin to see all of the labor and time wasted putting together the original resource requirements and project plan? APF saves all of that wasted time!

Among the TPM approaches, there are two general models. All other TPM approaches are specific examples of one of them. These general models are defined below, with at least one specific example of each type given.

Linear Models

These models have a number of phases that operate in sequential order with no feedback loops. The interested reader can consult Chapters 3–9 in my book, Effective Software Project Management,⁴ for details. Figures 1.3 and 1.4 show two popular TPM models. Note that both models are linear—there are no feedback loops.

⁴ Wysocki 2009.

Figure 1.3 The Standard Waterfall Model

Figure 1.4 The Rapid Development Waterfall Model

Standard Waterfall Model

The Waterfall model has been around for more than 50 years, and is discussed in any good book on systems development life cycles. While it was originally meant for software-development projects, it has applications in non-software development as well.

Rapid Development Waterfall Model

The Rapid Development Waterfall model is more recent, and is frequently used to get products to market faster by grouping development into parallel and nearly independent “swim lanes.” Do not confuse the Rapid Development Waterfall model with Rapid Application Development (RAD). The two are very different. Grouping for effective and speedy development is challenging. It requires swim lanes that are as independent of one another as possible. The linearity of the process is maintained with these parallel swim lanes. Figure 1.4 depicts the parallel swim lanes. There are several things to consider in creating such a development schedule. The first is risk. Squeezing the work into a shorter timeframe increases the incidence of errors and staff scheduling conflicts. The amount of work has not decreased; it just must be completed in a shorter timeframe. Allocating the work to concurrent swim lanes shortens the project duration, but increases the risk to completing the project. Cramming more work into a shorter time box allows less time to recover from mistakes. Having parallel swim lanes in the project schedule raises the possibility of further aggravating any resource scheduling conflicts that were present in the initial schedule. The last parallel swim lane that is completed determines the completion date of the development project. It is clear that the risk in following a Rapid Development Waterfall model is greater than that of the Standard Waterfall model.

Incremental Models

Incremental models are really just a variant of Linear models, but deserve separate discussion. Just as the Linear models require clearly defined and documented goals and solutions, so do Incremental models. Whereas Linear models build and release deliverables all at one time, Incremental models build and release deliverables in stages over time. For marketing and early sales reasons, these models are often chosen. For example, to release a product in stages to test market acceptance and other variables, an Incremental model is often used. The downside of Incremental models is that the client is tempted to introduce scope-change requests between increments. That’s okay, but the original project timeframe will have to allow time for such scope-change requests to come forward from the client, be evaluated, and be acted upon. Management reserve is a time contingency added as a task to the end of the project schedule to accommodate the time needed to process and incorporate changes. This is an often-overlooked detail in Incremental models. Also, having downtime for the development team between increments creates a temptation for resource managers to temporarily reassign team members elsewhere. There is always the promise that they will return to the team when the next increment is ready to start, but that rarely happens. As a form of insurance to protect against the loss of a team member, hand-off documentation is usually prepared. That adds work not found in the Linear models.

Staged Delivery Waterfall Model

When considering using an Incremental PMLC model, you need to give some thought to the added risk. Figure 1.5 illustrates an example of a Staged Delivery Waterfall model.

Figure 1.5 Staged Delivery Waterfall Model

The Staged Delivery Waterfall model suffers the same risks as any other Incremental model. A constraint of the model is the content of each increment. The deliverables from Increment n must have all predecessor deliverables built in the previous n-1 increments. This is likely to compromise, or delay, increments having business value sufficient to warrant release to the end user or the market. At best, the process is cumulative; that is, not every increment will contain sufficient business value, but the last several increments since the last release might offer sufficient business value to be released.

For details, see Chapters 10–16 in my book Effective Software Project Management.⁵ Incremental models encourage scope change but should not be used to further identify missing parts of the solution or improve an existing solution. That is a job for APF.

⁵ Wysocki 2009.

Feature-Driven Development Model

The Feature-Driven Development (FDD) model (see Figure 1.6) is similar to the Staged Delivery Waterfall model except that “swim lanes” are defined around the technical dependencies among the functions and features assigned to each lane. Because FDD is technology focused, it does not necessarily deliver business value at each iteration. FDD first appeared in Java™ Modeling in Color with UML^® by Peter Coad, Eric Lefebvre, and Jeff DeLuca.⁶ A more-comprehensive treatment of FDD can be found in A Practical Guide to Feature-Driven Development by Stephen R. Palmer and John M. Felsing.⁷

⁶ Peter Coad, Eric Lefebvre, and Jeff DeLuca, Java™ Modeling in Color with UML^®: Enterprise Components and Process (Upper Saddle River, NJ: Prentice Hall, 1999).

⁷ Stephen R. Palmer and John M. Felsing, A Practical Guide to Feature-Driven Development (Upper Saddle River, NJ: Prentice Hall, 2000).

Figure 1.6 Feature-Driven Development Model

Note that the solution must be known in order to use FDD effectively. A model of the solution is developed and used to create the functional WBS. The functional WBS contains a very detailed list of features. The features list is grouped into similar features based on technical dependencies and prioritized for development. FDD iterates through the design and building of the groups of features.

Much like the Rapid Development Waterfall model, FDD prioritizes parts of the solution. But in FDD, the prioritization is based on feature dependencies. With the addition of feature code to the solution, the solution grows in terms of business value. Intermediate production solutions can be released as part of this approach. Just as in the Rapid Development model, there can be multiple design/build swim lanes running concurrently in the Feature Driven Development model.

FDD provides for the early release of chunks of features so that the customer can begin to realize business value without having to wait for the single release of the complete solution. There may be several cycles of development before the client is satisfied that the cumulative features list has enough business value to be released as with the Staged Delivery Waterfall model. FDD models may use concurrent swim lanes, sequential phases, or some combination of the two.

Agile Project Management (APM)

For TPM projects, change is the exception. For APM projects, change is the norm. This difference is significant, and results in completely different approaches to managing projects. While the TPM project will follow some form of Linear or Incremental PMLC model as discussed above, the APM project will employ some form of Iterative or Adaptive PMLC model, as discussed below. When the solution is not clearly and completely defined, you will have to approach the project as some type of agile project and use the appropriate Agile PMLC model.

Agile projects come in two flavors.

• Most of the solution is known. These are projects whose goals are clearly defined and documented and whose solutions are complete up to the point of specifying the final rendering of one or more features. These projects are what I would call minimalist agile projects. These projects should use an Iterative PMLC model, but could also use an Adaptive PMLC model as described and illustrated later in this chapter.

• Most of the solution is unknown. These are projects whose goals are clearly defined and documented but whose solution features and functions are not clearly defined and documented. In other words, much of the solution has not been identified. These projects are what I would call maximalist agile projects. These projects should use an Adaptive PMLC model as described and illustrated later in this chapter.

Evolutionary Development Waterfall and Rational Unified Process (RUP) are minimalist agile approaches as defined in this book. That is, they are more effective when much of the solution is known. Scrum and APF are maximalist approaches. That is, they are more effective when much of the solution is unknown. In practice, I have seen project managers force-fit maximalist adaptive projects into minimalist approaches. While they may have some success with that approach, it would be better to use a maximalist agile approach which is designed for such projects.

Iterative Models

Iterative models are minimalist agile approaches. The Iterative PMLC models are most effective where we still know all of the functions but some of the features are not known as definitively as the client would like. A good example of such models is the Evolutionary Development Waterfall model shown in Figure 1.7.

Figure 1.7 Evolutionary Development Waterfall Model

Evolutionary Development Waterfall Model

In this approach, the project begins much like a project following the Standard Waterfall model. The known parts of the solution are developed based on current requirements. Through the Evolutionary Development Waterfall model, iterations on the details of the solution will be undertaken. As the features and functions needed to deliver the requirements are developed, the requirements may well change, but few additions or deletions to the original requirements are expected. The WBS for the current version is created along with duration, cost, and resource requirements. This model closely resembles the production-prototype approach that has been quite popular for many years.

Unlike with the traditional models, it should be obvious that the meaningful involvement of the client is critical to the success of agile models. The client members of the project team, not the developers, are the subject-matter experts (SMEs) on the project. The client works with a version of the solution and provides feedback to the project team for further enhancements and changes to features and functions. This process continues as version after version is put into place, until at some point the client is satisfied that all requirements have been met. Also note that this model always presents the client with a production-ready version of the solution.

In the Evolutionary Development Waterfall model (see Figure 1.7), the learning and discovering experience is obvious. With each iteration, more and more of the depth of the solution is revealed. This follows from the client and developers having an opportunity to play with the then-solution. For simple and obvious enhancements this approach works just fine.

There is one variation worth mentioning here. There may be cases where iteration through solution designs might precede iteration through versions. While these tend to be the early efforts for an adaptive model, they can be used here with good effect. Iteration on design helps the client move up the learning curve of understanding the solution concept. Armed with that understanding, the client is better prepared to participate in iterations through versions. Design iteration is done quickly. If you have the right design tools, in my experience design iteration can be done in a matter of days, not weeks or months.

The discovery of additional features is a process that fully engages the client in meaningful exchanges with the developers. Both client and developers work with the prototypes—sometimes independently and sometimes in collaboration. Collaboration would be done to decide how to go forward with new or redefined features in the next and subsequent iterations. For details, see Chapters 17–23 in my book Effective Software Project Management.⁸

⁸ Wysocki 2009.

The Evolutionary Development Waterfall model works fine for those situations where only a small part of the solution has not been clearly defined. Choosing how to represent a feature in the solution would be an example of where a small part of the solution is not clear. The development team merely presents the client with renditions of the alternatives and asks for a decision as to which alternative is preferred, then implements it in the solution. But when the missing parts of the solution are more significant, as in determining how to make a particular decision, then a more-powerful approach is needed. This more-powerful approach would be some form of Adaptive PMLC model.

Rational Unified Process (RUP)

The Rational Unified Process (RUP) is a completely documented software engineering process for building a solution in an iterative fashion. One might argue that RUP belongs in the maximalist-approach category. I have chosen to put it here. There is an extensive library of books and Internet resources available. A good starting point would be Krutchen’s The Rational Unified Process: An Introduction, Third Edition.⁹

⁹ Philippe Krutchen, The Rational Unified Process: An Introduction, Third Edition, (Boston: Addison-Wesley, 2004).

RUP, illustrated in Figure 1.8, consists of four concepts: Inception, Elaboration, Construction, and Transition. For a visual representation of how these four concepts are related to Figure 1.8, refer to Krutchen, especially his Figure 2.2.

Figure 1.8 Rational Unified Process Model

RUP is probably the most well-known of the iterative software development processes. It adapts quite well to process approaches that range from documentation-heavy to documentation-light. The foundation of RUP lies in a library of reusable code, requirements, designs, and so forth. That library will have been built from previous project experiences. This means that RUP can have a long payback period. The library must be sufficiently populated in order to be useful from a return-on-investment perspective. Four to five completed projects may be enough to begin to produce some payback.

RUP ranges widely over the project landscape. When complexity and uncertainty are low but the solution is not fully defined, RUP is a heavy process. It requires considerable documentation, especially for code reuse.

Note that each iteration begins with a requirements-gathering session. The presumption is that the previous iteration will have clarified future directions for the project to take, to be fleshed out in the next requirements-gathering exercise. The direction a RUP project takes tends to be reactive to the requirements-gathering activity. APF, on the other hand, is a proactive model that seeks out missing solution parts through probative swim lanes. APF does not depend totally on discovery of the solution, which is passive, but also depends on proactive initiatives, which are activities designed to learn about the solution. It is this property that sets APF apart from all other Agile PMLC models.

RUP consists of four concepts which run concurrently through all iterations.

Inception

Through a series of requirements-gathering sessions in each iteration, an understanding of the scope of the development effort is agreed to and a cumulative solution as to how the scope will be developed can begin to be developed. Whatever parts of the solution have not been implemented are expected to be uncovered in the requirements-gathering sessions at the start of an iteration.

Elaboration

Whereas the Inception phase focuses on what is to be done, the Elaboration step focuses on how it will be done. This is a technical design activity, with the appropriate technical specifications and plans as deliverables. RUP is an architecture-centric process, so these technical specifications must integrate with the deliverables from all previous iterations. RUP is not a client-centric process as is APF. In the APF world, these first two RUP concepts are equivalent to the Version Scoping phase and the Cycle Planning phase, respectively.

Construction

This is the build phase of a RUP iteration. It is equivalent to the Cycle Build phase of an APF project.

Transition

The then-solution may be released into production if the client is satisfied that such a release has business value and can be supported by the organization. This is the same as the release decision in an APF project.

Adaptive Models

Whereas Iterative PMLC models work well in situations where only minor parts of the solution (typically features) have not been implemented in the solution, Adaptive PMLC models are most appropriate for situations where sizable parts of the solution have not yet been identified. In the most complex situations, incompleteness could even extend to requirements. APF is one example of an Adaptive PMLC model. There are several others. Some of the more familiar ones that are briefly discussed here are:

• Adaptive Software Development (ASD)

• SCRUM

• Dynamic Systems Development Method (DSDM)

These well-established models work well for what they were designed to do, but their limitation is that they were all designed for software-development projects. The following sections give a brief overview of each of these models. APF can be used for software-development projects as well, but it has a much wider range of applications. Even though it is a member of the APM category, APF was first designed for use on non-software development projects, which is the focus of this book. APF was initially defined for a process design project (see the Kamikazi Software Systems case study) and a product design project (see the Snacks Fifth Avenue case study).

Adaptive Software Development (ASD)

Adaptive Software Development (ASD) is fully described in a book by James A. Highsmith III, Adaptive Software Development: A Collaborative Approach to Managing Complex Systems.¹⁰ ASD has three phases: Speculate, Collaborate, and Learn. These three overlapping phases are shown in Figure 1.9.

¹⁰ James A. Highsmith III, Adaptive Software Development: A Collaborative Approach to Managing Complex Systems (New York: Dorsett House, 2000).

Figure 1.9 Adaptive Software Development Model

Speculate

The Speculate phase is nothing more than guessing at what the final goal and solution might look like. Its result may be correct, or it may 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.

Collaborate

The Speculate phase has been completed, and it is time to take stock of where the team and client are with respect to an ultimate solution. The client team and the development team must collaborate on their journey to discover the solution. What great “aha”s did the entire project team discover? What direction should the project take in the next and succeeding iterations?

Learn

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

The ASD Life Cycle Model

Figure 1.9 also shows the detailed phases of ASD.

Project Initiation

The objective of the Project Initiation phase is to clearly establish expectations among the sponsor, the client, the core project team, and any other stakeholders. This would be a good place to discuss, agree upon, and approve the Project Overview Statement (POS). For a project of some duration (more than six months), it might be a good idea to hold a kick-off meeting, which might last 2–3 days. During that time, requirements can be gathered and documented and the POS can be written. As part of project initiation, a brief statement of objectives for each iteration is prepared. These are expected to change as the solution detail develops, but at least the sponsor, client, and development team have a sense of direction for their efforts.

Adaptive Cycle Plan

Other deliverables from the kick-off meeting might include the project time-frame, the optimal number of cycles and the time box for each, and objective statements for the coming cycle. Every cycle begins with a plan for what will be done in the coming cycle. These plans are high-level. Functionality is assigned to sub-teams and the details are left to them to establish. This is as opposed to 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 sub-team is responsible for some part of the functionality planned for the present cycle.

Quality Review

This is the time for the client to review what has been completed to date and revise accordingly. New functionality may emerge; functionality is reprioritized for consideration in later cycles.

Final QA and Release

At some point, the client will declare the requirements met and there will be a final acceptance test procedure and release of the product.

Scrum

Scrum is a term taken from rugby. Scrum involves the team as a unit moving the ball down field in what would appear to be an ad-hoc or even chaotic manner. 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, continually offers the client demos of the current solution, and adapts its development plan at the end of each iteration. For a complete discussion of Scrum and software development, refer to Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.¹¹

¹¹ Ken Schwaber and Mike Beedle, Agile Software Development with Scrum (Upper Saddle River, NJ: Prentice Hall, 2001).

Of all the development models discussed in this book, Scrum is clearly a client-driven approach. It is the client who defines and prioritizes the functions and features which the team prioritizes into phases and builds a phase at a time. The process allows the client to change functions and features as more of the solution depth is uncovered through the previous iterations.

The Scrum process flow is shown in Figure 1.10.

Figure 1.10 The Scrum Process Flow

Idea Proposed

The original idea for the system may be vague. It may 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.

Product Owner Develops and Prioritizes a List of Functionality

The Product Owner is responsible for developing this list, which is called the product backlog. It will help team members understand more detail about the idea and help 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 development team. This is the opportunity for the team to ask questions to clarify each element of functionality. In this first part of the meeting, the team commits to the Product Owner the functionality it will deliver in the first 30-day sprint. The team then spends the remaining four hours developing a high-level plan for 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 functionalities that are not yet completed for the current sprint.

Sprint Backlog

This is the running list of tasks that must be completed to deliver the product backlog for this iteration.

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 ultimate solution, or the budget has been expended.

One of my clients reported an interesting application of Scrum. You be the judge, but keep an open mind. All of this client’s software-maintenance projects are allocated to a product maintenance backlog file and prioritized by the Product Maintenance Backlog Manager, who is also responsible for estimating the effort and resource requirements for each maintenance project. This is a project-management consultant assigned to their Project Management Office (PMO). Not all developers are assigned 100 percent to Scrum projects. There will be delays between their Scrum project assignments. During these delays, they are responsible for periodically checking the product-maintenance backlog and working on maintenance projects found there. The objective is to empty the backlog. Periodic reports of the backlog size and dates provide objective measures of attainment.

Dynamic Systems Development Method (DSDM)

Dynamic Systems Development Method (DSDM) is what the Standard Waterfall model would look like in a zero-gravity world. Feedback loops are the defining features that separate DSDM from the Standard Waterfall model. DSDM advocates would claim that a DSDM approach will deliver results more quickly, with higher quality and less cost than any TPM PMLC model. DSDM is an adaptive model. 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 for the project can be revisited. DSDM claims to be the only publicly available framework that covers the entire systems life cycle from end to end.

The list below contains the nine key principles of DSDM. Note that these principles are quite similar to those we have previously identified as good practices. Active user involvement is imperative.

1. DSDM teams must be empowered to make decisions.

2. The focus is on frequent delivery of products.

3. Fitness for business purpose is the essential criterion for acceptance of deliverables.

4. Iterative and incremental development is necessary to converge on an accurate business solution.

5. All changes during development are reversible.

6. Requirements are baselined at a high level.

7. Testing is integrated throughout the life cycle.

8. A collaborative and cooperative approach between all stakeholders is essential.

Most Agile PMLC models can subscribe to these principles. With minor variation, these principles are common to the APF PMLC model too, and will be further commented on in the context of APF in the next section.

Figure 1.11 highlights the DSDM method.

Figure 1.11 Dynamic Systems Development Method

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

Pre-project: Idea Generation

This phase includes some type of project overview, charter, or high-level business case designed to support the decision that the project should be undertaken. Once the decision to approve the project is made, the project is funded and the feasibility study can begin.

Feasibility Study

A decision must be made as to whether or not to use DSDM on this project. The typical feasibility study is done, but with the addition of the question of the appropriateness of DSDM. As part of answering that question, consideration is given to the support of DSDM that can be expected from the organization and the capabilities of the available project team members. The DSDM feasibility study is not an exhaustive treatise, but is quite high-level. Two weeks at most should be allocated to the Feasibility Study phase. Remember: You want only to decide whether or not to use DSDM.

Business Study

The client team in collaboration with the developer team will do a high-level investigation of the business processes affected by the project and identify information needs. The investigation is best conducted in a workshop environment with the appropriate SMEs involved. High-level process and data-flow diagrams are often produced. Requirements are documented. System architecture is defined, but with the proviso that it will probably change as the project progresses. Finally, a high-level plan is developed. It will identify expected prototyping (if any) during the Functional Model Iteration and Design & Build Iteration phases.

Functional Model Iteration

In this phase, the functional model and information requirements are refined through repeated cycles of the following tasks:

• Identify what you are going to do in this next cycle.

• Decide how you are going to do it.

• Do it.

• Check that you did it right.

Design & Build Iteration

These iterations will select prioritized requirements and design and build them. Production prototypes are commonly developed as well. A partial solution is delivered at each iteration, and the complete solution is a deliverable from this phase.

Implementation

This is the hand-off from development to production. All of the typical implementation activities take place in this phase. Those activities include installation, training, documentation, operations support, and user support.

Post-project

A post-implementation audit will follow after a suitable period of use has passed. Revisions and other system changes are accepted and built into the system through new releases.

DSDM in Non-IT Projects

While DSDM is clearly a systems-development framework, it can be applied to projects that have nothing to do with IT. That is our interest here. The Try & Buy Department Store case study will illustrate the application of DSDM to a training curriculum development project. Because the Information Systems Department was organized along 184 customer groups and each group had developed its own project-management approach along with the tools, templates, and processes to support it, curriculum development would be a challenge. The final curriculum had to support this environment, so a DSDM approach was chosen.

Case Study: Try & Buy Department Stores—DSDM Approach

The Feasibility Study included an assessment of the skills profile of all 2,000 project managers and a gap analysis to identify the skills-development needs. The Systems Architecture Definition provided the overall structure of the curriculum, the courses, and their formats. Existing courses were mapped into this structure. In order to get meaningful involvement in the development effort, the Functional Iteration was conducted entirely within a workshop setting. It required only a few iterations to define specific courses, course content, collateral materials, support services, and the development schedule. Four development teams were put in place for the Design and Build Iterations. Each team focused on a different project manager position class: team leader, project manager, senior project manager, and program manager. Every two weeks, a course prototype was produced by each team. Once the prototypes stabilized, all four teams were brought together to finalize the course prototypes. The build phase followed. The teams decided that a phased roll-out was the best implementation strategy. Later versions of the solution included establishing coaching and mentoring services and course revisions.

From this example, you can see that DSDM is a framework that can be adapted to a given situation.

Adaptive Project Framework

I’m sure I have tested your patience by putting you through the project landscape discussion, including the brief discussion of specific models, but it was necessary. You can now put APF in the context of project-management models and understand how it fills a void left by all other models. APF presents an entirely different way of managing mission-critical projects with poorly defined solutions than do other agile PMLC models. The major distinction is that APF is an active model for searching out solutions, whereas all other Agile PMLC models are basically passive. By that I mean that for them, solution discovery emerges rather than being designed into actual initiatives. To search out the missing parts of the solution, APF uses probative swim lanes that run concurrently with swim lanes that integrate discovered solution components. The probative swim lanes can be of several types. Probative swim lanes are unique to APF. These are discussed later in this section.

APF is still a work-in-progress. It was first introduced in 2001. It is an industrial-strength model designed for a maximalist adaptive project. It is a five-phase approach designed to deliver maximum business value to clients from every cycle within the limits of client-imposed time and cost constraints. In this section, I discuss some of the major differences between APF and other models. I want to plant some early ideas and concepts so that you will understand the relevance of later discussion. As I develop the concepts and practices of APF, I would ask that you keep an open mind. Don’t saddle yourself with old practices and worn-out tenets. APF can open a whole new world of possibilities for you.

APF’s Roots

APF had its beginnings in two consulting engagements that were running concurrently and by coincidence had much in common. The first engagement was with a retailer who wanted to install kiosks in its stores. The kiosks would offer the latest information on product specials, give store-location information for products, and provide other customer services. Snacks Fifth Avenue is the case study of that company’s use of the initial version of APF. The second engagement was with a software-development company that designed and built internet and intranet applications for its clients. Kamikazi Systems Development Company is the case study of that company’s use of the initial version of APF. Both of these case studies are included here, but the names and industries have been changed to protect the companies’ true identities.

Even though these two projects were quite different, they did have one characteristic in common. Both companies knew the final goal, but neither knew the solution in detail. The question for both projects was, “How do you proceed with managing such projects when neither a complete Requirements Breakdown Structure nor a complete Work Breakdown Structure could be established as the basis for the project plan?” Both organizations followed more-or-less the traditional linear approach to project management. Both could see that that approach wasn’t going to do the job. But what would do the job? Something different was needed.

That need was the impetus for the development of APF concurrent with the projects themselves. Both projects were completed successfully, and APF became a reality. Since then, APF has been used successfully in a number of different organizations. I am aware of its use in developing new financial products for a large insurance company, designing and building computer-based commercials and short-subject videos, conducting new-product research and development (R&D) for a consumer-products company, engaging in drug research, and other applications.

I still consider APF a work-in-process, and will expand and embellish it through my own consulting engagements as well as experiences shared by others. All of my learning and discovery about APF will eventually find its way into the literature. This book is the initial work. In a sense, the development of APF is an APF project!

APF represents several departures from more-traditional systems.

Scope Is Variable

The first departure of APF from the traditionalist’s mindset is that in an APF project scope is variable. This can be disturbing to many more traditionally thinking project managers and clients. APF maximizes business value by adjusting the scope of the solution as part of each completed cycle. It does this by making the client the central figure in deciding what constitutes maximum business value and putting the client in charge of deciding what changes should be made. At the completion of a cycle, the client has an opportunity to change the direction of the project based on the cumulative learning from all previous cycles. This means that an APF project’s course is constantly corrected to ensure the delivery of maximum business value. At the completion of the final cycle, when time or money or both have been used up, the deliverable will have the most business value that could have been produced from the collective wisdom and learning of the client team and the development team. A Scope Bank will have been established to house all ideas emanating from the previous cycles but not yet acted upon, so that at the completion of the APF project the Scope Bank may still contain additional features and functions that can be integrated into the solution as time, money, and resource availability permit. These unrealized features and functions serve as material for “version 2” of the solution. And so we see that change through learning and discovery is not only embraced, but is a critical success factor for all APF projects.

APF Just-in-time Planning

Because scope is variable, APF project planning takes on a whole new meaning. The basic concept underlying an APF project is not to plan the future. The future is unknown: Leave it that way. Part of the solution lives in the future and is waiting to be discovered. As it is discovered, it will be integrated into the solution. APF planning does not forecast the future and then plan for it. APF is not a passive model. It does try to discover the future through what I will call “probative initiatives” (but more on that later—see Chapter 3: How to Plan an APF Cycle). Trying to forecast the future is a waste of time, and merely increases the non-value-added work already present in the project.

Initial planning in APF is done at a high level and is functionally based. TPM planning is activity- and task-based. In APF, planning at the micro level is done within each cycle. It begins with a mid-level component- or function-based RBS, and ends with a micro-level activity- and task-based WBS. I like to think of it as just-in-time planning. A key phrase to keep in mind when applying APF is, “When in doubt, leave it out!”—meaning that you include within each cycle only the detailed planning of those activities that clearly will be part of the end result. That is, in each cycle, include in your detailed plan only what you know to be factual. Thus, planning is done in segments, where each cycle includes work that will require only a few weeks to complete. A cycle is so short that it typically will not meet the duration requirements to be called a project. Therefore, while a cycle will use many of the tools, templates, and processes of a more-traditional approach, it is a unique artifact of an APF project.

Change Is Expected

Unlike the Linear and Incremental PMLC models, where we treat scope as fixed and hope to avoid change, the Adaptive and Extreme PMLC models require change in order for the project to be successful. In these two model types, change is what leads to the discovery and learning of missing features and functions needed to fully define the solution (in Adaptive PMLC models), or clearer focus on the goal (in Extreme PMLC models). Two useful metrics to track from cycle to cycle are the number of additions to the Scope Bank at each cycle and the number of additions that result in further defining the solution at each cycle. These metrics are discussed later in this section.

Change in an APF project is encouraged through frequent release of products or processes in order to collect input for further change. Without that input, an APF project will fail. The meaningful involvement and collaboration of the client team is critical to that change process.

The APF Project Contract

This is perhaps the most difficult part of an APF project to justify to managers whose mindset is in the TPM world. Simply put, an APF contract says that with meaningful client involvement the project will deliver the most business value within the limits of client-specified time and cost constraints. Stated another way, clients don’t know exactly what will be delivered at the end of the project, only that it will offer the most business value possible and that they will have played a critical role in that determination. For the time and money invested, clients will get as much of a solution as they possibly can with the knowledge they and the development team have of the situation. What this all boils down to is the need for trust and openness between the client team and the development team as well as between the co-managers of the project.

Remember that in an APF project, you can’t wait until somebody figures out what the requirements are; that will never happen. You must proceed with the project based on the information you have. Your expectation is that the approach you have chosen will bring the missing functions and features into focus and the project can deliver acceptable business value.

An APF Project Is Mission Critical

It is unlikely that an APF project is anything but critical to the enterprise. The situation is this:

• No complete solution is known

• The risk of not finding a complete solution is high

• The success of the project is critical

• None of the familiar Linear and Incremental PMLC models will work

• APF is the only model that offers any hope of finding an acceptable solution

So while APF may not be the silver bullet you are hoping to find, it is your only alternative. An APF approach will deliver as much business value as possible. Through a collaborative effort between the client team and the development team, the best solution humanly possible will emerge. It may not be a perfect solution, but it will be the best that can be done. The expectation is that with actual experience using the solution, a second and succeeding versions can be justified.

The Roles of the Client and the Project Manager in an APF Project

It would be foolish to use an APF approach in the absence of meaningful client involvement. In fact, without meaningful client involvement, it would be risky to undertake any project, regardless of the model used. Every PMLC requires some level of client involvement. For an APF project, however, there is much more to say about the role of the client co-manager and the role of the development project co-manager. It is best to think of the two as sharing the responsibilities of the project manager—they become co-managers of the project, with distinct responsibilities.

The first difference between traditional project management and APF management is that traditional project managers have to quickly get used to the fact that they are no longer in charge of the project—at least not by themselves. They now share that responsibility with the client. There is no finger-pointing, except at themselves. Different, isn’t it? In an APF project, the manager of the development team assumes more of an advisory role. The manager keeps the client team pointed in feasible directions and advises the client on the best choice from among a number of feasible alternatives. The client, however, makes the final decision among the set of alternatives. For some traditional project managers, this role will be difficult to accept. Rather than being in charge, they are going to have to share responsibility for leadership and decision making. For some clients, too, this role will be difficult to accept. Rather than deferring to the project manager, they are going to have to be meaningfully involved and make decisions. Project success or failure is shared between the client-team manager and the development-team manager.

From the client side, the role is different than the project manager would be accustomed to. Client-side accountability is one of the strengths of APF. The client is the business SME. The developer is the technical SME. Both the development-team manager and the client-team manager have vested interests in the success of the project. What otherwise might have been an obstacle to implementation success fades into oblivion.

The second difference is that clients have to be willing to step forward and clearly and openly state their opinions. Their relationship with the project team must be open. They must feel like equals with the team. They can no longer hide behind the excuse that this is a technology project and they don’t understand technology. This is a business project, and they have as much say and as much authority as does anyone else on the project team. A great synergy can be created between two parties with totally different perspectives on the same project. Find a way to leverage that power to the advantage of your organization.

APF Is Not a Recipe to Be Blindly Followed

I am not in the recipe business. You won’t find endless lists of things to do in an APF project. That would be a waste of time and the APF user doesn’t waste time. As you read and study the pages that follow, expect to learn how you, the APF project co-managers, need to start thinking about what you are doing and how you are working together. If something either of you is doing doesn’t make sense, it probably should be changed or not done at all. As an APF project co-manager, you will know how to recognize these situations and invoke the proper change. For some traditional project managers, this continues to be a difficult adjustment. They would rather not have to think about what to do, but be able to merely follow a recipe. I want you to start thinking about creating a recipe from the ingredients you have at your disposal. That way you will be able to take charge of the project rather than being victimized by it.

If you need a recipe to manage your project, APF is not for you. The effective APF project co-manager is a senior-level manager who not only has command over an extensive collection of tools, templates, and processes, but more importantly, knows when to use them, how to use them, and how to adapt them. This type of co-manager is the chef I wrote about earlier!

Why Do We Need APF?

APF offers a unique approach to types of projects that other approaches and models do not. First of all, APF can be used for software-development projects, but it was designed for non-software development projects, and has been used successfully on process and product design and improvement projects and a variety of R&D projects as well. These are mission-critical projects whose solutions are not completely known ahead-of-time and can only become known through doing the project. These are projects for which TPM approaches will not work. They are projects that must be done, and some way of doing them effectively must be devised. You have no choice! That need gave rise to APF.

APF is not the only Agile Project Management methodology. I listed several others earlier. But APF is unique in that it was designed for any type of project, not just software development as all of the other agile methodologies were. Project co-managers, the Scope Bank, and probative swim lanes are three of the unique artifacts of an APF effort and set APF apart from all other Agile PMLC models.

Benefits of APF versus TPM Approaches

APF brings a lot of business value to the table as compared to other approaches.

APF Projects Always Finish Sooner than TPM Projects

If it were possible to do the same project twice—once using a TPM Linear model and once using APF—the APF project would finish sooner every time. This is a claim made by all APM approaches. The reason for this is obvious. Because APF squeezes out all non-value-added work, it produces less to do than those projects that follow more-traditional approaches. The time spent planning is a good example. Linear and Incremental models plan the entire project, and then when change comes along and is approved, the plan has to be redone from the point of the change to the end of the project. That situation is repeated several times throughout a project, making much of the original planning into non-value-added work. The more changes that are approved, the more non-value-added work there will be. APF has none of this excess baggage, and is therefore guaranteed to finish sooner than traditional approaches.

APF Projects Are Less Expensive than TPM Projects

Non-value-added work costs money. There is at least a labor cost for the time spent planning activities and tasks that are never done due to frequent scope changes. This wastes money in the end.

APF Projects Have a Better Business Termination Policy than TPM Projects

Most distressed or failing TPM projects are terminated too late, because by the time it is discovered that the project isn’t producing the desired results and should be terminated, the available budget and time are nearly expended. That happens because the first deliverables come very late in the project life cycle, after most of the money and time have already been spent. Not so with APF. APF delivers early and often. If anything is going awry, it will be discovered earlier than in a TPM project, giving the project co-managers information on which to decide to terminate the project before any additional time or money is spent needlessly. This doesn’t mean the project won’t be done. It means that the project won’t be done in the way it was originally planned: Some other approach using APF is needed, and the time and money saved by this early termination will be invested in the new direction.

The APF Project Produces Higher-quality Deliverables than the TPM Project

The elevated level of client involvement in an APF project means that the client will have a look at intermediate deliverables early in the project and have an opportunity to adjust them. The quality of the final product will therefore exceed that of a TPM project.

TPM projects all suffer from the effects of scope change. The initial design will be compromised due to the changes. The more frequent the changes, the more the design is compromised. The final TPM solution, if there even is one, will be a patchwork.

The APF Project Delivers Maximum Business Value for the Time and Cost Invested

The continual adjustment and redirection of an APF project means everything that is delivered is needed and is of the quality expected by the client. The client, in collaboration with you, decides what goes into the solution at every iteration. Poorer-than-expected deliverables will not survive the APF project life cycle. If an APF project is terminated, at least you will have a partial solution with some business value.

Core Values of APF

As you can see, APF is more than just a framework. It represents a way of thinking about clients and how best to serve them. The client is the center of attention in an APF project. The client controls the direction of the project and determines where business value can be created or increased. APF projects continue at the clients’ discretion and with their approval.

This way of thinking is embodied in the following six core values. These core values are immutable. They must be practiced in every APF project—no exceptions. In time, APF teams will be recognized for the visible practice of their core values. I have had occasion to work with teams that periodically reward team members for practicing the APF core values above and beyond the call of duty. The core values are that important.

1. Client-focused

While I was looking for the appropriate name for this core value, the phrase “walk in the shoes of the client” was always on my mind. It still is an operative part of truly being client-focused. This value 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 value can never be compromised, and APF teams must go beyond simply keeping it in mind: It must be obvious throughout your interactions with your fellow development-team members and all of the members of the client team.

A client-focused attitude will be a radical behavioral change to those few project managers who are clinging to old practices. I have some clients who provide templates for their clients to use to submit a description of what they want and of what business value it will offer. I’ve seen questions such as: “What other systems will the requested system impact?” How they expect the client to answer that question is beyond me. Others will make the process a little less painful by assisting the client with filling out the document. That approach is better, but not the best. It still assumes that clients can in fact state what they want (or to be more precise, what they need). Few clients will be able to do that because of the complexity and uncertainty that pervades today’s projects. The simple projects have all been done many times. Best would be to engage the client in discussions about their needs, and from that start, forge a strategy for going forward. That is the APF strategy we explore in this section and in the remaining chapters.

Don’t think that I am advocating passive acceptance of whatever the client might request. Such acceptance would border on dereliction of duty. “Client-focused” means going way beyond doing what clients ask of you. It also means protecting their best interests. In a spirit of openness, you are obligated to challenge ideas, wishes, and wants whenever you believe such challenges are called for. Your goal is to maximize business value to your clients, even if you have to push back on their requests. You have to own the solution just as much as the client has to own the solution. To do otherwise is not part of being client-focused. You want to do the right things for the right reasons, and to always act with honesty and integrity.

2. Client-driven

One of the guiding principles of my business has always been to engage my clients in every way that I can. I want them not only to be meaningfully involved, but also to have the sense that they are determining the direction the project is taking. At the extreme, this value would mean having the client take on the role and responsibilities of the project manager. I’ve been in such situations a few times in the last 20 years of practicing project management. Such an extreme will not happen very often, but there are occasions when it will occur. An effective arrangement I insist on with my clients is to have project co-managers—one from the client side and one from my organization. I have insisted on this for my entire career in project management. In this arrangement, both individuals share equally in the success or failure of the project. There is a clear and established co-ownership. My own practice with my clients tells me that this is a key to successful implementation. The client will have a vested interest in the success of the project and will do whatever is necessary to assure success. The client’s reputation and credibility are on the line, just as mine are on the line. This is critical for a successful APF project.

For many clients, early in the history of APF adoption by their organizations there is a learning curve that you will have to pay attention to. The first APF project you undertake with a client should be prefaced by a workshop to help the client not only understand what APF is and why APF is being used, but more importantly, how to be a good client in an APF project. For the second and later projects, you can expect more from this client. Eventually, you may even move the client to the position of project manager, with you acting as advisor, coach, and mentor. Being the product owner in a Scrum project would be the final step in the growth and development of the client as a contributing member of an agile project team.

3. Incremental Results Early and Often

In the spirit of prototyping, in an APF project you want to deliver a working solution to the client as early and often as possible. Early delivery is especially valuable when there is any question that the real needs of the client have not yet surfaced despite your best efforts. The functionality of the first cycles of the project may be very limited, but useful in any case. In some cases, the first iteration might be a proof of concept. (See Chapter 7: Adapting APF for more on this point.) It should deliver business value even though it is of very limited functionality. It gives the client an early feel for the final deliverables. Giving clients opportunities to work with something concrete is always better than asking them to react to some vague concept or sketch on the back of a napkin or buried in a lengthy functional specification.

Early-and-often delivery helps get clients meaningfully engaged, and keeps them engaged throughout the project. It creates an ownership on the part of the client. This is critical to the success of the project. Without the client’s meaningful participation, an APF project is doomed to failure. Clients must understand this, and you must facilitate it. If you can’t get that involvement, use some other approach; APF is not the way to go. See Chapter 9: APF Frequently Asked Questions for advice and guidance on getting and sustaining meaningful client involvement from the very beginning of a project.

4. Continuous Questioning and Introspection

This core value speaks to an openness and honesty that must exist between the client team and the development team. Both parties must be committed to making the best business decisions possible. That can happen only with honest and open dialog. Personalities have to be put aside if this environment is to be realized.

Building a solution iteratively affords the opportunity to be creative. It creates the opportunity to adjust as better and more valuable features or functions are discovered. As the cycle build proceeds, both the client team and the development team should be looking continually for improvements in the solution or the functionality and features being offered. Look back at previous cycles and ask whether what was done was the best that could have been done. All of this learning and discovery will be captured in the Scope Bank (see Chapter 4: How to Build the APF Cycle for a detailed discussion of the Scope Bank) and will come together in the Client Checkpoint phase. Here is where the client and your project team propose, discuss, and approve further solution-development efforts.

A true spirit of openness must exist. Neither party should be afraid to offer or challenge an idea or the real value of some present or future deliverable. I’ve frequently told teams that if any one of their members had an idea and didn’t share it with the rest of the team, I would consider that dereliction of duty. Some think that coveting knowledge is a source of power. In the APF project, that is the kiss of death! The same is true for the client. The successful practice of this core value is heavily dependent on the existence of a true team environment.

5. Change Is Progress to a Better Solution

Dave Crane, one of my colleagues, is often heard saying, “You’re always smarter tomorrow than you are today.” He is referring to improving task duration estimates over time, but his comment applies to APF as well. The Version Scope phase begins with the requestor and provider coming to a definition of what is needed and what will be delivered through the Conditions of Satisfaction (COS) experience. (See Chapter 2: How to Scope the APF Project for a detailed discussion of COS.) Despite their best efforts, all the two parties have done to this point is make the best guess they can as to what will be done. That guess may turn out to be a very good guess or only partially on target, but that is not important. What is important is that by working with the deliverables from the earlier cycles, both parties will get a better picture of what can still be delivered. They will be smarter as a result of their experiences with the deliverables from the earlier cycles. The result is to improve the solution going forward into future cycles.

While change is needed to reach the best solution, too much change sends a very different message. One of the metrics I advise my clients to use is the frequency of change requests over time. The expectation is that the interim solutions are converging on the ultimate solution. This is evidenced first by an increasing number of change requests from cycle to cycle, and then a decreasing number of change requests later in the project. If this is not happening, there is a likelihood that the project is not converging on an acceptable solution, but rather is diverging. See Chapter 5: How to Manage the Client Checkpoint for more on the topic of monitoring project progress.

6. Don’t Speculate on the Future

There will always be the temptation to envision some ideal state and convince oneself that achieving it is realistic. An APF team must resist that temptation. APF strips out all non-value-added work. Guessing only adds non-value-added work back in. When in doubt, leave it out. APF is designed to spend the client’s time and money on client-defined business value, not on non-value-added work.

If you find yourself building the RBS or the WBS and you are, or the client is, guessing at what should be included, you are probably using the wrong approach. The RBS is your best checkpoint against the choice of approach. If there is any guessing at all, you might want to think about APF as the better-fit approach.

Overview of the APF Life Cycle

The stage is now set for our first detailed look at APF. Figure 1.12 is a graphic portrayal of the five phases of APF. First, note that APF is an iterative process. You iterate within a cycle and between cycles. Every cycle presents the team and the client with a learning and discovery opportunity. APF is crafted to take advantage of these opportunities. As you continue to study each phase, you will come to realize that defining the cycle content for learning and discovery is its real strength. It sets APF apart from all the other APM models.

Figure 1.12 APF Life Cycle

Version Scope

As shown in the Version Scope portion of Figure 1.12, the Version Defining phase and the Version Planning phase both contain approval points, which I call StageGates. There are four StageGates in every APF Project:

• StageGate 1: Approval of the POS so that requirements can be gathered (part of the version-defining process)

• StageGate 2: Approval of the high-level project plan so that the project may begin (end of the version-planning process)

• StageGate 3: Cycle approved as having met the cycle-completion criteria (required at completion of every cycle)

• StageGate 4: Version approved as having met the version-completion criteria (end of the version)

Version Scope defines the boundaries of the project. I have chosen to use the term version to indicate that a subsequent project might take the solution to the next level of development. An APF project begins with a stated business problem or opportunity. This beginning is the same as for a TPM project. A request has been made to develop a solution to the stated problem or a way to take advantage of a stated business opportunity. At this point, you are not at all sure what kind of project this might be, or how you might approach it from a methodology perspective. A Conditions of Satisfaction conversation takes place between the requestor and the provider to define more clearly exactly what is needed and what will be done to meet that need. A requirements-gathering session may be held in which an RBS may be constructed. The RBS is input into the decision process regarding which project-management category the project belongs in: TPM, APM, xPM, or MPx. Once the category is chosen, the project characteristics are used to decide which model is a best fit. For the sake of this section, assume you have discovered or suspect that the RBS is not complete. There is no formula or survey to determine the degree of completeness. It is a feeling, a very subjective call on your part and that of the client. In any case, because of the suspected missing functions and features, an APM approach is chosen and you have decided upon APF, so a project-scoping document—specifically, a Project Overview Statement—is written. A POS basically summarizes the COS and RBS, if either is available. The POS is a brief document (usually one page, with perhaps an attachment) that contains the following five sections:

• A statement of the problem or opportunity (reason for doing the project)

• A goal statement (what will generally be done)

• A statement of the objectives (general statements of how it might be done)

• The quantifiable business outcomes (what business value will be obtained)

• General comments on risks, assumptions, and obstacles to success

For a more-detailed discussion of Project Overview Statements, see my book Effective Project Management: Traditional, Agile, Extreme.¹²

¹² Wysocki 2009.

The second deliverable from this phase is a prioritized list of the functionalities that have been requested and agreed to in the COS. The RBS contains this information. Both parties recognize that this list may change and is probably incomplete, but at this point in the project, the list reflects the best information available. There may be additions, deletions, and changes as the project commences.

The third deliverable from this phase is the mid-level Work Breakdown Structure. Since the RBS is incomplete, the WBS will also be incomplete. If an RBS exists, it may be used as the starting point for defining the WBS. The RBS will specify what is to be done, and the WBS will further decompose the RBS to define how it will be done. For present purposes, a mid-level WBS is one that shows the goal at level 0, major functions at level 1, and sub-functions at level 2. Generally, such a WBS would have a two- or three-level decomposition. The number of levels is not important. What is important is to have at least one level of decomposition to the work level for as many functions and features as have been identified. Any more WBS detail at this point is not considered useful. The reason for this will become clear in the Cycle Plan phase.

The traditionalist would have a problem with this approach, because the entire foundation of traditional project planning and scheduling is based on having a complete WBS. I contend that the time spent trying to create a complete WBS at this stage is largely wasted. Again, I remind you of the question, “Why plan for the future when you don’t know what it is?” In this case, the piece that is missing is that you are not exactly sure how you are going to deliver the functionality. You do know what functionality has to be delivered, and you are using that information to generate a mid-level WBS, but not a complete WBS. The complete WBS will eventually be generated when we know enough to generate it. That will happen with repeated iterations through the Cycle Plan, Cycle Build, and Client Checkpoint phases. You will generate the complete WBS when you need it and not before; and when you do generate it, you will know that it is correct and not a guess. Again, since the RBS focuses on what needs to be done while the WBS focuses on how it will be done, if the RBS is incomplete, the WBS must also be incomplete.

The fourth deliverable from this phase is a prioritization of the variables that define the Scope Triangle (time, cost, and resource availability determining the scale of the scope and quality). This prioritization will be used later as an aid to decision making and problem solving during the Cycle Build phase.

Cycle Plan

Once the POS has been written and is presented along with a prioritized list of known functionalities that the client and the project manager believe are needed to take advantage of the business opportunity or solve the business problem, some high-level planning is done very quickly to prioritize the functionality into a number of time-boxed cycles for development. Typical cycle length is two to six weeks. The cycle length is documented and agreed to by both parties—along with the expectation that it will change as project work commences.

The Cycle Plan phase will be repeated a number of times before the project is complete. The first Cycle Plan phase has as input the POS, the prioritized Scope Triangle, the functionality that will be built in this cycle, and the mid-level WBS. Each subsequent Cycle Plan phase will also have a Scope Bank as input.

So far, we have been discussing specific cycle contents that relate to adding detail to the evolving solution. There is another aspect of the cycle contents that is equally important. Think of a cycle as containing two major swim lanes. (In this book, a swim lane defines a stream of work whose activities are related to the development or exploration of a single function or feature. These are streams of build activities that occur in parallel.) One type of swim lane is devoted to adding more detail to the evolving solution. These are called integrative swim lanes. The other type of swim lane is devoted to discovering aspects of the solution heretofore unknown. These are what I call probative swim lanes. There may be several occurrences of each type of swim lane in a single Cycle Build phase. They might comprise the search for answers to questions like: “I wonder if this is the way to solve that part of the problem?” or, “I wonder whether this would work?”

In the probative swim lanes we call on the problem-solving and creative skills of the client team and development team. In the integrative swim lanes we call on the implementation and process skills of the client team and the development team. Different skill sets are needed for the two types of swim lane. The challenge is to build a team that has both sets of skills.

I don’t dismiss this as an easy exercise. It definitely isn’t. Most of the difficulty stems from either the client team or the development team not approaching reprioritization with an open mind. People tend to become wedded to their earlier ideas, and are hard-pressed to give them up in favor of others. To be successful with APF, both the development team and the client team must have open minds, and not display pride of authorship on any functionality that was discussed previously.

One of the greatest benefits deriving from this approach is the meaningful and continuous involvement of clients. They are the decision makers in all activities going forward. They participate with full knowledge of what has taken place to date and with the collaborative support of the development team. They understand how business value can be achieved via changes in functionality, and they are in a position to take action. Their presence will be a constant reminder to the development team of the business aspects and value of what they are doing, and what changes should be made to protect that business value. Client involvement is a very important point to remember. It ensures that what is eventually built will meet client needs.

Cycle Build

Contrary to what you might think, the creation of the Cycle Build plan is a low-tech operation. While you certainly could use project-management software tools, I have found that a whiteboard, sticky notes, and marking pens are just as effective. This approach does keep the maintenance effort for a project file down considerably, allowing the team to focus on value-added work. This advice may sound heretical to those of you who are project-management software aficionados, so let me explain. Cycle length generally falls within a two- to six-week frame. There will likely be several small teams (a typical small team being one or two developers), working in parallel but independently, each on a separate piece of functionality. Each of these small teams will plan the cycle build in this phase and then conduct the cycle build in the next phase. Based on this description, a minimal planning effort is all that makes sense.

The cycle-planning effort might go something like this:

1. Under the guidance and advice of the client team, identify those activities that define the features and functionality that will be built in this cycle.

2. Decompose the activities, extracted down to the task level.

3. Establish the dependencies among these tasks.

4. Partition the tasks into meaningful groups and assign a team to each group.

5. Each team develops a micro-level schedule with resource allocations for the completion of its tasks within the cycle time and budget constraints.

This planning focuses on parts of the solution that will be implemented (i.e., it comprises integrative swim lanes). For the probative swim lanes (See Chapter 2: How to Scope the APF Project), repeat the steps, focusing on establishing whether certain proposed features and functionality would enhance the current solution. If they would, then these will become part of a future cycle plan.

There is no critical path to calculate and manage. The longest-duration swim lane is the critical path. Pay attention to it! The cycle is so short that too much planning and analysis leads to paralysis and, worst of all, non-value-added work. Take the low-tech approach; it will work just fine here. You don’t need to clutter the cycle with non-value-added work. The entire effort can be whiteboard, sticky-note, and marker-pen based. A dedicated war room would be helpful (about 300 square feet of floor space should be adequate). Here the team can post plans, work schedules, Scope Bank, issues log, and so on, and have daily 15-minute updates, weekly status meetings with the client, and problem-solving sessions.

Detailed planning for producing the functionality assigned to this cycle is conducted. The cycle work begins and 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 reconsidered and reprioritized for later consideration. The cycle build time box is never changed once the Cycle Build phase begins.

The first activity in the Cycle Build phase is to finish the cycle build schedule and resource allocation. With everything in place and understood by the team, work begins. Every team member has a daily task list, and posts task status updates at the completion of each day. Any variances are caught early, and corrective-action plans are put in place. Nothing escapes the attention of the project co-managers for more than one working day. A Scope Bank is created to record all change requests and ideas for functional improvements. An issues log records all problems and tracks the status of their resolution.

Client Checkpoint

Without a doubt, this is the most important phase of APF, for in this phase the client team and the development team come together and assess what has been accomplished, what has been discovered and learned from the just-completed cycle, and what should be done in the cycle to come. The client team and the development team jointly perform a quality review of the features and functionality produced in the just-completed cycle. These are compared against the requirements and their part in the solution and the overall goal of maximizing business value. Adjustments are made to the high-level plan and next cycle work as appropriate. The sequence Cycle Plan→Cycle Build→Client Checkpoint is repeated until the time and cost budgets for this version have been expended, or the project is terminated because it is not converging on an acceptable solution, or an acceptable solution has been reached for this version and no further work is needed.

The Client Checkpoint phase is a critical review that takes place after every Cycle Build phase is completed. During the Cycle Build phase, both the client team and the development team will benefit from several discovery and learning episodes. Variations to the version functionality will surface; alternative approaches to delivering certain functionality will be suggested, and each team will learn through continuous involvement with the other team. A definite synergy will develop between the two teams. All of this must be considered, along with the functionality that had originally been assigned to the next cycle. The result is a revised prioritization of functionalities for the next cycle. The most important thing to remember is not to speculate on the future. For the next cycle, prioritize only functionality that you are certain will be in the end result. The newly prioritized list will be input into deciding on the integrative swim lanes for the coming cycle. The learning and discovery from the just-completed Cycle Build phase will be input into deciding on the probative swim lanes for the coming cycle, while the available resources and the resource requirements of the prioritized integrative and probative swim lanes will dictate the contents of the coming cycle.

Post-version Review

During the Version Scope phase, you developed measurable business outcomes in discussion with the client. These became the rationale for why the project was undertaken in the first place. Think of these outcomes as success criteria: That is, the undertaking can be considered a success if, and only if, these outcomes are achieved. In many cases, these outcomes cannot be measured until some time after the project has been completed. Take the case of a project impacting market share. It won’t happen next Tuesday. It may happen several quarters later, and this timeframe must be part of the success-criteria statement.

When the budget and time allotted to this version have been spent, that marks the end of the project. Some functionality that was planned to be completed may not have been. It will be archived in the Scope Bank for consideration in the next version. The main purposes of the Post-version Review are to check how you did with respect to the success criteria, to document what you learned that will be useful in the next version, and to begin thinking about functionality for the next version.

What the client team and the development team believe to be the best mix of functionality has been built into the solution. The project is done. The deliverables are installed, and the solution is in production. At this stage, three questions need to be answered:

1. Was the expected business outcome realized?

2. What was learned that can be used to improve the solution?

3. What was learned that can be used to improve the effectiveness of APF?

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 board. If it wasn’t, determine why not. Can something further be done to achieve the outcome? If so, that will be input into the functional specifications for the next version. If not, kill the project right now. No need to send good money after bad.

There is also a lesson here for everyone. If projects are limited in scope and they fail with no way to rescue them, you have limited the dollars lost to those failed projects. The downside 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 an approach will not work, kill the project and save the time and cost of the later cycles. TPM would find out a project wasn’t working only after all the money was spent, and then a great deal of trouble might be involved in killing the project. The traditional thought goes, “After all, there is so much money tied up in this project, we can’t just kill it. Let’s try to save it.” How costly, and unnecessary!

The APF Scope Triangle

The APF Scope Triangle is defined by five variables (time, cost, and resource availability forming the borders of the triangle, and scope and quality comprising its area). You may be familiar with the “Iron Triangle.” It is defined by scope, time, and cost, and is a more-primitive form of the APF Scope Triangle. Both models are valid. The five variables that define the APF Scope Triangle form an interdependent set and define the project as a system in balance at the beginning of the project. If one of these variables should change for any reason, at least one of the others must change in order to restore balance to the system. For example, if the client changes the project-completion deadline by reducing the time allowed, then at least one of the following must be done in order to restore balance to the system (the project):

• Increase the budget

• Increase the development-team size

• Reduce quality

• Reduce scope

Five Project Variables

The five variables that define the project (system) form an interdependent set that works together to keep the project moving forward in an orderly fashion. Figure 1.13 represents the APF Scope Triangle.

Figure 1.13 The APF Scope Triangle

Scope

Scope defines the depth and breadth of the deliverables the project is intended to produce. The functions and features that define these deliverables are not all known at the beginning of the project—the reason why you are using APF. Scope will therefore change as the project work commences, and this is not unexpected. The changes bring the project closer to an acceptable solution and therefore are for the good of the project.

Scope changes in an APF project would throw the project out of balance. A larger scope results in a larger area occupied by scope and quality. Since time and cost are fixed, those cannot be adjusted to restore balance. The project manager does not have control over resource availability; that is the responsibility of the resource managers. That leaves scope and quality as the factors that have to change to restore balance to the project. So an increase in scope due to the addition of new features or functions will result in deprioritizing less-important features or functions in the Scope Bank—at least for the time being. Remember that maximum business value is the goal of an APF project.

Quality

Scope and Quality are linked. Changes in quality are considered changes in scope.

Cost

Cost is a constraint established by the client. The investment clients make is a statement of what they are willing to pay for a solution to their problem. The development team treats cost as fixed for the duration of the project. For business reasons, the client may change it. For example, if the project is complete but more business value could still be added to the solution, the client may increase the monies available and extend the project. On the other hand, if the project is not converging on an acceptable solution, the client may reduce the dollars available, even to the point that the project must be terminated.

Time

Time is a parameter established by the client. The amount of time clients are willing to give the development team is a statement of how long they are willing to wait for the solution to their problem. The development team treats time as fixed for the duration of the project. For business reasons, the client may change it. For example, if the project continues to add business value but the timeframe for the project has run out, the client may extend the project for one or more cycles. On the other hand, if the project is not converging on an acceptable solution, the project may be terminated.

Resource Availability

Those of you who are Project Management Body of Knowledge (PMBOK) aficionados will recognize the above three variables as defining the so-called PMBOK Iron Triangle. PMBOK does not separate quality from scope, so the Iron Triangle is defined by cost, time, and scope. PMBOK would say: “Fix any two and the third is determined.” APF would say: “Fix time and cost and the size of scope is fixed, but not its content.” For years I have contended that there are really five variables, the fifth being resource availability. Time, cost, scope, and quality can all be in balance, just as they should be, but the project may still be unable to proceed. If resources are not available during the window of time in which the project work is to be done, the project goes nowhere. If resource availability changes for the worse due to competing priorities, the project is slowed or stopped unless at least one of the remaining four variables is adjusted so as to restore balance to the project (the system).

Using the APF Scope Triangle

Figure 1.13 depicts the project as a system in balance before any work begins. The three sides of the triangle are exactly long enough to form a triangle that exactly encloses the area taken by scope and quality. (Don’t try to draw this triangle. It is a conceptual model only.)

You would use this model as follows. Suppose competing priorities result in reduced resource availability. The resource availability side of the triangle is shortened; the three sides no longer enclose scope and quality. To restore the balance to the system, at least one of the remaining sides must be lengthened, or the area inside the triangle must be reduced in size.

Several other permutations are possible. Some examples:

• Due to market forces, the client is forced to change the deadline for project completion to an earlier date.

• The schedule slips.

• There is a budget cut.

• Team members are lost to the project.

• Due to market forces, the scope of the project is increased

In all of these cases, one or more factors must be changed to restore balance. In all of my training classes, I advise the attendees to burn this graphic into their brains. The APF Scope Triangle is an excellent model for understanding scope-change requests and problem-resolution strategies. It has guided my problem-resolution strategies for many years.

Prioritize Project Variables

Despite all efforts, the project work can still be compromised. The need to make adjusting decisions can arise rather unexpectedly. These decisions may impact the work of the project going forward. Rather than wait for the unexpected, I strongly suggest being proactive. In the case of APF, that means prioritizing among the five project variables. Think in terms of prioritizing the five variables, beginning the list with the variable you and the client are willing to concede first if the situation warrants.

An example will help.

Case Study: PDQ Prioritized Scope Triangle

Starting with a table that contains no X’s, the project team decides the priority order of the five elements. Table 1.1 reflects these decisions.

Table 1.1 PDQ Prioritized Elements of the Scope Triangle

So the prioritized list reads Cost, Resource Availability, Scope, Quality, and finally Time. No ties are allowed! That can be tough, because everything is important. If the client had to choose which variable to compromise, what would be the pecking order? The table entries reflect that thinking. In other words, the client would be willing to add more dollars to the project as the first choice for change. An extension of time would be the last resort.

How should we interpret this information with respect to project deliverables? Because of the deterioration in home-delivery sales, the solution must be put in place as soon as possible. For all intents and purposes, that makes the planned project completion date sacred. Sooner would be even better! All other variables would be relaxed before the Time variable would change. Next in priority order is Quality. Maintaining quality of product and service are critical success factors for this type of business. Next in priority order is Scope. What can be postponed until version 2? Next in priority order is Resource Availability. Most of the development team will be contractors, and their numbers can be increased or decreased as the situation dictates. Last is Cost. Dee is willing to invest more if the added business value justifies it.

Applications of APF

There are five distinct application areas for APF. The case studies provide examples of these. The five application areas are described in the following subsections.

Software Development

There is a lot of similarity between APF and the five Adaptive PMLC models discussed earlier in this chapter. All of the latter were designed for software-development projects. APF works well for software-development projects, with the added benefit that it was designed for projects that are not software-development projects. The APF probative swim lanes, which do not have an analog in any of the other five models, allow for the planned exploration and discovery of software solutions.

New Product Development

APF was originally developed for new product/process development projects. For these types of projects, early APF cycles are used for business validation, proof of concept, product design, model building, prototyping, and focus groups. Later cycles actually build and test market the product/process.

Process Design, Development, and Deployment

There is little difference between the variant of APF that is used for new-product development and that used for new-process design. In this example, process design was treated as an APF project. The development phase used an Evolutionary Waterfall model, and deployment uses a traditional linear model.

Process Improvement

Perhaps the most powerful use of APF is for process improvement. Process improvement draws heavily upon learning and discovery through experimentation within each cycle. Ideas for improvement are suggested, prioritized, tried in priority order, further developed, and eventually implemented if they result in measurable process improvement.

Problem Solving

Problem-solving and process-improvement processes have a lot in common in the early stages. Both identify, evaluate, and prioritize alternatives. Problem solving generally picks one alternative. Process improvement, as in the Kamikazi case study, consecutively picks alternatives and lets their results affect process performance cumulatively until some target process performance level is reached or no further improvement ideas have surfaced.

Extreme Project Management

The Extreme Project Management (xPM) model is best described as the R&D model. Neither the goal nor the solution is clearly defined and documented. The project heads out in a direction where the goal and some solution are thought to be found. They might or might not have successfully been identified. If they have not been, then further investigation is warranted. If they have been found, then a new direction is chosen. At some point in time, a goal and its solution are both defined. Obviously, extreme projects are very high risk.

For example, the rough stated goal of a project might originally have been to cure cancer. Through iteration, the scope of the final goal may have evolved to curing breast cancer in Asia using a ginseng-root compress. Figure 1.14 illustrates the INSPIRE process: INitiate, SPeculate, Innovate, and REview. I developed INSPIRE as the APF version for xPM projects. There is a lot of commonality between xPM and APF. One of my clients is in the drug research and development business, and has successfully applied APF to xPM projects.

Figure 1.14 INSPIRE

For details on INSPIRE, see Chapters 31–37 in my book, Effective Software Project Management.¹³

¹³ Wysocki 2009.

Emertxe Project Management

Emertxe projects are Extreme projects, only backwards: The solution is known but the goal is not! While this might look nonsensical at first blush, it really isn’t if interpreted properly. You need to think of time being reversed. Does the solution have any business value? In other words, does the solution support a goal that has business value?

My favorite example is from a project conducted by Wal-Mart to determine whether Radio Frequency Identification (RFID) technology (the solution) could deliver business value when applied to warehousing operations (the goal). Initially it was determined that the reliability and accuracy of the technology was below the minimum needed to meet Wal-Mart’s standards. Because Wal-Mart was and still is the 800-pound gorilla in the room, RFID got better, and is now used routinely in warehouse stocking and pulling operations.

The simplest example I can think of would be a project to evaluate a commercial software package for use in your company. Suppose a major vendor of human resource management systems (HRMS) announces a new version of its product that it claims can be used for career and professional development and project staffing (the solution). The APF project is to evaluate the software package for application in your soon-to-be-released resource constrained project portfolio management system (the goal).

The most complex example I can think of would be to research a juice extracted from a tree that grows only in Borneo and is suspected to have some medicinal value to the natives for whom it is a daily part of their diet. Unlike with the previous example, you aren’t sure how to start such a research project.

In between these three examples is a whole family of projects that are equivalent to a solution (or some variant of it) looking for an application (the goal)—hoping that the solution has business value. One of my clients uses APF for xPM projects and has also used APF for MPx projects. Both xPM and MPx projects consist of an initial goal and an initial solution converging on a final goal and ultimate solution. If the final goal has business value, the project is considered successful. Obviously these are very high-risk projects—not because of any shortcomings on the part of the project team but because the solution, if there is one, is elusive.

Putting It All Together

In this first chapter, I have set the stage for the rest of the book. The rationale behind APF has been briefly explored, and I have given you a high-level overview of what APF involves. This introduction could well meet the needs of the senior manager who simply wants to understand APF at a high level and has no need for the details. For those at the program- or project-manager level, you are off to a good start. With this understanding in place, I can now proceed to peel back the layers of the onion—the layers of APF. In Chapters 2 through 6, you will discover and come to understand the most granular of details for each of the five phases of APF. My intent is that you have a working knowledge of APF when you are finished. I also expect you to be able to create a recipe for success using APF, rather than just following a pre-defined TPM recipe and hoping for success.

Discussion Questions

The following questions are posed for your use. Use them to test your understanding and potential application of the materials presented in this chapter. If you are using this book for a course you are teaching, the questions will provoke good class discussion.

1. Under your leadership, your organization has spent considerable effort to adopt a traditional approach to project management. It has reached maturity level three—that is, there are fully documented project management processes and templates, and everyone is following them. PMBOK is the recognized standard. You have earned a good reputation among your management colleagues. You have noticed a number of projects where the client has requested and gotten approval for several changes throughout the project. These have cost significant money and time, the loss of market share, and the subsequent loss of revenues. As Director of the Project Support Office, you have come to realize that APF is the approach that should have been taken on this project. You are convinced that by using APF these types of projects could have been completed earlier, at less cost, and with much better end results. What strategy would you suggest to introduce and institutionalize APF in your company? What obstacles do you foresee?

2. You are a senior project manager in your company. You have 15 years’ experience with the company and a solid reputation for delivering successful projects. What might you, acting on your own, do to get your organization to appreciate the value of APF? What plan might you follow to bring APF into the company? What obstacles might prevent you from going forward with your plan? How do you feel about stepping outside the box?