A few weeks ago, I posted about how to validate requirements without a formal, tedious, requirements walk-through. Alex Papworth followed up with an interesting comment and question:
There is a point when you need commitment or signoff from stakeholders. This is necessary when estimates are provided and requirements need to be frozen (not talking Agile here, obviously!).
In this instance, the requirements document is more of a contract and the walkthrough of the requirements is necessary to flush out any more issues and achieve consensus and signoff across a group of stakeholders.
Ah, yes, the infamous need for the “requirements contract” and the “fixed estimate.” As IT professionals, don’t we have a love/hate relationship with this notion? On the one hand, we get to fix the scope upfront and put up a wall against changes that throw us off track. On the other hand we are asked to provide a fairly detailed estimate on what it will take to build those requirements and this estimate becomes as hard as a rock, even as other aspects of the project change.
Drawing a line in the sand with a requirements contract leads to all sorts of nasty behaviors throughout the course of the project. In environments where uttering the term “requirements change” has an absolute negative connotation, people will go to great lengths to get around such changes. And in these circumstances the following types of behaviors appear to be perfectly rational:
- A misconception on the part of the business that they have provided all the required information and it’s in the hands of the IT team to deliver.
- Provides the business with a heavy hand when unexpected constraints arise during design and implementation…after all, “it’s in the requirements” and “you promised to get it done in this amount of time”.
- Leaves teams battling over the line between requirements and design instead of aligning around what is needed and wanted.
- Puts business analysts and project managers in a position where they feel like they should change out the deck, reinterpret and reclassify language around the requirements to accommodate the unexpected.
- Leads to IT team members scrambling through a long document to prove “it’s not in the requirements” instead of discussing the problem and collaborating on a solution and figuring out what it will take to solve it.
- Developers work overtime to meet the commitments they made months ago.
- Quality is sacrificed for a dedication to delivering “the requirements.”
All of these behaviors contribute to an “us vs. them” mentality. Because in all reality, a fixed scope, as defined by a requirements document, does not equal complete alignment or clear expectations. A requirements contract feels like a fool proof guarantee when the reality is anything but. As gaps are uncovered and failures mount one on top of another, we initiate a nasty cycle where the business stuffs more into the requirements to ensure they get what they want and the development team inflates their estimates to leave time for the unexpected. Both sides lose credibility because neither is able to truly live up to a requirements contract.
So my answer to Alex is to get rid of the requirements contract. And, realizing this might not be in your control, yes, a walk-through might be the best possible way to achieve a bit of real alignment and collaboration before a few choice people are forced to sign the dotted line. As part of this process, set-up some practices for ongoing communication, collaboration, and, yes, a bit of re-negotiation.
|
By Laura Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura Brandenburg |
Related posts:
Loading ...
{ 1 trackback }
{ 9 comments… read them below or add one }
All very TRUE Laura!
I wish that we could rework that contractual obligations that we have and have discussed this to no avail. Your last paragraph exactly illustrates what we have found ourselves doing instead. There is a very visible movement to better collaborate and work together. Two things come to mind when reading this article that you or other might find helpful.
The first is a checklist that IT is providing to our business customers across the board. The checklist covers what IT feels is a suitable and acceptable requirement for turnover FROM business TO IT. This includes the understanding that IT conducts additional detailed analysis at that point. This checklist follows the requirement(s) through the life cycle and is used to validate by both business leaders and analysts as it moves through the SDLC. On projects, requirements are grouped against a single checklist and there are several per project, while in Change Management, the checklist is actually attached to the ticket.
The other thing that we are making sure happens more consistently is getting the developers, testers and designers engaged much earlier in the process. This enhances the collaboration, short circuits potential architectural/infrastructure issues and provides insight to business customers about what IT has to deal with.
Thanks for your article. You could write a whole book about this and never be done.
DougGtheBA
Hi Laura
sadly, I’ve found the same inability to change this. I am no fan of the requirements contract – it is bad for all the reasons you outlined above. It’s embedded in the process where I work and we don’t have the ability to propose changes to this process (or not quickly at least).
The best approach is to develop a trusting and open relationship with your counterparts on the business and COLLABORATE as the project moves forward.
Also, work very hard with the business to bring alive the the requirements document so that you can be sure that it is a complete and high quality document. In defence of my organisation, if you are measured on your abiity to manage a project to within a percentage of a cost estimate then there is need to have a very clear understanding of scope and manage changes to scope.
Keep communication lines open, keep communicating requirements in different forms (e.g. early prototypes, screen shots) as the project progresses and maintain a good relationship at all times.
This is one of the great advantages of Agile but only if the organisation is comfortable adopting this approach.
Alex
Yes, yes, yes, Laura!!!
Years ago I had a “lightbulb above the head” moment when I read Fred Brooks paper “No Silver Bullet”. http://selab.csuohio.edu/~nsridhar/teaching/fall07/eec521/readings/NoSilverBullet.pdf
It dawned on me that the reason all these projects were miserable, stress-inducing failures (“death marches” according to Ed Yourdon) wasn’t that we were doing the process badly. It was the process that was broken, not us. By “process” I mean waterfall style, big requirements document up front with structured methods.
In his paper Brooks has the following to say about requirements.
“The truth is, the client does not know what he wants. The client usually does not know what questions must be answered, and he has almost never thought of the problem in the detail necessary for specification. … in planning any software-design activity, it is necessary to allow for an extensive iteration between the client and the designer as part of the system definition.
…… it is really impossible for a client, even working with a software engineer, to specify completely, precisely, and correctly the exact requirements of a modern software product before trying some versions of the product.”
In other words, the act of defining the requirements changes the requirements as the client develops a deeper understanding of what is necessary. Then as the application is built the client’s understanding of what is both necessary and possible continues to develop.
Any attempt to define the requirements up front is pretty well guaranteed to freeze a wrong, inappropriate set of requirements and punctual delivery of an application based on them is possible only if the client is steamrollered into accepting the wrong application.
A very insightful article, as well as “spot on” comments and experiences from the contributors. I do favor the contract and unless, and until, software development can live with one, we face a credibility gap. I’ve, obviously, faced the situational drawbacks of the contract. No one can honestly say they have not and be involved in real projects.
But the contract is, strictly speaking, a feature of traditional project management vs. incremental and iterative [what most call the agile approach!]
Incremental development necessarily breaks up the requirements into either features, user stories or, ideally, use cases. Since the goal of the increment is working code [actual functionality] and rarely is the entire requirement achievable in the increment, the contract is focused on actual results.
There is the proverbial slight of hand involved in this approach and highly trained and capable requirements analysts are required to make this work. The feature description or story or use case is a contract but only loosely so.
My advice, like Laura so wisely opines in her post, is to stay away from the contract/traditional approach. But if you must adhere to it, create a change process and a panel to adjudicate changes in advance of drawing up the requirements/contract. In fact, author a requirements management plan to guide projects including the detailed change process.
Nice, thought provoking article, Laura, and great comments by all.
I hear Alex’s plight on this one. I think that most would agree that using sign-off to indicate requirements are “done” in a contractual way does more harm than good and would love to do away with it in its current form.
How can anything positive come of an agreement where we’re asking stakeholders to, in essence, freeze the requirements when everyone knows we don’t know all the requirements yet? “And by the way, business owner, even though we all know we don’t know all the requirements yet, we’re not going to do the first bit of design until you’ve signed-off, and it’s going to take an act of deity to update the requirements from here on.”
As a practical matter, though, “sign-off” will continue to be a required milestone in many organizations – and may even be required long into the future 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 signed in blood 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.”
See http://www.processimpact.com/articles/customer.html
I think the business understands 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 affect 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, they will be evaluated and we’ll come to a mutual acceptable agreement as to what changes are made.
I think 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 think it is possible to baseline documents – yes, even to get signatures – without it being the nightmare that it is in many traditional waterfall shops.
We could tackle as a whole separate topic why no one wants to read the BTD’s (big thick documents) in the first place, let alone sign-off, but I digress…
JB
I’m with Alex on this one, I’m afraid.
Big waterfall projects are fixed up front so that a goal can be met, and that goal is cost, not quality, no matter what any high-falutin’ supplier CEO might try to tell you. Once the client fixes the price they’re willing to offer, the supplier fixes the services they’re going to supply for that price. The more ambiguity they think they’re taking out of the scope up front, the better. (We, of course, know that cheap requirements are ambiguous requirements.)
Once price is fixed, the PM is measured on his ability to hit that price, with sometimes the deadline being the second most important measurement, sometimes the first. Quality is expendable. The requirements contract is a round-about attempt to fix quality, but not the obvious way it seems – no, the point of a requirements contract is to force the client to accept both changes and the cost of those changes in order to receive a working product. The changes to the requirements bring the project back on track and realise the potential for profit to the supplier.
Cynical or Realistic? You decide. Anyway, cost-based measurement is the issue which has to be relieved, if not entirely solved, before the up-front scope setting contracts can be released from duty. In brief, you’re talking Agile!
By the way, (if you didn’t notice) I really dislike the requirements contract, and tend to set high estimates for my time if asked to work within that framework. At least then I, with as much of the team as I can muster, can give it the best shot I can at being right first (and only) time.
Paul
Thanks everyone for all the great comments!
@DougGtheBA I agree, getting the implementation team involved early is a great way to encourage collaboration!
@Alex Papworth I sympathize with the inability to change your situation and applaud how you are approaching things to improve them. I love the statement about “bringing the requirements alive” and that is a main driver behind my passion for UI prototypes.
@James Christie Thanks, thanks, thanks! I agree that as you define and build (and define and build) changes unfold. Flexibility can lead to increased creativity and better solutions. But I have to politely disagree that “ANY” attempt to define requirements upfront is going to freeze the wrong set of requirements. I am all for defining features/scope/etc upfront at a certain level to support planning. It’s the freezing and the sense of a contract that creates negative behaviors, such as the steamrolling you mention.
@Joseph Butson Thank you. I do agree that stories are mini-contracts and that some of the behaviors can surface at a micro-level within an agile environment…no less maddening and possibly worse because you must deal with them every day.
@Jonathan Babcock I have used the baseline concept. I think it is a good one. I can also remember (to my personal regret) wasting a good week or two facilitating a baselining process when we could have been digging deeper into the most risky unknowns. Was the trade off in time spent baselining (and aligning the multiple development groups involved) worth the delay in getting into the gnarly details? Probably, given how the organization approached projects at the time. However, in more recent projects I’ve focused on baselining at a higher level of granularity, giving the team more wiggle room in the details as we learn more. I’ve actually found it to be faster.
@Paul Thomas I vote cynical AND realistic, unfortunately.
I am just not willing to accept that we should knowingly sacrifice quality by engaging in a process in which we know it will be sacrificed. I think you bring to light the fact that this problem is really one to be addressed at the executive level. It’s difficult for an exec to sign-off on big investments with relative uncertainty as to what they will get for the money. In reality, they might be doing it anyway. But it sure is compelling to have a defensible contract to fall back on.
Laura writes “But I have to politely disagree that “ANY” attempt to define requirements upfront is going to freeze the wrong set of requirements. I am all for defining features/scope/etc upfront at a certain level to support planning. It’s the freezing and the sense of a contract that creates negative behaviors, such as the steamrolling you mention.”
I have to politely agree with you (with a somewhat red face). What I meant, but did not write, was that any attempt to define the requirements precisely & completely up front (ie define and freeze) is guaranteed to kill the quality. I agree there has to be a first pass for planning. That’s the trouble with blog comments. One just dashed down one’s thoughts without checking that the words reflect one’s thoughts. Mea culpa.
Hi James,
).
No problem and thanks for taking the time to clarify. I can politely agree that the “attempt to define the requirements precisely and completely upfront (i.e. define and freeze) is guaranteed to kill the quality”. I would just add “at a low level of granularity” because I think it’s the granularity that is key (though I have not actually written that yet
Cheers,
Laura