I’ve spent most of the last 20 years in “project recovery”, namely trying to sort out projects that were late, over budget, not delivering the right things, or some combination of the three.
These days, when assigned to a project, there are four questions I always ask, in this sequence. The clearer, better quantified and more detailed the answers, the less risk there is that the project will fail.
- What are we supposed to achieve? Often, projects fail because the answer to this key question is vague, or phrased in terms of technology rather than a business need.
- How will we know when we have achieved it? This is what an NLP practitioner would know as a well-formed outcome, and a IT professional would know as acceptance criteria. Typically on a failing project, the criteria will be something like “when the sponsor is satisfied with the system”. On a successful project, the answer looks more like “when transaction X is completed in less than two seconds more than 95% of the time; the transaction is deemed to start at the final activating keypress and end when the screen has been fully refreshed with the desired data.” Note: The area that is normally least well defined is management reporting.
- Who is paying for which pieces of work? A classic symptom of a failing project is an argument over who pays for item X, which all parties thought someone else would fund. Eventually, you will have to reach agreement on this; the best time to do it is before the money has been spent, not afterwards.
- The guys who actually have to do the work - how long do they think it will take? The usual answer on a failing project is that they were not asked, they were told, out of a fear that they would extend the duration out of laziness. In my experience, very few people really do that, and I have only seen this approach work once in nearly 50 projects.
Not rocket science, is it? But take a look at your current project; I predict you will be both surprised, and scared, at how few of these questions you can answer in detail.