Functional requirements sign-off

Hello, and welcome to the fifth and final video in my mini series on ecommerce replatforming Discovery. We’ve already talked about what discovery is and why it’s important, how you plan, how you run workshops, how you prioritize the documented requirements. And now the last short and sweet video is about ensuring you get a proper sign off for the requirements that have been documented and captured in the workshops.

It’s amazing how sometimes this can be missed off from the project management process. But it’s really important. There needs to be an audit trail of evidence that requirements have been signed off by the appropriate stakeholders before they’ve been passed down into the project to go into development queues. Otherwise you can end up creating future headaches and arguments where people say, “Well, no, that’s not what I agreed. I didn’t sign those off. That’s not what I asked for.” And then the people who have captured are saying, “But that’s what we thought you meant and you didn’t tell us we captured it incorrectly.”

So we need to nip that in the bud and make sure that everyone has bought into the requirements. It doesn’t mean that you can’t then update and amend later on. That’s what agile methodology enables. It enables you to come back and revisit in the light of decisions made based on knowledge progression during the project. But it’s really important that you have a starting point where people have put the time and effort into reviewing requirements properly and providing a sign off.

So the process should be as this. You will have had somebody, hopefully a qualified BA, document the requirements in each of the workshops. After that workshop, once those requirements have been documented, they should be then peer reviewed. If there’s a project manager or a business lead who’s helping guide the project, ask them to peer review to make sure that there’s no glaring omissions or errors, and make sure everyone’s happy that things are documented accurately. And get those requirements out to the stakeholders who attended that workshop who have sign off authorization.

On small projects, each stakeholder will look at the full requirements set for a workshop and go through it. On larger projects where you have many people attending, what can really help is appointing a senior stakeholder who has the authority to sign off on behalf of colleagues. Therefore they can take the pain point away from the BA and do a bit of liaising with their colleagues to ensure that they’re happy the requirements accurately reflect everybody’s viewpoints.

Ensure that there is an authorized person to do the sign off from the business point of view and also the technical point of view. Send the requirements across, giving them a brief, give them a timeline within which to reply so it’s not an open ended “please review them” and then you wait for weeks.

It has to be tied back in with the project timescales so that they know how long they’ve got to do it. If there’s any amends, you can edit and tweak and then send back so that they can see and do a final sense check. Make sure you’ve tracked those changes that they know what has been updated.

Once each of the capability requirement catalogues have been signed off, it then pays to circulate them to the people who are responsible for those areas of the business to say, “Look, your teams have reviewed and signed off these capabilities. You have them for the next few days if you would like to sense check and review and make sure they accurately reflect your part of the business or if you would like to discuss them with your team ahead of those being officially signed off for the project.”

This achieves two things. It gives the senior person who’s got budget responsibilities for that part of the business the ability to sense check if they want to. Some people like to get into that detail, others don’t. Secondly, from a political point of view, it has given them the ability to get involved, to sanitize those requirements in front of them rather than them later on in a project maybe having a nasty surprise and saying, “Well, I didn’t know that that was not in the requirements,”

If they’re been involved, the project team can say, “Well actually, yes, we did engage you in that process.” So it does help protect the project team against any future accusations of you did not share or involved us in this.

The next thing you need to do is ensure that you have the authorization sign off in writing. It might seem tedious and a bit autocratic, but that is a pretty important thing to do. That can be as simple as an email saying, “Yes, I approve these requirements as of this date.” Some people use document management systems to do that so the document has a signature on it and a date on it. Or they use collaboration tools where the person goes into the ticket where those requirements catalogs have been added and adds a comment that says, “Yes, this has been signed off.” And they can close that down and that is authorized.

A good example; you add each requirement set to a new Jira ticket. Here’s the requirements catalog. Yes, we’ve approved it. That ticket is now closed and signed off. Brilliant. It doesn’t matter what tools you used to do at. The most important thing is you have a established process that everyone knows for reviewing and signing off those clients before they get pushed down into development streams.

Hopefully that’s been useful. As always if you have any questions, please email me, james@digitaljuggler.com, or drop a line through LinkedIn and Twitter and you’ll find my contact details on the website