It will come to the point in every Individual Contributor’s life that they’ll be asked to lead or assist in the planning of a project. How and when this comes will depend on a lot on the company and your specific career trajectory, but sooner or later, the request comes for us all.
It starts out so innocently. “Can you give a t-shirt size estimate of how long this ask will take?” “What dependencies do you see for this task?” “Can you do some technical discovery for this goal?”
“Do you want to take ownership of this?”
And suddenly you’re a project lead. What now?
Software Projects: Brief Overview
Most of us start and spend the first several years of our careers in the Developing/Testing/Delivery part of a software project. The classic “Software Development Lifecycle” loop. We get a ticket, do the work, test it, and release it. It’s a comfy, familiar place. Moving from this comfy place to earlier up in the project pipeline is awkward at first. Expectations change, new skills are required and most people just expect you to know what you’re doing.
This post is focused on the “Designing” part of a software project. This is where a project lead will be asked to flex different muscles than what they’re used to, and where ‘winging it’ doesn’t always work out.
By “Designing” I’m referring to the creation of a detailed timeline of work such that it’s more or less ready to pass into the SDLC. This generally involves technical analysis, creation of architecture documents and a deep understanding of all tasks and how they relate to the overall project objectives.
Creating a Basic Timeline
Creating a timeline is one of the most challenging and important tasks a technical project lead will be asked to complete. There are three main aspects to creating a timeline: listing all tasks, sequencing tasks and estimating the time to complete the tasks.
The following is a generic overview of my favorite way to approach creating a software timeline.
1. Create or pretend you created the architecture
Has the architecture already been decided on? Study any documentation available, and talk to the original architect or team that created it (if possible). Ask questions and challenge decisions. Understand which part of the architecture fulfills which requirement. Perform technical analysis to understand why certain decisions/tradeoffs were made. Even if you did not create the architecture, you should be prepared to defend it and explain it in detail to individuals across a variety of technical backgrounds.
Does the architecture need to be determined? Become familiar with the requirements, perform technical discovery and start drafting up architectural documents. Iterate of the architecture until you’re confident it satisfies the requirements. Get the architecture approved by whatever mechanism your company follows.
You exit this step with architectural documents.
2. Make a high level list of tasks and iterate until you have a detailed list of tasks
Probably the most important step.
Use the knowledge gained in the technical discovery/analysis phase to determine the list of high level tasks that need to be done to fulfill the architecture. Iterate over this list to break high level tasks into smaller sub-tasks. Iterate over the subtasks until you get to some atomic level that cannot be meaningfully broken down any more given the available information.
This step always feels really tedious and tends to be the most skipped step, especially if the developer perceives the project to be small and low-impact. Developers will typically have a “clear idea” of how to implement something in their head, but can struggle translating their thoughts to manageable tickets with acceptance criteria that map to specific requirements. This is where the “rest of the owl” type tickets originate. They assume simplicity instead of confirming it.
Iterating through the list of tasks to the most granular detail as possible will uncover tricky cross-team dependencies, hidden tasks or inaccurate assumptions that would otherwise would be uncovered in the middle of the project, causing delays/drama/project cancellation/scope growth.
While it is impossible to fully prevent all “surprises” during a project, performing this step will rein in many surprises. As they say, it’s not the plan, it’s the planning. This exercise is excellent for providing clarity into the depth of work and identifying risks.
You exit this step with a really detailed (if messy) work breakdown structure (WBS).
4. Create a dependency graph
The goal of this step is to organize the WBS you created into clear streams of work, many of which can and should be parallelized.
Take the WBS generated in the pervious step and identify dependencies across the tasks. These dependencies should be through ALL tasks, not just the high level ones.
Make sure to also identify and account for external dependencies that aren’t strictly part of the project scope, but will affect the project’s success (ie. is there another team working on a project that touches similar parts of the code? Or are there major infrastructure updates needed to be completed before a certain step?)
You exit this step with a dependency graph, with as many parallelized streams of work identified as possible. Properly paralleled work leads to faster project completion times.
5. Translate the dependency graph into tickets
If you did steps 3 and 4, this step is easy. It’s literally just taking the dependency graph items and creating tickets for each node. You already have the hierarchy of tasks in the graph, so the sequencing can be set immediately on the tickets upon creation.
Additionally, since you already did the work of breaking down the tasks into small, atomic chunks, the scope of the ticket will be easy to understand by all team members. And since you created the small tasks from high level tasks that were associated with top level requirements, you should easily be able to tie in the acceptable criteria on the ticket to a top level project or architectural requirement.
Depending on company preference and project size, the work may be broken down into several milestones, each tracked separately (but still with dependencies between them preserved). But the overall steps here are the same – just more iterations into finer and finer detail are required.
You exit this step with an initiative/milestone/project filled out on whatever project tracking software your company uses.
6. Estimate and refine tickets
With your team, go over the work that needs to be done and how it fits into project objectives. Make sure everyone on the team understands the acceptance criteria; listen to questions and update the tickets as needed. Sometimes you’ll notice a huge gap in required work and you’ll need to go back and reshuffle the tickets a bit. This is fine, don’t fight it . Better now than mid-cycle.
You exit this step with tickets ready to be handed off to developers.
7. Bonus: Estimate time to complete timeline
Sometimes a project has a fixed date (eg. compliance deadline). But sometimes a project’s scope is more important than a strict deadline. In either case, management is usually very interested in knowing how long a project will take.
Project estimation is not an exact science and can get political. I’d love to do a deeper dive at some point, but there are a few common techniques I can recommend.
Critical Path Method or CPM is a technique to identify the longest sequence of dependent tasks on a project. This sequence is the Critical Path and is considered the most essential sequence of work on a project and represents the MINIMUM amount of time a project will take. This technique is great if you have a large project with complex dependencies across several parallel streams of work and you want to prioritize tasks efficiently. I’ve read it’s often paired with Project Evaluation and Review Technique (PERT).
Gantt Charts. You’re probably familiar with the good ol’ Gantt Chart, the project manager’s favorite tool. Once you have task dependencies and estimations, you can overlay that data into a Gantt Chart to get a detailed depiction of a project’s dependencies. Some planning software will automatically create this for you given an estimated project.