In a previous post we looked at some of the reasons why projects fail. Now it is time to start looking at ways to avoid those common reasons for failure. Every project starts with a plan. When the plan is detailed and well thought out it is more likely to lead to a successful project. Let’s look at some key points a plan should address and a checklist to help ensure your plan addresses them.
The most important goal for any project plan is to set expectations. These need to be set for the project owner, the end users, and the implementation team. Expectations form the basis for whether a project is a success or failure. Therefore, providing details and communicating those expectations will ensure that everyone is on the same page. This step alone will reduce the chance of projects running late, going over budget, and providing a useful solution.
A sports team knows the rules of the game and thus can work together to win a match. A project team that is agred on the expectations works the same way. They can focus on the end goal rather than get bogged down by clarifying the rules of the game.
Ask and Answer Questions
A successful project starts by asking the right questions and answering them. This starts with the expectations, but it goes beyond that. For example, a project might be defined with the following expectations.
- Use technology X
- The project has to be completed in thirty days
- Users need to be able to login
- Users will be able to search for other user profiles and comment on them
These are a start, but every point evokes questions. Why use that technology? Can other technologies be used to augment the solution? What defines a completed project? Will it be live in thirty days or just ready for testing? As you can see, each bullet point leads to questions. A good plan looks at the expectations and asks questions about each of them. Then the plan provides answers. This exercise forces the project to be more than a simple consideration and front loads design and decisions.
When the questions are asked and answered in the early design phase then the cost of changes and clarifications is dramatically reduced. There is a lot of anecdotal evidence about this found in articles. However, there is also a great article on it from the late eighties (Boehm and Papaccio, Understanding and Controlling Software Costs).
A Checklist For Success
In my experience I find myself asking the same questions over and over to start a project. I have turned these questions into a checklist. The checklist is available via a link at the end of this article and I hope that it will help you start your next project in the best way. Maybe a better start will help us reduce the scary failure rate of all project big and small.
If you have questions about any of this you can shoot me an e-mail at [email protected] or leave a comment. If you have a way to improve on this I would love to hear it and use it to improve upon this starting checklist.