However, inevitably the conversations turns to how to use Microsoft Project and how "I tried it once but could not make it work", or "my guys tell me Project can't do [this or that]."
While this gap in knowledge will often provide an opportunity for me to help them, I freely give away some simple rules for making Microsoft Project work:
- Schedule, plan, and estimate deliverables ... not Tasks. Keep "todo's" out of Project. Let people manage the todo's. Let Project compute the cost/schedule.
- Keep the plan in Project as "high level" as possible. There is no "standard" work package size and believe no one who says otherwise. Use judgement and think.
- Focus your brain power on you and your team's energy to define the logical sequence of the project. Get the critical path network as right as possible while at the same time keep it "simple enough". Sometimes yet more complexity is a great thing because probably that complexity is indeed in the project you are about to embark upon and there is no reason to avoid it in your project model. Better to let complexity hit you in the model than let it take you by surprise in real life.
- Put no start/end dates on any task except for the start. Break this rule when in fact the date is a date that will not ever change, e.g. the date and time of a future solar eclipse ... things like that. Project deadlines are never fixed in Project even though the boss or client insists "it must be done!"
- Fix project deadlines in Project in the Deadline field. Let Project alert you when Project forecasts your plan is computing forward as missing future deadlines. [Hint: use the built-in field "Status Indicator".]
- A detail but worth a lot: properly manage the mpp files with respect to versions, backup, etc. Avoid relying on manual methods like email, file shares, etc. wherever possible. Create "one version of the truth", and if not true, make it so.
If this topic interests you, contact me.
Posts
No comments:
Post a Comment