Loading...
Quick Links

7 Incorrect Ways to Use Microsoft Project: Too Much Detail in the Schedule

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.

Share This Post
8 Comments
  1. Looks a lot like a re-write of my article the seven deadly sins. 🙂 Guess most need all the help they can learning what they fail to see or do correctly

    Reply
  2. Hi Kevin, It’s true that the subject had been re visited alot on the internet. I haven’t read the seven sins yet but will make an effort to read it soon sounds like a set every pm should read, can you share a link?

    Kind regards and thanks for reading and commenting,
    Erik

    Reply
  3. Hi Erik!

    I can’t see a picture under the article’s header.

    Could you please fix or re-post it?

    Reply
  4. the sooner we get behind schedule, the more time we have to make it up

    Reply
  5. Erik I have a few thoughts.

    Day 2 meeting. The detail is critical because everyone on the team needs to know the following: first drawing, check first drawing, rework first drawing (you forgot this), recheck first drawing (you forgot this too), sign-off, document the drawing, review the document (missing step), revise the document (missing step), and finally approval to use the drawing and the document (missing step). Everything that was missing or forgotten (common mistakes) eats up time and cost. The detail also makes it easier for the scheduler to explain who, where, why, and how the work package was improperly planned.

    Day 12 and Day 20. A normal occurrence in a dynamic environment. The duration reduction is most typically due to the missing detail from Day 2.

    Day 30 meeting. Right presentation to the board. The out-of-order tasks are the fault of the scheduler not coordinating with the functional leads for validation in a timely fashion. The email comment about not working on the project has to be adjudicated by the project manager not the scheduler.

    Day 60. All the scheduler can do is document the situation. The amount of time for approval to come is something the scheduler cannot control or manage.

    Day 1250. As the scheduler I document who did what when for how much. Being the bearer of bad news the scheduler gets the blame for being late and overrun. The detail in the schedule is not the main reason for team member dissatisfaction. The angst is more than likely related to managerial pressure to finish and avoiding responsibility for the debacle.

    Key take aways. The perception that the team had high capable people was probably correct within their expertise. The resultant bad performance casts significant doubt on the ability of the highly capable people to perform outside of their expertise.

    As a Master Scheduler, I take grave exception to the comment about constantly being in the way. If the project manager is not controlling how the project is executing then the scheduler has to constantly remind the team of who needs to do what when and how much it is costing.

    Reply
  6. Arthur,

    I agree with you on the “selective detail” on some parts within the schedule. As always you would like to use your own best practice of the organization. As a master scheduler you are probably aware of the best practices here.

    Kind regards,
    Erik

    Reply
  7. As a PM and scheduler, it would be great if all could go according to “Managed Project” option. However, this is sometimes not possible within companies that don’t have key players that could maintain their own schedule.

    If in the case I try to give them bigger blocks of activities, one or two things happen:
    1. they would look back to me to schedule them their tasks- arguing they are not the planners but executioners
    2. they mismanage their tasks and we are now behind schedule

    It’s very hard to find the right amount of granularity to use with the teams, and doubly hard if the schedule has to be shared with the client who wants very detailed status report. However, it’s very hard to actually keep these detailed schedule up-to-date (I had multiple project schedules ranging 3000~3500+ lines).

    Any recommendations for this type of challenge which PMs face all the time?

    Reply
  8. Hi,
    you said that your tasks should not be more than 300 tasks . but I managed multi projects that each of them has more than 500 tasks. what is your suggestion it is overwhelming, and due to the massive numbers of activity sometimes I have some errors in my scheduling. it is hard to keep track of all the activities.

    Reply

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Please complete this equation so we know you’re not a robot. *

Thanks for submitting your comment!
You must be logged in to comment.