Getting Predictable^SM Definition

Typically, business requirements and specifications are written at the same time. However, we find it more effective to gather the high level business requirements up front and let these define the boundaries of the entire solution.

1. Define the Boundaries: All project stakeholders meet together for three to four half-day sessions to create a common vision of success for their project. While ideas get challenged and minds change, by the end of the sessions we have a clear business perspective of what is going to be built, the processes and activities to be included in Release 1, Release 1.1, Release 1.2, as well as future releases. We also plan changes due to regulatory issues and other elements outside of our control.

2. Gather Scenarios: On many projects, developers leave off key features and the business feels robbed. In order to prevent this, our next step is to take each of the process areas and activities identified in Step #1 and break them down into scenarios. We also define exactly what needs to happen in order for a scenario to be deemed completely done. Before an estimate is made or a line of code is written, we capture all the energy around these scenarios in business terms.

Can the user do X, Y, and Z with the system? Has quality assurance signed off? Are the client’s expectations met? Only when these questions can be answered affirmatively, is a project truly done.

3. Create Technical Feasibility: Now that the business has agreed to what will be built, we define the technical needs of each scenario. Here’s where we ask a lot of questions: What did you mean when you said you want to collect name and address information? Do you need two distinct screens to collect name and address information, or is one good enough? Will the information we collect be different based on different variables, or will it appear the same for each customer? Confidence builds as we see for the first time the transition from vision to the specifics of what will
be built.

4. Build the Release Plan: During the final stage of definition, the delivery team presents a release plan that includes the expected cost, duration, and resources required to successfully complete the project. Created by the Project Manager or Technical Lead, there is no ambiguity about the duration of the project, how it is staffed, who is working on what scenarios, what is being built, and how it gets it into production. The plan is maintained throughout the project and provides the stakeholders with a clear view of how the project is tracking toward the agreed to success criteria.