by Josh

Missing - by Robert S. Donovan via Flickr [Creative Commons-licensed for commercial use]

Missing - by Robert S. Donovan via Flickr

There is one specific item I would like to address today.  Then, I’d like to hear your examples in the comments.

This is something I have forgotten about when planning projects in the past, and I see other project managers overlook it.  It’s obvious when you point it out, but that’s as long as you are not in the pit with the alligators.

Monitor & Control Work Appropriately

I was once in a situation where the scope of my project was constantly changing.  This happens on all projects of course, at least those of any size and complexity.  It’s a natural process.  This one was particularly bad.

One day, I asked myself how much time had been spent in replanning activities.  How much time had the other project managers spent?  The project controllers?   Myself?  What is all this re-planning costing us in terms of schedule, dollars, and quality?

Then the obvious hit me.  The project team had also been impacted of course.  They had to sit down and re-estimate tasks, consider impacts of the changes, etc.  Every step of the way.  Where was this tracked?

Nowhere.

Yikes!

Project Planning - by Iain Farrell via Flickr

Project Planning - by Iain Farrell via Flickr

Nowhere?

This goes back to a common mistake when constructing a WBS and defining the scope of your project.  Sure, you have a “project management” element at level 2 in your WBS.  Do your engineers charge there when their attention is diverted away from getting things done and instead goes towards project management related activities?

After all, the time they spend re-planning with you is deducted from the time they would otherwise have been doing design work, writing code, or whatever their real job on your project is.  If they record that time appropriately, you can use it.  If they just charge it as normal work, it’s a lost opportunity.

But Why Track It Anyway?

I’m not advocating you track this for the sake of it.  Only track what makes sense.  This gives some benefits you may want to consider:

  • It helps you know what the impact of re-planning is to your project.  By not hiding this diverted work alongside the real work, you can know the impact to schedule, budget, and quality.
  • It helps you manage your stakeholders. Solid data about past impacts to project work resulting from massive scope changes can help ensure change requests are submitted and approved only when the value outweighs the costs.
  • It helps with better estimates in the future. By really knowing what it takes for you and your team to respond to scope changes, you can now include the estimated impacts of this inevitable project activity, instead of missing deadlines or going over budget because you failed  to factor change into your project planning.

Leave a comment right now.  Share one of your experiences with the community.

11 Comments

Mendelt SiebengaAugust 5, 2009 7:11 am

I’m familliar with this problem. But I don’t think you’re going in the right direction with more tracking. When pm’s say “I’m want to track x” that invariably means “the team should track x”. More distractions for the team, more work lost.

If you’re team is spending a significant amount of time reworking requirements and estimates that are far in the future you’re probably better off with a more agile approach. Let your team work on what’s important now and keep your backlog lean. That way reworking requirements and estimates will only cost minimal time.

Josh Nankivel August 05 2009 12:46 pm

I know exactly what you are saying. That's why I stressed "only track what makes sense". Only if it adds value should it be tracked.

In my project environment, this would not add much if any overhead to the team. That's because this type of work is so different from their normal activities, and has a clear start/stop time. For instance, in most cases it would be something like 1-2 hours for a planning session on a given day. They'd just put those hours into a separate code; their normal work goes under their normal code.

Most people on that project had 1 charge code, some had 2 or 3. When I first arrived, some people had 10 charge codes. I did everything I could to protect them from having to do much tracking of anything that would get in the way of their work.

It's a highly valid point though, and thanks for the comment!

Josh Nankivel August 05 2009 12:49 pm

On the point about agile, we are using that on some elements, but we're talking about a project with 200+ people here. Cross-contracts. For a federal agency. I've used agile methods on small projects before. I wish we could use them to a greater extent on this one.

Bill DuncanAugust 6, 2009 4:49 am

I would go a step beyond just “tracking” and recommend that you BUDGET for this activity as well. I’ve been doing (and teaching) this for years.

Josh Nankivel August 17 2009 07:44 am

I absolutely agree Bill. I didn't get into budgeting in this piece, but part of where the budget is derived comes directly from the estimates.

What I'm getting at is uncovering any and all assumed scope that doesn't show up properly in your project planning (WBS, estimates, budget, etc.)

Thanks for the insight!

Dr. Paul D. GiammalvoAugust 17, 2009 6:52 am

I’m with Bill on this one. As a contractor, I have to build in the costs for all the overhead activities as I prepare my bid, otherwise anything I miss comes out of the profit margin. One of those activities is project monitoring and control.

One of my frustrations with the government sector (and some large owner organizations as well) is because they have no profit motive, it allows or enables them to be sloppy with the estimates, and then they attempt to manage at a relatively high level, while we know that “the devil” lies in the details.

We consult from time to time with a major US based automaker, who just got out of bankruptcy and one of our suggestions back in early 2000 was to turn all their functional departments from cost centers into PROFIT centers.

They did it on a pilot basis and when they found out it was more cost effective to outsource than it was to keep their functional departments…. No, they did not do away with the functional departments- the stopped the pilot analysis……!!!

It appears that many of our government funded programs operate in much the same way….. The primary objective is job preservation and not in generating shareholder (or taxpayer) added value….

BR,
Dr. PDG, back in Jakarta
http://www.getpmcertified.com

Josh Nankivel August 17 2009 07:49 am

This is a great point Dr. Paul. My experience with this lies primarily in the way a specific federal agency works, and seeing it within private firms for internal projects.

I think you hit the nail on the head. When you are making your money from projects and have a profit incentive tied specifically to how well you run your projects, "dirty laundry" in the form of poor practices are aired quickly.

Thank you too Dr. Paul for the insight!

Dr. Paul D. GiammalvoAugust 20, 2009 8:37 am

Another perspective through the eyes of the contractor. If you even HOPE to be able to get paid for the changes, you need to document the hell out of them. Even when there is no question on either side that the change order was a legitimate one, I have yet to see the owner who didn’t try to negotiate the actual cost down, even if it had been agreed to in advance.

The story an old timer told me has always stuck with me. The reason that you pay a prostitute in advance is the value of her services diminishes significantly after she has rendered them, and remains so… Until you need her services again……..

So the wise contractor gets the owners agreement up front BEFORE the work starts otherwise risks a testy battle to get paid after the work is done…

Good night from Jakarta….

BR,
Dr. PDG, Jakarta
http://www.getpmcertified.com

Leave A Comment

Posting your comment...

Subscribe to these comment via email
blog comments powered by Disqus
http://pmstudent.com/wp-content/themes/selecta