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: usable@usablehq.com

Alternatively, sign up and try Requirements now.

Today we’ve deployed out a new version of Usable Requirements. We’ve made managing project requirements even better.

It’s more beautiful. The new version of the application is more readable thanks to revamped fonts and layout. We’ve tweaked the themes so there’s more variation, improved the colour schemes, and added labels to absolutely everything. We love the new look and we hope you do too.

We’ve add status markers. The current status of any requirement or task is immediately obvious thanks to a new colour flash on the left side of each item. You can see the status of your project at a glance. The markers flow through the entire app too, so you’re never left wondering.

We’ve made preferences easier to update. With Requirements we know you want to be in control of your account. Previously the way the app works and the way it looks were managed separately; we’ve consolidated these preferences on to one page so you can manage your settings more easily.

We’ve updated the dashboard. When you log in to your project you’re presented with a dashboard that gives you easy to understand yet in-depth data about how much activity there is on your project. You can see recent updates to requirements and tasks, change activity, and more.

Account updates happen in real time. We’ve take the protocol we invented for the Requirements app to keep projects up-to-date in real time between logged in users and re-used it on the account management application. This means any changes to a user in an account or project are automatically sent to all the others in that account or project. This means everyone knows exactly what’s going on all the time.

We also fixed some bugs, improved the speed of the application, and added some code to make building new features faster. We’re keen to hear from everyone, so drop us a line at support@usablehq.com and let us know what you think.

If you’re not managing your goals, driving your tasks and tracking what changes in your projects, sign up for Requirements now.

We’re really happy to announce that Usable Requirements is now in Open Beta. Hop over to the Usable Requirements website and you can sign up for an account today. Pop your email address in and you’ll get an invite right away.

What is Requirements?

Project management tools tend to focus on when things should be done, not what things should be done. We feel that this is the wrong approach to managing projects, especially if what needs to be done is changing quickly. Teams get out of sync with one another very easily – what might be a vital and important change can be lost in an email or a change to a document, and missed entirely if it’s a task on a ToDo list that’s been ticked off.

Requirements changes the focus of project management from when to what.

Usable Requirements is a requirements management tool. At the beginning of the project, and then throughout the project as a continuous process, users are encouraged to communicate and collaborate around the project goals. As things change, as they’re completed, and as they’re discussed all of the project information is captured in one readily available place – the requirements list.

To capture the requirements at the beginning of the project you can import your existing specification document; uploading a Word document or a PDF and converting it to requirements is an simple and straightforward process. Once the content has been read by our content server you can simply highlight blocks and turn them in to requirements. And we’re working on making it better by automating the requirements capture process even more.

Once the requirements are in place everyone involved in the project can add comments and discussion points to the requirements. Those comments can drive changes to the project. Changes give the project manager and client a good overview of the project – points that cause more discussion and have more changes are most often the points that are most contentious. Requirements draws out the areas of the project that need to be looked at most before being signed off.

Once the project specification list has been agreed the on-going day-to-day tasks can be driven from those requirements. By associating the tasks to requirements everything that’s done on a project is given context; a task exists to drive the project to completing a goal. Those tasks can be sync’d with existing services such as Asana and Basecamp so your workflow doesn’t have to change.

All of these features and more are available now – sign up today.

We didn’t set out to create yet another project management tool. There are plenty of those around already. Tools such as PivotalTracker, Asana, BaseCamp and Jira are regularly used in software development and projects. However, we believe they are all built on an unproven assumption: that the teams know what the outcomes of the project are. The interesting question is: do they know, and if so, how?

For the most part, we think that people on projects ‘know’ what they are doing by frequently checking (in the good case) or hoping (in the worst) case. This is checking in the sense that they question the project stakeholders via demonstrations, meetings, emails, phone conversations, testing and other consumer-producer interactions.

The time between these checks is often the difference between success and failure – the drift between what the consumer wants and how that changes over time, and what the producer thinks is needed and also how that changes over time, is only corrected at these check points, and if the drift becomes too large then the project fails.

Addressing drift.

The obvious answer is to meet more often.

Agile methodologies address drift by encouraging collaboration and reducing the time between checks on the concepts and outputs of the project. Where uncertainty and risk is high, Agile is a methodology with a track record for delivering something to the stakeholders that at least meets some aspects of the intended outcome.

As projects become increasingly complicated levels of formalism appear necessary as stakeholders lose confidence. Without a semblance of certainty in the project, specification documents begin to appear to tackle the apparent lack of specificity; they appear to nail unknowns and bring control to the project. The desire to contain the project and predict its outcomes overwhelms the reality that stakeholders don’t know the actual outcomes that will satisfy their needs, wants and problems. Typically, Agile then becomes the methodology of implementation, and not the methodology of ideation and discovery. People fall back to documents, emails, phone calls and other ad hoc or post hoc rationalisations.  And typically it falls to the project manager to bridge the gap between the agile team and the other project stakeholders.

