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.