Effective collaboration is key to the success of business projects and transformations. By working together towards a common purpose, individuals can create greater business benefit.
Collaboration can be particularly beneficial during requirements gathering, when it is crucial that relevant voices are heard and that all parties are pulling in the same direction.
This article explains the advantages of eliciting, capturing and managing requirements collaboratively and provides tips and tricks for doing so successfully.
Who needs to collaborate?
Project teams are usually formed of diverse individuals and parties, each with their own agenda. Business executives and sponsors, suppliers and contractors, business analysts and business representatives all have a role to play.
The requirements gathering process phase is likely to involve a broader group of stakeholders too, including the management board and end users from various business functions.
Everyone has something to contribute, be it an executive’s big picture understanding of a high-level business need or a finance representative’s specialist insight to a niche business process. A collaborative approach enables individuals to make their contributions more easily.
Eliciting requirements collaboratively
There are many tools and techniques for eliciting business requirements that offer a more sophisticated approach than simply sitting a group of stakeholders around a table and asking them to brainstorm system requirements.
The most commonly used technique is based on business processes: talking through the steps taken to achieve a business output. Role playing can be a fun approach here, with representatives from sales, finance, marketing and operations acting out typical, day-to-day business process interactions.
An alternative, more structured approach is to begin by defining high-level business requirements and then to gradually unpick the lower-level requirements underneath this.
However, this approach carries a risk of compartmentalising different business functions, permitting teams to champion their own high-level requirement and disregard those ‘belonging’ to other teams.
Another technique is to hold separate sessions to gather requirements relating to each of the headings under ‘FURPS’: functionality, usability, reliability, performance and supportability.
This can help business representatives to think beyond their own business area and imagine how it might feel to use the new system and what features and functions will have benefit for all users.
One risk of a highly collaborative approach to eliciting requirements is that too many requirements are collected. If everyone is encouraged and enabled to contribute, the requirements elicitation phase can drag on and a completely undeliverable number of requirements will be captured.
Business analysts can help to mitigate this by identifying ‘nice-to-haves’: smoking out superfluous requirements with polite challenges such as “Which other teams need this feature?” or “How do you manage without this function at the moment?”.
Despite this risk, it is undoubtedly preferable to make sure all voices are heard than to overlook a reticent team and thus fail to deliver a crucial area of functionality.
Capturing requirements collaboratively
The seemingly innocuous process of writing down the requirements that are elicited can in fact be a very challenging part of the requirements gathering phase.
‘Capturing’ requirements can be surprisingly contentious, with project members often disagreeing vehemently over words and phrasing. This is where collaboration really comes into its own.
If requirements are elicited collaboratively, project members are more likely to understand each other’s viewpoints and feel a sense of shared ownership of the requirements. This, in turn, makes people more willing to negotiate and compromise.
The basic rules of requirements capture still apply: state goals or needs rather than solutions or procedures, be clear but not overly prescriptive. It can be helpful to posit a first draft of a requirement and then encourage the group to restate it together using alternative words.
This cooperative approach is more likely to achieve buy-in from the whole group. It should also reduce the number of dissenting voices when the document is circulated for comment and ultimately makes it easier to achieve sign-off from the project sponsor.
In the early stages, while requirements lists and spreadsheets are still works in progress, a high degree of document-sharing can be beneficial.
Disparate individual stakeholders or teams from different business functions can be given access to outline requirements documentation and encouraged to flesh out their sections as well as reading those added by others.
Shared ownership of the document allows stakeholders to see the volume and range of requirements that are being proposed. This helps them to understand the scale of the challenge and is an important part of managing expectations.
The role of collaboration in managing expectations
It is inevitable that some level of competition will develop as requirement sponsors push to have ‘their’ requirements moved to the front of the queue, but giving all contributors sight of the complete list can mitigate this to some extent.
Managing expectations is a key skill for a project manager, as interested parties are likely to optimistically assume that the new system will solve the problems and frustrations they encounter while doing their jobs.
They may be surprised and disappointed by the small scale of the initial software delivery. It is understandable that individuals and teams may be upset if ‘their’ requirements are delayed or de-scoped.
However, a collaborative approach can enable stakeholders to cultivate a common goal of successfully delivering a minimalist core application – with limited features – that lays the groundwork for future development and enhanced functionality.
Managing requirements documentation collaboratively
Any business analyst or project manager knows that requirements documentation can quickly become unwieldy. It is not unusual for large projects to have hundreds of requirements, not to mention multiple versions and ‘cuts’ of the requirements documents.
Mistakes and confusion can easily arise and these can have serious consequences: wasted time and effort, disappointed clients or the delivery of functionality that is not fit for purpose.
Careful document management is always important in projects and programmes, but this is particularly the case when collaboration is actively encouraged.
It is necessary to establish who owns the requirements documents and which individuals are authorised to edit them. One approach is to allow everyone to access the document but insist that all changes are channelled through an agreed person.
Change control is vital for avoiding duplication and confusion: updated versions must clearly state who made the changes and when and which requirements are impacted.
A dedicated requirements management tool can be a real asset to the project team, facilitating shared working and offering document control and other invaluable features.
The value of the requirements documentation increases as it is shared and used.
It is therefore important to make these documents easily accessible, perhaps through a shared project folder or intranet site that also contains other key project documents such as the project charter, plans and timelines, status reports and contact details.
If all members of the project team – including contractors – have access to this information, communication and understanding will be enhanced. A great deal of business benefit can be gained from ensuring that all stakeholders feel included and informed.
A project where the project sponsor, project team and wider stakeholders are all pulling in the same direction stands a good chance of success.