Gov't Grant Project?

[maarkr]

Curious and may be too much for this forum...

Does anyone have experience in working on a Gov't Grant in
Project?

I have 4 distinct phases to our 12 different projects
(initiatives)...Assessment, Planning, Implementation, and
Evaluation, with multiple tasks for each.

A sample Assessment phase task is "Assess ... using a
survey tool" and "Compile an inventory of..."
A sample Planning phase task is "Plan for ... capability"
and "Create a purchasing plan..." Ditto for the other
phases.

Someone kindly advised me earlier not to link the phases
(thanks), but I was curious about other advice on setting
up the project.

Should I use different files for each project initiative?
There are 12 initiatives. Right now I have about 50 tasks
per initiative, and I put each initiative in a file to
manage it better (I tried putting them all in one file but
it became a mess quickly). I expect more subtasks will be
added to each project, making up to maybe 300-400 tasks
per initiative.

Should I separate phases using a SNET constraint?
Since many tasks are subtasks under the Phase and each
phase lasts for months, I started the Assessment phase at
the project start date and roughed the tasks in for 4
month length; the Planning Phase starts 3 months after the
project start and tasks are roughed in for 4 months; other
tasks in the phases similarly start in the same manner...

Should I use Fixed Unit, Not Effort Driven, No Calendar
for all tasks? Any other settings to recommend?
I'm not tracking resources; primarily just trying to track
the hundreds of tasks going on, assigning deadlines,
milestones, tracking documents supporting each task,
setting priorities, and trying to finish by the grant
timeline.

I'm just learning Project, I bought a big old Que book and
just want to set this up right.

Thanks to all you folks who suppport this fourm!

 

[Jason-W]

I haven't worked on any Gov't Grant Projects, but based on
the information you provided here is my advice:
initiative? There are 12 initiatives. <<
I assume that all the initiatives are going to have the
same (or at least similarly) tasks. I'd create a template
first, and then setup one Project file (based on the
template) for each initiative. So if there are 12
initiatives, you'll ultimately have 12 Project files & a
template you can use later date if you have more Grant
Projects. You can always add/remove items from each
project as required. Additionally, you can also make a
Master project by inserting the 12 initiative projects if
you needed look at everything together.
The general rule is to never put constraints on tasks,
since they make projects less flexible. Have you
considered adding lead/lag time to task dependencies? You
may be able to run a Finish-to-Start dependency from an
Assessment Phase subtask to a Planning phase subtask &
then put a -1 month lead time on it (so the Planning
subtask starts 1 month before the Assessment task
finishes). Example: It is like having a construction
project, where one phase is to put up a wall and then the
next phase to paint it. If I were to schedule this, I'd
make a FS dependency from 'put up wall' to 'paint wall',
but then put in a lead time. Ultimately, the
dependencies/constraints you put into the project should
model how you expect them to flow in real life.

IMO, After your initial estimate (remember to save a
baseline!), adding constraints to your project is not
always a bad thing. Like if you have to submit a document
for approval as scheduled, but the approval agency tells
you they won't get it back until, say October 23 (later
than scheduled). I see no reason not to just set a FNET
constraint to October 23 for the 'document approved and
returned' task.

for all tasks?<<
IIRC, since you aren't using resources, it doesn't really
matter which task type you use.

Leaving the calendar to "none" will make the task use the
project calendar (under Project->Project Information),
which is the "Standard" one by default. So unless you
plan on using multiple calendars for different tasks, just
leave it to "none".

HTH,
Jason

 

[Steve House]

Some experts suggest never to link summary tasks while others are ok with
it. I feel it depends on the nature of the project and the summaries. The
recommendation that one link from the last subtask in the first summary to
the first subtask in the 2nd summary certainly can work well, *but* it
presumes one specific task is known with certainty to be the "last task" in
the summary that truly defines its end and that it will not ever change as
the project develops. Certainly that's true with some sorts of activities
but it may not be true with others. If there are several chains of subtasks
in your Assessment phase running in parallel, there is no single task
engraved in granite that is certain to be the "last one" that marks the end
of the summary. You would then need to include a milestone as the last
subtask in the summary with all the chains converging on it, then link from
that milestone to the first activity in your planning phase or have links
from the end of each chain in the summary into the first task in the next
phase. That to me seems the equivalent of simply linking the two summary
tasks FS to begin with. In fact the default behaviour in MSP if one has a
series of summary tasks with subtasks under them, select all the tasks, and
hit the link button on the toolbar, is to link all the tasks at a given
level FS.

