When planning/starting a software project (probably other projects as well) you are often provided a list with requirements written by the customer. It is now your job and responsibility that you meet all the requirements. Not only do you need to meet the requirements you also need to meet the requirements in a manner so that the customer agrees that the requirements are met. How can you increase the possibilities for this to happen?
First you need to make sure that you and the customer understand the requirements equally. It is quite easy to interpret the requirements, the hard part is to interpret the requirements correctly (according to the customer). What you need to do is to systematic go through each requirement and describe, with your own words, the functionality you associate with the given requirement. When this is done you must present your functional description to the customer and make sure that you both have the same and good understanding of the requirements. This might be time consuming, but it is worth the time.
You have now ensured that you understand your customer’s needs and you know what functionality the customer expect to get delivered. These needs and functionality will naturally change during the project and that is OK, you have a great fundamental for absorbing and acting on changes when you have a clear view of the original proposed functionality.
Next step is to make sure that the developers and architects know what functionality you are about to develop and how this can be technically implemented. It is time to start writing Use Cases. When writing use cases you extract use cases from the functional description you wrote earlier. It is OK to start of with writing large use cases and make sure that all major functionality are covered with use cases. Now it is an good idea to start splitting your use cases into smaller and more specific use cases. While doing this it is also smart to identify common/general functionality and place this in other use cases. You can now refer to this use case from other use cases when you need to describe this kind of functionality. You can read more about how to write use cases in a previous post I wrote on this subject: Writing use cases for agile (Scrum) projects.
When this is done it is always a good idea to take an extra look at your functional description making sure that this is now covered by use cases.
At this point I would start to place the use cases in my preferred project tool: JiRA GreenHopper og ScrumWorks. I am using agile development methodologies so I would populate my project backlog with the use cases. Each use case would be represented by one backlog item. You can now start adding tasks to each backlog item (use case) identifying all tasks that needs to be done before a use case is fulfilled.
When you have all use cases as backlog items with tasks attached you can start estimating each task. Since each task is very specific and small the estimate for each task should be pretty accurate (if estimated correctly, but that is another story). When all tasks are estimated you should be provided with a accurate number for the whole project.
It’s now time to bring the customer back into the loop and present the project backlog and prioritize the backlog items together.
If you succeed in the steps explained above you should be able to deliver the project with the correct functionality to your customer on time and at the estimated cost.