Planning & Reports
I like planning - OK, maybe a little bit too much. There’s just something about having a plan, having it structured nicely, and keeping it up-to-date that’s exciting for me. I thought I would share some of the tricks that I’ve picked up on over the years from both having doing it myself, and from having talked to others (especially project managers) about how they approach different scenarios.
First, I think sharing one of the most important lessons I’ve ever learned is pertinent. There is a very big different between being accountable for communication and being accountable for the work. This ties directly into my planning / project mgmt / reporting philosophies.
If you are accountable for work, you are right in there - down & dirty, doing tasks that are associated with a project day in and day out. If you are accountable for communication, you are typically meeting with project managers / team leads regularly to discuss the issues they are having managing to their milestones. But again, this ties directly into some of the things I want to write about in this post.
1. Find Out Your Milestones & Manage To Them
There’s nothing peskier to me, and seemingly something that can easily facilitate micro-management, than NOT doing this. If you don’t know any milestones on a project you are either a) working on or B) responsible for managing and communicating, figure them out as soon as you possibly can.
I would put money on the fact that if you are working with a team to execute a project and it doesn’t have milestones, there is confusion. People are probably doing makework, overlapping work, not sure what else needs to be done (which hinders top performers that like to be proactive) - all of these things directly contribute to project failure.
If you don’t know how to create a milestone, there is a pretty good description on Wikipedia. Check it out.
Make sure once you identify them, everyone on a project, or everyone that’s in your team knows what they are. Then, in your weekly reports up the management food chain, or to your entire team, you can discuss project status to the MILESTONES, not to what Jenny ate for breakfast on the morning of the 21st.
Again, if you are accountable for communication, meet with team leads each week (or day depending on urgency) and then report on their progress in achieving the milestone. It’s the team leads job to manage the detail contributing to the success of a milestone - not the “project director” or “managers.”
2. Create a Simple Plan
If you are accountable for the work, identify everything that needs to be done - and thus, create the “project plan.” You really should be feeling out how complex this needs to be. Typically a fully developer MSFT project plan isn’t required, and while I have tried them, I like to stay away from them when I can. I will typically prefer to use Excel. Yes, some knowledge of how Excel works is important - but that shouldn’t be too hard to obtain. You don’t need complex formulas to create a project plan.
I will typically include columns like Task Summary, Owner, Status (%), Due Date, and Notes. Unless you are getting into hardcore time management, variance tracking, noting things like estimated start dates, actual start dates, cost per task, etc… aren’t probably just overhead. I will sometimes include estimated and actual end dates. This helps during a post-project review to spot any problems that might be cropping up in certain people’s estimating.
The key here is to keep the plan updated. It’s easy to create on, and let it grow out of date. I like to print a copy out at the beginning of the week and mark it up throughout the week and make the updates on a Friday before / during writing a project report.
Remember: simple is key. Oh, and making sure people can actually read them when you print them out. I like really small type - others don’t =)
3. Scorecard
For me, I love using project scorecards. If you have a really large project you are managing, one per project might be required - for many smaller ones, you can get away with having one project scorecard for them all.
In the scorecard, I indicate which projects are green, yellow, and red. I have space to note any issues that have come up and need to be solved after speaking with team leads, or in my own projects. If you are doing resource loading, high-level cost estimates can be indicated here as well. Also, if you are doing EV tracking, you can note differences between estimates to actuals and overall totals.
This scorecard will get attached a regularly weekly report. It helps to show the big whigs where troubles lie, what issues currently exist, and how those issues are being solved. And, what does mgmt care about the most? *cough* the money *cough*. Yes, it does include that as well, as I mentioned.
These aren’t hard & fast rules - just things that I’ve found to work for me as I’ve progress through trying certain things out. Project management is such a key part to being a successful product manager, that by knowing what works for you and in your own scenario, it can help contribute to additional success.
Excelsior!
