Project Roadmaps can Manage Uncertainty in Startups' Web Applications
Project communication breaks down quickly due to miscommunication about
- Estimates
- Targets
- Commitments
These concepts are not clearly understood by everyone involved in a typical project.
Often times the person commissioning a project has ideas about specific outcomes that may or may not be realistically achieved given a budget and a timeframe. When he or she is asking for an estimate, what is really desired is a commitment to provide his or her desired outcome by a very specific calendar date for a very specific budget. This is categorically not realistic for custom software projects.
Consider this example of a fairly healthy discussion between an executive in a software development company and a lead developer who is responsible for managing the team that builds a particular custom web application:
{% blockquote Steve McConnell’s “Software Estimation”, page 5 %} EXECUTIVE: How long do you think this project will take? We need to have this software ready in 3 months for a trade show. I can’t give you any more team members, so you’ll have to do the work with your current staff. Here’s a list of the features we’ll need.
PROJECT LEAD: Let me make so that I understand what you are asking for. Is it more important for us to deliver 100% of these features, or is it more important to have something ready for the trade show?
EXECUTIVE: We have to have something ready for the trade show. We’d like to have 100% of those features if possible.
PROJECT LEAD: I want to be sure I follow through on your priorities as best I can. If it turns out that we can’t deliver 100% of the features by the trade show, should we be ready to ship what we’ve got at trade show time, or should we plan to slip the ship date beyond the trade show?
EXECUTIVE: We have to have something for the trade show, so if push comes to shove, we have to ship something, even if it isn’t 100% of what we want.
PROJECT LEAD: OK, I’ll come up with a plan for delivering as many features as we can in he next 3 months. {% endblockquote %}
What the EXECUTIVE and PROJECT LEAD in this fictional discussion have done, is talked through a project roadmap, that has a minimum viable product (MVP) launching by the time of the trade show, even though some or many of the executive’s desired features may be developed subsequent to the initial launch.
In his book, Mr. McConnell gives some key suggestions for developers being asked by a client for an estimate.
- Distinguish between estimates, targets, and commitments
- When you’re asked to provide an estimate, determine whether you’re supposed to be estimating or figuring out how to hit a target.
- When you see a single-point “estimate,” ask whether the number is an estimate or whether it’s really a target.
- When you see a single-point estimate, that number’s probability is not 100%. Ask what the probability of that number is.
The probability is not a simple bell curve either, it’s a distribution with a narrow window to deliver on or before a certain date and a large probability of delivering after the desired date. In other words, projects are far more likely to be late than not.
In short, projects are surrounded by uncertainty. A healthy project management process embraces this reality and deals with it throughout. To increase the chances of a successful project, the team must navigate its lifecycle while embracing change as new information is discovered.
One great tool for answering the question “What should we build and by when,” is the use of User Stories to document requirements and a backlog management tool, such as Pivotal Tracker, to estimate Story Points and track developers' Velocity throughout the lifecycle of the project. The result is a continuously updated project plan that benefits from the law of large numbers to give reasonably accurate estimation by what calendar date the current phases' functionality can be completed and for what ballpark cost.
See How to use Story Points to Estimate a Web Application Minimum Viable Product for how we estimate project budgets using this Story Point process.