Chapter 10. Taking Stock
At this writing, APF is less than 10 years old. Its development has been an exciting and challenging journey. The journey continues. The learning and discovery continue. I’m encouraged by the feedback I’ve received, by my own experiences using APF, and by my clients that have added APF to their Project Management Life Cycle model portfolio. Their testimonials lead me to the conclusion that I am on the right track.
APF is a work-in-process. Designing and building the APF PMLC model is itself an APF project. APF is new. APF is exciting. APF does not waste your time or your money. APF is the approach that will address many of your concerns about project failure, cost overruns, missed schedules, and other events that are impairing the successful conduct of your business activities.
My colleagues had a chance to review APF long before I introduced it to the public, and they felt that at least 70 percent of the projects they encounter today would benefit from using APF instead of either the TPM or xPM approaches. I thank them for their confidence in APF even though it is a work-in-process. As I continue to experience its use with my clients, I will undoubtedly find improvements and enhancements that will provide even more payback to my clients.
I am taking a bold step forward, and I know that it is in the right direction. The bottom line is that APF works very well on the project types for which it was designed (process design and improvement and new-product development), and many project types (such as IT systems design and development) for which it was not designed. It completely fills a void left by current agile project management models, which focus almost exclusively on systems-development projects.
Organizational Environment
To successfully incorporate APF into the organization’s portfolio of PMLC models requires a cultural change and an open-style management approach. The culture must support a creative environment. The new management style must be facilitative. It must remove every barrier and obstacle possible so teams are free to move in directions that make sense to them rather than being limited by the need for compliance with the organization’s processes and procedures. This means that a high level of trust must be placed in project teams. At the same time, the client team and the developer team must be held accountable.
Making Choices
You don’t choose APF just because you like it. You choose it because the characteristics of the project, your organizational environment, your human-resource skill and competency profile, your client’s willingness to participate, and market conditions all suggest that APF is the best fit, and maybe the only fit, among PMLC models. From my colleagues, I have heard that some companies use agile PMLCs exclusively; in one case, Scrum is the PMLC model of choice for all projects. I’d like to hear the rationale for that exclusivity, because it simply doesn’t seem to make any sense. If that organization really does use Scrum for every project, it must have only senior-level developers who are colocated, and every client must be able to step up to the bar and assume the required Product Owner role. I doubt such an organization exists.
Prioritization Rules
The rules for prioritizing will be different for every organization. The more commonly considered factors will be business value, risk, technological complexity, and effort to implement.
Value of the Project Landscape Model
My project-landscape model (see Figure I.4 in the Introduction) is based on two variables, goal and solution; and two values for those goals, clear or not clear. I guess my Polish heritage and my drive for simplicity and intuitiveness led me to this model. It works, and that’s really all that is important. It is timeless and will continue to work into perpetuity. I am not aware of a more-intuitive or robust way to classify projects when the purpose of the classification is to choose a best-fit PMLC model. The known project-management approaches—linear, incremental, iterative, agile, and extreme—fit this landscape perfectly. The known systems-development models also fit this landscape perfectly. I believe my approach will be proven to provide a logical structure for PMLC model selection where none existed before. That is critical to any attempt to developing an effective project-management discipline.
The Current State of APF
APF has come a long way in its journey to maturity, but there is still a long way to travel.
What Have We Done?
In terms of this book, we’ve reached the end of this adventure. If you have stayed the course, I want to thank you for your continuing interest. You now have another arrow in your quiver.
APF is a new and refreshing approach to a class of projects that heretofore did not fit very well with the available approaches. The primary reason for the lack of fit was the absence of any process requirement that the client be meaningfully involved with the project from inception. We have discussed the critical importance of that involvement, and you have clearly seen the role of the client throughout the life cycle of the APF project. You have come to appreciate the reasons why in an APF project the client is really the pilot and the project manager the navigator. Together, the client and the project manager form a project-manager “mind meld”—as the co-managers of their APF project, they are of one mind in their expectations, enthusiasm, and commitment to the project. They share equally in success or failure. This may seem idealistic to you, but it is the reality of successful APF projects. If we expect to have a positive impact on project success, we need some outside-the-box thinking. APF is not a silver bullet, but it is a fix for many of the problems that have plagued project teams and their clients.
In looking back over the material we’ve covered, I want to come back to the six core values of APF, first discussed in Chapter 1:
3. Incremental Results Early and Often
4. Continuous Questioning and Introspection
5. Change Is Progress to a Better Solution
6. Don’t Speculate on the Future
Now that you have an understanding of what APF is all about, it makes sense to look at some details for each of the core values.
1. Client-focused
If business outcomes and business value are what sold upper management on your project, it makes sense to me that we should then evaluate the success or failure of the project on its ability to deliver on those promises. I am amazed at how many projects do not do that. In post-implementation review after post-implementation review, no check is made of whether or not the project delivered on those promises. Some senior managers have even told me: “It doesn’t matter. The project is over and I’ve got other pressing projects that are already behind schedule.”
Client focus is pervasive through the entire APF project life cycle. This is most evident in the task of prioritizing functionalities. The client is responsible for those decisions, with the support of the project team. Prioritization decisions will be based on the business value the client assigns to each piece of functionality. It is the responsibility of the project manager to keep the client focused on feasible choices.
2. Client-driven
The client is on the hook for delivering on promised business results, and one way or the other the client is paying for the project. The client must be in charge of the direction the project takes and decisions to continue or abort the project. This calls for much more client involvement than most project managers are used to. They have to view their role as a facilitative one, and to support the client all along the way. Remember, the client is the pilot, and the project manager is the navigator.
3. Incremental Results Early and Often
We already know from our prototyping experiences that once the client has demonstrated interest in the project, we have to show results quickly. Prototyping is a way to provide that quick response, which is why so many tools have been created to make fast response possible. APF supports early results. In an APF project, the early cycles are short cycles. That makes fast response possible, and helps sustain the energy and excitement that we have cultivated in our clients regarding the project.
4. Continuous Questioning and Introspection
The heart and soul of an APF project is the relationship that is established between the project manager and the client. Here is where all of the guards must come down, and the client and the project manager must learn to work as one. So strong a relationship has never been promoted in any other project-management approach I am familiar with, but you now know that it is essential for APF project success. It makes for better decisions. “What,” “where,” “who,” and “when” questions should be courageously asked and candidly answered. This is not the place for playing political games or trying to get “one up” on the other party. Being honest and open is the very essence of the core values of APF.
5. Change Is Progress to a Better Solution
The frequency of change over the life of an APF project is a good indicator of tempo and convergence toward an acceptable solution. It tells us that learning and discovery are taking place, and that the client is meaningfully engaged with the team. It’s a good sign in an APF project when change occurs frequently in the early cycles and trends toward less frequency as the project moves further into the cycles. I find it interesting that in a TPM project, change is viewed as the enemy. It sends a signal that the clients really didn’t know what they wanted at the beginning of the project and are only now learning what they need. Change in a TPM project upsets the plan, the schedule, and creates havoc with resource managers. In an APF project, on the other hand, change is expected and welcomed. It is considered a sign of a healthy project, one that is converging on an acceptable solution. APF is designed to anticipate change and to accommodate it without incident.
6. Don’t Speculate on the Future
If you don’t know the future, why plan for it? I first raised that question in Chapter 1. You have learned that APF is designed to minimize the amount of effort spent on non-value-added work. In today’s business world, time-to-market is a critical success factor. If we can’t figure out how to get a project done faster, our competition will, and we’ll lose business. APF departs from TPM in that the Work Breakdown Structure is not developed up-front but rather evolves over time. At the completion of each cycle we expand the WBS to include activities that came into focus as a result of learning and discovery about the solution. The APFist doesn’t guess at the contents of the WBS. When activities appear in the WBS, it is because we know that they will be part of the ultimate solution. To do otherwise is to risk spending time planning activities that never contribute to the end result. That wastes time, and APFists don’t waste time!
What Do We Still Need to Do?
APF is such a radical departure from what most businesspeople understand project management to be all about that you need some type of orientation program to get executives and business units on board. Anticipating some of the questions they will have, you should include in your orientation program answers to the following.
• What kinds of projects do we have that would benefit from an agile approach?
• What is the Adaptive Project Framework (APF)?
• Why is APF a better approach than the current approaches?
• What is the role of the executive in APF?
• What is the role of the client in APF?
• What should we expect from an APF project?
How Should We Do It?
Training, training, and more training are critical. Initially, the training should come before the first APF project, and it could be at a high (overview) level. During the execution of the project, look for opportunities to include more-detailed training. Use the project as the vehicle for training. This is an excellent way to get the message across that APF is really different, and that every APF project will be different. Share your project experiences across the organization so others will benefit from the learning moments those projects provide. Sharing best (and worst) practices will be valuable, especially early in the history of APF in your organization.
Practice, practice, and more practice are also critical. APF is application-oriented, and only through critically reviewed applications will APF improve over time. Developing APF is an APF project without end! If those of you who use APF will keep me in your experience loop, I will be forever grateful.
The End State of APF
There is no substitute for APF experience. The learning curve can be steep for some people, shallow for others, so be ready to anticipate both. Eventually, the overall experience level of the organization will be fully matured and an APF mindset will prevail!
Having seen the success of APF in actual client practice, I am convinced that it should be the model of choice for every agile project and most extreme projects.
Implementing APF in Your Organization
I recommend selecting one of the following two approaches for implementing APF in your organization.
Top Down
If executive managers recognize the value of having an agile PMLC model in their portfolio of PMLC models and if you have their solid support, then a formal task-force approach is the clear choice.
That approach might go something like the following. We’ll use the Kamikazi Software Systems case study to illustrate implementation planning.
Prepare a Project Overview Statement for Executive Endorsement
An example of this type of POS is given in Figure 10.1.
Figure 10.1 POS for Establishing an APF PMLC Model
The Problem/Opportunity statement is an obvious statement of the situation. It should be a non-contested statement of the project-management problem Kamikazi is facing. The Goal statement may seem a bit pompous, but it can be defended quite well. Except for APF, all other agile models apply primarily to software-development projects. APF can handle those as well as process design and improvement projects and new product development projects. It is therefore more robust, and can be used as the PMLC model for any type of agile project and most extreme projects. It will serve well as the de facto PMLC model.
The five statements of Objectives are what you would expect. The Success Criteria are quantitative measures that together define successful implementation of APF. The second criterion may not seem too demanding, but consider the fact that agile and extreme projects are very high-risk projects. The Assumptions, Risks, Obstacles statements acknowledge the realities of an agile or extreme environment.
Recruit the APF Task Force
It is critical that the task force be representative of all parties that can affect or will be affected by APF. If there is a Project Management Office, the Director is the best choice for managing the APF implementation project. If you do not have a PMO, the most senior and respected champion of APF—probably a senior-level project manager—would be my recommended choice. Other likely members of the task force are some or all of the following:
• One or two project managers at each position level
• Human-resource managers
• The director of software development
• One or two business analysts at each position level
• A key staff member from each of the major business units
The task force is more of a sounding board for APF than a design and development task force. I see the project as a presentation to the task force of what APF will look like when deployed, along with elicitation of their feedback. There may be several iterations of presentation and feedback before a final APF process is defined and deployed. Even then, there will be further iterations as a result of experience gained in practice. In effect, APF implementation would be approached as an APF project!
Prepare the Project Plan
The Objective statement provides the structure of the plan. It should have five major parts, one for each objective.
Constructing the Work Breakdown Structure (WBS) for Kamikazi Software appeared straightforward, but Harry wasn’t willing to assume the WBS was complete. He chose to use a production prototype following one of the Iterative PMLC models. Since most of the solution was known, Harry planned for the first iteration to deliver all that was known about the solution.
Plan and Hold a Kick-off Meeting
The transition from the traditional PMLC model to APF was a big change for the Kamikazi development teams, so Crash and Harry decided to pull out all the stops and make a major event of the APF implementation project launch. They recruited the agile consultant who was the original architect of APF to keynote the kick-off meeting. His objective was to get the company excited about the business value that would follow from the successful application of APF.
Bottom Up
If the organization needs to be convinced of the value of adding an Agile PMLC model to the portfolio of PMLC models, you will have to champion the effort by demonstrating its value through the actual use of APF.
Choose the demonstration project(s) carefully. They should be projects that
• Are critical to the organization
• You feel reasonably comfortable will successfully deliver acceptable business value to the organization
• Will be projects of high risk, but have mitigation plans that will be successful if needed
• Have a sponsor who has the leverage and power in the organization to effectively support and represent the project to executive management; and
• Will have the meaningful involvement of the client
Above all, you don’t want a demonstration project to fail!
As I’ve previously discussed, one of my colleagues is a respected project manager assigned to the PMO. She has adopted a version of the bottom-up approach that is worth commenting on. She simply uses APF on the projects in her portfolio that require an agile approach. Her PMO Director hasn’t been too receptive to agile approaches, so my colleague doesn’t advertise APF; she just quietly stays under the radar and goes about her business. Fellow project managers note that she is very successful, whereas they are not. Her project failure rate is minimal compared to theirs. They are starting to ask her what she does to achieve such a high success rate. They have effectively opened the door to the spread of APF across the PMO. She is preparing to walk through that door!
Role and Responsibility of Executive Management
Adopting any agile PMLC model in the organization can be a big culture shock for executives who are of the traditional mindset. They are used to supporting well-defined projects with specified deliverables, and must adapt to supporting poorly defined projects with unspecified deliverables. Heavy-handed management approaches will no longer work. Management must be more hands-off in order to give agile project teams the opportunity to be creative. Teams must be trusted to align with the delivery of business value, and to know when a project is not converging on an acceptable solution so must be terminated. This calls for a facilitation approach rather than a compliance approach.
Putting It All Together
APF is a work-in-process. As you know, it was built in the context of recent client engagements, and is not fully baked as of this writing. Even at this early stage of its growth and development, however, APF shows every promise of making a significant mark on contemporary project-management practices.
I welcome any comments. You may reach me at [email protected].
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. Discuss how you might incorporate APF under the monitoring and support functions of a PMO.
2. What are the major challenges to implementing APF in an organization that rigidly adheres to TPM approaches?