Best Practice question

[Bill Cole]

Is more detail or less detail better in a published project?

I am involved in the initial rollout of Project Server / PWA at my
organization. We have used Project Server for years in the scheduling of
projects but had never tracked the progress electronically once the project
started. Of course we want to get buy in from our engineering staff to
apply their hours via PWA weekly and also properly enter the work remaining
so that Project can give us the best possible prediction of when the project
will be complete. This level of detailed project tracking is something new
for our company's culture so the issue of buy-in from the staff is
important.

We have a fairly detailed development schedule consisting of about 200
activities, ranging in duration from 1 day to 2 weeks. This is a
development team of about 9 resources on a development project of about 8
months.

My question is what is the best level of granularity to publish in to
Project Server for the best balance between detailed tracking and user
buy-in on a first project? My initial thought was to publish the detailed
schedule as is and track every single leg, this would give the best possible
results in tracking the project end date. However, some feedback I have
gotten from various members of the team indicate that it may be better to
compromise on this (i.e. not overwhelm users new to PWA), and only
publish/track the schedule to the level of the 'rollup tasks', i.e. maybe 40
major task groupings instead of the whole. These would be easier for users
new to PWA to deal with, especially for a first project.

From a project post-mortem point of view, I am fine with this, I only intend
to compare 'estimated hours' vs. 'actual hours' on a high level feature
basis at the end of the project.
But I am concerned that if we are tracking at a less granular level, that
the project finish date will be less accurate as development goes along, as
it is tougher for people to realize that
a 6 week leg has fallen behind than a 1 week leg.

Any advice from those who have successfully used PWA for tracking projects
and then analyzing the results post-project? What is the best practice
here? As much detail as you can
get, or only track high level tasks?

Thanks,

Bill

 

[Dale Howard [MVP]]

Bill --

I would not recommend that you let team members determine how project
managers plan their projects. It sounds like your current practice of using
work packages lasting 1-2 weeks provides you with sufficient detail to
accurate plan and status your projects. Under these circumstances, if a one
week task finishes 2 days late, you know about the slippage after only 1
week of work. If you let team members force you to combine smaller tasks
such as these into much larger and longer duration tasks, then you will not
know about slippage until much later in the life of the task, at a point
where it may be too late to do anything about it. Therefore, I don't think
you can let your team members decide how you will do this, as this would
amount to "letting the inmates run the asylum!" HA!

Instead, I believe part of your planning for a Project Server implementation
should include "massaging" your current culture to accomodate the new way of
doing things. One client I worked with used the following process for 6
weeks BEFORE they rolled out Project Server:

1. Each week the PM's printed a paper timesheet for each team member
2. Team members wrote their Actual Work values daily in the paper timesheet
for each task on which they worked
3. At the end of the week, team members wrote an estimated amount of
Remaining Work (in hours) for each task on the timesheet
4. The team members mailed their timesheets through inter-office mail back
to their PM at the end of the week
5. Each week the PM's manually typed the numbers from the paper timesheets
into the Microsoft Project plan

During those 6 weeks, you can probably imagine that the team members did
lots of "belly aching" about how hard and time consuming this process was.
Then at the end of the 6 weeks, they trained the team members to enter their
time in PWA. How do you suppose the team members reacted? Their comment
was, "Project Web Access is SO EASY! Why didn't we do this before?" The
net result was nearly 100% compliance with team members doing daily entry of
actuals in PWA and weekly submission of actuals to their PM's. See how they
"massaged" the corporate culture by beginning the hard way (paper
timesheets) and then finshing the easy way (using PWA)?

That's just a small example, but perhaps it will help you. I will invite
others to share their comments as well. Hope this helps.

 

[mark.everett]

Is more detail or less detail better in a published project?

I am involved in the initial rollout of Project Server / PWA at my
organization. We have used Project Server for years in the scheduling of
projects but had never tracked the progress electronically once the project
started. Of course we want to get buy in from our engineering staff to
apply their hours via PWA weekly and also properly enter the work remaining
so that Project can give us the best possible prediction of when the project
will be complete. This level of detailed project tracking is something new
for our company's culture so the issue of buy-in from the staff is
important.

We have a fairly detailed development schedule consisting of about 200
activities, ranging in duration from 1 day to 2 weeks. This is a
development team of about 9 resources on a development project of about 8
months.

My question is what is the best level of granularity to publish in to

Project Server for the best balance between detailed tracking and user
buy-in on a first project? My initial thought was to publish the detailed
schedule as is and track every single leg, this would give the best possible
results in tracking the project end date. However, some feedback I have
gotten from various members of the team indicate that it may be better to
compromise on this (i.e. not overwhelm users new to PWA), and only
publish/track the schedule to the level of the 'rollup tasks', i.e. maybe 40
major task groupings instead of the whole. These would be easier for users
new to PWA to deal with, especially for a first project.

From a project post-mortem point of view, I am fine with this, I only intend
to compare 'estimated hours' vs. 'actual hours' on a high level feature
basis at the end of the project.
But I am concerned that if we are tracking at a less granular level, that
the project finish date will be less accurate as development goes along, as
it is tougher for people to realize that
a 6 week leg has fallen behind than a 1 week leg.

