"How much time will this take?", this is a difficult question to answer. Difficult might be underestimating this. I never get the right answer to this question. There are many variables and unknowns that can impact the actual time a feature or project takes to ship. I always end up being either too optimistic or too pessimistic.
Given that question always returns uncertain results, it's not a very helpful question. Instead of wondering about time, let's think about speed. More specifically, we could ask, "How fast is this moving?".
Now that's a different question, one that we can get a good idea on. One of the proxies for execution speed is how fast you're moving along the critical path. This is an idea I've picked up from the Phoenix Project. If you're focusing your energy on the critical path, you're going close to top-speed in a project. By identifying the critical path and focusing on that, we've got a rough idea of how fast the project is moving.
Finding the critical path is not always obvious. I've struggled with this in the past, and I've been experimenting with simple questions. It has a decent success rate so far. The idea is a three-step process. That process is something I do when I try to improve my Execution goals.
1. Setting ambitious checkpoints
It's hard to predict what happens over a long period of time (3+ weeks), but we can have a decent guess in shorter windows. The first step is to picture a best-case scenario over a small window of time (1 or 2 weeks). We want to focus on the best-case scenario without limiting us with constraints. This allows us to see where we could get if all stars aligned. If the answer to this question feels unrealistic, you're on the good track.
Project example
Given that question always returns uncertain results, it's not a very helpful question. Instead of wondering about time, let's think about speed. More specifically, we could ask, "How fast is this moving?".
Now that's a different question, one that we can get a good idea on. One of the proxies for execution speed is how fast you're moving along the critical path. This is an idea I've picked up from the Phoenix Project. If you're focusing your energy on the critical path, you're going close to top-speed in a project. By identifying the critical path and focusing on that, we've got a rough idea of how fast the project is moving.
Finding the critical path is not always obvious. I've struggled with this in the past, and I've been experimenting with simple questions. It has a decent success rate so far. The idea is a three-step process. That process is something I do when I try to improve my Execution goals.
1. Setting ambitious checkpoints
It's hard to predict what happens over a long period of time (3+ weeks), but we can have a decent guess in shorter windows. The first step is to picture a best-case scenario over a small window of time (1 or 2 weeks). We want to focus on the best-case scenario without limiting us with constraints. This allows us to see where we could get if all stars aligned. If the answer to this question feels unrealistic, you're on the good track.
Project example
- Q: Let's picture by the end of the next two weeks. We have three milestones in the project: A, B, and C. What would make you the proudest to share regarding progress?
- A: If we've shipped A and B, that would be a heck of an accomplishment
Personal example
- Q: By Friday, what would be the most amazing thing you could present at the demo for this new project?
- A: I would have ramped up on the new project, understood the main components, and have a prototype demoed
2. Discover the critical path
Now we know the best-case scenario rarely happens. If we found an ambitious scenario in the previous question, we're adding a touch of realism now. We have an unrealistic optimist picture, where won't this work? Asking this question will help us discover the critical path. This takes a few rounds of curiosity and digging into why it won't work. For simplicity, the following examples only do 1 round of questions. It's important to not focus on solutions yet, that will be the last step.
Project example
- Q: What will prevent the team from shipping A and B in the next two weeks?
- A: Well, A depends on another team so we will need their help. We haven't explored B yet, we will need to prototype it. With the prototype, we can make technical decisions. Then we need to produce production-quality software.
- Critical path:
- A: Locking in help from the other team
- B: Exploring & prototyping
- B: Making the technical decision
- B: Making it production-ready
Personal Example
- Q: What will get in your way of showing a prototype by the of the week?
- A: Well, I've never touched this codebase, so I will need to learn about components X, Y, and Z. It's also not clear what the project's scope is yet. Then I'll need time to make a meaningful prototype. On top of that, I've got quite a few meetings this week.
- Critical path:
- Learn about X, Y, and Z
- Clarify project scope
- Implement a prototype
- Availability
3. Make a plan
You've got an optimist plan, with a touch of reality, let's take action on it. The previous step allowed you to find all the obstacles to reaching your ideal scenario. You've discovered the critical path by going through this process. By focusing on the critical path, you're setting yourself up to move things quickly. The last piece of the puzzle is the execution and focus. Notice what sort of things get in the way of reaching our objectives. This is not an exhaustive list, but those are frequent aspects of a critical path.
You've got an optimist plan, with a touch of reality, let's take action on it. The previous step allowed you to find all the obstacles to reaching your ideal scenario. You've discovered the critical path by going through this process. By focusing on the critical path, you're setting yourself up to move things quickly. The last piece of the puzzle is the execution and focus. Notice what sort of things get in the way of reaching our objectives. This is not an exhaustive list, but those are frequent aspects of a critical path.
- Dependency on another team
- Ramping up & learning: Reading, Prototyping
- Decision making: Scope, Technical
- Implementation
- Availability: Meetings, other responsibilities, etc.
Project example
- Q: How will the team focus on removing the blockers?
- A: The team that we depend on is quite busy, but they can afford a 1-hour pair programming to get us started and some code reviews. On top of that, we can start prototyping right away. We'll aim for a technical decision by the end of the first week. This would give us a week to throw away the prototype and implement a production version of it.
Personal Example
- Q: How will you prioritize your week?
- A: I can't get started before I know about X and Y. With this understanding, I can explain how the uncertainty in the scope is impacting me. I'll aim for scope clarification by mid-week. By Wednesday I can start getting into prototyping. I should be able to have something working for Friday. My Thursday is all about meetings, but some of them don't have any agendas, I'll see if we can do those asynchronously.
Will those examples actually work? It's difficult to say. Some other unknowns and curveballs might send those plans sideways. One thing for sure, though, we're applying a weekly (or bi-weekly) perspective. Going faster requires optimizations within each exercise (speed of implementation, decision making, etc.)
How much time will this take? One week, two weeks, or more It's still difficult to give an accurate answer. How fast is this going? As fast as we can make it move. We're working on the highest-leverage activities and setting ourselves up with ambitious goals. Keeping the focus on our goals and repeating the process of discovering the next critical path has served me well. I hope it helps other folks as well.
Cheers.