Courtesy of Chris Wright

SharePoint: How long should you spend on requirements

Estimating  how long a project will take to complete is a complex task, with hundreds of books and articles having be written about the various techniques and methods of getting it right. I’d like to look at a different slightly angle, that of how long you should spend on requirements gathering in any given project.

The answer of course varies from project to project. The simple answer though is as long as possible! However, clients normally want a bit more precision than that. Experience has taught me to aim for 30% of a projects total development time to be spent on analysis. Not all of this time needs to be upfront, some can be done along the way. But the total should be in the region of 30%.

Nearly every project I have worked on has dedicated less time than this, and nearly every project has suffered for it. Certainly if you have a developer
spending more than a week coding, you are going to need this kind of percentage of time. And as development time increases, and complexity generally increases with it, your analysis time becomes ever more important.

Securing this amount of time is always tricky. Clients, and sometimes members of your own team, often struggle to see the benefit of spending such a large chunk of time talking about the problem rather than writing code. You really need to fight for your corner to get the time you know you’ll need. I find the best way is to try and help the client understand how complex things can quickly get, and how any problem can be interpreted in a number of ways if not fully understood. Try to demonstrate where you see the complexity, ideally in ways they have not even considered. Remember you are the expert, so try to show this in describing how you intend to spend the time.

Even better yet sit down the various members of the project team, including the client, and describe a complex scene or setting to them all. Ask everyone to draw what you have described on a piece of paper. Make your description sufficiently complex, and open to interpretation. Once done compare the drawings, hopefully you will have quite a bit of variety. Hopefully some are totally different! Compare this exercise to diving into a solution on your project, without defining details properly. Without proper analysis and discussion a problem can be easily misunderstood, and the resulting solution inadequate.

Once you have secured your 30%, ask the client if they have yet thought of the testing time that will be needed! Well maybe that is a battle for another