According to Dictionary.com, a template is “anything that determines or serves as a pattern; a model”.  The idea of a Requirements Template is to provide your organization with a thorough and far-reaching list of questions or areas of inquiry to either answer or rule out at the beginning of every project.  If you include input from enough people and groups, whether they typically identified as project stakeholders or not, you can eliminate many of the scope problems that your organization’s projects might have encountered in the past. 

If you ever do projects for external customers, start your template-building exercise with Marketing and Business Development.  Ask them about what types of features customer and prospects initially express interest in and what marketing and advertising messages they respond to.  This can give you some good high-level areas of inquiry for your Template by helping you understand what prompts your external customers to engage with your organization. 

Next, visit with the Sales group and ask them to think about every problem customers have identified as wanting to solve when they accept a sales proposal.  Ask them also to think about customer satisfaction issues after a sale is completed:  what characterized projects that had satisfied customers, and what characterized projects that didn’t.  Ask them to describe situations where the customer was temporarily unhappy and why.  Ask to see any type of documentation they use to begin identifying what a customer wants. Then start building your list of questions. 

If you are dealing only with internal customers, start by reviewing the documents that accompany any request for a new project.  You want to include all of this information, but your template will go into much greater detail.  Interview someone from your organization’s Steering Committee and ask them what is missing from the current initiation documents they use.  Ask for examples of specific projects that got kicked back from the Steering Committee due to insufficient information, and get them to identify the types of additional information needed for them to make a ruling on a new project.  Continue building your Template by adding this to your list of questions.

Next, visit with all the teams that are responsible for executing the project plan.  Talk to developers, DBAs, cost estimators, trainers, folks who do the documentation; basically, everyone who actually performs work on a project in your organization.  Ask them for a list of everything they end up needing to know in the middle of the project that no one ever asked at the beginning.  Ask them what kind of work they are doing in the stabilization period, and if that work is a result of missed requirements.  Ask them for the most common examples, as well as the outliers.  Your goal is to create a comprehensive list of everything that should be considered at the beginning of a project.

Then move on to your support teams – whoever is responsible for the product of the project once it is operational.  Ask them to identify the things they wish someone on the project team was asking about.  Again, ask for the odd and unusual situations as well as the most common examples.

Finally, spend a little time with other groups that may not be at all involved in the project, but can potentially be affected problems with a project, like Legal, Accounting, Corporate Compliance and Public Relations.  Ask if they have ever been affected by missed project requirements, or have an area of potential concern around project requirements.  Document their concerns as areas of inquiry to consider during the requirements phase.

If you have all these conversations and hear all these war stories, you will be able to create a useful tool for the people in your organization who have the responsibility of collecting requirements.  Continue to updated and modify your Requirements Template as new information becomes available. 

In addition to getting your project off to a good start and nipping some scope creep issues in the bud, you may find that this tool helps you have better conversations with customers, both internal and external, by helping them uncover needs they didn’t know they had or gaps in their process they hadn’t discovered yet.

Good luck!

There is no silver bullet answer to this.  You cannot get a high quality detailed estimate without detailed requirements.  One simple approach to this however, is to not try to over think things at the project selection stage.  It is an established fact that estimates have a greater degree of risk and less certainty earlier in the project when less is known.  Rough order of magnitude (ROM) estimates made during project initiation can have margins of error in the range of +-50% from actual.  As the project progresses and knowledge increases, the risk goes down and the margin of error on the estimate decreases to as little as -5 to +10% when all the requirements are hammered out.  So beating the team up to get a binding estimate at the beginning is futile and the selection committee should be educated on that.  A technique that works better is using range buckets.   The ‘McDonald’s approach’: i.e.  - small-medium-large works very well for this.  Usually a project request has been documented briefly with some amount of information regarding high level purpose and objective, business need and justification.  Based on this, a technical resource should be able to slot the project into one of 3 possible ranges or buckets such as:

The actual numbers associated with small, medium, and large, can of course be adjusted to whatever makes sense in your organization.  This first estimate should be understood to be within some amount of error, depending on the detail in the project request, but enough to determine approval.

We like to re-visit estimates twice more during the project.  After the scope baseline has been defined, a second estimate, considered a “planning estimate” is developed.  This should generally be between 10 – 25% from actual. The third time is after detailed requirements are developed and clarified between the business and the implementation team.  That is when the team should achieve the -5 to +10%  accuracy.  The rule is, at each of these points if the new estimate varies significantly from the understanding of the project steering (approval) committee, the team must seek permission to continue, or make adjustments to scope to get back to the cost in the original estimate.  That way the team is protected from being saddled with work they didn’t get funding for in the original estimate, and the sponsors stay in control of costs.