PM Articles > Kent McDonald > Project Closeout: Plan for the Peace, Not Just the War

Project Closeout: Plan for the Peace, Not Just the War

by Kent McDonald

I recently finished reading How Wars End: Why We Always Fight the Last Battle by Gideon Rose. The main message of the book is that the United States of America has a habit of doing a lot of good planning for war, often based on lessons learned from past struggles, but doesn't do a good job of thinking about the ensuing peace. This was a book about political and military history, but in my never-ending quest to apply lessons from history, I think there are some things we can learn for our project teams. A good analogy can be drawn between "planning for the peace" during war and planning for what happens after a project finishes.

What does it mean to "plan for the peace" in a project context? In the Guide to the Project Management Body of Knowledge, the "Close Project or Phase" process in the Project Integration Management Knowledge Area includes an output specifically called "Final product, service, or result transition," described as follows:

This output refers to the transition of the final product, service, or result that the project was authorized to produce (or in the case of phase closure, the intermediate product, service, or result of that phase).

And that's all it has to say about worrying about what happens after the project is over. Is that a huge oversight in the world of project management? Perhaps. More likely it's a reflection that planning for after the project is not just a project management issue. It's an overall project concern. In other words, part of the outcome of the project is figuring out how to make that outcome happen.

The Business Analysis Body of Knowledge recognizes this need to "plan for the peace" by introducing the concept of Transition Requirements. In the words of A Guide to the Business Analysis Body of Knowledge:

. . . [transition requirements] describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to a desired future state, but that will not be needed once that transition is complete. They are differentiated from other requirements types because they are always temporary in nature and because they cannot be developed until both an existing and new solution are defined. They typically cover data conversion from existing systems, skill gaps that must be addressed, and other related changes to reach the desired future state.

To extend the military analogy (perhaps stretching it to a breaking point) planning for the peace needs to occur as part of implementing the war.

Planning for the peace consists of getting to a peaceful state, and determining what to do once we get there. The BABOKĀ® Guide idea of transition requirements helps us get to the peace. This line of thinking takes into account things which may seem technical in nature, such as initial data loads or data conversions that need to occur as a result of a new system or a system update. For example, one project I worked on added a new source to an existing data warehouse incrementally. Each time we added a new increment, we had to perform a historic load of data from the source system. In order to do this as efficiently as possible, we planned for this process and established specific procedures that we followed every time we did it.

Other transition considerations include how the outcome of the project will be deployed to users, which can influence the order of project implementation. Agile approaches help address this transition need by only developing the necessary features for the customer base targeted for first delivery. In effect, give the initial customers something, get their feedback, and then decide where to go from there.

There are several questions to ask when thinking about closing a project. It's probably a good idea to ask and answer these questions sooner, rather than waiting until the week before the end of the project.

Will your stakeholders (customers or users) need training to use the solution? This is especially important when you are developing a new application or making changes to an existing one. Consider what that training needs to look like. Is it fairly extensive hands-on training that will take a day or two, or will a one-hour overview of the changes be sufficient?

Will your users' work need to change as a result of your project? In many cases, changes in process drive scope in a project, but sometimes outcomes introduced by projects require corresponding changes in a business processes or in a stakeholder's day-to-day work. During the project, are you including the people that would be able to tell you whether their work is changing? If their work is changing, what should you do (if anything) to help them make those changes?

How will you support (or do you need to support) the outcome of the project? There are a couple different things to consider here. One is the "maintenance period," where the project team is available to react quickly to issues that the stakeholders run into right after the final deliverable is released. The other is the question of longer term support. If you know the outcome of your project will be supported by someone who is not on your team (e.g. an operations group) include someone from that group on your project team during the course of the project so that they can start getting familiar with the outcome. At the same time, figure out what information that support group would like persisted and in what format, so you capture the necessary information. If possible, have the person from the support group create whatever documentation is needed. After all, they will be the one most familiar with what information is needed. (They will, of course, need some help with knowing what to write.)

How will you measure whether the project was successful? Here, we are not measuring success in terms of scope, time, or cost, but rather what business objectives the project will meet. The tricky thing with this one is that you can't always tell whether a project was successful immediately after it ends. Often the outcome has to be introduced into the wild and used for a while before you can tell whether the objectives are met. Identifying the objectives you will look at, how you are going to come up with those measurements, and who is responsible for doing the measurement are all things you want to figure out during the project, because additional work may be required to make those things happen.

If you are replacing an existing system, when do you shut that existing system off? Many software projects that start off as a system replacement never seem to get to the point where the old system can be shut off. For one reason or another, every area using the old system doesn't move off of it in a timely manner. This is perhaps one of the biggest dangers in approaching system replacement projects, so it's part of planning for the peace that actually needs to happen when you are planning the war. Is the main goal of your project really to replace an existing system? At the heart of the matter, does that even make sense? Resist the urge to start a systems replacement project for the sole purpose of replacing an existing technology without allowing any changes to how business is run. Instead, look at what capabilities you need to continue to have and the best way to deliver those capabilities. Looking at the project from that perspective, you are less likely to implement a new system that includes all the broken processes from the existing system, and more likely to provide only the capabilities that are really needed.

Sometimes you are unable to completely replace an existing system because you ignored or underestimated the political aspect and can't drive the necessary adoption. This is a clear analogy to what happened with most US wars in the 20th and 21st centuries. Militarily we had a pretty good handle on what we wanted to do, but politically we dropped the ball. The same thing happens with many projects. Technically your project team is able to work through most of the issues that prohibit implementing a new system, but politically the ground work isn't done to get the new system adopted throughout the organization. This can often happen when the focus of the project is on replacing a system rather than providing capabilities. Project work is demanding, so it's easy to see where project teams can lose sight of what happens after close-out. As they near the end, many teams just want to be done and move on to the next thing, so they may not consider all the niggling post-project considerations. This inevitably leads to issues that the team has to go back and fix later. Planning for how you are going to get to the peace, and what things look like when you get there, will make the end of the project that much more satisfying and will allow you to truthfully declare "Mission Accomplished."

Not all comments are posted. Posted comments are subject to editing for clarity and length.

I've often heard say that change management is the most overlooked part of a project. My experience tells me that change management folds into the peace plan and that post-implementation is where too many projects fall short.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.