Fifteen Compelling Reasons to Adopt the Adaptive Project Framework
Adaptive Project Framework (APF) is not a recipe for how to manage complexity and uncertainty. APF is a tool for creating the recipe. It's a framework that teaches you how to think about agile and extreme project management in response to the very different kinds of projects you'll encounter. I like to think of APF as organized common sense. If your project management process requires you to do something that doesn't make sense given the nature of your project, don't do it. Use APF instead.
To understand the position of the Adaptive Project Framework with respect to the types of projects that businesses encounter, it's helpful to have a picture of the contemporary project landscape. I've used the model illustrated in Figure 1 for the past 10 years. It has served me well as a tool for organizing my approach to organized common sense project management. I offer it as a model to organize how you think about projects.
Figure 1 The contemporary project landscape.
To keep the project landscape simple and intuitive, each dimension (goal and solution) has only two values: Clear or Not Clear. The difference between Clear and Not Clear is more qualitative than quantitative. The original purpose of the project landscape was to guide the project team to the best-fit project management life cycle (PMLC). The best-fit PMLC is a function of the project's characteristics. It's not a "one size fits all" approach. Those don't work and may never have worked. I've used this project landscape for over 10 years and it works. So, with Figure 1 as the foundation, let's look inside that four-quadrant landscape and see what else it's telling us about the projects that are found there.
Traditional Project Management (TPM) Quadrant
The Traditional Project Management (TPM) quadrant contains the simplest of all project types, but those are the least likely to occur in today's continuously changing business world. Many TPM projects are familiar to the organization, routinely done, and successful. The client has clearly scoped the problem (the goal), and the project manager (PM) and the client's business analyst (BA) have defined how they'll reach that goal (the solution and its requirements). Managing such projects is outside the scope of APF. APF could be adapted to a single iteration model and used quite effectively. I haven't done that. Such projects also put the team on familiar technology grounds. The hardware, software, and telecommunications environments are familiar to the team. They've used them repeatedly and have developed the bench strength to handle such projects.
A complete plan is generated. The limiting factor in these plan-driven approaches is that they're change-intolerant. They focus on delivering according to time and budget constraints, and rely more on compliance to plan than on delivering business value. The plan is sacred, and conformance to it is the hallmark of the successful project team.
Few changes are expected. This is where many TPM PMLCs get into trouble. The assumption underlying all TPM projects is that requirements are complete and there will be few change requests. Every requirement change request requires team member time to analyze and recommend the response. There are two variations of TPM to consider, Linear and Incremental, and the challenges of effective project management are different for each variation.