In studying for my PMP exam and expanding my knowledge base around project management, I read the book Effective Project Management: Traditional, Adaptive, Extreme 4th Edition (Wiley Publishing, © 2006) by Robert K. Wysocki. In this text, the author puts forth a project management model that differs from the Project Management Body Of Knowledge (PMBOK) called the Adaptive Project Framework (APF). It is a middle ground between traditional waterfall project management and an Agile development style of project. Wysocki has since published two new books relating to this topic: Effective Project Management: Traditional, Adaptive, Extreme 5th Edition (Addison-Wesley Professional, © 2010) and Adaptive Project Framework: Managing Complexity in the Face of Uncertainty (Wiley Publishing, © 2009). I will provide an overview of APF based on the 4th Edition text, an article by Jorge Dominguez, and the introductory chapter of the new APF text (located online here) in this post.
Change is a given in the project environment. Nowhere is change more prevalent where the goal is not clearly defined, or the path to the goal is unknown at the beginning of the project. Wysocki provides a framework to determine which style of project management (Traditional, Adaptive, Extreme) to use on a given project. This is based on whether the goal is clear, and whether the requirements and solution (path to the goal) are clear. This defines four quadrants as shown in this diagram:
Projects in Q1 (Goal is Clear, Path is clear) can use the Traditional Project Management methodology (as defined in the PMBOK) commonly called waterfall. The projects in Q4 (Goal not clear, Path not clear) call for an Extreme Project Management solution, usually some form of Agile Development (Scrum, eXtreme Programming, etc.). However, projects in Q2 and Q3 (either Goal or Path is not clear) call for the Adaptive Project Framework.
This is a diagram showing the various components of APF:
The APF consists of the following components, organized into 5 Phases:
• Version Scope
- Develop the Conditions Of Satisfaction (COS) to define what is needed and what will be done to meet that need
- Develop the Project Overview Statement (POS) which summarizes the problem/opportunity, what will be done and how, the business value, and risks, assumptions and obstacles to success
- Prioritize functional requirements; this list may change but currently reflects the best information available
- Develop mid-level Work Breakdown Structure (WBS) showing goal, major functions, and sub-functions
- Prioritize scope triangle (consisting of time, cost, resources, scope, and quality, customer satisfaction was left out)
• Cycle Plan (iterative)
- Extract from the WBS those activities that define the functionality to be built in this cycle
- Decompose the extracted WBS down to the task level
- Establish the dependencies among these tasks
- Partition the tasks into meaningful groups and assign teams to each group
- Each team develops a micro-level schedule with resource allocations for the completion of their tasks within the established cycle timeline and budget constraints
• Cycle Build (iterative)
- Conduct detailed planning for producing the functionality assigned to this cycle
- Begin cycle work
- Monitor and adjust cycle build
- This cycle ends when its time has expired. Any functionality not completed during this cycle is reconsidered as part of the functionality in the next cycle
- Create a Scope Bank to record all change requests and ideas for improvements
- Create an Issues Log to record all problems and track the status of their resolution
• Client Checkpoint (iterative)
- Client and project team perform a quality review of the functionality produced in the just completed cycle against the overall goal of maximum business value, and adjustments are made to the high-level plan and next cycle work if needed
- The sequence Cycle Plan / Cycle Build / Client Checkpoint is repeated until the time and cost budgets for this version have been expended
• Post-Version Review
- Determine if the expected business outcome was realized
- Determine what was learned that can be used to improve the solution
- Determine what was learned that can be used to improve the effectiveness of APF
Note that at the beginning there is a phase that defines the overall scope for the project. The first step is to have a Conditions of Satisfaction (COS) discussion with the project sponsor/ business owner. Once this is complete the project management method is selected. If the APF is chosen, then the Project Overview Statement (POS) artifact is prepared. This is an agreement between the project sponsor/ business owner and the project team that helps define and scope the project. A template for a POS is shown below:
Note that the COS can be captured in the Success Criteria portion of the document. The intention here is not to completely define all aspects of the project, but to come up with a common understanding before the project is initiated.
The majority of the APF is contained in the three iterative phases (Cycle Plan, Cycle Build, Client Checkpoint). These phases allow for just enough design and planning, a fixed duration functionality build, and then affords the client an opportunity to assess whether the project is meeting expectations or should be changed. This framework also allows for the client to end the project at the end of one of these iterations if the business value is no longer present, or the overall situation has changed with a much smaller cost than a waterfall project. Finally, the last phase allows for a review of what has been delivered, and can either serve as an endpoint of the project, or set the stage for follow-on work.
This methodology accommodates and embraces change. It is a framework and as such it can be adapted for a wide variety of projects, not just software development. This is a very high-level overview of APF, and I suggest the texts shown above for anyone involved in projects, especially project managers of all types.
Please post your comments and questions below.
No comments:
Post a Comment