Help a BA! How Do I Get Sign Off on Requirements?

A reader asks:

How do I get sign off on requirements?

Michelle’s answer:

While gathering requirements is critical to the project, validating them with stakeholders is also critical.  There are two times during each project when I ask for sign off on the requirements from the business.  The first is when the business requirements document (BRD) is complete and the second is just prior to launch when the requirements traceability matrix (RTM) is complete.  A third review occurs during the testing phase if any requirements cannot be met by the solution; at which time I would initiate a gap analysis.

When the BRD is complete, you will have a sign off list of people who will read and validate the document.  Usually this list includes the project sponsor, the steering committee, the IT Lead, the project manager and the business lead.

The best and most efficient way to obtain sign off is to follow this process:

  1. Send by email the BRD to all the people who must review and all the people who must sign off.  Ensure that you allow about 1 week for them to provide comments.  On the email, place reminder for 2 days prior to the deadline, and place the deadline date in the subject line.
  2. If you are not hearing feedback 2 days before deadline, either talk to the team or send out a reminder email.  Talking is most likely the best as people sometimes ignore email (no – never!  :))
  3. On the day you need sign off, print a copy of your document.  If there have been changes, ensure that everyone on your list knows about the changes (send a revised email indicating a summary of the changes).
  4. If everyone who will sign the document is in your location, walk it around and obtain sign off.  If you have other locations, have them sign off on the sign off page, then have them image it and forward it by email to you.  Print this off and include with the printed copy.
  5. Once you have everyone’s signature, scan the document, save and load up to your SharePoint site or wherever you are saving the final version.

The second time you need sign off is when you have completed your requirements traceability matrix.  This ensures that the solution has met the functional requirements.  Follow the same process as you would with the BRD.  Usually this document is prepared while you are in testing, so any gaps identified would be noted on the gap analysis document and you can obtain sign off at the same time.  Your business stakeholders and IT team should be aware of any gaps prior to this document needing sign off.  I cannot remind you enough – communicate!

Interesting question. How do you get sign-off on your requirements?

Update: Michelle has been kind enough to share her sample change request template. Thanks Michelle!

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.