Any advice from those who have successfully used PWA for tracking projects
and then analyzing the results post-project? What is the best practice
here? As much detail as you can
get, or only track high level tasks?

Thanks,

Bill

Bill -

If it isn't your corporate culture to use detailed timesheets - or any
timesheets at all for that matter - then I would agree that a highly
detailed timesheet to collect progress can be intimidating.

Rather than compromising your project management practice, which
appears to be very sound (basically, the 8 / 80 rule seems to be in
effect) you might look at how you collect progress, rather than the
detail level.

So you could start out collecting % Work Complete, with some added
fields (actual start, actual finish). Then, with another major
project, you could go to total hours. Finally, after general
acceptance, hours worked per day.

I have found in the organizations I have worked with on Project Server,
that it's the method of collecting progress rather than the task detail
that impacts user opinion most.

Hope this helps,
Mark S Everett | PMP

 

[Bill Cole]

Dale,

Very interesting answer. Thanks for the input.

Its a very good point that when a new process involves a significant culture
change to an organization, that
some training or as you suggested, 'culture massaging' is in order. In
your example it was a creative idea to
go to a more cumbersome paper method to first collect the info, and then
move to the high tech world of Project Server
where the same information gathering was easy.

Still, a challange for many of us is to get this 'buy in' from our resources
that collecting this info at all is important and
worth the time spent collecting it. Whether the schedule we are tracking is
made up of 1 week chunks or 6 week chunks,
the Project Finish Date that Project calculates is only as good as the
"Percent complete" or "Hours remaining" data that
the resources put in weekly. For many of us who work for small companies
who have had formal schedules for years but
tracked them via written notes in the margins of the printed schedule,
getting team buy-in for the Project Server / PWA
rollout is as big a challenge as any of the technical issues we discuss on
this forum.

Thanks again,

Bill

 

[Bill Cole]

Mark,
Thanks for your input.

In an initial rollout over the last 3 months, and on previous activity
tracking on a paper status report system, I have found that the 'percent
complete' method of estimating progress did not seem to lead to good
results. When I moved to an 'hours remaining' method of estimating the
results were better.

For the rollout of my new project plan on PS, I will be asking resources to
input hours worked and hours remaining on each item. The only question was
level of granularity to
track.

Bill

 

[Rod Gill]

I do a lot of Project Management training and one neat exercise I do is to
get the participants as a group to estimate how many minutes it would take
to walk round a couple of blocks (carefully chosen for having a number of
crossings and other variable time frames). We then walk it and everyone has
to put their watches in their pockets.
Once back at their desks I ask them to guess how many minutes it Actually
took. It has never been less than 20% out and that's 1 minute after
completing the task, with them dedicated to the task (no multi-tasking or
interruptions)!!! So if you get people to enter times to large tasks the
lack of accuracy would negate the value in doing it.

The only way to schedule accurately is to make plenty of predictions (of
work, not duration) then measure the actual work, learn and then improve!!

Team members will only do timesheets accurately if they see value in it. One
such value can be more realistic time frames. Nothing worse than being
forced to try and meet what you know to be too tight a timeframe. If filling
in timesheets provides factual data for negotiating more realistic time
frames next time around, you get some buy in. If they have to attend a
number of quick progress meetings or fill in paper timesheets, then being
able to avoid all that by filling in an easy electronic timesheet will also
get buy-in.

What you reward and or measure is what you get.

 

[Dale Howard [MVP]]

Rod --

I absolutely love your example and your good ideas! Thanks for sharing
them.

 

[John Sitka]

Do an experiment around these three simple rules.
Enter actual work and work remaining upon...
1.)Task completion
2.)Task change
3.)End of shift

 

[Bill Cole]

I agree judging a tasks progress by actual work applied and estimated work
remaining is a good method. I have found that judging progress by
assessing actual work and PERCENT COMPLETE does not work as well. For some
reason people do not give accurate results when asked to estimate "Percent
Complete". When asked to estimate hours or days of work remaining, they
seem to give the best results.

Bill

 

[John Sitka]

Often I see detail levels "morph" as a person becomes part of a reporting process, they get a better
definition of what they actually do. There are benefits from decomposing
a task to it's most basic atomic unit. Sometimes an individual is not even aware that a common
usage task definition is so very far of the mark upon investigation. This comes from familiarity.
The decompossing process often sheds light on the challenges they face to actually accomplish something.
If a task is really maybe a whole logical sequence of serial and parallel activities, using
a set of resources, often the realization is no wonder there is so much stress when trying to
accomplish or manage them. For example they may be reliant on resources that are not even formally recognized
as being required. Sure the common task definition flys around in conversation, but it
becomes non trivial when reinvestigated after a long history of "believed" planning and scheduling
competence. Once the actors are aware of each unit in a task; it can be decided how should they be
bundled or abstracted. That advances the logic planning/schedule model.
From there the next step is to evaluate status tracking timing and responsibility for those updates.
With respect to this timing; of the three rules I mentioned, I can't yet figure out where they would fail.
I hope someone can point out where these rules may be flawed before I elevate them..

JS