The Action Plan: Project Management Made Simple

"Luck is what happens when Preparation Meets Opportunity"

Seneca

There is rarely a year where at least one study is not published bemoaning the high levels of project failure within the profession of Information Technology. In 2009, a study by IAG Consulting found that 68% of IT projects were unlikely to succeed, and when they did succeed it was largely attributed to pure luck. In 2012, a study by McKinsey and Company, in conjunction with the University of Oxford, found similar results:

On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. Software projects run the highest risk of cost and schedule overruns

A frequently cited cause of project failures, cost overruns, and missed deadlines is a lack of communication or a lack of effective communication--a perverse irony given that IT exists as a profession in part to facilitate communications. Even causes such as "poor planning" and "lack of leadership" are ultimately attributable to poor communications.

As poor communications is a cause of project failure, improving communications during various project phases should improve the probabilities of project success. Having had the privilege of leading a variety of technical teams over the course of my career, I have learned--occasionally the hard way--the particular importance of effective communications in accomplishing virtually any goal or objective imaginable.

One profession where effective communications is literally a matter of life or death is the military: throughout history, battles have been either won or lost on the quality of communications between various military units.  The United States Army and Marine Corps address this challenge through the use of the Operations Order, also known as the Five Paragraph Order. The purpose behind the Operations Order format is clear and concise communications which can be transmitted and received in the very chaotic conditions of the battlefield. An ancillary objective is eliminating potentials for miscommunications or misunderstanding.

An IT project is not a matter of life or death, yet there is still a pressing need for clear and concise communications. With the interactions among multiple technical specialties that take place within most IT projects, the parallels to military operations can easily become a rather expansive list. Consequently, it is not unreasonable to look to military communications as a guide for improving project communications within IT. With that in mind, one can adapt the military Operations Order format for IT projects. I call my adaptation of this format the Action Plan.

The five paragraphs of the military Operations Order--and thus of the Action Plan--are as follows: Situation, Mission, Execution, Administration/Logistics, Command/Signal (I typically title this section Communications). The extent to which one wishes to follow the military structure will vary, but I have rarely seen a need to replicate more than this top-level structure; analogies by their very nature are imperfect relationships, and it would be ill-advised to expropriate a communications structure designed for moving tanks and artillery to use for moving servers, switches, and routers unmodified. However, I have found that this basic structure lays out a comprehensive communications format that allows everyone engaged on a project to understand what is taking place.

Situation

The Situation paragraph is the task's background and context. Here one would describe the particular business problems that need to be addressed, as well as any technological priorities that might exist. The need to address a severe zero-day exploit would be one example of what would go into the Situation paragraph. Alternatively, the rationale for moving a data center or other operational facility would be placed here. 

Mission

The Mission paragraph should be a clear and concise statement of task objectives. Depending on the task, it might even be a single sentence--and I have found that using fewer sentences here is better. "Apply firmware updates to all network routers" would be one example of what would go here. "Install replacement servers/switches/access-points" would be another example. If it is an object of the exercise, it needs to be stated in this Mission paragraph. 

Execution

The Execution paragraph is not really a paragraph at all, but rather a specific task list. The task list might be broken down by individual or individual area of responsibility, or all relevant actions might be contained within a single task list--adapt as needed to fit the realities of the project. The crucial characteristics here are that the tasks specific--right down to the individual server and/or software revision number--and are sequential--the tasks that need to be performed first should be listed first. 

While the Execution paragraph needs to be comprehensive, as with all the parts of an Action Plan it needs to be brief. Thus, in large or highly complex projects, the tasks within an Action Plan might themselves lead to subordinate Action Plan documents. The Execution paragraph of a global Action Plan for a project might describe the specific task objectives for a number of different technical teams, and in turn each of those teams would devise their own Action Plans to address the particular requirements of their specific task objectives. 

Administration and Logistics

The Administration and Logistics paragraph is where any special resources or equipment items get mentioned. Similarly, an outside vendor either on hand or standing by in case of an unforeseen even would be listed here. If there are special contingency considerations, this is the paragraph where those get documented. Whom gets tasked with deciding whether to abort a task also gets listed here.

Communications

The Communications paragraph outlines how members of the assigned team can communicate with each other. Responsibilities for providing communications beyond the project team are also detailed in this paragraph. 

The goal of the Action Plan is to inject certainty into project management by giving a concise and comprehensive description of what is in. Properly written, the Action Plan clearly sets expectations, identifies objectives, and describes every person's role within the overall project. To the greatest extent possible, it seeks to remove thinking from task execution; thinking and planning ideally take place before task execution, not during. By unburdening team members in this fashion, they are able to be more adaptive and flexible during the execution phase of a project, simply by virtue of starting the project knowing their individual objectives.

There is a psychological benefit to the Action Plan as well. In its structure, its tone, and hopefully its verbiage, it is goal oriented rather than process oriented. It focuses attention on project goals and objectives, with only secondary emphasis on project process--the "what" is far more important within an Action Plan than the "how". This emphasis allows project leadership to focus on managing results and outcomes while simultaneously allowing all project participants to bring their various skills and experiences to bear on determining methods and processes to be used. 

Most importantly, the Action Plan aids in the planning process itself. Even before an Action Plan is written, applying a standard communications framework to planning discussions allows effective plans to be built. The Action Plan is as much about the process as it is about the documentation. Whether a team employs top-down leadership or uses a more collaborative structure, the Action Plan approach brings systematic organization to planning efforts. It is a comprehensive structure, able to address all portions of a project, and yet it is simple enough to be easily reproducible throughout a project, enhancing organization and coordination at all levels.  As a planning activity even for individual work, I have found that using this format as a guide makes individual efforts more effective simply by bring a measure of order to activities; by working through the steps of a particular project or task in this structured fashion before undertaking them, potential flaws or missed steps can be identified--errors and failures can be pre-empted and avoided, and every problem avoided is a problem one does not have to devote scarce time and effort to solving.

No document is ever a substitute for actual planning, and even the Action Plan structure is undermined if one merely works through the document by rote, treating it as merely an item to be checked off.  An Action Plan is a guide, not a mandate. However, when used as a guide, it will simplify project planning, and enhance project communications. It will facilitate the full engagement in a project by project team members, ensuring a maximum contribution by each member towards project success.

Good project plans increase the chances for project success. If luck is the convergence of preparation and opportunity, the Action Plan is one preparation that gives all project participants the opportunity to get lucky and succeed.