Comments

  1. Hi,

    Now I am working on product development. Can any have sample of BRS and requirement tracebility matrix. So that I have an idea to develop. If anybody have the document please attach the document.

  2. How do track the requirement which come pre development with IT i.e. after BRD & Tracebility Matrix are signed off. Will this be added as addedndum to the BRD ?

    Will i be required to get a sign off on the addendum, can some please share a template of the addendum to the BRD or advise me how should i proceed with this.

  3. Michelle Swoboda says

    I believe that every situation is unique and I would modify this document for your use. Usually with our changes, the business (our customer) is the one who has requested the change, so they are in the loop.
    I would add the detail you need to see. It is not a perfect document – only a sample of what has worked. Great comments!

  4. Hi Michelle,

    I reviewed your document and I have a question. It has only a change description but does not specify anything in detail regarding the change (or new requirement to be implemented). How do you explain the customer then about the new functionality? what about if we want to include mockups?

    Thanks,
    Janice

  5. Michelle Swoboda says

    Marci, thank you!

  6. Michelle Swoboda says

    Hi Janice,
    I have tried to edit the post and add a template but I cannot attach it. If you can think of a way I can get it to you, please let me know.

  7. Michelle, you are right that stakeholders take a while to digest their decisions and often change their mind afterwards. On my project I had twice-weekly meetings to elaborate the requirements on an ongoing basis, and it was often the case that things changed from one week to the next. Every time an acceptance criterion changed, I updated the Functional Spec and added the new “sign off” date to the relvant acceptance criterion. I had to use my judgment to decide when a given story was stable enough to go into a development increment.

    My own experience of formal sign-off is that it doesn’t add very much value to the process. If a solution is wrong, then it’s wrong, regardless of what the spec says – and it needs fixing. A formal sign-off allows me to shift the blame on to my customer – which is useful if money is involved – but if my customer is internal, pointing the finger usually doesn’t help anybody to get the problem fixed.

    There is an argument to say that a formal sign off makes your stakeholders take their decisions more seriously, and thus results in a better quality solution. But I don’t think it’s a strong one. Reguylar workshops and continuous refinement of the solution based on feedback is IMHO way better.

    On my current project I *am* required to get formal sign-off. But I’m with Laura on the approach – have a walk-through and then get an approval email as a follow-up (almost as minutes of the meeting). Sometimes, in order to avoid having to chase people, I write the meeting minutes myself as a record of the approval. This only works well if you have a trusting relationship with your stakeholders.

    • Tony, Great point to challenge the “why” of sign-off. As I crafted my response for this reader, I side-stepped mentioning that in many of my more recent positions sign-off was very much like you mention — a tacit approval from stakeholders that I interpreted as “ready for development.” It was a balancing act of keeping the delivery cycle fed with new ready-to-build requirements and keeping unnecessary change to a minimum. I think as an experienced BA you can get to the point where it’s not too difficult to balance that. As a new BA, it’s probably tough and more formal sign-off helps solidify the milestone until you work through a few project experiences.

      • Nick Panagopoulos says

        I tried not to address the ‘why’ we need signoffs to begin with, since that wasn’t the topic, but how can we avoid it.
        The reason we want signoff is to hold the stakeholders accountable for helping, but we treat them as people that are not part of IT.
        In a perfect world, the customer and IT would be one organization and one team. No need to sign off, because they are working out those details together, not as a formal deliverable. Contracts detract from this feeling of being one team, though.
        Failure of IT is a failure of the customer. IT needs to understand what it takes to make the customer succeed in their goals, and it’s up to the customer to properly communicate that to IT. If the two are one team, working together day-in and day-out, then we can banish the sign-off process for documents.

      • Nick Panagopoulos says

        By the way, Laura….I like your approach for ‘ready for development’, but what if the customer wants a change? Does that approval move back to ‘needs further business analysis’?

      • Nick, Yes, all changes would require business analysis. It really depends on what the implication of a change is in your project/organization environment. In more of an agile environment, a change is just one more thing added to the backlog. In a more waterfall environment, obviously change has a cascading effect and often requires multiple layers of approvals. When working in a more agile environment, I try to keep the focus on the cost of the change and ensure there is a cost-benefit analysis that is understood by stakeholders. If the ROI is there, it makes sense. If not, it doesn’t. I also try to ensure that we learn from the “changes”, so if we could have made a better decision earlier, we improve our processes. But sometimes, the change is the result of the process we went through to implement or information we didn’t have when we decided to implement and that, in my opinion, is “good change”.

      • @Nick I agree with you that too much formality can create a “contract” atmosphere, instead of a “team” atmosphere, but I think something like a sign-off is still needed, because at some point it is important to baseline the requirements document (and possibly other documents as well). Even without treating it legalistically as a “contract”, it is important to acknowledge that agreement has been reached, with a specific version of the document. As Laura states, “sign-off helps solidify the milestone”.

        To me the “signature” itself is less important than making sure that everyone agrees to the same version of the document, at which point it is base-lined.

  8. Michelle Swoboda says

    Hi Nick, I find that people leave the meeting and think of other requirements or clarification so it gives them some time to think about them and then come back with any concerns or claifications.
    Are you suggesting meeting, then some time and then a follow up meeting because that would work.
    We also have to consider our virtual teams. With my current contract – not everyone is in Calgary.

    • Nick Panagopoulos says

      Well, nobody likes too many meetings either, but you can recap and obtain approvals as part of a future meeting.
      I too like to see the documentation updated before I give my final approval. Sometimes/Most of the times, what we discuss in meetings and what is actually documented is not in line.
      I have been using web conferences very frequently, and make updates real time as we discuss the issues. This is more collaborative and people like this approach better, although it has its negatives. A good positive is that the requirement/change is worded the way everyone wants so that reqs are not misunderstood.

      I currently use the documentation approval process as well, and conform to your steps, but I think it’s rather cumbersome. As a BA, I find it annoying to chase people for approvals. Emails, reminders, etc….sometimes, people would rather have a meeting instead.

      One final point on your #5. I get all my approvals via email. Signature & scanning is good if your team is local, but I work from home. To get an email approval in a team repository (i use IBM Lotus Quickr), I print to PDF using free pdf software -> http://www.cutepdf.com/Products/CutePDF/writer.asp . I have been using this for years, and it’s better than other heavyweight PDF file creators. I just print to PDF, and I get a prompt to save the PDF file.

  9. Nick Panagopoulos says

    This is a departure from @Tony Heap’s method….. which is to get sign-off when you discuss the requirements in a meeting setting, not via some document sent in an email.
    Which would you prefer as someone signing off on a document?

  10. Michelle Swoboda says

    David, it is funny but I feel like I missed an entire piece when I wrote the article. I gather the requirements, then in a large group – validate them. Then I give them some time to think about it, prepare the documents. Then I send the BRD out for them to validate. In my most recent project – we then sat down at the table and revalidated the requirements. Then we asked for sign off.
    Do you use track changes to highlight the changes or a different method. I usually highlight the item that has been changed.

  11. Sorry – must have hit return. Was going to say to gain acceptance of any gaps in the Solution and in System Testing.

    Regards, David

  12. Michelle

    I follow a very similar approach to you, with the main difference being that I gather and document Requirements, then send out a draft document for review. I’ll ask for comments within a week, update the document and then bold q walkthrough with all stakeholders so that any questions/concerns can be addressed in front of anyone. I’d ask a scribe to capture all comments made and conclude the meeting with a ‘pre-close’ (a sales technique) – asking if I make the changes we’ve discussed will the Stakeholders sign off the Requirements.

    I then update the document with changes highlighted and issue for sign-off. We just collect sign-off’s by email ( we don’t have the ability to scan and email – although my last employer did almost 10 years ago).

    I’m in the middle of Traceability at the moment and although we don’t ask for sign-off, I will from now on to gain acceptance of any ga

  13. Michelle Swoboda says

    From personal experience, I would use a single change request document. What does your project manager or the steering committee expect?

    • I work with an internal client.
      The committee wants to have new requirements approved by users before implementing them into the system. The process is: user wants a new functionality, I evalute if it is possible to include it in a coming release, if thats the case then I prepare a requirement document. Once done I send it to the user for signing off (alway by email).

  14. I’d like your input on this:
    Currently I’m working on a new system release.
    We are going to include new user requirements. I’m not sure how to proceed on this: if use a single change request document for all requirements or use a document for each requirement. The problem with the second approach is that I’ll be sending a lot of documents for the user to sign off.
    Your thoughts will be appreciated.

    Janice

  15. Michelle Swoboda says

    Janice, I do have a template. It is at work and I will send it to Laura and ask her to attach it to this post.

  16. Michelle Swoboda says

    Allison, would you approach the RTM review and sign off by a conference call where you could use live meeting to share the document and then proceed with sign off?

    • allison crossley says

      I would Michelle. A couple of our stakeholders have on occasion requested such an medium not just for an RTM but also for general project update meetings

  17. Do you a change request template that you can share?

  18. allison crossley says

    Very interesting question indeed. It usually a daunting task to get stakeholder sign-off on requirements, especially since they are in different geographical locations within my city. The process you mentioned above Laura is feasible and has been adopted by the PMs within my unit. I think though we need to enforce a more aggressive RTM review and sign-off process.

  19. Michelle Swoboda says

    Laura and Bob, thank you both for sharing your methods. I have found it depends on the company you are with as to whether email voting is accepted or if they want a signature on the document.
    I also use Sharepoint and I find the versioning so important if I ever have to review the document.

  20. I have used the Outlook tool as feel, but that was kind of a pain, because I had to talk to several people personally to tell them to respond to the email.

    I generally take a different approach. First, I try to plan for approval, by formally documenting who has to approve up front (like a RACI matrix). Then I have a meeting with stakeholders who need to approve, we walk through the document, and I ask for verbal approval. Then I write up meeting minutes saying what happened {These people met on this date. We walked through this version of this document. The document was approved as is — with no changes.}. Finally I send a copy of the minutes by email to all participants, and my boss, and whoever else seems appropriate. I also save a copy of the baselined document and the minutes in a project repository (like sharepoint or a wiki).

    I agree with Michelle’s comments about providing the document in advance, as that is how I would like to be treated. Honestly, however, I find people rarely read the documents they receive — or maybe I should say it is a rare person that does. That is why I find it necessary to always read through the document with them.

  21. Hi Michelle,
    How interesting to read your sign-off process. I’ve frequently used sign-off mostly for scope/business requirements and then for individual sets of functional requirements. So, we might have several iterations of sign-off on different project deliverables. I haven’t done sign-off on the traceability, but that’s probably because I haven’t typically been involved in that aspect of the project.

    Most often I’ve used walk-throughs for sign-off. So yes, we walk through the entire document and then I either take a verbal commitment or a follow-up email as confirmation of sign-off. I shy away from these now for scope/BRDs but still think they are valuable for shorter documents such as use cases, which represent a subset of the entire project requirements.

    Also I once used the Outlook voting feature to obtain sign-off – which helped eliminate signatures and scanning, but still gave you a real record of approvals. That was kind of cool but then we moved away from it (and I’m not sure why).

Comment

*

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)

21689
21690

Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.