A newer, more beautiful Requirements
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 firstname.lastname@example.org 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.
What’s the problem with projects?
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.
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.
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.
Requirements Update – Document Import
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.
Getting Started With Usable Requirements
Getting started with Usable Requirements
At Usable HQ we think that projects driven from the perspective of a shared and joint understanding of requirements are more likely to succeed than those that are only managed as a collection of tasks. The requirements give context to the tasks and enable all project members and stakeholders to understand what the key outcomes and needs of a project are.
Usable Requirements is a tool for organising the information about what the outcomes of a project should be and what should be done to achieve those outcomes. Desired outcomes are requirements and activities that need to be completed are tasks. Usable Requirements enables groups of people to manage requirements and tasks on projects.
Who Requirements is for?
If you do projects for customers or clients and need to agree the scope, needs and outcomes of the project, then Usable Requirements would help you with those projects. Requirements helps to capture, organise, tag and agree the project specifications, and then link tasks to those requirements to drive the project. During the project all the team members can see where the project is and what needs to be done. To make it easy, Requirements works with your current workflow. If you use Basecamp, Pivotal Tracker or Asana to manage tasks now you can continue to use any of those apps alongside Requirements.
How Requirements can be used?
We’re in beta right now. Requirements isn’t finished, but there is a good set of features that will help your projects right now. But we’d really like to see if it’s useful to you which is why we’re offering it for free right now. In return, we hope you will tell us what you like, what you don’t like, what works, what doesn’t and what you think we should be adding (or taking away). If you have a project, why not add a few requirements:
- Start with the project’s Objectives or Business Case. What critical things must the project achieve to be successful? These are top level requirements. Create a single ‘Business Case’ top level requirement and create the individual business case items as sub-requirements. You probably only need 4 or 5. Tag them with ‘BC’ or ‘BusinessCase’. Tagging requirements makes them easier to manage by allowing you to group them in flexible ways.
- Now add Functional Requirements. To help with organisation, create a top level ‘Functional Requirements’ and then add sub-requirements under it. In project management terms we talk about ‘products’, and these are things like documents, software, electronic items or delivering a training course. Functional Requirements are things that these products should do
- You may also have Technical Requirements. These are limitations or specifications that a product must meet. e.g. a server something is hosted on, the size of a container, a browser specification or performance requirements (1000 simultaneous users).
- A rarer form of Requirement is a Legal or Regulatory Requirement. These are things like accessibility, security or privacy requirements and could depend on the industry or environment in which the ‘products’ are to be used.
Once the requirements are entered you can either export them as a PDF document to share with the stakeholders, or better yet, invite the stakeholders to the Requirements and share the project with them – simply invite them to it. They’ll be able to join the project, read the requirements, make comments and you’ll be able to change and agree enough requirements to get the project going. You don’t have to agree everything to start, just to make sure that you’re on the right track.
In the next post, we’ll be looking at tasks and collaboration in the project.
Here at UsableHQ it’s been a heck of a year. We’ve raised a round of funding, built a pretty amazing app, met loads of brilliant people, and got to a position where we’re poised to make projects much more likely to succeed. First thing in 2013 you’ll find an invitation to try out Usable Requirements sitting in your in-box (if you’ve signed up). New year, new projects, and a new way of tackling requirements and managing change. It’s going to be awesome.
Until then, we hope you have an awesome break. We’ll see you in the New Year.