If you are a TPM, you will spend a lot of time planning and executing projects, so it’s worth thinking through a model so it’s easy to repeat. There’s a lot of advice and frameworks out there for how to plan out a project. Unfortunately, I’ve found that about 90% of them are too complicated for most projects. They tend to overplan every detail, and then when things go wrong, it completely changes the plan. This is fine for something like architecture or construction, where details really do matter. But this isn’t generally great for software development, where a lot of TPMs will spend their time.
Software development by nature is supposed to be flexible. It’s not that hard to change code later – even after shipping a product. Use that as an advantage when planning. Even within software development you will find many different styles. Software comes in many sizes, and some software is more risk tolerant than others. Designing a widget should have a different plan than sending a man to the moon.
The goal of project planning is to do just enough to create peak efficiency in executing the project. Add anything more than that, and you will quickly destroy that efficiency. Planning doesn’t move the ball forward, it only creates an optimal path for the ball. But if you spend too much time optimizing the path, you haven’t gone anywhere. Keep it simple, and strive to find that balance.
Here’s my basic framework for project planning. This is built for software development and generally geared toward small to medium size projects that can be completed in less than a year. Bigger projects may require more steps, but this is a great way to start.
Step 1: Project Goals and Kickoff
Define the goals of the project
This is the what and the why of the project. Why is it important to the company? What problem are you solving? And at a high level, how are you solving it? Are you building a new software or feature? What do you expect the result to be?
Identify the stakeholders.
Understand who is interested in your project. Obviously your boss, but think about anyone else that might be impacted by what you are building. Is this for current customers, new customers?
Identify the core team
The core team is people directly working on the project. Usually we’re talking about engineers, but don’t forget about other support functions like marketing and partnerships if needed. You don’t necessarily need to put names to it yet, but have a rough idea of numbers.
At this point, you should make sure you have approval/agreement from the potential team members and your org leadership to continue. You don’t want to do more work that could be wasted if this doesn’t get the green light.
Step 2: Requirements and Use Case
Now that you have agreement to execute, flush out the project details. Write out as many requirements as you need, but no more. The Product Manager will typically work on use cases and design. The TPM should then create requirements from the use cases to make sure the engineers know what to build. Describe how the system should work, not the technology it should use. Leave the implementation details open to engineers. It’s ok to modify requirements later on, this will just give a baseline to work from.
Step 3: Work Breakdown
Take what you just wrote up and start to break it down into bite size chunks of work. Here’s an easy way to do that:
At the highest level, split up your project into milestones. Think of these as phases of the project. Some ideas not necessarily in order: Planning (this), Research, Implementation, Internal Release, Alpha Release, Beta Release, Launch Date, Testing Complete, User acceptance, etc. These will vary a lot depending on your development style. Example: If you are developing your own product, you will be most interested in the launch date. If you are developing a product for an external customer, you may be more focused on the testing and user acceptance. Choose the milestones that make sense for your project, not based on something you found online.
To make milestones meaningful, you should have at least one deliverable attached to each milestone. A deliverable is some finished piece of the puzzle. Maybe a collection of feature that provides a single use case, or maybe a test run that verifies all the software is running correctly. If you don’t have a deliverable, at least have an important decision made.
Tasks are just a breakdown of the activities you need to get to the deliverables. A lot of people say that tasks should broken down until you can do them in a day or a week. I think breaking down tasks too far risks losing context for the tasks and engineers are bound to misinterpret them or miss out on optimizations. Instead, break down tasks until they are a coherent item that can be worked on. Most of the time it will fit in a few days or weeks. It’s also helpful to link tasks to each other so people know what tasks are dependent on others.
Finally, put together a rough schedule. I say rough because humans are notoriously terrible at estimating how long things take. So rather than pretending the schedule is rock solid, understand it is fluid and update it over time. Start with gathering estimates for low level tasks from engineers and stack them together so you can figure out how long each deliverable will take. Understand what tasks can be done in parallel and which tasks are serial (depend on other tasks). Use this to calculate some dates for your milestones. Remember to leave yourself plenty of margin for when things go wrong. I recommend adding 30% to estimates. Oh, and please don’t use a Gantt Chart. They are needlessly complicated and difficult to update. Good for construction projects, not software engineering.
If things do go wrong (or when they go wrong…) and you burn up your margin, you’ll need to make adjustments. If you can move your milestones, that’s great. If you can’t, you will need to figure out how to adjust resources to meet the milestones or cut out some work.
We now have a solid project plan. We decided on goals, gathered detailed requirements, and put together a plan for how we are going to deliver it. It’s not complicated and will work for 90% of projects out there. It also doesn’t require any fancy apps. You can do all of this in Excel or Sheets. Apps are nice and fun, but don’t get caught up in finding the perfect system. Create the best system you can with the tools you have. Simpler is often better. Time to get to work!