Discovering Risk With 3 Point Analysis
3 point analysis is a method of estimating the time that a project feature will cost. Rather than define a single cost value, 3 points are chosen;
- Optimistic. The cost of implementing a feature if everything went perfectly.
- Likely. The most likely scenario, e.g. how long the feature will probably take.
- Pessimistic. The cost of the feature if everything goes horribly wrong.
Defining three cost values for each estimate doesn’t take a great deal more time, but they can give a project manager a fantastic insight in to the likely upper and lower bounds on the amount of time a project should take and where the risk lies is in the project.
Ordinarily, with a single cost per project item, a project manager will have the sum of the estimated costs in order to estimate the total cost of the project. While useful, that doesn’t give an accurate representation of risk. How much longer the project would take if things don’t go to plan is important. The sum of the optimistic costings is the best possible time that the project could take, while the sum of the pessimistic costings is the worst. Adding the optimistic and pessimistic cost estimates gives a deeper insight – a project that takes 10 times longer if things don’t go to plan is incredibly risky.
This analysis can help test the project as a whole, they’re also useful on individual requirements. If the difference between the optimistic and pessimistic costs is small then there is a consequently small risk – even if things go wrong the budget for implementation cost isn’t adversely challenged. Conversely however, if there is a large difference, then a lot can go wrong and the feature carries a great deal of risk to the project deadline and budget.
Usable Requirements has 3 point cost analysis for requirements rolling out in the next week. Every requirement can be estimated with optimistic, likely and pessimistic values. The project dashboard gives project managers a simple graphic view of both total costs and risk based on these estimates.
A Usable Way To Add Requirements
Usable design is the art of creating an experience that everyone can enjoy. Even within the close-knit team of developers at Usable we have different approaches to how we use applications. Some of us like to drive applications in a very visual, mouse-oriented way. Other prefer a focussed keyboard-driven approach. Requirements has been designed to appeal to both.
With Usable Requirements you can create a complete set of requirements without leaving your keyboard, or to use your mouse to drive everything in the application.
In this video demo the user adds requirements to a branch to define how a user can update their profile in the account management dashboard. In the first part of the video the user is creating requirements using the keyboard-driven “Quick Add” panel. From a single form you can create a new branch, add sub-requirements to an existing branch, and navigate up and down the requirements tree without having to lose focus on creating requirements in your project.
In the second part of the video, the user creates two requirements using the “Create Requirement” button. This mouse-driven interaction makes adding sub-requirements to different parts of the project fast and easy.
In Usable Requirements we’ve focused on usability without restricting or changing the way you like to use web applications.
Case Study: Requirements In An Agency
At UsableHQ the team behind the software has a total of more than 20 years web development experience in agency settings – we’ve seen the successes and encountered the pain points working on projects from the smallest brochure websites to the biggest e-commerce applications. That experience is a large part of what drives us to make Requirements a great tool for agencies that produce websites and web applications.
A requirement is something that the project has to do in order to successfully meet a project goal. In very large corporations the “what” and “why” of a project is managed as a set of requirements in a tool such as IBM’s “Rational”. If your project is huge with tens of thousands of requirements, you need an enterprise level requirements management application.
Managing a project in an agency can be a difficult process as parties pull in different directions, especially in today’s industry, where collaboration between stakeholders is necessary for anything but the smallest contracts. The job of the project manager is to balance the will of the different companies involved with the needs of the project. Consequently, without a clear oversight of what the project needs are, it’s much more difficult to keep things on track.
Defining an initial set of requirements for a project is essentially the same process as creating a specification. Each feature of the project is broken down in to a set of smaller parts. In a traditional specification document the focus is very much on the technical implementation details though – what the feature should do from a technical standpoint. Using requirements management there is also a focus on business and non-functional requirements*.
The advantage of a requirements driven approach is that each of the parties involved have an input, lending expertise wherever they think the problems will be, and helping to design a set of project goals that become an exciting, deliverable body of work. At the same time, the client’s needs are addressed properly and are much more likely to get an outcome that actually does what they need. In addition, everyone gets a set of requirements that show precisely what work will be delivered.
Once your project begins using a set of requirements can transform the project management process.
A project’s requirements are a living set of aims that define what needs to be built in order to achieve the outcomes that have been defined as a successful project. At any point in time the requirements define the scope of the project. As more information is discovered during the project’s development phase, the goals for the project are likely to change. New features are be added to react to the demands of users. Redundant features will be removed. Other features are refined. Managing changes to the scope of the project is important. It’s easy for tweaks to build up, for the project to suffer from “scope creep” (aka “feature creep”), without the client ever agreeing to the necessary changes to the project budget or the specified project deadline to cover the cost of the modified project specification. Consequently it’s impossible for the project to be a success – a project that is delivered late or over budget is considered to have failed even if it’s not cancelled.
Mitigating scope creep can be achieved by keeping track of changes and demonstrating where things have been altered and by how much. A project snapshot enables a project manager to capture what the scope of the project looks like at a set point, and then highlight changes to the requirements between that point and the current project view. By snapshotting when requirements are agreed, at the beginning of the project, at milestones and at points of particularly significant change, a view of how the project has changed throughout it’s life can be constructed. This view makes it clear why things have changed, how often changes have been requested, and makes the case for negotiating additional budget or time for that “one little tweak” a client has requested.
Beyond managing project change, a requirement set is a good indication of where the project stands. A report from a task management application only tells you what has been done to date. In the majority of “To Do” based task applications there are no good indicators of how important a task is to a project. The fact that a set of tasks have been completed doesn’t give the client or the project manager an idea whether or not a feature is complete unless you either keep a separate overview list for features with sign off as they’re completed, or use very high level tasks in the lists for individuals working on the project. The downside of high level feature lists is that you lose sight of how far along a feature is. By driving tasks from a set of requirements it’s immediately obvious how far along a feature is in production.
Usable Requirements gives project managers a set of features that make defining requirements before a project, managing change during a project, and driving tasks from requirements very simple.
Requirements aids a project proposal by making it easy to produce a requirements document before the project starts. By defining the requirements to build the client specification, or tendering document if the contract hasn’t been won yet, every stakeholder in the project can have an input to what the project will be. Developers, designers, analysts and project managers can collaborate to produce a detailed plan very easily. Comments can be added to requirements to question assumptions or suggest improvements. Costs can be attached to requirements to estimate the total required time to complete everything.
Requirements also includes a feature to create project snapshots and highlight any changes between either two snapshots or a snapshot and the current state of the project. Having to report on the number of changes a client has requested by trawling through dozens of emails and arguing whether or not a change was really in the original specification is a thing of the past.
Finally, Requirements includes a basic task manager to keep track of user’s To Do lists, but it also integrates with some of the leading task software available, including Basecamp and Asana. We’re adding more integrations to other leading project tools too, so teams don’t have to change the way they work in order to benefit from the useful features Requirements adds to a project workflow.
Sign up to the Usable Requirements beta today.
* Non-functional requirements are the things that the feature needs to have that aren’t actually part of the implementation. For example, accessibility compliance is very important for a web project but it isn’t something you actively do.
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.
Opening the doors.
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.