This post is actually a slightly adapted version of a comment I made on Laura Brandau’s post, The myth of the “requirements contract”. Check out Laura’s post for her insights and some interesting dialog in the comments.
“Sign-off” is a common term to folks who work projects that include documented deliverables. Often a Business Analyst will seek out stakeholder signatures to signify an agreement as to the state of the deliverable. Achieving agreement and sign-off can be a contentious and difficult exercise if not handled correctly.
I think most project professionals would agree that using sign-off to indicate requirements are “done” in a contractual way often does more harm than good and would love to do away with it in its current form. It’s difficult to imagine anything positive coming from an agreement wherein we ask stakeholders to, in essence, freeze the requirements when everyone knows we don’t know all the requirements yet.
Pitfalls of the Sign-off “Contract” Mentality
Do any of these examples sound familiar?
- Business stakeholders withhold signature because they know once they sign, the requirements are considered “frozen”, and requests for changes and updates will be met with the typical post-sign-off response from IT: “We gave you an opportunity to review the document, and you didn’t know everything. While changing the requirements now isn’t impossible (although it may require an act of deity), it won’t be cheap, either!” And, of course, the design team isn’t going to lift a finger until requirements are signed-off, so the longer the business tries to keep that window of opportunity open, the further the delivery date gets pushed out.
- Signatories from within the solution delivery organization withhold signature until the document is “complete”, even if completeness stretches the requirements process well beyond the point of diminishing returns – (see also: “analysis paralysis“). Possible causes: 1] the document really is bad – as others have been bad in the past – and the delivery teams don’t want to risk being burned again 2] the teams are stalling so they can shift blame to the BA for not meeting his/her deadline as a pre-fab excuse for not meeting theirs.
- To just finish the darn requirements, the BA eventually gives up and says, “you just tell me what you want in the document and I’ll put it there,” just to get the signature, move the project “forward” and preserve a modicum of sanity.
These are just a few of several ways that the sign-off “contract” mentality can make the requirements validation and sign-off process adversarial and more an exercise in protecting turf than in collaborating to advance a solution.
How can we do better?
As a practical matter, “sign-off” will continue to be a required milestone in many organizations – and may even be required long into the future; especially in regulated industries for compliance/audit purposes. For cases where we can’t just do away with sign-off, I think we can reasonably redefine it more as a “baseline” or “snapshot” than a contract to keep it from being so adversarial. I really like Karl Wiegers’ approach (we use a similar approach in my shop) to defining what sign-off means. Per Wiegers:
More important than the sign-off ritual is the concept of establishing a “baseline” of the requirements agreement—a snapshot at some point in time. The subtext of a signature on an SRS sign-off page should therefore read something like: “I agree that this document represents our best understanding of the requirements for the project today. Future changes to this baseline can be made through the project’s defined change process. I realize that approved changes might require us to renegotiate the project’s costs, resources, and schedule commitments.
In reality, business folks understand that IT needs to have at least a somewhat stable understanding of project scope for the purposes of estimating and resource planning. I think they understand that scope changes have an effect on those estimates and resources. They just hate it when IT uses that good-faith signature as a “gotcha.”
When it comes time to baseline, I prefer to acknowledge to the customer and other signatories (designers, developers, QA, etc.) that we know we won’t identify every single requirement up front, but that what we’d like to do is agree that the content of the document accurately represents the requirements as we understand them at present. This way we can move forward with activities with an acceptable level of risk (note, no mention or implication of scope being “frozen”). As additional requirements are uncovered and existing requirements refined, they will be evaluated and we’ll come to a mutually acceptable agreement as to what changes are made.
BA’s and Project Managers have some leverage to define or redefine the terms of sign-off in a way that is fair and agreeable to all parties. And while agilists may disagree, I am convinced that it is possible to baseline documents – yes, even to get signatures – without it being the nightmare that it is in many traditional waterfall shops.
Is it a methodology issue?
One interesting parting thought is that I find that sign-off can be especially rough where there is a lack of trust and cohesiveness between either the business and the delivery organization, or even within groups in the delivery organization. I think it’s common these days to blame the problems we have with getting sign-off on the traditional waterfall methodology, but I am of the opinion that the problem has less to do with the methodology than it does with the personalities and corporate cultural/political climate. In other words, if the sign-off process is rough in an organization, it is probably more a symptom of other issues than a fault of the methodology.
Your thoughts on that notion? What is your experience with document validation and sign-off? Any additional insights or pointers?
As always, I’m anxious to hear your thoughts and experiences.
Trackbacks/Pingbacks