This is a particular problem for projects where the outcome can’t be defined perfectly before you begin – projects where there’s a process of learning about why and what your project goals are as part of completing the project.

Some projects do lend themselves to specification. Known unknowns (such as building houses, cars, ships, electronic devices) present uncertainty as to where, when and who complete objectives, and less about why, what and how. It’s the unknown unknowns that catch us out.

What is Usable Requirements?

At Usable we started out with a simple premise: managing your project’s requirements is hard.  We set out to build a tool to help us, and others, manage requirements better – both more effectively and more simply. It was that simple. We needed a tool that helped draw out the necessary features of the project goal that weren’t necessarily well known at the beginning.

The challenge was provide a document paradigm but not actually have documents – to get inside the document metaphor, challenge it, and make it work better. We looked at how documents work in projects.  In particular, we focused on the requirements specification document.

However, most projects don’t have a ‘requirements specification’.  What they really have is a document here, a few emails there and wireframes, phone calls, meetings, etc. These all define requirements without informing the project stakeholders about what they are. Someone, usually the project manager, might try to lay out all the information that’s known at the start in a single document but as the project progresses it’s often forgotten about and later bears little resemblance to the final project.

At Usable HQ we believe that projects will have better outcomes if they are driven from those requirements from the beginning. Requirements then drive stories and tasks. By really looking at the requirements, and their context, we find the naturally important areas of the project and concentrate on those first i.e. the risky or unknown parts where we need to delve into what the requirement actually means.

Providing context to stories and tasks maintains an overview of the project as well as being able to dive into the detail and really understand how and what the stories and tasks will deliver. Further, being able to link elements together help the project manager to proactively manage risk rather than reacting to it. But it’s not just about risk; the other key killer in a project is change.

Projects change.

Change is inevitable in projects. Whether we acknowledge that change or resist it often determines how the output of the project fits with reality. Embracing change, both understanding its origin and its impact on a project, enables us to actively incorporate it into project process. This ensure that the project outcomes account for the changes during the project. In other words, it means the project is a success.

Exposing, analysing and working with change is often difficult in projects. Change gets lost in the tasks and stories that are planned and executed with no appreciable way to map them back to the original business case and requirements. Feeding change forward becomes an ad hoc process as the project team reacts to new input. While Agile has the capability to actively monitor and manage change other popular methodologies don’t surface it and allow the drift to be observed.

We’ve made the ability to manage change forwards and backwards in the project a key goal. Our initial implementation helps surface and manage change in the requirements of a project, and we plan to build on this set of features over time.

Dealing with risk and change greatly improves the chance that the project will meet its stakeholders’ needs but even that isn’t the whole story. The next step is for action to be taken in a project. Action equates to stories in an Agile world and tasks in more traditional systems. We recognise this at Usable HQ and we’ve already implemented the first iteration of our integrations with three great tools for managing stories and tasks (Pivotal Tracker, Basecamp and Asana), and we’re going to be continuing with our vision for linking action to the project, using the most appropriate tools, to intentions, needs and wants in Requirements. This will ensure that your projects always deliver.

Usable Requirements is now even easier to use – you can import requirements to your project directly from an existing document.

With the latest update to Requirements, there’s a new feature available when you upload a document. Using our offline parsing technology to read documents we’ve created a system that enables you to pick requirements directly from the text of a document and turn them in to requirements in a single step.

(Skip forward to 0:35s to see the requirement import process)

The video demonstrates the workflow of uploading a client brief, selecting requirements from it, and turning them in to Usable Requirements.

• 00:03 – The project is opened at the Project Dashboard.
• 00:06 – The user checks the list of requirements. As it’s a very new project there’s only one.
• 00:13 – Clicking the files tab.
• 00:15 – On the file listing page the user chooses to upload a new file.
• 00:28 – Once the file is selected the user uploads it.
• 00:30 – In the listing, the file has a “Generate Requirements” button.
• 00:35 – When the file has been read the text is sent to the application.
• 00:40 – The user selects some text and generates a requirement from what’s been selected.
• 00:50 – The gathering process is repeated for each requirement after selecting the first requirement. This adds the following requirements as children of the first.
• 01:10 – Once the requirements are imported the user returns to the requirements listing.
• 01:15 – The user then edits one of the new requirements to set it as pending and add a tag.

The document import processor currently works with Microsoft Word .doc and .docx formats, PDF, text and Excel spreadsheets. The entire process from uploading a document to importing requirements from it takes just 7 clicks. And that’s with the first iteration. We’re working to make it even more straightforward. We believe is an exciting new feature that will make gathering and managing requirements much simpler.

We’re continuing to innovate and improve document imports, and we’re looking for feedback on how you might use this feature. If you have any ideas or criticisms please leave them on the UsableHQ UserVoice page.