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.
Starting a new project – Right at the beginning.
Starting a new project is an exciting prospect, but it can be daunting at the same time. At UsableHQ we have started many projects and taken them through to eventual success, but it hasn’t always been easy. We’ve identified five particularly painful things that can lead to difficulties in projects from the very beginning.
Starting Pain #1: Commissioning a project for something that isn’t actually needed.
Every project begins the recognition of a need. Someone needs something. That need could be something very big, building a new application for example, or something very small, such as adding a new feature to an existing website. Once that need has been communicated to the person responsible for commissioning the project that will solve the need, and it’s been agreed that there really is a need, then the project proposal can begin. The problem that strikes at the heart of many projects is the perceived need isn’t agreed by all parties in the project, nor is it based on any repeatable metrics. There should be evidence that backs up the reasons to start the project rather than assumptions or guesswork.
Starting a project that isn’t necessary is an obvious waste and very likely to lead to project failure when people can’t agree what it’s setting out to achieve. It’s critical to discuss and agree that the overall goal of the project is something that’s really needed before you begin.
When the necessity for a project has been identified it’s important to create a project proposal. The proposal should outline the needs and aims of the project – the objectives for the project. This is the next common place for project problems to occur.
Starting Pain #2: The project proposal is really a specification in disguise.
A project proposal should be a document that sets out the pain people are suffering, and outlines a potential solution that would make the pain go away. On technical projects particularly, it’s easy for a knowledgable project manager to try to find a solution that would work and write a specification rather than a proposal – and then commission a project team to implement the specification.
The problem with this approach to project commissioning is that there is a lack of communication and collaboration on the solution to the problem. Ideas that could come out during the specification phase of the project are shut down because they’re not in the proposal document – it’s much harder to put forward an idea if there isn’t a forum for gathering input in place.
Starting Pain #3: A lack of communication around the requirements.
In a successful project everyone involved has to pull together around the project specification to make sure problems are spotted as early in to the project lifecycle as possible. This means communicating.
If details of the project are kept secret from the people who will be creating solutions for the project’s goals then it’s likely potential problems won’t be spotted until they start to affect the project outcomes – pushing up budgets or making deadlines slip. It’s critical to get feedback on the project goals from all the either people representing the team or directly from the team itself in order to ensure there’s plenty of data about everything going on in the project.
Starting Pain #4: The desire to cover every possibility before you begin.
Almost the opposite problem to a lack of communication around the project specification at the beginning of the project is the problem of wanting to gather absolutely all the information needed to complete the project before anything is begun. Often gathering data can be completed during the project itself rather than before starting.
Needing all the data to be in place at the beginning has two problematic effects. Firstly, it can delay the start of the project. If the project is time critical then this is an urgent problem. Secondly however, wanting all the data in place at the beginning is often a symptom of refusing to change during the project as more data comes to light. Information changes as more data is made available – failing to react to new information is another important project problem.
Starting Pain #5: Not going back to the agreed specification when new things are learned.
The project proposal, and the ensuing project requirements, are only as good as the data that was available at the time that they were written. Once everyone has had time to input in to them, to correct and elaborate on them, and they have been agreed as a specification that will fulfil the client’s needs for the project, they still shouldn’t be set in stone. A project’s needs change.
It’s important to keep requirements up-to-date as you learn and discover new things. Revisiting a set of requirements to change them and make sure the project will still solve the pain that it started out to solve is important for project success.
UsableHQ Requirements has been designed from the ground up to alleviate these problems. From the project inception, to creating an initial set of requirements, to communicating around the requirements with everyone involved in the project and agreeing on a set of requirements to manage through the project, the aim of Requirements has always been to make sure projects managed using it will be more successful. Requirements has many features to help make a project run more smoothly, but even without using those tools it can make a project more likely to succeed.
Requirements helps you in several ways;
- Drafting your requirements – In Usable Requirements your requirements start with a status of Draft. You can create, edit and update them as often as necessary before making them Pending requirements to be agreed with all the project stakeholders.
- Communicating and collaborating – Commenting on requirements is an important feature in Requirements. Anyone in a project can leave feedback on a requirement, and as there are no limits to the number of users in your projects everyone can have a say.
- Agreeing an initial set of requirements – Requirements enables you to update the status of a complete set of requirements in just one click – agreeing a project specification is easy.
- Making change visible – Once your client has agreed a set of requirements you can snapshot the project to freeze the state in time. Later, after things requirements have changed or new ones have been added, you can compare against the snapshot to see exactly what has changed.
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.
Projects, but better.
Projects, but better. That’s what we’re aiming to do at Usable.
For many, many years the Usable team have been doing projects of various kinds. We’ve been developers, project managers, product managers, and we’ve run our own businesses. We’ve all known the pain of a project that isn’t going to plan. Even the best managed projects have their problems, and problem projects are expensive, late or fail entirely.
We recognised this problem, and we recognised the solution: requirements management software. Unfortunately though, as it stood before we started Usable, requirements management software was either horribly expensive or just plain horrible. Enterprise tools for companies designing a new airliner are available if you’ve got the money to spend, but for the majority of businesses those tools are simply beyond their reach. At the other end of the spectrum there are tools available, stand alone or as part of a project management suite, but they’re not really requirements management: they don’t work the way that requirements management ought to. All too often they’re actually task management. Requirements are not tasks.
Requirements management means you manage what your project’s end goal is about continuously throughout the project lifecycle. By embracing the inevitable changes, by tracking and managing them, and by communicating them to everyone involved in the project you can effectively ensure that everyone is going in the same direction – people missing a line in an email that changes something important is a thing of the past.
Usable Requirements is shaping up to be something that brings most of the power of the enterprise tools to small and medium enterprise. We have real-time collaboration, document import to manage existing requirement documentation, a unique requirements editor that gives you the power of Word with the intelligence of a requirements management application. More than these features though, we’ve thought long and hard about how to best management changes and tracking, we’ve gone to great lengths to make the application beautiful and easy to handle. Things work the way they should. We’re writing documentation, but we don’t want you to have to read it. You’ll be able to pick up our software and run with it, just like you’re used to with Word or GMail.
Learning from Apple
With some of the best technology products on the market developed in total secrecy, how does Apple manage their project development process?
To Mac geeks the process behind developing a new product is something akin to Willy Wonka’s Chocolate Factory. Amazing things happen behind the closed doors of Cupertino. Until recently the process of exactly how Apple go from an idea to an iPhone has been a mystery. Now, with the launch of a new book written by an ex-Apple executive, the veil has been lifted and we’ve all been given a little peak inside.
The first thing that has to be said of Apple’s process is that it is expensive. Fantastically, horribly expensive. Apple doesn’t iterate prototypes like any other company might; Apple builds final versions of products, learns from them and then throws them away. That’s an option only open to you when you have $98b in the bank.
Beyond that though, the process is eminently sensible. The process is weighted to design up-front, because design is Apple’s unique selling point. People buy Apple products for the work they’ve put into their industrial design. For a different company it would make sense to load the effort into some other aspect that the customer comes to you for. At Usable, we put the effort into usability. That’s what our customers want.
The process at Apple is very, very fast, especially for such a big company. The iteration cycle used is between one and two weeks. At Usable we use two week iterations, but we’re a young and energetic start-up. We have two employees; Apple has more than 60,000. What’s most amazing is that Apple have managed to create a start-up like environment within their corporate environment. They’ve removed the barriers and bureaucracy that prevent other companies doing such amazing things. Usable seeks to emulate that, with the obvious advantage that we are a start-up. We love the rapid development process and actually enjoy the challenge of managing the changes that arise from going so fast – it’s something Usable Requirements is solving.
The final thing to learn from Apple is that, at every single stage of the process of developing a new product, there is a single responsible individual. Apple does not build products with committees of people arguing over the minutia. One persons word is law. Ultimately that was Steve Jobs, famous for his attention to detail and somewhat obsessive nature about making the best possible product. That is a vitally important facet of project development – if no one takes responsibility for something then it won’t get done properly, or even done at all. Again, Usable knows this. We have clear boundaries that set out who is accountable for each aspect of our products, and in Usable Requirements the workflow of sign off is very well signposted. When you use our app you can tell immediately who is responsible for what.
It’s interesting, exciting, and hugely encouraging to know that we’re using the same sort of processes to develop our software as Apple use to build the products that we use every day. We’re looking forward to bring these tools to you.