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.
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: email@example.com
Alternatively, sign up and try Requirements now.