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

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

Kurt Maute wrote:

> Hi Lincoln, 
>
> You've got some excellent ideas.  I'll throw in my 2 cents...
>
> On Fri, 2004-07-09 at 05:07, lincoln phipps openmutual net wrote:
>
> > What I'm envisaging is that this "Objective View" would also be
> > the default view for Planner and that project managers input the
> > project objectives /deliverables and then focus on tasks and resources
> > for each of these deliverables in turn. You would set an
> > association (I'll call it a binding) from 1 or a set of tasks
> > (and thus implicitly the assigned resources) to each deliverable.
>
>
> Wouldn't your project hierarchy take care of the associations?  In other
> words, your WBS defines your project deliverables and the tasks
> supporting those deliverables should be nested beneath them:


Not really. I think thats the problem with MSP and thus also
Planner is that we sort of create summary tasks and milestones to
represent deliverables.

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.
> Site Move (Project)
> 1 New Data Center (Deliverable)
> 1.1  WAN Connectivity (Deliverable)
> 1.1.1    Task A
> 1.1.2    Task B
> 1.1.3    Task C
> 1.2  UPS (Deliverable)
> 1.2.1    Task D
> 1.2.2    Task E
> etc...
>
> The trick, it seems to me, is to let Planner know which are the
> deliverables, and which are the tasks so that it can do an effective job
> of rolling up for the Objective View.

Thats why I think my view should be quite easy to program because
it kind of is doing that but its deliverable-centric.  You have
a list of deliverables and they are bound to specific
summary or tasks (ideally summary tasks IMHO).

A lot of the process stuff may not even be bound to a
deliverable but is just part of the process of a company; that'll vary
from company to company.

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

> A variation on the Gantt would be helpful as well to graphically show
> progress against the plan ("Progress Gantt"?).  In my experience, its
> often easier to communicate with pictures and graphs - at least when
> making presentations that is.

I think we'll look at baseline variations when we start on my
snapshot idea,
http://bugzilla.gnome.org/show_bug.cgi?id=140676

> Perhaps the view could be collapsed by default, but allow drilldown to
> the task level to see what may be falling behind schedule?

as above... http://bugzilla.gnome.org/show_bug.cgi?id=140676
would look at giving deviation from planned.
> 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"  !!!!

My deliverabe view is an idea related to outputs from a project and
not the internal operations of a project. Reporting as to what tasks
need to be worked on this week or started is another matter which Planner
should seriously address.

> Thoughts?

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.  As to how closely
the actual deliverable was bound to the project depended upon
what bound tasks you added. That is up to the project managers skill
to chooset he critical tasks to bind to a deliverable that correctly
summarise when that artifact is ready.

Rgds,
Lincoln.