Planning - less is more (usually)

I recently finished an assignment at one of the global leaders in software development, and my role included that of Software Configuration Manager in the worldwide internal rollout of a new product.

The product was multi-functional, with the different business functions at different stages of development. The first couple of applications were already implemented, and the subsequent applications in the set were now coming up for implementation alongside upgrades and enhancements to the earlier ones.

The implementation of each new product required very careful control and testing, as the company was actually now relying on each installed application for major parts of its global operation.

Because of the operational status of the applications the installation work could only happen over the weekend. The global datacentre is in Silicon Valley, so I spent many a hectic weekend out there planning and monitoring the implementation of new application software.

The time window for the implementation was very short. We could not get our hands on the live systems until 6pm Pacific Standard Time, Friday (close of US business), and the systems had to be up and running at 6pm Sunday (start of day, Asia-Pacific region).

very long Gantt chart We had a plan. Goodness, what a plan we had. There were over 500 separate activities in the plan, to be accomplished in the 48-hour time window. Some of these activities were only a few minutes in duration but absolutely vital to the overall job. We had decided to use the plan as a checklist for driving the database administrators who would be doing most of the technical work, the support teams (in three continents) who would test and approve the new applications stage by stage throughout the weekend, and the senior management who would give approvals at key stages during the job.

The plan had been started by the man who was now my boss, the Director of Global Operations, and he had refined it over about 6 separate weekend upgrades. The plan became pretty comprehensive. We had a mechanism for updating the plan if we found something missing, and, generally, the technical team found the checklist approach very useful. In the middle of a long night anything that reduces the guesswork is useful.

However, I found the plan cumbersome, and I was the Software Configuration Manager responsible for running each weekend project! I found it too easy to get lost in the detail, especially as I came to this particular project late in the day. My 'induction' started at the most detailed level (in at the deep end!), and I found it difficult to see the big picture.

I discussed this with my boss (you know, the person who developed and refined this plan), who was gently ironic in his response. Something about 'I thought you were an expert in Microsoft Project'. He was reluctant to even discuss changing the plan so soon before the project started. When I said that I needed an idiot's guide to the plan he was less than gentle!

So, the next big weekend came, and one of my specific responsibilities was to warn the senior managers just when they would have to log on to the system to inspect and approve the various stages of the upgrade project.
I just couldn't figure it out, and it was rather important to get it right. I would be calling up these people in the middle of the night, and because every project ran slightly differently we couldn't guarantee the timings in advance.

So, I drew up a milestone plan from the detailed plan. I extracted the six or eight milestones where major sign-offs were to be achieved, and made a simple word-processor list, showing milestone, time, and people involved. I noted down just what was to be examined for approval at each milestone, and finally I added a note reminding me what depended on the acceptance, so I would know what to do if acceptance were delayed or refused.

I pinned this list above my desk; I was ready.

My boss came past, saw the list, and had a sort of conversion experience, like Saul on the road to Tarsus. He snatched the list away to make a dozen photocopies. He also asked me to email it to a list of folks.

When things calmed down a little he had the grace to admit that he had invested so much effort in the detailed plan that he thought it could do everything, and that everyone should see it all. Now he had seen how successful the simple milestone plan had been he realised that different players in the project require different views of the plan.

He was also very pleased with the response from the management. At last they could see enough of what was happening on the project with a glance at a single sheet of paper. We made the full plan available on the network for the odd detail-obsessed person, but the two-level plan became an essential feature of that project from that moment.

Of course, with Microsoft Project we could insert the milestones into the appropriate places, and filter to extract only milestones. We then went on to try to produce extracts from the plan just for the technical team, but this didn't work. They asked to be able to see all the activities assigned to other functions, as it helped them plan their breaks during the night!

I suppose this final view underlines the need to consider very carefully just who will receive the plan, and what they need it for. The most expert project planner must be prepared to produce several levels of plan, from fully detailed to very simple, just to make sure that the project plan achieves one of its key objectives, which is to be a vital communication tool.

Different levels of planning have relevance to different people. The project manager mustn't assume that just because he or she has invested a lot of effort in producing a fully detailed plan other people will be thrilled to receive it!