I used to be a very scientific and data-centric project manager. I lived by the Microsoft Project plan. I thought a project was all about tasks.
The project plans I managed in those days were full of activities, tasks and subtasks. Estimates were verified and tracked to actuals. I could calculate cost variances, earned value and performance baselines with the best of them.
When it came time to report status I had it all together. At the beginning of each week, I’d print a filtered list of tasks for each team member. At the end of each week, I met with team leads to get updates on all of the tasks that were completed for the week.
With that information, I could prepare my status report to top management. Tasks accomplished were all the tasks the team members finished. I always wanted to make the list as long as possible to show everything that we were accomplishing.
For more information see Stakeholder Management for Project Managers
Tasks planned for the next week was hopefully just as long of a list. I wanted to show management a lot of accomplishments each week.
I don’t know how many executives I completely confused until the time that an executive asked me to stay for a few minutes after one of my status meetings.
He waited until everyone left and asked me about the tasks. He said, “I can kind of see that we’re making progress on the project, but I don’t really know what each of these tasks means. It doesn’t tell me whether we’re making progress.”
I was kind of confused. All he needed to do was go to our shared drive and look at the project plan to see how it all worked together.
For any of you that have reported to executives, you know how ridiculous that last statement was. No executive is going to spend the time to read a project plan. They just don’t deal in that level of detail.
And the fact that they don’t deal with detail is exactly why the tasks I listed didn’t make any sense to him. It was too detailed to be meaningful to him.
He asked if I could put it in some form of graphical form. I went back and figured out a simple bar graph that showed him – and the rest of the executives – what was supposed to be completed to date and what was actually completed.
I also showed it in higher level terms. Rather than the low-level tasks, I showed major activities that were meaningful to the executives.
It was a great lesson for me. It taught me that I was reporting status in my own terms, when I should have been reporting it in the executive’s terms.
I had always heard the term “know your audience” when it came to public speaking, but I didn’t realize it also applied to status reporting as a project manager.
If you would like to learn more about a career in Project Management, get Lew’s book Project Management 101: 101 Tips for Success in Project Management on Amazon.
Please feel free to provide feedback in the comments section below.
Copyright 2014 Lew Sauder, Inc.