Over the years I’ve been involved in loads of projects and I’ve noticed that there are two key factors that every successful project shares. They seem obvious but it’s surprising how often they’re lacking.
At the outset of a project, especially a long and/or complex one, it is often difficult to see what the finished system will actually look like. This is not because no one knows what the system needs to do. Quite the contrary, usually by the time that a project is even being considered its well established what the finished system needs to deliver. The problem is that it isn’t clear exactly how it should work and what all the details should be.
The reason for this is that it usually requires input from the both developer and the client over the course of a project to arrive at the final solution. The best solutions evolve through a cycle of development, testing and actual use. It’s unrealistic to think that it’s possible to foresee every detail at the outset of a project. It’s only through using, testing and feedback that everything gets picked up and optimised.
This leads me to the first point – ‘Getting Started’. Obviously if you’re going to complete a project you need to get started at some point but getting started can often be a real sticking point. I think the main reason for this is that people tend to focus on the final version rather than the first. There are often lots of meetings to discuss what everybody wants from the system. The problem with this is that it means that the solution actually gets further away rather than closer because the software keeps getting more complex. This makes it even harder to visualise the eventual solution and makes it harder to make a start because the concern that something might be missed increases. It’s like climbing Everest – before you can work out how to reach the summit you need to make it to the first base camp.
In the graph above, point A represents the first delivered version of the software and point B represents a finished version. Point C represents a further version with more functionality added. Moving from point B to point C takes time, but you can’t get to point B without going through point A. This is the importance of getting started. Focusing on the core functions of the software and getting to the first version is crucial. Once you get to point A it much easier to see what is going to be required to get to point B – having something on screen as a starting point means you have something to develop from. This makes the process much easier for everybody.
You’ll notice that the time taken in the graph above to get to point B from point A is greater than the time to get from the start to point A despite the overall system complexity growing much less. The reason for this is that the development process to get to point A rests with the developer alone. At the outset of the project a specification for point A will be agreed and the developer will go away and build the software. To get from point A to point B requires the client to test the software and feed the results back to the developer. This process may require a number of iterations, and this brings me to my second key point – ‘Project Momentum’.
What I mean by project momentum is simply that the project needs to keep moving forward for those involved not to lose touch with it. If nothing happens in a project for 3 months everyone’s grasp of the project, especially the details, will diminish and the longer nothing happens, the harder it becomes to pick it up again.
With the best will in the world a developer cannot give a project momentum. A developer can ask for input or updates but they can’t actually make things happen to move the project forward. It is therefore the job of someone on the client side to provide the momentum and keep the project moving forward. It best to assign one person the role of project ‘champion’ who can keep track of where the project should be and be able to force things forward where necessary.
So in order to get to the finished solution you need to get started and keep going. Both of these points are absolutely obvious when you stand back from any project, but it’s surprising how often they get missed. These are the only elements required for a successful project, but they are crucial components.