Fast Starts; Part 2 of 2
In the first part of this post I described an all too common dysfunction with large software projects, which can start impressively fast only to get bogged down and end up disappointing.
What can you do to avoid possible disappointment?
Let me try an analogy to see if I can illustrate a good approach.
Running Track
Let’s assume you are a runner, and your race is one lap around the track. It is probably a bad idea to stop half-way and reconsider your strategy for the second half of the track. You are in the middle of your sprint, and should generally finish with the same plan you started with.
But after the first few meets, if you are not happy with your finish times and positions, you will likely want to reassess your plan: how you train, what you eat, how you deal with weather and other conditions, how you approach particular meets, and so on. Based upon your assessment, you’ll probably make adjustments.
On the other hand, if your races have been good you might not stop to think about these sorts of issues, and just keep running.
But perhaps you should take a little time to reassess. Consider what you have learned from your initial meets. Are you training too hard? Will you have sufficient energy for the end-of-season championships? Is the weather changing as the season progresses? Are you ignoring a minor injury? How are your competitors faring?
My point is not that you must always change what you are doing, but rather that there is value in considering changes (replanning), given the new information you gain as your season (or project) progresses. This is obvious if you are facing challenges, but is still valuable when things are going well, to help catch issues before they become serious difficulties.
Plan on Planning
Whether your project begins with a quickly whipped-up demo or a careful planning process, make it part of your plan to stop and reassess at regular intervals. This is the key idea from this entire post.
To paraphrase Einstein: Keep your planning as simple as possible, and no simpler. Ideally, you will have all of your material from your initial planning sessions, plus the additional information you have gathered since then. But if you are starting from scratch, your planning process will likely require a bit more time in order to gather information and stakeholders.
The point or points at which you pause to reassess will depend upon a variety of factors. For a project that started without much planning, you will be best served by stopping sooner. For long-term projects that are going well, you may want to wait a couple months. I would almost never suggest waiting more than three months, as too much can change (and much should be learned) in that time span. Like the runner in my analogy above, pick reasonable reassessment points after you have gathered additional information.
Ask Good Questions
One key part of good planning is asking and then digging into good, relevant questions. For a software project the following are generally good questions, but you should devise some that are more specific to your situation.
• What have you learned about the project?
• What new questions have been raised?
• Are you still aiming for the same goals?
• Has anything changed since the last check-in?
• What feedback do we have from stakeholders (customers and end-users)?
• Have you found any new challenges which must be investigated? Or do some tasks seem harder than initially expected?
• Have you discovered major issues which threaten the project or will require substantial help?
• Are you still focused on the most valuable parts of the project?
Dig into these questions and any other good ones that are relevant. Do this with appropriate stakeholders, including the engineering team. Ensure that everyone puts proper thought into this reassessment, as any process that is given lip service only is useless.
Don’t panic if you don’t know all of the answers yourself. You will rarely possess all of the domain and technical expertise that the stakeholders and engineering teams have, but you should be able to develop a good feel for whether the relevant questions have been asked and then given proper consideration.
As you gain new insight, update your planning artifacts, schedule any new investigations that are required, adjust the work backlog, and move forward. One other item: If the project will continue for long enough, schedule the next check-in!
Fast Finish
A fast start to a project should be a good thing. But don’t let it make you lazy, and don’t let any surrounding hype fool you. Particularly with longer, more complex projects, be sure to plan to stop and reassess, to ensure that the progress you have made leads in the right direction, and doesn’t mask underlying problems. A fast start is great, but a fast finish is even better.