> On Thu, 5 Feb 2009 12:16:42 -0500 Nicholas Tang <[email protected]>
> wrote:
> On Thu, Feb 5, 2009 at 12:11 PM, Luke Hankins <[email protected]> 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
[email protected]
http://lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
