Chris Ferguson #portfolio

Tips for creating project requirements

"A person holding a list of requirements so long that it trails along the floor."

This is an update of an article I wrote in 2022 when I was working for an agency that specialises in WordPress. It was inspired by the receipt of a large set of RFQs that was clearly beyond the client's desired spend, and our 5 millionth request as an agency for an .xlsx uploader and parser. The required functionality of which were specified in one short sentence.

It can't be easy writing requirements for a web project. I have to speculate, as I've never produced them, only received them - always the vendor, never the client. If I was a client however, I don't think I'd produce a list of requirements anyway (more on that later).

Having worked on a lot of tenders and projects, I've seen a lot of lists of requirements - and there are some common behaviours that cause the team working through them considerable pain and frustration. What follows is some hopefully helpful advice if you are the chosen stakeholder/owner of a project who has to have to produce a list of requirements to send out to agencies for quotations.

Do you really need that feature?

Someone gets the job of collating project requirements, and there's always politics involved: Sometimes it can be hard to say "no" (or "later"), especially if a requirement was generated by C-Suite. Of course, you can always just leave it to the vendor/agency to tell them "no"/"later" - which they will (well, the good ones will anyway) – but allowing the agency to focus on getting into the details on the features you really want will lead to better results. Have those awkward conversations internally.

Do you really need that feature now?

You may end up deciding that a feature has to be on your roadmap, but does it have to be in the first iteration of your project? Performing a bit of a MoSCoW analysis can help anyone quoting on your project understand the level of detail they need to go into in a proposal, and understand your priorties.

It can also be helpful if you advise which priorities/MoSCoW categories need to be quoted for.

Is it feasible?

It is possible to work out if something can be built even without specific/technical experience by searching if it has been built before. This will give you a good idea of the feasibility - it may still be a complex build, but at least you'll know it's possible. If you are working on a WordPress project a good tip is to perform a search to see if a plugin exists that does what you are trying to achieve.

If something hasn't been built before it can become a project in itself. So if this feature is a Must-have then at this point you should realistically look at your budget and question if this is the right solution. You should also re-assess how you are approaching the project, and if you should be dictating the requirements (we'll come back to that).

Sidenote: Beware any vendor who tells you they can estimate something they have never built before.

Be specific

This should go without saying, but be as specific as you can. Leaving little room for interpretation will speed up responses, and ensure you are getting like-for-like quotes.

The benefits...

By producing a more focussed list of requirements, and ensuring that what you want is decscribed in as much detail as possible, you will have an increased chance of receiving clearer and more accurate (and more positive) responses - and you should receive them faster. Reducing room for interpretation means vendors will be comparing apples to apples - meaning you can compare vednor quotes with more ease, and free up time to assess them on things that really matter (like the quality of their work and how interested they are in helping you achieve your goals).

There is an intangible benefit in performing these prioritisation and detailing discussions within your internal team: You will increase understanding of your project internally, and improve alignment and knowledge of your goals.

Should you be writing a list of requirements anyway?

There is one, larger point to be made about RFQs - especially if you find your list of requirements is stacked with complex monsters: Should you be sending a list of requirements, or should you be sending a list of problems?

Doctors and Waiters

"A waiter will ask if I'd like an appetizer or a dessert. My doctor will remind me that I’m 30 pounds overweight," - Jeff Patton https://it.utah.edu/node4/posts/2016/august/customer-centric-pm.php

You tell a waiter what you want and they bring it to you. A Doctor's job is to solve your problems. Why is this? because you know what you like to eat, and trust your expertise on that matter over the Waiter's. When it comes to your physiology, you tend to trust the Doctor's knowledge/experience (expertise) over your own. When looking for a technical solution to your problems, unless you have specific experience in an area, it is often better to approach projects looking for a Doctor.

Sidenote to agencies: If you're working to lists of specifications/deliverables, you should probably be using waterfall methodologies.

Working like this can be daunting: As with your Doctor, you have to trust your vendor as it is unclear what you're going to get for your money - a lot of companies aren't comfortable with this concept. It also removes the benefit of comparing apples to apples when choosing a vendor - but price and speed is never the best measure of quality anyway (where's my iron triangle?).

But trusting the experience of others by describing your problems, challenges and goals in as much detail as possible will always achieve the best results - so if I was looking for a vendor, I'd spend my time with my stakeholders understanding and describing these in great detail. Rather than an RFQ, it beocmes about asking vendors how they would approach solving these problems.

Revisiting feasibility: if you perform this analysis and it turns out your highest priority requirements have no precedent, and the project does not exist without them, then you need to re-assess what kind of project you are running and subsequently what kind of relationship you want with a vendor...

Summary