Project Management

Please login or join to subscribe to this thread

Done the plan, now the hard bit... getting the job done!

linkedin twitter facebook   Estimating   Work Breakdown Structures (WBS)  
avatar
George Whyte Airdrie, North Lanarkshire, United Kingdom
Nowadays there are so many systems for planning and and execution of
projects it's easy to get into a "system to do all" syndrome. We have used
a number of planning tools for programme, portfolio and project management
and I'd say with certainty we have a good handle on the business priority
projects.

For me this is where the fun begins... how do you get the right job done at
the right time. Working in a large multi-national managing global project
teams (usually 3-6 countries) I face the challenge of ensuring resource is
allocated to tasks and the tasks are executed to deliver what's required on
time and on cost. Our organisation is a "balanced matrix" (PMOBK 2.3.1
Organisational Systems Fig 2.6). It's common place for resource managers to
reprioritise priorities and move resources away from the projects, thus
slippage is inevitable even before we encounter project related constraints
or developmental problems.

We've been considering implementing a time reporting system thereby allowing
task assignment and progress reporting at a resource level. We hope to see
a more focused approach as a result of this detailed feedback to the PM's.
Here's the "ringer"... PM's are already furiously driving the task
management themselves. Does a time reporting system ease the pain?

Say a task has been estimated by the resource to take 40 hours of effort
over 12 working days duration, roughly 3 hours/day. It's possible the
person does not intend to do 3 hours each day, maybe a full day, 8 hours or
4 x 10 hour bashes. Equally, a day into the task may reveal it'll take 60
hours, not 40, or less but usually more. Additionally, percentage complete,
is not proportional to progress made to a deliverable. In my mind it is
better to know someone is working remotely by reporting they are "doing
time" on a task than not, but I'm not sure how much this leads to getting
the result. I'd like to know your thoughts on a reliable approach to task
completion.
Sort By:
avatar
Michael Wood Project Manager / Business Analyst / Business Process Improvement Guru| Independent Contractor Gig Harbor, Wa, United States
I have yet to see tools that allow breaking a task up over time (duration) in unequal chuncks. What you describe is the reality of how work gets done. Most Project Management and Estimating systems fail to allow us to reflect this ... Maybe all.
In a prior position I implemented a time reporting system. Each week the staff reported time against tasks, the remaining hours they estimated it would take to complete each task and the date they expected the task to be completed. The application calculated percent complete based on the time spent to date and the estimated remaining time to complete. The system then generated a revised plan and used color coding to represent the following status -- On plan, Ahead of schedule - behind schedule -- critically behind schedule. Finally, the application produced conflict reports showing where staff were overbooked based on the new data.

This was not an easy process. But it did help in managing and communicating reality.

Wish I had that little tool today.




avatar
Frank Patrick Boonton, Nj, United States
To get work done, you've got to do the work.

It's that simple.

The idea of estimating effort and duration that is as far apart as 40 hours and 12 days for a single task is anathema to effective project performance. If you set up an effective project environment -- one in which resources are allowed/encouraged/expected to focus on the single most important task until complete, then the vagaries that get added by multitasking will be minimized.

On the other hand, you do have to recognize the possibility that Murphy's Law has not yet been repealed. Using a 2-point estimate, let's say 30 hours aggressive and 60 hours safe, is far more useful than a single point 40 hour estimate. With such a pair of estimates, you can develop a buffered critical chain schedule that will reflect both the possible and the possible. Using such a methodology to schedule, and then a simple frequent and regular reporting of estmates to completion allows one to track consumption of buffer, which provides guidance 1) for identification of the "most important task," 2) possible needs for corrective action, and 3) general health of the project promise.

But the behaviors -- relay race behaviors -- are the key to making it happen on time.

avatar
David Kester PMP Bothell, Wa, United States
As Steve McConnell once said "Estimation is a Black Art."

I've had a series of conversations recently with the PM team I work with on this subject and we have lots of cool ideas. But what I continue to find effective is:

1. Define a scoping method that works for the types of projects that your company runs. Currently we are building hardware and software server room systems. This requires factors for Hardware, Firmware, and Software systems. Each is scoped differently and has different factors that effect time frames.
2. Once you agree on the method for scoping the project ask the engineers to create the WBS for the project using the development methods chosen.
3. Once you have the WBS ask the engineers to weight each of the tasks in either "estimated hours" or a percentage of the complete work (you can break this up into several sections if you have a lot of components to develop with different organizational elements owning different components.)

With this percentage of the work or estimate hours you can apply the historical spead by which the team completes projects of this scope and after a couple of weeks of watching progress you know the following:
1. Is the team on track to complete the project on time based on the scope information and progress rates.
2. Is the project team able to work to the WBS and the PBS in a meaningful way.
3. Is the project team building the correct project.

You know these things in the following way.
1. You track progress and hours on each task. This will allow you to access project performance early and often.
2. If new tasks are being added then you know one of two things.
A) The project scope is changing.
B) The project team didn't correctly create the WBS.
3. If the product is being built according to the PBS.

I've found that even in companies with no historical performance data and very little historical record of project performance you can assess the WBS and PBS very early and predict extremely closely when the project will actually be completed.

David Kester


Please login or join to reply

Content ID:
ADVERTISEMENTS

"Life begins at 40, but often so does arthritis and the habit of telling the same story three times to the same person."

- Sam Levenson

ADVERTISEMENT

Sponsors