I would keep on with all the initiatives in their own individual project
file. If they share a common body of resources use a resource pool file
that connects to each project to provide the required resource (see resource
sharing in help). When you have such an arrangement and you open the
resource pool file, Project offers to build a consolidation file for you
that shows the overall big picture.

IMHO, setting the length of the phases in advance is putting the cart before
the horse. They'll take however long it will take to complete the required
work, no more and no less,and that time is determined solely by the nature
and amount of the work itself, not a preconceived notion of how long it
*should* take or how much time we want to allow for it. Estimate the length
of time each subordinate activity will require, sequence them, assign and
level resources, and Project will inform *you* how long the phases *will*
last - how long you THINK they should last is irrelevant.

I am not a big fan of SNET constraints to drive tasks to desired dates.
IMHO, a constraint is appropriate when it helps you model physical reality.
A required component won't be delivered by a vendor until a certain date,
for example, so a SNET constraint on the task that uses that part makes sure
it won't be scheduled to start before the part is in hand. But the
consequence of using a SNET in the manner you're thinking is that the
Planning will then never be scheduled earlier than the constraint date, even
if evolving circumstances - Assessment takes less time than you first
thought it would, for example - are such that it actually could or should
be.

Suppose the Assessment Phase is expected to be 4 months start July 1.
You've said that you want to start the planning phase 3 months later and
you're tempted to use a SNET constraint to set it so. But what exactly is
it that sets this magical date as the date planning should start? Surely
it's not just arbitrary - there must be something in the work done during
Assessment that says "we now know enough to begin planning" and you're
estimating it will happen 3 months into Assessment. You can handle this
better than SNET by choosing whichever one of these strategies it is that
best models your reality:

1: There is a certain piece of work in the Assessment phase that produces a
deliverable that is crucial to Planning and so the Planning phase can
commence when this deliverable is ready. Model this by FS linking from the
task producing that output over to the entry task in the Planning phase.

2: You estimate that we will have amassed enough data 3 months into
Assessment to begin Planning, regardless of how long it really takes from
that point on to finish the rest of the Assessment phase. Link Assessment
to Planning (or if you prefer the entry task in Assessment to the entry task
in Planning) Start-to-Start and add a 3 month lag time to the link.

3: You estimate we will have enough data to start Planning when we are 75%
done with the Assessment phase. Link Assessment to Planning FS with a 25%
lead time, entered as a -25% lag time, to shift the Planning to start when
there's 25% of the Assessment left to do. If Assessement's start date or
duration changes, the date of the 75% point also changes and Planning will
move forward or backward in response.

Hope this helps

 

[davegb]

"Steve House" wrote ...

Some experts suggest never to link summary tasks while others are ok with
it. I feel it depends on the nature of the project and the summaries. The
recommendation that one link from the last subtask in the first summary to
the first subtask in the 2nd summary certainly can work well, *but* it
presumes one specific task is known with certainty to be the "last task" in
the summary that truly defines its end and that it will not ever change as
the project develops. Certainly that's true with some sorts of activities
but it may not be true with others. If there are several chains of subtasks
in your Assessment phase running in parallel, there is no single task
engraved in granite that is certain to be the "last one" that marks the end
of the summary. You would then need to include a milestone as the last
subtask in the summary with all the chains converging on it, then link from
that milestone to the first activity in your planning phase or have links
from the end of each chain in the summary into the first task in the next
phase. That to me seems the equivalent of simply linking the two summary
tasks FS to begin with. In fact the default behaviour in MSP if one has a
series of summary tasks with subtasks under them, select all the tasks, and
hit the link button on the toolbar, is to link all the tasks at a given
level FS.

