I was going to post more about Process Intelligence and the Adaptive Project Framework last Monday but I was snowed under at work. Good thing because John Kamensky posted a great comment on President Obama’s Accountable Government Initiative. As I read the snapshots of the six initiatives, I was struck by how the success of each initiative depends on good project management and good business process management. There was a good discussion recently about the role technology plays in Gov 2.0 but I personally think the key to successful Gov 2.0 and OpenGov are the management methods. We need new methods for managing projects and for continuously improving Gov 2.0 processes.
Traditional project management is still useful. Thanks to TPM, the US Government built Trident submarines, nuclear aircraft carriers, and landed men on the Moon. Much of what made TPM so effective are the innovations pioneered by the Federal project managers such as Earned Value Management and Program Evaluation and Review Technique. But, for TPM to be effective, the goal and the solution must be known in advance and change must be minimized as much as possible.
In the Gov 2.0 reality, change is paramount and rapid while the goal may be well-defined but the solution to achieve the goal is often vague. Timelines are extremely short and so are resources and budgets. Using TPM to manage Gov 2.0 projects is just inviting failure (as the numerous examples in the IT Project Failures blog will attest). For Gov 2.0 and OpenGov to succeed we need new methods to manage these projects and their implementation. That is why I advocate the Adaptive Project Framework.
The APF was created by Dr. Robert Wysocki during his 40+ years as a project manager. He wanted a project management method that could better handle change and allowed for exploring a way to a solution while minimizing wasted time and resources. The best feature of APF is that the project scope is variable and that is what makes it perfect for Gov2.0 projects.
Scope in a project is what work needs to be done during the project (Project Scope) and what features the project product will have(Product Scope). In TPM, both Project Scope and Product Scope is fixed as early as possible. All planning, scheduling, and resource requirements are anchored to the scope and this is why change is so disruptive to the TPM project.
APF uses Cycle Plans and Cycle Builds to incorporate change into the project management process. In the initial planning, the project manager and project customer(s) create a high-level document that defines the project goal and conditions of satisfaction. Then a Requirements Breakdown Structure is built that captures the project product requirements at that time. A Cycle Plan is created that details what requirements will be created during the Cycle Build. The Cycle Build is time-boxed which means that it is a short duration (two weeks to a month).
During the Cycle Build you can have two streams of work. In one stream, some team members explore new features to include in the final project product while the other stream integrates proven features together into the product. As new ideas emerge they are added to the Scope Bank to be part of future Cycle Builds. Any features that are not completed within the Cycle Build are added to the next Cycle Plan. The Cycle Build can also be terminated early if the features are not working or if the current solution no longer fulfills the project goal.
To illustrate the difference, let’s use an example from recent events. Suppose you are working on a project to apply Search Engine Optimization (SEO) strategies to your agency website. You are halfway through the project when Google launches Google Instant. Then Twitter launches a redesigned search service. This requires a major change in your SEO strategies. Now what do you do?
Under TPM you could continue on with the project but your project product will be outdated and ineffective by the time you deliver it. Or you could cancel the TPM project and start all over again. You have wasted time and resources while incurring the additional costs of a new project. This will not look good on the IT Dashboard.
Under APF, the most you have to do is modify the Conditions of Satisfaction document and the Project Overview Statement. You can cancel the current Cycle Build and begin a new Cycle Plan to incorporate the new technologies and techniques into the final project product. Waste and loss of time are minimized while the current project can continue on toward the original goal but with an improved solution.
In my next posting, I will go into detail about Process Intelligence and how that can help address the issues raised by William Eggers and John O’Leary in If We Can Put a Man on the Moon… Getting Big Things Done in Government. I have also added two new pages devoted to collecting resources about Process Intelligence and Project Intelligence to my personal blog.
Bill – This sounds really smart! Are your principles for Adaptive Project Framework sufficiently reflected in the DOD/Ashton Carter acquisition memo released last week?
Now all that needs to be done is to convince the current crop of project managers that there might be a better way and bring them on board!
I agree 100% that project management is the key to not just Gov 2.0 but any undertaking. I’ve been managing programs and projects for a decade and consistently the one thing that undermines them (besides for organizational/psychological dynamics, insufficient resources, and so on) is an inability to manage change effectively. It’s almost like people either say, “this is the plan and we’re sticking to it” (even if the plan is wrong) or “the plan won’t work, let’s abandon all plans and just proceed.” I’d like to learn more about APF.
I’m so glad to hear about the adaptive project framework. Seems like that should be used more often in government contracts, especially those involving Gov 2.0. The APF process described in this blog sounds a lot like the process we use in my shop to manage internal projects with changing parameters.
APF at a minimum provides a critical function often missing from projects due to a) cost considerations, and b) resource allocation – our dear friend, risk management.
Since any great PM will utilize some degree of risk management to at least track, assess, plan, monitor, and communicate for some degree of a probabilistic scenarios it’s better to utilize a process that inherently limits risk like APF.
Most projects in government function traditionally and as costs are increasingly sunk as the project progresses, inherently, risk increases and the tolerance for failure decreases. I’m willing to bet many of these IT projects that are challenged/failing could be sharply mitigated by greater flexibility in the process and baked-in risk mitigation.
After all, isn’t one of the great PM hallmarks the pro-active risk manager not the reactive? So why would we not start with the process itself?
@John – Thank you for your question and for pointing me to the DOD memo on achieving greater efficiency and productivity in defense spending. I think APF can be very helpful in achieving the goals of the memo. Now, I am not an expert in acquisitions so my suggestions may not be realistic or workable but I hope that I can at least point to some solutions.
I believe APF can help with the defense acquisition process in three ways:
1) One of the two initiating documents of APF is the “Conditions of Satisfaction” (COS). This is where the goals listed in the memo can be translated into decision guidelines for planning the Cycle Builds and for determining if the project should go on to the next Cycle Build.
2) The short length of the Cycle Build is designed to limit the waste of time and resources. If a set of project tasks are not working or achieving the COS , the current cycle can be terminated and a new Cycle Build is planned. The major advantage of Cycles Build is that you are essentially given a fresh start multiple times during the project. This makes taking a different direction or reacting to changing circumstances much easier to accommodate than in TPM.
3) I didn’t mention this in my posting but a crucial part of APF is the Client Review after each Cycle Build and before the next Cycle Plan. In this review the Client determines whether the current solution is reaching the project goal(s), what features should be built in the next Cycle Build, or if the project should continue or terminate. This would also be the ideal place to put in “Would Cost/Should Cost” measures to evaluate the solution.
A couple of other points to consider:
4) Given the nature of Cycle Builds, I think it would be easier to swap out contractors in mid-project without much disruption to the project solution. For example, Contractor A has been working on the project solution for the first three Cycle Builds but their performance has been declining in the last two Cycle Builds. The Client can decide to bring in a new contractor to continue the project solution in the next Cycle Build.
This will inject more competition in the contracting process because a contractor knows that they can be discharged at any time for poor performance without being able to argue that the project will not be completed without them. I have not heard of this happening in an APF project but it should not be that difficult to implement.
5) Even if you don’t use APF for the entire project, Wysocki argues that you can incorporate APF subprojects into a TPM project. So, in projects where both the solution and goals are well-established, you can still use APF to handle those aspects of the project where there is the most risk for waste and uncertainty. It’s also a good way to incorporate innovative subsystems or technologies into the larger project product.
Again, great question and a good exercise in applying APF to a complex project management area.
@Henry – That’s my Mission from God! 🙂
@Danielle – The book is available in both hardback and eBook. Well worth a read.
@Christina – Maybe we can talk offline about your shop’s project management process and how it compares to APF.
@Michael – TPM uses risk management but risk increases as the length of time in the project increases. The benefit of APF is that you carve the total project time into smaller chunks so that risk is easier to spot and stop before it grows too large. Plus, making scope variable essentially turns the project into a more adaptive creature that can better react to risk.
This is great stuff, Bill!
I like how it formalizes some of the things that you already see in great project managers –
I think it sets the whole process up for measuring what should be measured, rather than how good a guesser the PM is, i.e., laying out the entire schedule all the way to the end of the project, freezing it, and then measuring “success” against the baseline guess.
Because of the short-term focus, I also see opportunities for incorporating some of the handoff principles from Critical Chain to allow better coordination of resources, single-threaded tasking (as opposed to multi-tasking), resolving bottlenecks, etc.
I love the concept of the Scope Bank–especially with the prospect of incorporating the identified features into future Cycles instead of just “rolling it into version 2.0.”
I will be exploring APF more–thanks again for the post!
In looking at the APF, it is nice to see it take a number of agile-related concepts (e.g. a Cycle Build is reminiscent of SCRUM), and couple it with more PMI-style concepts in an active way (e.g. the core value of continuous questioning and introspection).
While I agree with a number of comments below that project management is important to any undertaking, I don’t believe that it is “the key”. Another piece to consider is the size of the efforts that we as public servants are asked to produce. Sometimes those efforts due to their size, complexity and number of people involved, are headed for failure because they get too large and have to serve too many constituent groups. Something like the Adaptive Project Framework may allow us to break these very large, complex efforts into smaller activities that will deliver consistently and progressively.
For me, this will take some additional research and further reading, but it looks like a more refined agile approach that will also satisfy some of the more traditional project management needs we have to satisfy our auditors and federal partners.
I had a copy of an APF book that I can’t seem to find now. It sounds like a mix between the concept of progressive elaboration in TPM and sprints in scrum to me?
@Josh – Yes, that is an accurate description of the process. Wysocki also describes when to more agile project management methods when you have projects where you are not sure of the goal and the process of getting to the goal.