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 is change?
Change in a project is the transition from one requirement to a different, superseding requirement, the addition of a new requirement, or removal of a requirement that is no longer relevant. There are changes driven by deliberate choices, by new information, and from challenged assumptions. There are changes from the tweaks to insignificant project minutiae to wholesale rewriting of an entire project specification. Motivations for change can be a desire for improvement, a realisation that things are going awry, or an ego-driven “project stamp”. The truth behind any change to a project is that, if the change is managed properly, it doesn’t have to result in challenge. Change can be a good thing.
Managing your changes
It’s important in any project that, when changes arise, they’re managed and communicated properly so that everyone involved is aware of the new project parameters. In particular there are seven key factors in change management;
The project manager should be aware of how much a change affects their project.
How a change affects a project obviously depends on what the change is. A large scale change has a much greater impact on a project than a small change. That isn’t the whole story though. A small change can have an significant impact on the project’s effectiveness if it comes at a time when there’s already a large amount of change in the project; “The straw that broke the camel’s back” is a fitting cliche to describe something small that might have a catastrophic effect. It’s fitting here. A project change that tips the balance by demotivating the team as their workload increases beyond capacity, or adds too much to one team member that they can’t cope, can cause a project to fail. Awareness of the total scale of change in a project is critical.
People are affected by a project change.
A change in a project doesn’t only affect the outcomes of the project – it affects the team implementing the project, the project sponsors, and the end user of the project’s goal if there is one. When a project changes it’s important that everyone affected by the change is aware that it has happened and that they’re onboard with the change. If there are people who haven’t negotiated their position on the change then they will be resistant to it. Such resistance can be a reason behind project lateness.
Some teams are better at change than others.
If the team has worked on projects together before you’ll have a good idea of how well, or otherwise, they work together to manage changes in a project. Most importantly, how long have changes in previous projects have taken to be accepted. If a team is very slow to react to changes then that factor should be considered in estimating how much addition time a change will add to the project estimate. Teams that are comfortable with change are more likely to be successful in implementing a project that’s very dynamic and unknown at the beginning.
Project sponsors need to be onboard with changes.
Another factor that can slow a project considerably is having a project sponsor (client, lead, project manager, etc) that resists change. When each of the stakeholders needs to sign off on a change to the requirements a project can slip when one delays the sign off process for any reason. Developing a strategy that mitigates resistance from known awkward parties is a valuable asset if an unexpected change occurs.
Every change carries a risk to the project.
Identifying the specific risks that a change adds to a project is a key strategy for deciding whether or not a change is important enough to include in the requirements. Moreover, understanding how the change affects the overall risk facing the project is important too. Changes rarely happen in isolation – a change to a requirement affects the requirements that it depends on, and the requirements that depend on it. It’s critical that the project manager understands how the requirement “network” changes with updates.
Different changes require different approaches.
Perhaps most important of all, a key factor in project success is dealing with each change in an appropriate way. There isn’t a “magic bullet” that will work for everything. Some changes will require a great deal of management, some will slot in to the updated project requirements very easily. The specific tactics that are used to manage changes in the project need close monitoring and constant evaluation; tactics change with the territory. As more information is made available the tactics we use to implement project requirements will also change.
Usable Requirements is a project tool that gives project managers a set of features that can help with changes to project requirements. Project Snapshots freeze the requirements to be viewed again later, and snapshots can be compared against both one another and the current project requirements to analyse what has changed in the project since a given date. Requirements also features powerful reporting, cost change analysis, and a project dashboard that gives the project manager an easy overview of the state of the project.