In the long run, of course, it's best to always have almost up to the minute accuracy in the project status report. I realize that's nearly impossible - and completely impractical. But what we can do is make sure that the status report - and project schedule - is updated every week and that both contain as much accurate and up to date detail as possible when we walk into that weekly project status meeting with those two things in hand ready to drive the meeting forward.
How do we do that? Well, it's simple, but not always easy. And there are a couple of ways to do it depending on how well your project team members communicate and how much you can trust their accuracy without asking some detailed questions to drill down to a more specific or accurate status update from them.
Option 1 - the revised status report and schedule
This is likely your easiest option - if you can trust your team to actually make status updates or revise their own tasks in a commonly accessed collaborative project scheduling tool. I did this once on a very large government project that contained nearly 8,000 tasks. And to get to the point of that fully detailed, 8,000 task project schedule it took some serious work on the part of me and my staff and the use of mind mapping software with several peer managers on the program to get us there. It was really more like a large program – ongoing for three years – and I required updates by peer managers (who could delegate to their team if they wanted, but they were still responsible for their updates). It worked pretty well – they couldn't all be trusted all the time, but I knew who to regularly follow-up on and who’s input my team had to closely check up on and verify.
If this approach works, great. Just send out an editable copy of last week's status report and have them send back their revisions one day before the weekly status call with the project customer. And do the same with the project schedule - have them make their own task progress updates and get them to you a day before the customer meeting so that you can finalize everything, ask any follow up questions you might have, and then send the revised status report and schedule off to all stakeholders for the weekly status call.
Option 2 - the internal weekly meeting
This is the option that I almost always resort to. I call the other one easier because in a perfect world, if your team does a great job of putting in their updates, you should just have to do a quick check and send it. Sure. Just like my kids don’t take care of the house quite as well as I do because they don’t own it – I do. Yes, the PM owns the schedule, the status report and everything about the project. So, if you want to make sure that you’re sending out the latest and greatest status information right before the weekly status call with that very demanding project customer, then this is the way you’ll likely want to go.
Every week I conduct an internals status meeting/call with my team. Usually it’s the day before the customer call. I use this opportunity to verify where I think everything stands and to go around the table and get updates, issues and concerns from everyone. Then, that evening I make sure that the project status report, the project schedule, the resource forecast, the issues and risks lists, and the budget forecast shows everything as up to date through that day. That’s the best I can do and all anyone can really ask for. And, when speaking in reality, this is the easiest option – at least for me. Again, because no one truly owns it like the project manager and no one cares about it nearly as much.
Our project clients deserve up to date project information. Some are demanding and some are pretty disengaged. But at least when we sit down with them on a weekly basis we should be able to guarantee that the information we are reviewing is 99% accurate to that moment in time. It makes for more productive meetings, increased customer confidence and participation, and far fewer ‘takeaway tasks’ from the project status call than if you walk in with many outdated piece to the project status puzzle.
Brad Egeland is an IT veteran of 27 years having worked as an application developer, manager, project & program manager, consultant and business strategist and is the author of BradEgeland.com