Re: [Planner Dev] Planner - Suggestion for Deliverable or Objective view.

["lincoln phipps openmutual net" <lincoln phipps openmutual net>]

Kurt Maute wrote:

> 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.


My main concern was initially the paying customers as opposed to
internal process deliverables but this is easily solved.

A while back in one of the planner-dev emails I wanted to create
a "role". This would thus allow organisation to be represented in
planner. Currently resources in planner have one of two types,
worker or material but no named role.

I've just raised the bugzilla on this before I forget,

http://bugzilla.gnome.org/show_bug.cgi?id=147249

It doesn't have deliverable on it but I envisage something like,

Deliverable -> is -> Artifact type
Deliverable -> bound to-> Tasks
Deliverable -> has -> Human -> has -> Role

where the role would be picked from a list and would be
such things as "Stakeholder" or "Client" or similar words and
then the actual human client could be picked after that filter.
See later for artifact.


> 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?

You're probaly right in that the deliverable table should have a
flag to describe what type of artifact it is. I think that
if we had an artifact type table which was populated with,
"Customer Deliverable" and "Process Deliverable" then we'd be
right.

As for complexity .... It won't be !. As with all of this, if
no one uses the role tables or even bothers to add in the deliverables
but just uses Planner from the gantt then its never noticed. For
that matter you can use planner by just adding tasks and not even
bothering with resources. I'd only got to SEI-CMM Level 3 but it
got easier as you went on anyway.

So I feel that though what we're discussing now may seem out of
place for a 1-person project with clear deliverables we'll never
stop people from using planner for those types of projects i.e. we
won't force people to define roles or deliverables.

> > > > 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?

I didn't want the deliverables to have relations but to inherit those
relations from the bound-to tasks by binding to summary tasks. This
is what glues whats delivered to the project.

In my example above, 1.6 could be a Summary of "Unit Testing" and 1.6.5
could be for example "Unit Tests for Widget 1" and e.g. 2.5 could
be "Integration Test Signoff" or similar so the idea was that to deliver
"Widget 1" it had to be tested in its own right and it had to be tested
with other things. This'll be the skill of the project manager to work
out when something is ready to be released and what really indicates
its progress. To see predecessors (which could be quite complex paths),
you'd mouse-over the bound to tasks and then right-mouse and select
Predecessors (this'll simply launch the Task Edit dialog with the focus
set to the Predecessor tab).


> > 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?


As in my example above I felt it was not right to add relationships to
the bound to tasks. This is why I'm using the word "Bound" as opposed to
"Link".

The project manager must simply manually choose the best tasks/summaries
that indicate that the deliverable is ready. In my example table above
I have a task and a summary. By choosing a summary you automatically
inherit the relations of the tasks within that summary. That solves the
issue of relationships.

> > > 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).

Reporting would be a nice tranch of work. We should probably look at
whats already available as opposed to reinventing the wheel. Maybe
within the GNOME work there is a nice "Crystal Reports" style engine
we can hook into.

> > 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!