Re: [Planner Dev] Planner - Suggestion for Deliverable or Objective view.
- From: Kurt Maute <Kurt Maute us>
- To: Planner Project Manager - Development List <planner-dev lists imendio com>
- Subject: Re: [Planner Dev] Planner - Suggestion for Deliverable or Objective view.
- Date: 09 Jul 2004 20:35:45 -0400
On Fri, 2004-07-09 at 14:49, lincoln phipps openmutual net wrote:
> In larger companies quite a lot is process. This is necessary to
> make software projects "repeatable" (the magic SEI-CMM Level 2
> word here !)
>
> Things happen because they must because thats the process
> needed to make sure whats delivered matches the requirements
> and spec.
>
> So how a Project Manager defines the WBS and how they allocate
> teams of people is more than the actual deliverables.
Agreed, but let me test my understanding. When you're talking about
deliverables, you're referring to only Product deliverables (owed to
your customer), not process deliverables (owed to your management to
support your SEI based project management methodology). They're all
valid deliverables, its just a question of which stakeholder they're
owed to, and what purpose they serve.
So from my perspective, there's two ways to go. One would be to create
a 'deliverable' flag and use it only for product deliverables if that's
what you want to show in your view. The other would be to create two
flags: 'process deliverable' and 'product deliverable' so that your
view could be used to display either success in delivering the product,
or success in following the process, which would help you on your way to
SEI Level 4. Maybe that's a bit much for the average planner user?
> >>I'm thinking a table view,
> >>
> >>|Deliverable | %Compl | Due Date | Work To Go | Bound To | Resources |
> >>+------------+--------+----------+------------+-------------+------------+
> >>| Widget 1 | 15% | 1 October| 15 Days | 1.6.5, 2.5 | RH, LP, ACS|
> >
> >
> > Your 'Bound To' column wouldn't be needed if you buy what I said above,
> > but perhaps would be good to show predecessors here instead?
>
> Well yes but as I want a deliverable to be ready for shipping/payment
> when the "bound to" things are complete I wanted a way of tracking this
> independant of the process of a project. That was my idea. It was to
> give a very quick heads up to anyone as to what and who is on the
> critical path for that deliverable no matterw hat project process was
> being used.
I guess I'm still a bit fuzzy on the whole 'bound to' concept. We
already have two ways to show that a deliverable is not complete until
certain things are done. First is the tasks beneath it, and second is
via predecessors. You could assign FF predecessors to deliverables to
show that certain non-subtasks need to be complete before the
deliverable can be considered complete. Could you give us an example of
where one of these relationships wouldn't suffice?
> > Finally, I've always struggled with a good way to get MSP to show me a
> > concise view of what tasks should be active in the current and next week
> > or so. In other words, I've got to manually scan down my plan for tasks
> > that should have started already or are about to start, and tasks that
> > should have finished already or should be finished soon. This is a
> > special pain with larger plans. I'm not sure if this would need to be a
> > separate view, or a variation of the view you're proposing.
>
> Reporting is a completely different section of Planner that we must
> eventually address. What you are talking about is a bit like my favourite
> MSP report of "Should have Started tasks" !!!!
Yes. Exactly. I'd love to see someone tackle reporting. It'd be a
wonderful feature to get in for 1.0 (or even 0.13).
> What I'd like is that I can, hand on heart, say to my client that we
> are x % complete on this manual and y % complete on this widget and
> this was the idea for the deliverable view.
Sounds excellent!
--
Kurt Maute <Kurt Maute us>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]