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.