Project start dates are assumed an easy input. I often see too little thinking go into this date. Its actually one of the most important inputs because all other values are based from this date. A day off is at least a day wrong in the forecast without creating team stress. The most common reasons this date turns out incorrect (different than planned) are –
- Its a date based on the “planned” finish of another project and that project goes long
- The team intended to start the new work is still performing release activities or stabilization of a production tool
- People are exhausted after a hard slog o a prior project
- The team doesn’t exist yet, or in a full set of required skills
- They don’t have the tools or environments to begin development
- The project isn’t approved to go ahead yet
- The team isn’t trained in the skills it needs
These are my shortlist. They have little to do with this project or feature, and a lot to do with what else is happening inside the company. To get this date right you have to boldly ask difficult questions of other teams. You have to look at how similar projects have started and assume you will fare no better without taking a different approach.
Estimate this date to the best of your knowledge considering that the following conditions are met (make your own list and tick them off as you go) –
- Do i have a core team with the skills required?
- How long will i take to interview, hire and onboard new staff?
- Do we have physical seating space for the team?
- How long does it take to get access to critical IT resources (database, websites, tools)?
- What software and tools are needed for them to do their job, do we have it on order?
- What other projects or production issues might my team be “borrowed for”?
You get the idea. Look for things that will delay the team hitting its delivery stride. Either set the date past that estimate, or assume a slower throughput in the early days. But most importantly – don’t just use the “desirable” start date for forecasting.