Pete Jansson provided these interesting notes on how to make proper
use of MS Project. Fortunately, I don't have to use MS Project much,
but they seem instructive about this class of software.

Begin forwarded message:

> From: Pete Jansson <petej@ieee.org>
> Date: February 5, 2009 3:39:18 PM EST
> To: discuss@lopsa.org
> Subject: Re: [lopsa-discuss] Project prioritization tool?
>
>> On Thu, 5 Feb 2009 12:16:42 -0500 Nicholas Tang <nicholastang@gmail.com
>> > wrote:
>> On Thu, Feb 5, 2009 at 12:11 PM, Luke Hankins <luke@ethersmith.com>
>> wrote:
>>> “Ok, so you want a new stack of machines and that esoteric piece of
>>> software? That'll, let's see… *click* *click*… push project X
>>> out a
>>> day and project Y will slip a week.”
>>>
>>> I want to be able to, at the core, dynamically drag rectangles
>>> representing
>>> tasks around on a set of timelines, one for each resource. Out of
>>> that
>>> comes reports about project end times, etc. (But the more features
>>> you add
>>> (dependencies, half-available resources, wildcard resources,
>>> baselines,
>>> etc.), the more it starts looking like MS Project…)
>>>
>>> I haven't found anything that can do it, unfortunately. I smell a
>>> niche
>>> for a product. Perhaps if enough sysadmins get laid off in the
>>> upcoming
>>> bloodbath, one of us will have the spare time to write it. 🙂
>
> You're doing it wrong.
>
> OK, I keep seeing “but then it would turn into MS Project,” as if
> that's a bad thing. MS Project is actually good at a few things, but
> you have to use it right, and almost everyone I've ever met uses it
> wrong. (This suggests usability problems in MS Project, but that's
> another story.) Here's how to use it right:
>
> The First Rule of MS Project is not to touch start or end dates until
> after the model is fully populated.
>
> The Second Rule of MS Project is not to touch start or end dates until
> after the model is fully populated.
>
> Most people get the First and Second Rules wrong, resulting in MS
> Project trying to be waaaaay to helpful in doing things that you
> really don't care about at this point.
>
> To use MS project, do things in this order:
>
> 1. Create a top-level task. Don't fill in anything about this task
> other than the name.
> 2. Create a list of tasks to do as sub-tasks of that top-level task.
> Pick any way to order them, but stick to only one way for now. Add
> all of the tasks. If your brain works better with outlines, use the
> outlining feature, but try not to over-do it, because outlines and
> dependencies can confuse things.
> 3. Estimate durations for all of the tasks below the level of the
> top-level task and fill them in. Do not fill in an estimated duration
> for the top-level task; MS Project will do that for you. Estimate in
> half-days or so. Don't worry about working days at this point. Again,
> as the model is not yet fully populated, pay attention to the First
> and Second Rules.
>
> An aside about the outlining feature: When you create tasks indented
> below another task, MS Project treats the containing task as a summary
> task. Now that you have a summary task, never fill in anything else
> about it — no estimated duration, no start date, no end date, no
> dependencies, no resources! Also, you've now created implicit
> dependencies of the summary task on its descendants. For the moment,
> keep this in mind.
>
> 4. Fill in dependencies. The default for MS Project is to create
> predecessor dependencies; it's possible to create successor
> dependencies, but I find it usually confuses things, so I recommend
> avoiding it. Also, MS project has a lot of flexibility in creating
> dependencies; the default is that the successor can't start until the
> predecessor finishes, but you can also do “this task starts 3 days
> after that one starts” and others. Also, I mentioned summary tasks
> above; I would recommend not making summary tasks depend on any other
> tasks, because they implicitly depend upon their subtasks. I find it
> easier, at least at the start, to manage the dependencies at the
> detail task level. Once I've got the model fairly stable, it can be
> helpful to convert some tasks to depending upon a summary task instead
> of all of its subtasks, but you can typically also put in a milestone
> task at the end of the summary task and use that. For now, again, I'd
> only create dependencies where detail tasks (e.g., those with no
> subtasks) depend upon other detail tasks.
>
> You didn't start messing with start or end dates yet, did you?
>
> 5. If you are confident of the task durations, this is a good time to
> fill in resources for the tasks. Here's the one problem with MS
> Project: resources need to be specific people, like Adam, Marty or
> Donna, and not pool identifiers like “Junior Admin.” MS Project is
> just not capable of telling you how to assign pooled resources.
>
> 6. If the overall project has a deadline, add it as a “Must finish by”
> constraint on the top-level task.
>
> 7. OK, now you can touch the start and end dates on tasks, but do it
> as little as possible. The more constraints you put on the tasks, the
> more MS Project will try to be clever and solve the problem for you.
>
> If you've built your model this way, you can now take one of the tasks
> and try setting a “Cannot start until” constraint, or change the
> duration, and, if you use one of the detailed GANTT view options,
> Project will actually show you which tasks are now late.
>
> If you've used tasks to represent projects in your portfolio, rather
> than specific tasks, you can use this for exactly the kind of modeling
> Luke wrote about. Again, it still won't tell you how to assign
> resource pools, but working with specific people can go a long way to
> demonstrating to a particular manager that staffing for a particular
> portfolio and constraints is infeasible.
>
> I've used MS Project in this way not only for scheduling, but also for
> doing hotspot analysis on processes (a critical path is a critical
> path, after all), and, when used this way, Project is really a pretty
> spiffy modeling tool with a responsive UI. There is still plenty it
> doesn't do, but I think more of the perceived problems are with how
> people try to use it.
>
> So, stay away from the start and end dates and see if it doesn't start
> making more sense.
>
> Pete.
> _______________________________________________
> Discuss mailing list
> Discuss@lopsa.org
> http://lopsa.org/cgi-bin/mailman/listinfo/discuss
> This list provided by the League of Professional System Administrators
> http://lopsa.org/