Dear Savi,

Why were they not listening much EARLIER?

Got a problem that needs solving?

I think this is something you see a lot of in projects. I searched through recent responses and could not find a scenario exactly like ours so I hope you can help us, and anyone like us.

Ten months ago, we embarked on a major systems replacement at our charity. We achieved Business Case approval for the budget, but target timeframes were short and we were forced to run a very quick requirements exercise to allow us to start the bidding process from potential suppliers.

So, the project set off with the best intentions to document our requirements. I can probably say we encountered pure bad luck in this stage.

As well as the short timeframes issue, we just got a ‘bad’ bunch of volunteers to represent our requirements. Workshops were chaotic. They resembled giant talking-shops about the charity’s problems. Despite thorough briefings about the project scope, you would have thought we were planning Amazon’s next website based on some of the impractical and wildly expensive requests we heard.

In hindsight, we should have approached the process of gathering requirements entirely differently, with specialist help for business process mapping, and a focus on what each business areas really needs, instead of what they would like. This was suggested but did not lead to additional spending on that resource.

So not only did we know at the time that we had a messy list of requirements, but we also had a suspicion it may not be complete either.

Fast forward to now. We are in the User Acceptance Testing stage and in every week’s testing session, we have some of the same individuals spending their time chaotically testing the system and raising many new requests on a daily basis for software they now say is critical for the launch.

Of course, we assess everything and have manage to push back on certain items yet there is a huge gap in our system around business rules that we must now fill. Plus some of our testers are already saying the system won’t meet their needs without the things they didn’t mention when they were asked months ago.

Our supplier is helpful and we are working in an Agile way, so have adapted to take up some new requirements. But the supplier has requested a Board meeting and it looks like we are heading towards a project extension and budget increase.

I can accept that. My major advice request is how we can stop the rot? How do we know we will have enough cover to complete the project launch without having to re-run ‘discovery’ (and possibly even requirements gathering) with our users?

It would be great to get your perspective, Savi.

Wishes He Had a Time Machine

GetSavi response:

Dear Wishes He Had a Time Machine

This is a tough situation. I will start with a reminder on best practice here, which I understand would be more help if you really did have a time machine.

This is a reminder of why it is so important to structure and manage users during the requirements gathering exercise, as it causes issues later if not well run.

This role carries a lot of responsibility in helping articulate the difference between must-have requirements to deliver business needs versus the a wish list. Both have a place, but it is important everyone understands the difference – and what they will be getting during the project.

Like you, I am more concerned about what happens now.

Really, there are only two main options (a) carry with a poor set of requirements and hope for the best, or pause the build stage while you solidify the requirements.  It can be tempting to consider (a), especially in an Agile project where some things can be added as part of the build. Pausing the project build could be embarrassing and is an admittance that something has not gone to plan on earlier phases.

However, we know automatically that the right thing to do is (b) and pause the build phase while you improve the requirements. If you need reassurance on this, consider one thing – I can promise you that any problems you get for pausing the project at this relatively early stage, will be about 1% of the problems you would experience later if you carried on and tried to go live with the output from your current set of requirements. That’s the stuff that gets people fired!

During this pause, you need assess what is to be built and its alignment back to your requirements. You must get to the bottom of missing requirements and help your supplier re-estimate the size and cost of a project extension. However, you can also exercise scrutiny over this list.

If something is not vital to the launch or may provoke a new decision about what areas to include in your new system, you may be able to win back some time and budget.

My major advice about your testing and user involvement in this exercise is to re-assess capabilities.

If certain individuals are causing chaos rather than helping gain clarity on what is missing, consider not including them in this stage. Politically, this can be described as doing a wider review of requirements for that business area (but with other people who also know what that areas needs).

Finally, it sounds to me like you and your team need to re-evaluate the discipline of testing.

Testing should feel like a quiet, scientific process. This means structuring the people, tools, timeframes, and feedback processes for any testing that takes place.

You may need help here and if you have a choice, choose someone who is very details oriented and good at getting people to complete and return tasks with minimal fuss.

This is the testing discipline, and it has no space for passengers who want to drag it off course.

On that point you may need your Sponsor or Senior Management Team to help with the messaging because testing is where the users start to take some responsibility for signing-off that the system meets their needs. It’s usually called “user acceptance testing” for a reason – The users (and it can only be actual users) are accepting they have what they need.

The clearer your reporting process during testing on issues found in testing, or new requests raised,  the easier you will find it it to manage your project back to where it needs to be.

I wish you luck in re-shaping things.

SHARE THIS STORY

Share your thoughts!

Add a Comment

Your email address will not be published. Required fields are marked *

Related Letters

Q-U-A-L-I-T-Y

Our whole team is writing to you here. In protest! Not against you (!) but against our current supplier. We will save their shame by

Read More »
Shopping Basket