In The Official Plan I mention how we took the “official plan document” and turned it into a real plan that we used everyday. This was different from the classic plan that was created to meet a checklist requirement (ISO, SEI, ITSM, etc.) and then sat in a repository where it could be found by an auditor or updated once a year or at milestones in the project — but rarely used by anyone doing daily work.  Here is bit more on how we made the change and how moving to a real plan can often confuse folks and how we overcame this normal confusion.

Your Task Is To Update THE Plan

We had such a plan. I had been roped into helping the organization update their five year Information Technology strategic plan. It would include budget numbers, so I thought it should be important to get something useful. In the past, it was just a collection of hazy thinking about what we would be doing in the next few years with somewhat random numbers on what that would cost. It was just one of those things that had to get done each year, and we had to be able to reasonably talk about each line item to a higher headquarters review board. Does this sound familiar to anyone?

Great, I thought, another massive document I had to update so we could check off an item and then get back to real work. Well, I wasn’t that kind of guy. I hated to do anything that was not directly useful. Like most of my efforts, I focused on trying to make this exercise completely practical and useful. This initially drove everyone batty.

Get Back To Basics And Start Simple — Throw Out The Old Plan If Necessary

My first shot at the five year plan took up all of one page. This was in stark contrast to the large tome that existed for the last five year plan. Why was I not just updating the existing plan, people would ask? No problem, I said. I would be growing the updated plan using the existing plan and getting inputs from everyone. Well, what I really did was just take the inputs from everyone and compared it to the old plan. Luckily, only a few people told me to just use whatever was currently in the old plan as their inputs. Most folks were happy to describe what they really wanted or needed to do over the next few years.

The plan grew to multiple pages. These pages were now primarily tables of details on equipment and requirements. I assigned costs and schedules to each of these and used the math capabilities behind the text tables to do the calculations. This allowed the costs and schedules to update when I got a call with the request “can we add a few more devices to our capabilities?” At this point no one probably believed that the plan I was building would be any different than past plans, but they appreciated the fact that they only had to give me data and they didn’t have to look at their old portion of the plan and try and update it (which was the exercise from previous year’s plan updates).

Grow The Plan Into Something Actually Useful Based Upon Everyone’s Inputs

Soon, the plan was growing large as I pulled in more detail and as I explained to people the impact of the detailed requests they gave me. This was new to them as we were engineering the details as they gave them to us. This included seeing how they all would hang together and what was implied if someone wanted to put new equipment at a location that then required support and connectivity that might not already be there. I finally had to convert the text document’s growing tables to a spreadsheet to keep up with the detailed relationships we had to model behind the requirements.

Eventually, as the plan became large and complex, we converted it to a database. The “official plan” became just a database “view.” This notion that the “plan” was just a view or report from out of a large database was something that confused a lot of people. No, they would say, the plan has to be a text document. That is what a plan is! I would say no problem I can generate the current five year plan print copy anytime you want.

We Know We Have A Real Plan When It Becomes Something We Use Everyday

This plan database became the organizing direction behind our multi-national IT department. What we did on a daily basis (implementing new capabilities, retiring old equipment, etc.) was driven by “the plan.” We could display what needed to happen and when it needed to happen from the plan database. It provided all the details and captured all the essential engineering interrelationships we needed to implement. As things changed, we updated the plan database and checked the engineering. The database would balk at adding something if a prerequisite didn’t exist or would show what else had to be added, changed or removed if we added or removed equipment or software.

A humorous and frustrating part was when my boss told me that we needed to “turn over” the plan to the new HQ strategic planning department. He was still thinking of the plan as a periodic document that got updated and archived and a decision had been made (without my inputs!) to have the HQ keep the plan. I told him they could have a copy of the annually “approved plan” view, but as we did things, the database and hence the plan would be updated regularly. When we went for approval next year, it would already be updated and ready to go — the HQ didn’t need to coordinate it.

It May Take Awhile Before Others Understand What A Real Plan Looks Like

I’d explain this to my boss each time he told me to “turn it over.” One of the last times he asked, frustrated, for me to finally turn it over he said “don’t explain it to me again because I’ll agree with you again but I’ve also already agreed to turn it over!” We never did turn it over because that no longer made any sense. We had essentially moved from a waterfall style annual plan update to an agile daily update of the plan. This multinational governmental organization struggled to cope with the notion — but these same government customers loved the levels of service and flexibly we had achieved using the plan and their inputs.

We had taken an annual exercise in killing trees (i.e., reviewing and updating a large printed plan) and turned it into a tool that became the center of how we did our daily business. While the transition to a practical plan initially confused many people, it eventually became the logical way to do planning. Creating a practical and useful plan that we really used was, not surprisingly, a great project management tool.

Are your project plans real plans that are used every day, or are they used primarily to complete a checklist?