2.3 How Requirements are Derived

---

2.3 How Requirements are Derived

The process, albeit somewhat nonlinear, looks something like the illustration in Exhibit 1.

Exhibit 1: Requirements Development Process

Keep in mind that, as the project manager, you are driving the bus, but you are not the mechanic. Although your prior experience or expertise may add value to the shaping of requirements content or detail, your focus must be on ensuring that the right people are engaged and that ideas are circulated and openly debated. No matter how ribald these conversations become, you must keep everyone headed down the road of adequate specificity with a high level of consensus. Even if you do not agree with each emerging point, so long as the team does, and the process is thorough and professional, your opinion should fade into the background. Not that you should not make yourself heard, but in this context your voice should be just one in the crowd.

Look at it this way. Your job is to lead and to induce consistent buy-ins from stakeholders. Even though you think something should be one way, if the consensus heads elsewhere, you must go with that, because they are tasked with making it happen, not you. If you force your preference on them, chances are their effort will lack the thoroughness and enthusiasm you need, and in the end everyone looks bad, particularly yourself. This guideline has exceptions, but be very certain you are doing more than advocating your personal prejudices before making the ill-fated "my way or the highway" speech. This is one performance that is not likely to raise calls for an encore!

---