Getting Predictable Definition


When it comes to requirements, most of us agree there’s usually ambiguity and confusion. People may think they hear things. They may understand something differently than a colleague. Business stakeholders may change their minds or misunderstand the consequences of a particular decision. It’s not unusual for the project’s business case to get lost — especially when you have six to 12 month projects and 50+ people making decisions that are not aligned to a common vision.

Getting Predictable Definition solves this problem by creating alignment between IT and the business as well as between business stakeholders. Why is this so important? Because when all the business stakeholders agree to exactly what they need, it makes it easier for the development team to deliver it!

Getting Predictable is a collection of simple, effective best practices that emphasize the value of a shared vision on project success between stakeholders across the organization. Because requirements are defined in terms of business goals, Getting Predictable provides metrics that quantify success in terms that make sense to all project stakeholders. Plus, any ambiguity as to when a project is done, done, done is completely gone, gone, gone.

How it Works

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.

The Phases:

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.

The Client Experience

Getting Predictable Definition requires the business stakeholders to commit time and make business decisions about the project. There is collaboration and debate on the business issues. New issues are on the table. A feeling of accountability grows among these stakeholders — if they request something, they’re going to get it.

Throughout the process, a trained facilitator drives discussion. Within hours, the business perspective of project success criteria begins to emerge – without geek talk or project specifications. By the second day, energy levels are high as we quickly start flushing out the rest of the vision.

More people get on board as the common vision crystallizes. The business stakeholders begin to feel there is a step-by-step plan and they are getting actual results from the Getting Predictable process. By the end of the session, there is total confidence that a common vision of success has been achieved and communicated to the development team.