Deferred Requirements – More Harm than Good?

November 17, 2010 at 5:44 pm 6 comments

I could use some input.  Many requirement management frameworks state that you should include out of scope and/or deferred requirements in your specifications.  While I understand the nature of this direction, I find myself wondering if it sets a false expectation.

On the positive side, capturing these requirements and referencing them in your documentation provides comfort to the stakeholder who provided them that their input was not ignored.  However, documenting these requirements does nothing actionable, which is why I struggle with the value of including them in the specification.  It does not guarantee that the requirements will be worked in a future project.  Unless someone facilitates turning those requirements into a corresponding project, we may find those same requirements still sitting in a document years later.

As an alternative, as a Business Analyst, I have typically taken any deferred requirements and worked with the stakeholder to determine if they truly warrant a project of them own.  If a business case can be made, I help them get the request submitted.  If the Business Analyst is not in the position to help with this step in the process, then it could end up being passed onto someone else, who fails to take action.  Either way, having requirements documented offers little assurance that the work will be done, in my opinion.

If you have experiences, positive or negative, in the handling of deferred or out-of-scope requirements, let me know your thoughts.


Entry filed under: babok, Business Analysis, Business Governance, IIBA, IT, PMO, project management, Requirements Management, Technology. Tags: , , , , .

Why I Love Twitter Should Quality be a Variable

6 Comments Add your own

  • 1. Karie Price | Real World BA  |  November 17, 2010 at 9:48 pm

    Hi Jenni,

    I typically do *not* include out of scope requirements in my specs for a variety of reasons.

    1) As you mention, there is nothing actionable that will result from the work.
    2) It adds time/cost to the current project for items out of scope.
    3) it causes confusion as to what is actually delivered. I view the specifications as the details of what is being delivered and if what is documented may not be delivered, you lose the benefit of having a set of documentation that represents what is deployed.
    4) if you’re not delivering it now, how do you know that what you specified is the solution that will be implemented later.

    As an alternative, I keep a future enhancements log for all of those items we’ve removed from scope. I include enough detail or notes to capture the high-level content or problem, as well as any impacts that can be quickly identified. If there is time between projects (and depending on how your organization allocates resources) you can spend time writing business requirements for the highest prioritized items so that they are ready for future projects.

    This allows you to focus on the in-scope items without delaying project delivery or focusing on those items that for whatever reason were not prioritized to be included.

    Does your organization utilize a backlog of any kind that could be leveraged?

    • 2. jennidoyle  |  November 19, 2010 at 12:57 pm

      Thanks for your contribution to the discussion! Your requirements log is a good idea! I do keep an application portfolio/backlog where I add Business Requirements for potential future efforts. Your concept would blend with my portfolio well.


  • 3. Dave Schrenk  |  November 19, 2010 at 12:06 pm

    For out of scope items, I only document the highest level business requirement. I feel that this helps clarify the boundaries of the current project effort.

    For deferred items, we usually only document them for projects that are planned to have multiple releases where future releases will not be defined until later. These may be enhancements or requirements where there is a workaround of some sort and business decided that using the workaround will not have a major impact on system acceptance. But, in future releases, which might include deployment to a larger user group or market segment, the impact of the workaround might be larger. In those cases, we document the requirements since there is a high potential that they will be included in a future release. Other than this scenario, I agree that there is no value in documenting deferred requirements.

    • 4. jennidoyle  |  November 19, 2010 at 12:54 pm

      David – thanks for your input!! I like the idea of the highest level business requirements being included.

  • 5. Gayle  |  November 29, 2010 at 9:14 am

    Hi Jenni, I agree with David. When we had the business requirements or features in our V&S document, then we would list these high level requirements. They were not taken forward into the SRS. So, explaining to the business that the SRS is the governing document for development and testing, helped with the issues of communication with the business. However, the out of scope high levels were captured in the V&S for future use.

  • 6. jennidoyle  |  December 17, 2010 at 7:45 pm

    A little closure to this story! For the organization that I’m part of now, we opted to capture Deferred Requirements in our documentation (BRS). Assuming that the Deferred Requirement is included in the final approval and the costs of the requirement are included in the business case, they will be worked by IT at a later date. The Business Analyst will be responsible for documenting them and then turning them over to the IT Application Manager responsible for the area impacted. The IT Application Manager is then accountable for working with the business owner of the Deferred Requirement to find an appropriate project/release to deploy the requirement at a later date. The requirement will still have to be ranked against other work planned in the organization – no freebies or gimmes – but it will get worked.

    I think what this does is 2 things – first, by documenting the Deferred Requirements in the BRS, we show the Business Stakeholders that they were heard. This is important in developing & maintaing relationships. Second, it puts the accountability in the hands of the business owner & their IT partner. A business owner shouldn’t have to fight to be heard after the requirement is identified as deferred. If the requirement wasn’t truly worthy of being worked, it should be identified as Rejected – not Deferred.

    I really appreciate everyone’s input! Every organization has to weigh standards/best practices against what their culture will accept. I love having multiple perspectives from you guys – please keep commenting!!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 39 other followers

Top Posts & Pages

%d bloggers like this: