What Requirements adds to your project toolbox
At the beginning of a project there is a goal. That goal is the desired outcome of the project – to build a house, to put on an event, to develop a website. In an ideal world once the goal is set everyone would work towards the desired result and at the end you’d have your house, event or website just as you’d specified at the beginning.
This approach is a “Waterfall”-style methodology of project management. On a simple project it can work well. Unfortunately though, it often doesn’t. As good a specification as it’s possible to write at the beginning, things change. Managing the process of how a specification changes during the lifetime of the project is difficult. Even in the unlikely event that things don’t change, being able to react if they do is a good thing. Over the past decade a new methodology has come around to improve software development and manage the risk in a project better – Agile. In a nutshell, “Agile” is a continuous assessment of desired project outcomes and whether or not the project activity is working towards what are thought to be the right goals given the available information at the time. Managing that uncertainty, whether or not the goals are the right goals, and how changes come about to alter what the goals are, is what makes Agile powerful.
Requirements works well alongside both Waterfall-style and Agile.
In a more traditional Waterfall-style approach Requirements takes the specification defined at the beginning of the project and manages it through the unforeseen pitfalls that could happen along the way. Even on a simple project it enables all the team members to maintain the same vision of the goals that will produce the desired outcome. Additionally, Requirements serves as a historical journal of project discussion – emails between team members that would ordinarily be very difficult to keep organised can be gathered together with the specification and added as commentary to a requirement. This affords a project manager a record of exactly what has changed, when and why. At the end of the project such a commentary can prove invaluable in debriefing and deciding upon project success.
In an Agile project Requirements is even more useful. Stories in Agile are equivalent to Requirements – stories define features. In the Backlog Grooming and Sprint Retrospective stages of an Agile project sprint the team look back and reflect on how things have gone and what has changed. The manager then uses those insights to update the stories and plan the next sprint. Using Requirements we make these stages better by snapshotting a project (freezing the requirements at a given moment in time) and then enabling the team to compare those requirements with the current state of the project. At a glance a project manager can inspect anything that has changed during the previous sprint. Any tasks associated with a requirement can be checked to see if they’re still valid. And, as Requirements integrations with online task management tools such as Basecamp, any changes to tasks are automatically reflected in ToDo lists immediately. Plus, of course, in addition to snapshots and comparisons Requirements also brings the tools that are advantageous in Waterfall-style projects – a commentary on requirements, a record of changes throughout the project lifespan, and reporting on the project at the end to debrief all the stakeholders.
If you think Usable Requirements could help you manage the risks in your project, get in touch now: firstname.lastname@example.org
Alternatively, sign up and try Requirements now.