IMHO there's a lot more revising to do. If I've understand your post
correctly, "Customers" should not a sub-project, phase, or summary because
there is no one specific project deliverable created by all of the tasks
that you are putting together under "customers." Indeed, I think it is very
likely that "customers" should not be listed at all in the task heirarchy.
From the top down, tasks, whether they are summaries or work packages,
describe the project's final product at a greater and greater level of
detail. The top level summaries are not time blocks, administrative,
accounting, organizational, or even reporting groupings.
Your "meeting with a & b for specs" should be listed once and only once in
your project plan (unless you have more than one meeting with them of
course). It should be included as a task under the summary that describes
the production of the deliverable that uses those specs and that one meeting
on Tuesday at 3pm should not be listed anywhere else.
In my building example in my reply to John, the final deliverable the
project is intended to produce is a completed home office for our company.
The process of getting there might involve major phases of site acquisition,
laying foundation, erecting frame, installing roof, installing electrical,
installing plumbing, installing HVAC, finish interior, finish exterior,
landscaping, and move-in. These phases would be the top level summary
tasks. Each individual phase has a number of component activities -
foundation may involve dig hole, erect concrete forms, tie rebar, install
embedded piping and ductwork, pour concrete, remove forms. That's the next
level of detail and those tasks may either be individual activities called
"work packages" or summaries themselves that will get broken down farther.
Which they are depends on the nature of the work itself. In "foundation"
we'll probably have one crew tieing rebar and can list that as a single
task. But in "finish interior" we may have 20 rooms to paint and need to
break it out with 20 subtasks of "paint room 1" "paint room 2" ... etc.
Even those may be summary tasks so that "paint room 1" is further broken
down into all the component work packages that have to be performed in order
to produce a completed painted room. But notice - regardless of the level
you're looking at each task or summary ends with the production of a single
specific product, deliverable, or result. The outline structure is driven
by where that output is used. If it is a component of a higher level
deliverable, then the task that produces it is a subtask of the summary that
produces the higher level deliverable. That in turn may be a component of a
still higher level deliverable and so that summary is in turn a sub-task of
the next higher level summary.
I'm using building construction as an example because it's usually easy to
visualize but the notion of the WBS being organized as a hierarchy of
deliverables with the tasks being the packages of work activities that
produce those deliverables applies to all projects regardless of industry or
the nature of the final deliverable.
One trick to help insure that every entry in the task listing, regardless of
the outline level, is appropriate is to begin every entry with an action
verb - lay the foundation, dig the hole, write the module, film scene 3,
etc. If what you have in mind can't be legitimately described as an action
that has a measurable result, it probably shouldn't be included. So as I
suggested, "customers" probably shouldn't be included but on the other hand
"determine customer requirements" might be very appropriate as a summary
task with all of the things you need to do to complete that requirements
document indented as subtasks under it, including the one occurance of the
"meet with A & B to review specs" task we've been talking about.
--
Steve House [MVP]
MS Project Trainer/Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs
Post by Uri L.John, Jack and Steve,
Many thanks for the tips and clarifications. Indeed I'm quite a beginner
in using project, and still need to dig it more to understand its
capabilities and methods :)
Post by Uri L.The "meetings" summary task was in order to facilitate the presentation of
the project, however, I took the advice about re-organizing the tasks
hierarchy , and changed it.
Post by Uri L.Initial Plan
- task 1
- task 2
- meet a&b for specs
Customers
- meet a&b for specs (here it's linked form above)
- research...
- task 3
So now I have 2 parent tasks called "Initial plan" and "Customers" , to
which the sub-task "meet a&b" is logically related.
Post by Uri L.The "meetings" summary was ditched.
Progress-wise, "meet a&b" should be in the "initial plan" summary, as it
follows the other tasks there.
Post by Uri L.Context-wise, I'd like to put a link to it in "Customers", for a full view
of all related tasks.
Post by Uri L."Customers" and "initial plan" are parallel processes (while moving the
initial plan, we are also making some preliminary research for customers).
Post by Uri L.Again, many thanks for the tip. I'm not sure I fully understood it, but
will take the time and tamper with Project a bit to understand values &
fields. Will update how it went :)
Post by Uri L.Thanks again,
Uri
Post by JohnSteve,
I hear what you are saying but I take exception to "meetings" not being
relevant to delivering a product. On the surface, meetings held during
the course of a project are generally thought of as administrative but
there are exceptions and Uri didn't detail what subtasks are under
"meeting" in his plan. For example, a design review (preliminary,
critical, final, etc.) are very relevant to ensuring the designed
product meets it specification and to solicit important feedback on the
approach being taken. Those type of "meetings" are often pivotal to
follow on performance tasks in the plan. Perhaps those are the
"meetings" in Uri's plan.
Don't misunderstand, I am not an advocate of meetings in general
however, let me cite something I read recently when I was researching
exactly what "PWA" is. The article (buried somewhere in the Microsoft
pages) talked about the importance of sharing information amongst all
participants on a project and touts PWA as a excellent tool for doing
that. Whether through PWA or not, I think we all cold agree that
Information sharing is a critical element of good project management.
Gee, at least on one level a PDR or CDR (i.e. meetings) sounds like
sharing information to me.
Just my two cents.
John