August 29, 2023
When and what to adjust during the project delivery timeline
In my previous post, we discussed the various options at a manager’s disposal in order to influence project delivery timelines. In this part two, I’d like to expand on the scenario planning delivery vectors and apply them to each part of the project’s delivery lifecycle. Let’s think through when it’s best to adjust the project scope, the number of developers, and the percentage of developers’ attention.
Scenario 1: The beginning of a project
Let’s say we’ve identified a top-priority deliverable, we’ve just kicked this project off, and you want to make sure that you deliver on time. At this stage in the deliverables lifecycle, what is the most effective way to ensure you hit your targets?
At the beginning of a project, it’s impactful to move almost any single one of those dimensions.
In the beginning, this is the ideal time to adjust the number of developers on a project because everyone is just getting up to speed and onboarding together. Everyone having context from day one rather than starting in the middle of a deliverables lifecycle is likely most impactful for them to be expedient down the road. If there’s enough work for people to take on, this is a great time to make sure that everyone’s following along on how things are going to be architected.
Also, cutting scope upfront early in the process before it’s even worked on is definitely a way to accelerate timelines.
Lastly, you can adjust the amount of attention that developers are spending on this project. Being spread too thin across projects can cause a lot of wasted time and context-switching. It’s also difficult to help onboard everyone to a project if they’re working on other things. Protecting the team’s time early on is a great way to focus the team and accelerate delivery. But if there’s not enough work defined upfront for the team to pick up, this might not be a viable option.
Scenario 2: The project is well into delivery
For this second example, let’s examine a top-priority delivery where we’re halfway through development. We’re getting nervous that we may be missing our targets. What might be the most effective way to accelerate delivery at this point in the deliverables lifecycle?
Cutting scope is always impactful, and that is going to help if we remove work. But when it comes to adding additional engineers, it’s best not to expect a linear output. These engineers will need to get up to speed and onboarded to the project, maybe even slowing down the engineers that are previously working on it. Doubling the engineers midway doesn’t necessarily mean that time is cut in half, unless there were a bunch of dependencies in the work upfront and it wasn’t possible to increase the amount of engineers on the project. Generally, we can’t expect the same velocity.
Another question we have to think about when adding other developers is: what else are they working on? Is this a trade-off we’re willing to make, and how do the engineers feel about being moved off of other projects to work on this one? Are there engineers wrapping up other work and could easily jump on this project? Regardless, new engineers most likely won’t have the same velocity on the work and those with the highest familiarity of the code base or how the project was architected will have an easier time providing value right away.
And then the last option: increasing the focus of existing engineers on the project is still very relevant. Reducing context switching should help, and when you’re deep in it, this is the time to really focus the team and make sure their priorities are well understood.
Scenario 3: Approaching project ending
In the final scenario, let’s say we’re about 90% of the way through development and need help taking the project to the finish line on time. What would be the most effective way to accelerate timelines and deliver this project on time?
Adding engineers in the 11th hour might not do much, and it could slow down development as engineers get up to speed. There just might not be enough work for them to take on. You can increase their focus on the project, for sure. That’s always on the table, but maybe you’re maxed out in that department because you did that earlier as a triaging step when we were in the middle of the project.
So what’s the last vector to consider in this situation?
This is the time to cut scope hard or push the timelines if the timeline itself is soft and there isn’t much left to accomplish. You could discuss with the team that the remaining pieces are worth delaying the release, but for this example, let’s assume it was a hard deadline. Cutting scope is what is necessary and in these scenarios, the cuts can usually become fast follows after the project delivery due date.
As much as we’ve been talking about facilitating these trade-off decisions, understanding when to apply these vectors is only part of the bigger picture. Let’s say we’ve made some decisions, how do we communicate those and make sure everyone is on the same page?
Communicating the impact of trade-offs
How we communicate these trade-off decisions is important because, as humans, we yearn for stability. Feeling like the rug is pulled from under us is not a good feeling. When priorities shift in an organization, and people have to move around on projects as a result, the news can feel unsettling. Sometimes tough decisions have to be made, but how we communicate those decisions can make all the difference in teams feeling unsettled versus well taken care of.
These trade-offs and scenario-planning decisions are impacting real people. The decisions we make have real consequences on productivity and happiness. We need to make sure we’re communicating the why behind our decisions and acknowledge the active trade-offs being made. What are we giving up to go with the new plans and why? What’s been happening historically? What do we plan to do as a result to change our future outcomes?
I hope this was helpful, and we can’t wait to hear your thoughts on how Jellyfish can better support you in the trade-off decision-making process.
