Re: [Planner Dev] Re: Objective or Deliverable View

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

Brian Christensen wrote:

> Lincoln,
>
> I am very interested in your ideas for an "Objective View".
>
>     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.
>
>
> Are objectives really the same things as deliverables? I think that you may be right that the report should track and emphasize deliverables, but does that really keep the focus on the project's objectives?


Yes, now that we'd discussed it, it really is a "Deliverable View"
that most people are interested in as these are tangible items and they
are complete when certain (critical to that deliverable) tasks
are complete. "Objectives" are more mission oriented goals and not as
tangible but still trackable but in thinking about this, its probably
just the hard tangible items that I want to record in any first cut
of code....

e.g.
a module of code, a manual, a contract signed, the installation
of machinery on a set date,....

>
>     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.
>
>
> "Bound To" is about as generic as link. Is there a more specific name for what you are trying to describe here? Aren't they more accurately "Deliverable Tasks"? Or is there a better name?


We'd already use "link" when we connect one task to another. Thus I saw
it as too semantically overloaded within Planner. "Bound or Bind" I
felt was a similar but different word. I'm hoping other languages also
have a similar pair of words. Bit like "join" or "tie"; kind of the
same but different.

The deliverable only affects the tasks in that if the deliverable is
changed (a bad thing !) then the selection or tasks usually must
change in scope and be renegotiated.  This is different from
task -> task links where the duration of a predecessor impacts the
successor and where the successor cannot be moved other than within
slack but a change in one tasks usually doesn't affect which tasks
you actually link with. As you'd know, no tasks should be in a project
unless they are working towards a deliverable of some kind, be it
an internal project process or a external one; this is why I think
the Deliverable/objective view would be a cool feature as it would
twist the traditional gantt/task view that many people have of
project plans on its head.

>
>     |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|
>
>
> Am I correct in understanding "%Compl" as being based on the earned value to date for the tasks that are "bound to" the Deliverable? (Completion weighted by anticipated effort?)


Eeek, I don't know about EV to date but I won't forget EV, though in my
initial design I felt we need some easy way of getting a good idea as to
how far this deliverable has come and whats to go. Trouble is that
some summary tasks may say e.g. "Project Documentation" and have 5 manuals
in the set. If we want to focus on just one manual we couldn't
bind to the "Project Documentation" summary but just the specific task
that makes that one manual.

All tasks have a completion value in Planner. In my fist cut I plan to
simply use a work-weighted average of the completion percentages and give
the result. It'll NEVER be prematurely 100% though it may not exactly
track the actual worked percentage complete - it'll err on the low side.

>
> Is the Due Date you have in mind the date when the last "Bound" task is scheduled for completion?


Yes.  Its up to the project manager to pick the right tasks and summaries
to feel when a deliverable is really complete.

The due date is the latest finish date of the tasks they select. It'll
probaly be some sign-off meeting or similar milestone. Its easy to
get an array of dates and pick the latest date.

>
> What do you envision "Work To Go" as being? Is this effort or duration remaining? If duration isn't that just a count of the number of (work?) days until the due date?


Work would be effort (work in Planner) not duration. I think work is
more important as we have the delivery date (last date of the tasks)
but deliverables at risk are those that have e.g. 100 days work due
in 100 days duration. Low risk is 1 day work in 100 days duration.
(Actually I should show the days to go (calendar not workable) to the
due date so manager types don't have to do the maths !).

>
>     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).
>
>
> How important do you think it is to have this mouse linkage to the Tasks? (Mouse clicks from Deliverables to Tasks to Prerequisites) Would the view still have most of its value even if it was a report view without the dynamic navigation links?


I think these links are easy to do in Planner so I was going to
add them. See the Gantt for an example - the Resource names (or short
names if you have those set) are hyperlinks to the resource view).

>
>     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.
>
>
>     The project manager must simply manually choose the best
>     tasks/summaries that indicate that the deliverable is ready.
>
>
> I entirely agree with your insight that the value of this "Objectives View" is entirely dependent on the skill the project manager shows in using it. Is there someway to make it more likely to be effective?


Training, experience and a documented project process in the company
(and it need not be formal) !.

Maybe one way of making it more effective is to maybe have a list
of unbound tasks. After all, every task should be doing something
towards the deliverables (ignore if its summary is bound).

Also if a task is bound to more than 1 deliverable (other than if
its a milestone or summary), then maybe it needs to be broken down
further.

A lot of skill is needed in looking at the deliverables and saying,
to do that we need to do this, this  and this....

I'm hoping that my deliverable view would steer how some people could
use Planner. They start on the deliverable view....

a) Start with the Deliverable view; add the internal project process
deliverables; such as PFS (Project Functional Spec), PRS (Project
Requirements Spec), PP (Project Plan), SDD (System Design Document).
This could be templated.

b) They then add the actual paying customer stuff i.e. why we're doing
this, such as a Contract, a set of Widgets, or a set of packages. This
to could be templated if its a commonly repeated project.

c) They then get the right people (or do it themselves) and break
down each deliverable into the tasks required to produce that
getting the estimates on work, complexity, difficulty and risk for each.
Planner doesn't track complexity, difficulty or risk yet (*).

d) Now the hard part - resourcing ! Based on some internal negotiations
around step c) they get an idea as to who and when and for how much
can work on the project.  c) and d) work together.

e) They then....
    - stick the resources into the resource view,
    - tasks into the task view,
    - assign resources to tasks,
    - link tasks to tasks (fudging the resource levelling with FS links),
    - bind tasks to the deliverables.

f) The first cut of the project schedule/plan (people use different
terms here) is presented to mangagers to sign off. The steps (c),(d),(e)
are refactored based on these meetings/signoffs.

Well thats how I view it from my background in software (both delivered
and failed) projects !.

(*) the complexity, difficulty and risk could easily be added as
custom task properties.



Rgds,
Lincoln.


>
> -- Brian
>
> ----------------------------------------------------------
> http://www.SimpleProjectManagement.com
> (What everyone needs to know about project management.)