Are You Missing This Critical Piece Of Your Project?
![Missing - by Robert S. Donovan via Flickr [Creative Commons-licensed for commercial use]](http://pmstudent.com/wp-content/uploads/missing-300x201.jpg "missing")
Missing - by Robert S. Donovan via Flickr
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
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.
Aug 5th, 2009 at 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.
Reply
Josh Nankivel Reply:
August 5th, 2009 at 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!
Reply
Josh Nankivel Reply:
August 5th, 2009 at 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.
Reply
Glen B. Alleman Reply:
August 5th, 2009 at 2:15 pm
Josh and Mendelt,
Even in an agile project environment there needs to be some representation of a “Plan.” A collection of statement about where the project is going, how to recognize that the project is moving in that direction, and some kind of visibility into how much work is left to do.
Burn Down, Burn Up, anything that shows total planned work, work accomplished, and work remaining.
In formal environments, the authorization of specific work at specific times is required. Out of order work can be costly. The more informal approaches allow work to be performed in the order determined by the self-managed team. Full DCMA Earned Value does not allow this for all the good reasons of baseline integrity.
But the continuous planning processes must be accounted for. Rolling Wave Planning is standard in Earned Value environments, and has the right “smell” for agile environments as well.
Independent of agile, Planning Packages in the future are still needed. Knowing what “Done” looks like has various resolutions. But “no visibility” into the future cost, schedule, and deliverables is called Level of Effort. The project is over when the money runs out.
Reply
Mendelt Siebenga Reply:
August 6th, 2009 at 5:32 am
@Josh, There are ways to scale agile to large projects too although I don’t have any experience with projects of those sizes myself. I recently heard people claim agile actually scales better than traditional waterfall and they had some decent arguments.
@Glen, I completely agree. I had discussions with lean/kanban people who claimed backlogs should be completely eliminated because it’s work in progress. I think backlogs are important to keep track of the big picture. Having vision statements and architecture overviews etc will help too.
I merely think you shouldn’t go overboard with planning. It’s important to have a complete list of features or user stories. But if you expect requirements to change often you shouldn’t put to much work in complete requirement analyses until you’re ready to implement them.
Reply
Aug 6th, 2009 at 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.
Reply
Josh Nankivel Reply:
August 17th, 2009 at 7: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!
Reply
Aug 17th, 2009 at 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
Reply
Josh Nankivel Reply:
August 17th, 2009 at 7: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!
Reply
Dr. Paul D. Giammalvo Reply:
August 17th, 2009 at 8:00 am
The really scary thing is, Josh, (at least for us Americans) is that the same people that brought you the B1 Bomber, the war in Iraq, GM and other corporate bailouts and the Post Office now want to manage our health care?
What are they? INSANE?
Not to drift too far off track here, to bring this back to project management, the “dirty laundry” of poor practices gets aired quickly- by those contractors who are inefficient going bankrupt. Unfortunately, our government (MOST governments?) don’t think like this, hence having to bail out GM and other companies who cannot manage efficiently. An example of the inefficient saving the incompetent. Where is Darwin when we need him most?
BR,
Dr. PDG, headed to bed in Jakarta
http://www.getpmcertified.com
Reply
Aug 20th, 2009 at 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
Reply