With this minimal information, all you can estimate is the definition of scope. Remember, there are no silver bullets (at least none found by the software community). Whatever estimate you define, even for just the scoping phase, will probably be incorrect by about 35% at least 75% of the time. However, management needs an estimate to assign staff.

SBDi does not have a perfect metric approach. We have a starting point that counts something. We adjust this count based upon additional information we gather from the initial executive interviews or from our knowledge of the interviewees (long talkers, minimum availability, and so forth). Use this as a guide to adjust or confirm your own approach. Our general guide is the following:

1. Three days to set up and organize for the project and obtain any material about the business domain.
2. Five days to review any existing material about the business domain. If none exists, still add the five days as the next step will also increase.
3. Two days for each person that will be interviewed to define the scope. This encompasses scheduling the meetings, holding the meeting (1-2 hours), analyzing the information gathered, writing and issuing meeting minutes, any follow-up questions, and conflict research and resolution. We ask to interview at least one individual from each business area that potentially may be involved in or affected by this project. If the list consists of more than six individuals, we encourage the use of a facilitator and organize a facilitation session to clearly define the scope. Each facilitation day would be counted as three days (preparation, session, post analysis).
4. Five days to produce a scope definition report covering all types of requirements and expectations.
5. Two days to schedule and hold final meeting with the executive sponsor and make any final adjustments to the scope.
6. Two days to initiate change control of the approved requirements.

Past experience is valuable. Keep these thoughts throughout all the phases of the project and plan accordingly.

1. Alter the estimate based upon similar projects with similar corporate styles (never underestimate your intuition and gut).
2. Alter the estimate based upon the project type (new, maintenance, enhancement).
3. Politically charged environments will prolong the effort, as well as users new to the business domain.
4. Projects without business executive sponsorship will also add time.
5. The Requirement Engineer skill set will either increase or decrease the estimate.
6. Adding new tools, techniques, or processes will increase time.
7. Expect people to interview to come out of the woodwork ... especially if this project has high visibility. Add for at least 1/3 additional interviewers that will require contacting for meeting minute approval and final approval of the scope.
8. Identify up front any vacations or holidays that will occur during the scoping phase and adjust accordingly. Plan for a percentage of unexpected outages.
9. Never plan on a full day of work. IBM used to (and may still do) estimate that you will only have 4 hours in a day to accomplish planned work. The rest of the time will be spent on telephone calls, emails, unexpected meetings or ad hoc discussions, interim reports to executives, and so forth.

It is important to set the expectation level of those that will be involved in this process. This is only a definition of project scope. Detailed business requirements will NOT be produced. You are just refining the area of investigation by clearly defining the concept. Make sure that the executives have the proper expectation.

Requirement Engineering specific roles would include both the Requirement Architect and the Requirement Controller. Requirement Producers may be subdivided by domain, perspective and focus only capturing requirements for their assigned category cell(s). If this is the case, they must also work with others to ensure that all interface requirements that affect their category cell(s) are also noted and accounted for.

A template for the scope definition report could include:

1. Product Name
2. Product Business Manager
3. Product Development Manager
4. Business Idea Statement
5. Business Objective
6. Overview of the Scope (could include graphical illustrations WITH notation descriptors)
7. Next Steps
8. Approvals
9. Itemized list of scope level requirements organized by focus (who, what, where, when, why, how, product constraints, project constraints). Each item will minimally have an identifier, name, description, and priority.
10. Outstanding Issues (in priority order) including any conflicts.

Appendix: A. All Meeting Minutes B. Glossary of Terms C. Reference Documentation

This scoping estimate guide is a manual method. Though quick and easy, it is not accurate. As anyone that estimates projects will tell you, accurate estimating methods are complex and require integration of many kinds of information...none of which you have at this point in the project.

Add to Your Library: Estimating Software Costs by T. Capers Jones (McGraw-Hill, 1998). This is an excellent overview of estimating software. It is a comprehensive book that will be a reference for all project managers for years to come.

The above list of example roles within the Requirements Related Role Categories are usually found in Fortune 500 companies. Remember, when working with small organizations, the same person may have responsibilities that cover many of the above roles. Similarly, multiple individuals may be responsible for the same set of responsibilities (and role).

SBDi is available to assist your organization in defining the responsibilities that will fully support a quality requirement engineering effort.

Pat Ferdinandi