That’s the worst time to fully realize that a planned feature is far more difficult than anybody had anticipated. Sometimes, it’s found that the feature in question isn’t even possible with the current skill set of the team or maybe it becomes obvious that it will affect five other areas of the project (which are now near completion, of course). This will usually cause major scheduling delays and can give the software a non-cohesive feel when it’s finally released.
To demonstrate the importance of the order in which things are done, lets assume you want to build a car. Your team will be building the entirety of the car, including the engine, dashboard, brakes, body, everything! Members of your team have previously built all parts of a car and there’s a ton of experience on board, so you feel confident that the new project will be a success. But, the engine is of particular concern because, except for a few small engines, nobody on the team has built anything even close to the 300HP motor you’re planning for this particular car.If that was your project where would you start? Would you start with the parts that your team are comfortable with or would you start with the engine?
I hope in this example it’s obvious that building a prototype and proof of concept of the engine is the highest priority. If the engine’s size is different than what is expected, it could drastically alter the dimensions of the car, the styling, cabin room, the weight of the car, possibly require different brakes, etc. If the engine runs hotter than you had expected, you might need a different kind of cooling system, larger air intakes causing a different body design or changes in cabin space and overall dimensions again. There’s a lot that depends on the characteristics of the engine. Starting with the engine is essential to the overall success of the project! Furthermore, it’s not possible to estimate the time frame of this project accurately until the proof of concept of the engine is complete.
Now, if your teams biggest strength is engines, you might start elsewhere, confident that your team could reconfigure the engine to conform to limitations imposed on it by other aspects of the project.In software though, most development teams don’t start with the hardest component of the project, which often has the most dependencies. Instead all parts are treated equally. Developers are asked to estimate the project requirements and they simply start development in the order that’s most convenient. Sometimes the order in which things are done is the order in which Microsoft Project’s resource leveling algorithm suggests to get the most bang for the buck. This can leave critical elements of the project for the final weeks or months. By then, the equivalent to the engine might be too big to fit into the body that was designed or it runs so hot that it will melt the surrounding equipment.
To make things work, the top notch quick-thinking team-members generally build additional work-arounds to “make things work” and have the least impact on the project schedule. The end result is software that, at best, is late and doesn’t feel right to end users.
The alternative method of development is to identify key, critical areas of the project that are areas of concern and build those components first. Build prototypes. Create proofs of concept. Test out the team’s theories before committing to a project schedule. If you are committing to a tight schedule for a collection of components that your team has never built before, you’re committing to failure. Don’t leave it to chance, if you want to ship your software on time.