walking-dead-1666584_1280 It was a dark and stormy night, and a lone executive who couldn’t sleep decided he wanted to spend some quality time reviewing the project schedules for a massive IT integration and implementation program.

Normally, we get very excited about a senior manager who wants to spend time reviewing potential issues, risks and problems with our projects; but this manager had just enough understanding of Microsoft Project to be very dangerous.

You see, this organization wasn’t fully in Project Server or Project Online so they were using master projects. In fact, this particular program had one of the most layered levels of master projects I’d ever seen. Let me provide the gruesome details.

At the project manager level, each PM for a given functional area (of which there were six) had his or her own project schedule, enabling them to edit their schedules and giving team leads the ability to support them.

Then each functional area had a functional manager responsible for activities their allocated PMs were working on. That meant for six different areas, we had a master project where the project managers’ projects were inserted and viewed as an overall functional area project schedule.

Those functional managers had one of three directors overseeing their work. Each of those directors also enjoyed the rollup of all of the projects schedules into a master project view of their direct reports.

Finally these three directors reported to a single vice president, who required bi-weekly and monthly detailed reporting on the progress of this massive program. So the directors’ master schedules were embedded into a single master schedule.

So let me recap. To create this final work of art, we had 16 project schedules rolling up to six functional manager master schedules, rolling up to three master-master schedules, rolling up to one single master-master-master schedule or M3.

And it actually worked for real-time visualization, planning and discussions.

But here’s where the horror happened that still wakes me up at night in a cold sweat. The vice president decided to view M3. Typically, this is done with a scheduler or some other person who’s extremely adept at showing the views and reports. Everyone else had already gone home that dark and stormy night, so this vice president decided to handle the viewing on his own.

What happened next later generated mass chaos and a certain amount of howling from every PM in the organization involved with that initiative. You see, that vice president decided not just to view the data but to start moving things around to see if he could accelerate the overall schedule.

After an hour of playing around with it, the VP went to perform and undo and found he couldn’t. So he began trying to recreate what he had originally started from. Eventually, he gave up and simply closed the program. That would have been OK, but because it was late and he was tired, he clicked Save All instead of Cancel.

That meant the changes were saved at the M3 level, on down through to M2 and M1 and eventually at the most basic PM level. Every project schedule was impacted. What ensued in the morning was pure pandemonium as every schedule was moved, changed or shifted out of alignment. It took over a week to recover the work.

The moral of the story: If you’re going to work with master schedules, remember these two very important settings.

The Undo Level: Remember that this Microsoft Office setting default’s to 20. Bump this up to 99 if you want to do what-if planning!

Read Only Mode: When setting up a master project for those who lack experience in Project or just need reporting, don’t just insert a project plan into a master project; make sure you click the Read Only button. To do this:

Click the Project tab and select Subproject.
When you find your file, make sure not to click “Insert”, but use the tiny drop down arrow to choose “Insert Read-Only.”

These two little tricks would have saved so much time and anguish by the project teams.

Previous Post
Next Post

Image Source