Give us the requirements first (reconsider!)
Having spent most of my professional life on the technical side of the world, I'm amazed at how often this statement arises:
They haven't told us the full requirements. Once the business users give us the requirements, we can get back to them with the level of effort.
Are you on the technical team? Before uttering the above words, first consider whether you are missing an important opportunity to shape the requirements. Are you on another team? Try to use the points in this blog post to encourage more of a dialog with developers.
Obviously the word "requirements" is not ideal in the first place (probably a blog post topic on its own). Some people get hung up on "a requirement is a requirement", but requirements are more subtle than that. By slightly shifting assumptions, you can often satisfy the underlying need with different written requirements. For example, I might say "I need an email when a user signs up for our newsletter". But what if I got the response "since we already all carry cellphones, and we have such a specialized newsletter that sign-ups are rare, could we send it as a text instead — also, you might not be aware that we're having problems with our email notification system so would rather add functionality to it"? I might say, sure that's fine. So if I stuck to the requirement as originally-stated it might take a long time and lead to greater instability, but by talking about it we wound up with a reasonable (perhaps better) solution that is more stable. Yes, if you're a stickler then you might say that the true requirement was notification and not email or text specifically, but the point is that talking about the requirements is more effective than lobbing written documents at each other. Obviously, this was a trivial example, but your requirements probably are not trivial so the ante is higher in moving toward strong requirements.
Why teams are tempted to use the give-us-the-full-requirements-first approach?
Some possible reasons:
- Business users often do not understand their own requirements, and technical teams have been burned with shifting requirements once development starts
- Being overwhelmed with requests, this maneuver helps ensure that the business group is serious about these requirements
- If the work will be farmed out by the technical team, having very clear up-front requirements will help in that process
- Pure CYA (cover your ass), especially if relations between technical and other teams have significantly broken down
What are the problems of shifting the burden to the business side?
A few main issues:
- Extended time period from initial idea to implementation.
- Limited opportunity to define ideal solution.
- Increases adversarial relationship.
The first two issues above arise since there could be a very wide gap between the expectations of the business users and what can be implemented. Let's say the business users are imaging a castle, and write a huge document laying out the castle requirements including a moat. The technical team sees this and all they can work with is leather and wood, so they suggest a tee-pee with a pond. Obviously, if this is the start of the "negotiations" then it's going to be a long discussion (especially if the teams just lob documents at each other). Let's say that you eventually end up with a reasonable brick house (perhaps the masons on the tech team became available). Another subtle issue that arises in this type of arrangement: the business team still remembers that they wanted a castle and will compare the end result to the castle. The technical team will remember they first wanted to do a tee-pee and think anything about that is a favor. So the expectations really did not start things off on a good footing.
Collaborate instead
So what is a better approach? Collaborating from the start. From the technical perspective, you have the opportunity to shape the requirements in a useful direction. Some specific recommendations:
- When first discussing requirements, always make it clear what elements of the request are easy and what is difficult. Moreover, consider how if the requirement changed slightly and the approach was a bit different, it would be far easier and more reliable to implement. In addition, the business team should consider the impacts to them if the functionality is implemented (for instance, the need for community manager to drive a new forum).
- Have a process for product managing these change requests (including deciding what gets implemented and what does not), and have product management take the lead on bringing the teams together to deliver a high quality and consistent implementation.
- Don't implement anything that will cause significant degradation of overall quality or reliability.
- Document the pros/cons and decision process.
Agile methodologies help encourage a more collaborative approach, but regardless of the methodology you use consider working with the business users in developing your requirements.
