A Trick to Better Project Timelines
How many of you work at a place where project timelines are always spot on? I’ve been in countless meetings where folks expect a project team to break the laws of physics to get things done faster than is humanly possible and then continue to be surprised when milestones slip. They also fail to see how their internal culture is affecting how long it takes to get stuff done.
I have a trick that helps estimate accurate timelines for the non-tech parts of project management. It’s just simple math but something frequently overlooked by the project team when creating timelines.
Meetings, meetings, and more meetings
Every company, product group, cross-functional team, and so on have an operating rhythm that’s specific to them. A cadence that is directly tied to how integral meetings are in their culture. Every company I’ve been at has a very meeting heavy culture. The key is to know how often folks that need to be in meetings have those meetings, how long they take to get on the calendar, and how many meetings you need to approve / make decisions.
In my experience, when I needed a meeting on a plan, proposal, follow-up, or review here’s how far out it was scheduled on average in the different product groups I worked at.
- Windows: 1 week
- Microsoft Japan Entertainment BizDev: 3–4 weeks
- Xbox Live: 24–48 hours
- OnCue & go90: same day
- Google Play: 1–2 weeks
Caveat: There are always exceptions based on priority but this was the cadence I experienced most regularly.
With knowledge work and agile product development, projects are broken down into small enough pieces that it rarely takes somebody longer to complete their tasks than it takes to get a meeting scheduled. This is especially true with globally distributed teams.
So project and program managers could be much more accurate at the start of a project if more time went into estimating how many meetings it was going to take to hit each major milestone. I think this is especially true with the massive shift to work from home with COVID-19 as the number of meetings for many folks have only increased.
For example
Here’s a real world example of writing a proposal for a large process or tool change at a company with a 1–2 week operating rhythm.
- 2 weeks — to draft a 1-pager that describes the change that is being proposed or required
- 1 week — to gather feedback from the project team to be incorporated into the draft prior to review
- 1 week — to revise the draft and schedule a review meeting with extended project team or decision makers
- 1 week — to hold the review and get feedback
- 2 weeks — to incorporate feedback from the review into a second draft
- 1 week — to schedule a second review
- 1 week — to incorporate final feedback into project document and send for approval / green light
- 1 week — to either schedule the approval meeting or obtain through email
So the best case scenario for something that doesn’t take multiple teams, stakeholders, product groups, etc. is 10 weeks from starting a draft to getting approval just begin the actual project. This is also true because just about everyone is juggling multiple projects and responsibilities simultaneously. So over 2 months and the project hasn’t even started yet.
Then add in timing for software development via whatever method your company uses. This helps administrative planning for reviews, documentations, roll-outs, training, and such to be better planned via simply thinking through how many meetings it’s realistically going to take.
Simple math but it works for me
I use this simple math for basically anything that involves a heavy set of meetings. How many meetings will it take to get headcount approved, how many to get partners on board with a plan or a change, how many to launch a new feature, etc. There’s only so many hours in a day and if your group requires meeting to move things along this trick may serve you well.
Feel free to try it out and tweak it to fit.
