10 Signs You Don't Really Know Microsoft Project
PMConnection gives us 10 Signs You Don't Really Know Microsoft Project:
- You manually create a Project Summary Task
- You "hard code" dates
- You don't input the teams estimated Duration on all tasks
- Your tasks don't start with a verb
- You assign Predecessors to Summary Tasks
- You assign Resources to Summary Tasks
- You never inspect the critical path tasks
- You never search for (or eliminate) Resource Over-Allocations
- You never Baseline your schedule
- You never update your schedule to align with reality
Interesting, but why are these things signs that you don't know MS Project (or any other project-setup tool for that matter)? Here is my perspective on these statements above.
- I think this is a purely mechanical aspect. It's a waste of effort to create an overall summary task, but I don't think it really affects calculations and the end result.
- Hard-coded dates are a definite mistake. At best a project plan is an educated guess of what is going to happen in the project. Activities never take exactly the time allotted to them, and there are those surprises that throw off timing. It's much better to status the project regularly and keep in communication with the team on what activities are active in the current time period.
- Without estimated durations, you cannot even claim to have an educated guess as to the project time line. However, I have used default durations to build templates and to play around with the project network.
- Another mechanical aspect of building project networks, but having tasks that are actions is a nice way to be clear about what is involved.
- Summary tasks are merely visual place holders for users. They shouldn't contain predecessor/successor links or any other data that will end up confusing project calculations.
- As above. Assigning "Bill" to the summary task will not show the proper loading for "Bill" over the time involved in that task.
- Neglecting to inspect the project plan is not a good idea. But neglecting to inspect the "critical path" is a sure way to execution problems. This is the longest path through the network, and mistakes here will derail the project instantly. (I prefer checking the critical chain, but it's the same result.)
- The nice thing about Critical Chain Project Management is that it attempts to
remove resource allocationsresolve resource contentions in the identification of the critical chain. And then execution of the project uses buffers to manage situations where resources become over-allocated due to the natural task variations during execution. [Corrected on 2 Feb 2012, thanks to a reader comment.] - The baseline helps compare what you thought would happen to what is really happening during execution. I prefer monitoring the buffers provided by CCPM software.
- Good execution of projects requires that you update the activities in the project with what is happening. Otherwise, the educated guess you had at the start of the project becomes a pretty picture for your cubicle with little connection to reality. CCPM execution of projects cannot work without regular "how much time remaining" updates on open tasks.
What about some other signs? One of my favorites is signs that you don't know how to execute a project (holding people to the dates in the original plan, forced-multitasking, assuming local success creates overall success).
11 Comment(s)
Projjex.com is a great new site that does a fabulous job of collaboration. It's completely browser-based, really easy to use, and has a free version. Cool videos too - I love it!
On #1, the reason it is a waste of time to create a project summary task is that it already exists, but is not visible by default.
To make it visible in Project Pro 2007, go to Tools, Options, View tab, and check the "Show Project summary task" box in the lower right hand corner.
You will now have a Task ID 0 that displays the project name, project start and finish dates, rolls up total duration, project completion %, etc.
The Project Summary info is the same info that will show in Project Center on Project Web Access 2007.
Your reasoning for #6 does not convince me. What if I have a summary task that I would like to break down further for the purposes of displaying the steps involved in the task, but I need Bob to work on it at 50% through it's entire duration. Whay not assign him to the summary task?
Perhaps breaking it down was a good way to ensure that there was common understanding of the task.
Maybe one of the sub tasks was a predesessor to another task in the project, but none of the sub tasks were dependent on another task in the project.
Please explain. I'm not convinced. I've seen so many places that say it's best proctice, but why?
Scott, The problem is that Summary tasks change as the underlying tasks change. So, if you add a 10-day task for Joan in the sequence under the summary, then it looks like Bob is engaged for another 10-days, when that is not the case. There are frequently parallel chains running through a group of tasks. Thus, while Bob is busy on one chain, Joan and Fred might be busy on other chains. And if you discover more work on one of those chains?
I agree with all but #4. On many of my projects we do not start with a verb but contain a verb. Even this practice has gone to the way side. Many in the profession schedule verbs and nouns for simplicity.
For example:
Produce Information Assurance Letter
or
Information Assurance Letter
Sometimes it is best to let the Summary task do the talking.
Produce IA Letters
City of NY IA Letter
City of Boston IA Letter....
Rob
Thanks for taking the time to write this post. Very informative!
Am guilty as charged for about 9 out of 10 of these ; P
Buuuuuuut... Isn't it a little fiddly to try to enter system logic when you have agreed on specific dates for certain tasks? You have to start fiddling with lags etc.
Thanks Laure-Anne. This is a very common problem in planning: setting dates before the plan is really established. I recommend that people DO NOT agree on specific dates for any tasks, ever. Work needs to get done to reach the goal of the project, but the specific timing depends on all sorts of interactions that are bound to be early and late. Sure, people know approximately when things will start, but the team should be asking people to move things along as quickly as possible, not to finish their task by a given date.
said:
I agree with 9 of the 10 but not with #5.
There are times where a summary task represents a group that cannot start prior to a specific event. I will use Milestones, as an example, in a project where there may be versions of a delivery and the next version cannot start prior to the milestone. A milestone could also reflect a starting point for multiple summary tasks so placing it within the summary is not an option either.
"The nice thing about Critical Chain Project Management is that it attempts to remove resource allocations in the identification of the critical chain"
Can you please elaborate on this one? I've always thought critical chain (unlike critical path) does account for the fact that parallelization cannot be performed on tasks that require the same resource...
That's embarrassing. It should read "resolve" not "remove." I'll fix the text.
Leave a comment
Previous entry: Matt Moore interview video
Next entry: The KM jobs are out there
Syndication Options
KJolt Memberships
Great Post. Thanks for the info.
Love & Gratitude,
Tina
Think Simple. Be Decisive.
~ Productivity, Motivation & Happiness