Estimating software projects is hard. Early on in the development process, you can’t precisely define the scope of a project. Because inevitably, the scope will change after development kicks off, since the team will have learned more about the project and its context by then.
Software projects are surrounded by a high level of uncertainty. Even if developers or a consultant gives you a project estimate, until development begins, you won’t know exactly what resources you need to implement the user stories that you’ve planned for your next release.
Compared to product management, project management is more tactical. It is as vital as keeping the strategic vision for your product. Even if your development team consists of only one person, you still need to make sure that all requirements are understood and deadlines are met.
Once you’ve completed the preparation steps and assembled your team, it’s time to start building your app. However, where do you start? In what order should you build everything that you’ve outlined in the spec document? To figure that out you need to create a roadmap.
Software requirements is a very fragile structure and can be easily destroyed by the misuse of a written language. That’s why most of the lengthy requirements specification documents fail miserably.
In a couple of previous posts, I wrote about preparing specs and mockups for your product (Part I) and hiring designers and developers (Part II). Once you have your product spec, design and team ready you can start the development process. This step is equally complicated as any of the