I'd like to respectfully disagree with Steve on this. I am strongly
against linking summary tasks. In over 20 years of scheduling, this
always seems to lead to problems, at least in real projects of real
complexity. Actually, when I started consulting, I was pretty hard
core about this, then softened for a while and tried it with some of
my clients. I'm hardcore again. I'll try to explain why I believe
this, but it's one of those things that's hard to describe, mostly
based on empircal evidence. Experience.
Why doesn't linking summary tasks work? For several reasons. If you
think about it for a minute, a summary task only exists on paper, it's
a theoretical sum of a group of working tasks, tasks that someone is
actually doing. It's only function is to represent the totality of
those tasks. It can't have a relationship with other tasks because
it's not "real".
On a more practical basis, working tasks must be dependent on other
working tasks. If the summary weren't there, they'd still be dependent
on each other. Also, linking summary tasks lead to problems with
circular or impossible linking. Further, it tends to lazy scheduling -
just link the summaries and don't think through the task
relationships. But it's the working task relationships that are
ultimately going to determine which task can be done next and which
have to wait for a deliverable from another working task.
One of the arguments for linking summary tasks is that sometimes, you
may not be sure of which task is the first or last in that phase,
which is sometimes true. Of course, the solution is to link all of the
tasks that might be last in a phase to the first task in the next
phase, or, as Steve suggests, link them to a Phase Completion
milestone and link that to the first task in the next phase. Of
course, this same methodology can be used in reverse if you're
uncertain of the first task in a phase.
Another reason to link only working tasks is Schedule Continuity. When
a schedule is complete, every task should have at least one
predecessor and at least one successor, except for the start and
finish milestones. If all tasks are properly linked, there's no need
to link summary tasks.
I want to be clear here that I appreciate Steve's contributions in
this forum, and that I do not intend to in any way diminish that. I
just disagree with him on this point and look forward to his or
other's replies in this or any thread.

David G. Bellamy
Bellamy Consulting

 

[Steve House]

Your points are well taken, Dave, and in general I'd agree with them. When
I think of linking summary tasks I usually am thinking of high-level
summaries that represent major phases of a larger plan, broad enough almost
to represent essentially independent subprojects in their own rights. The
example I often use in class, for example, is filming a movie with the top
level summaries being pre-production, shooting, and post-production. Each
phase is an integrated whole, a project in itself. We know we have to
complete pre-production before we can shoot and we must complete shooting
before we can go to post but in the early planning stage we have no idea
which of many possible tasks will mark the end of pre-production and not a
clue which scene will be the first up in the shooting schedule since scenes
are *never* filmed in the order they appear in the script. After we
complete all the pre-production we might even have a milestone that marks a
go/nogo decision point that determines whether or not we even go to shooting
or kill the project right there. Rather than have a dozens of
criss-crossing links flowing from the various chain endpoints in
pre-production into the starts of each of all the scenes in shooting. not
knowing which is first to shoot at this stage, it seems clearer to me to
simply link pre->go/nogo->shooting->post.

 

[davegb]

Steve,
I appreciate your comments. Since I know less than zero about making
movies, you're probably right. OTH, if it were up to me, I'd just like
the final task in each phase to the first task in the next. Seems to
me that, from stories I've heard in interviews, that many movies have
started filming without a finished script (i.e., Casablanca, a best
picture Oscar winner!) And I would find it hard to believe that no one
has very started cutting and editing before filming was done.
Hollywood has deadlines too!
In the final analysis, we do what works for us. If it works for you,
do it. For me, it seems to eventually get me in trouble. We probably
have to agree to disagree on this one! If we get the chance, would
love to buy you a beer and argue with your for hours! I'm from the
east coast, love to argue, don't think a thing about it afterward. My
sister-in-law cringes when my brother and I go at it, leaves the room
to avoid seeing bloodshed, then is amazed when she comes back five
minutes later and we're laughing uproariously about something else
entirely. Water off a duck's back.
I think it benefits everyone who reads the NG to see differing POV.
Let's give them our differing opinions and let them decide what's best
for them.
BTW, what kind of beer do you drink?

David G. Bellamy
Bellamy Consulting

 

[Steve House]

You got it! Would love to down a couple and discuss PM principles. Don't
have a single fave but generally go for strong beers like Crest, Maudite, or
La Fin du Monde.