This is the fourth article of this series highlighting common incorrect uses of Microsoft Project. The images in these posts are built using the Microsoft Project 2013 Pro edition, but this series can be useful for all versions of the product.  In my last post I talked about the lack of a Work Breakdown Structure, and this post will continue on that path. Please feel free to give your own insight on the subject because it is highly theoretical.

Flaw #1: Date-Related Planning

Flaw #2: Capacity as Activity 

Flaw #3: Lack of Structure (Work Breakdown Structure)

Flaw #4: Too Much Detail in the Schedule

Too much detail in the Schedule will make any project a non-manageable blur. Imagine the following situation where you are the project manager for the construction of a massive new skyscraper.

The case

The Project has 5 main phases, an estimated duration of about 24 months and a team of highly capable people.

Micromanaged project (A schedule with too much detail)

Day 1 Building the WBS. You start with defining the 5 phases, add some tasks to these phases, and describe the phase milestone.

Day 2 Meeting with the team. We are off to a rocky start, the team looked at the schedule draft and it needed more detail: phase 1 (initiation) needs at least 2 new tasks to describe writing the project scope and adding a confirmation milestone. Phase 3 (pre-building phase) needs to be a checklist that the work floor can use to check their daily tasks. Tasks like “first construction drawing”, “check first construction drawing”, “first construction drawing sign-off”, “documenting first construction” are repeated for the second, third and final construction drawing. And there is an eight-task long list describing all actions that need to be taken for the tender bid. A meeting is scheduled to look at the revised version of the project schedule once it is edited.

Day 12 Another setback. Some team members from Phase 3 didn’t show up on the meeting. A new meeting is scheduled.

Day 20 Revising the revised schedule. The team had some changes to the schedule in the Construction Phase. New tasks have been added. The schedule now exceeds 400 rows of tasks. There were some arguments about the definition of “first construction drawing” because this isn’t really a drawing but more a sketch. The duration of 2 weeks is also reduced to 4 days.

Day 30 Kick-off. The board of directors had a nice presentation where they were just shown the top level of the WBS. But it took a whole lot of work to get the tasks in their right order. After the meeting, you get a mail from one of the team members. They want to know when the new revised schedule based on the feedback from the board will be available. They will not work on the project before the board has approved this new schedule.

Day 60 Management approved. I believe you get the picture…

Day 300 Project is half way through phase 1.

Day 1250 Project completed. Much too late, and way over budget. Some team members have made it clear that they don’t want to do a next project with you. A meeting with your supervisor has been scheduled 🙁

Managed project (the way to go)

Day 1 Building the WBS. You start with defining the 5 phases, add some tasks to these phases and describe the phase milestone.

Day 2 Meeting with the team. Right from the bat you make sure the team knows they are the ones that need to make this project a success. You are just the conductor, they are the music. Positive reactions are heard in the meeting room. Now you set the rules of the game, you show them the schedule you made.

• Rule 1: You meet with key players every month. These key players will be “responsible” for the work packages that have been done during last month and will report on progress for the next month.
• Rule 2: When there is something wrong, you need to immediately tell this to one of these key players. They will escalate the problem to you if needed.
• Rule 3: Problems that can be solved within the month and within a limited capital expense don’t need to be escalated to you.
• Rule 4: You control the schedule, they control the work packages.
• Rule 5: Tasks in the schedule are not smaller than 2 weeks. The schedule will not exceed 300 tasks. (exception for the parts on the schedule that are high risk, of course)

Some comments are made on the schedule but they are all within the rules you established.

Day 10: Presentation to board. The board is excited about the schedule, and when asked about specific parts you direct them to one of the key players and they explain their work package. After some mails are exchanged, the board accepts your project and you can start.

Day 20: Official kick-off and first key player meeting. Between day 1 and day 20 you have had multiple small meetings with the key players individually. During the meeting, you make notes about progress and change some high level items in the schedule.

Day 120: The project is well on its way. Your key players know what to do and make minor changes when needed. During the meetings you make important decisions. The total budget is exceeded by 5% so far, due to decisions your team has made to ensure the deadline is met with the desired quality.

Day 500: The project is completed, 20 days behind original schedule. Within 102% of the original budget. You schedule one last meeting with your team, on top of the building you just finished. There is campaign and a lot of laughs. Management has an eye on you. A new, more challenging project is on the horizon, some team members have asked if they can do another project with you.

Key take aways

Where did it go wrong with the first example? There was to much detail in the micromanaged project. No one in the team got to bring their expertise to play, because you were constantly getting in the way. I use the term “Arguing semantics” when people tend to micromanage (perhaps incorrectly but it suits me just fine :)).

Here are some key take-aways to make sure you don’t step into this flawed use of Microsoft Project:

1. If a schedule has a duration that spans years, it isn’t necessary to build a schedule that focuses on days.
2. Know your team, make it a habit to do regular team meetings with key players for the current and upcoming phase. Build your schedule around these meetings! When you meet with your team, make sure you at least have a few things to scratch of your to-do list.
3. Don’t make a meeting a checklist scratchfest: A meeting should be about the important upcoming events, issues that have popped up since the last meeting, and about issues that haven’t been resolved yet.

I hope you liked the post, feel free to share any interesting links in the comments below. Keep your eyes open for my next flaw: Not using the baseline functionality.

This article was originally published on Erik van Hurck’s website, The Project Corner. You can visit his website for more helpful tips.