Actually Making it Work

I had a meeting yesterday in which the contractor mentioned that the System Requirements Specification (SRS) would be delivered next week. We took a few minutes to go over schedules to ensure that we will have people to review the document.

But then I noticed something. The work that we were talking about was simply a document review. For the stakeholders on the project, they didn't understand that this is a big deal. Let me take a moment to explain.

The PMBOK does an awesome job about telling you how the processes should work. It does an awful job of grounding those processes in reality. When you read the PMBOK, you will understand that you have to manage the scope of the project, and that there needs to be a Change Control Register. But what the PMBOK fails to identify the point from which you manage CHANGE. In a practical sense, the first second you sit down in a project is a change right? Everyone has their different assumptions and ideas, and for most people, those ideas evolve into consensus. Wouldn't that be change?

No. We begin to measure change from what we call the requirements baseline. The artifacts that comprise the requirements baseline are going to be different based on the organization's preferred templates and the software development lifecycle that is selected. But in many instances the requirements baseline is comprised of any of the following:

• System Requirements Specification (SRS)
• Functional Requirements Document (FRD)
• Data Requirements Document (DRD)
• Requirements Traceability Matrix (RTM)

Once these documents are "Accepted" we (the stakeholders, the development team, sponsors, PM, all project participants) have agreed to the Requirements Baseline. This is important because this baseline is the point from which we manage CHANGE. Before we get to a point at which we have accepted these documents we don't really have a baseline and as such nothing from which we can objectively say, "That is a change." After these artifacts are approved we then have an objective point from which we can measure change.

When you have this conversation with the stakeholders you must help them to understand that when they review the SRS, they are agreeing to the requirements baseline.

Be careful though because the second you have this conversation the inverse reaction can also happen. Someone could say, "Well, I don't think I can approve the SRS because it might have something that we'll want to change later." If you are prepared as a PM, you'll address this issue as well.

I then went on to tell the stakeholders that "perfection" is not the goal of the SRS. I only do Agile (spiral) development for just this reason. In the SRS, our goal is to have a document in which the average person would agree that yes, it is generally correct. The reason for this fuzziness is because we are going to have design and QA sessions, we are going to review functionality a couple of times and we are going to have User Acceptance Testing. Thus, the things that are not perfect in the SRS, and the things that are not fleshed out in great detail will be reviewed as we progressively elaborate the requirements into design and design into features.

Also, you must tell your stakeholders that some amount of change is acceptable. Just because we have agreed to the Requirements Baseline doesn't mean we can't or won't accommodate changes to it. But rather, I will force the stakeholders to be more deliberate about the change. If we want to change the name of a field, and the developer uses resources to implement that change, we don't want to change it this week only to change it to something else next week, and, God forbid, change it back to what it was originally a couple weeks later. I have been on projects that have done that and I learned a lot from those situations. No, if we're going to implement a change, our goal is to only change it once, and when we make that change it will be perfect.

Finally, we may get to a point in which we have a mountain of changes, more changes than what can be accommodated within the scope of the project. Here is what my commitment has been to the stakeholders: We will address your NEEDS, and if we have the resources to handle it, we will address the WANTS. This is important. If you have a mountain of changes, you have to be able to identify the things that are necessary (NEEDS) to get past acceptance testing versus WANTS. This is why we prioritize the change control register. Needs will bubble to the top and wants will not.