You compiled all the requirements and built your application to spec. So does that mean your project has been successful? Not exactly.
Start With Requirements
Most IT projects follow the same old pattern. A client has a problem, an IT budget or ideally both. A vendor looks at the problem, and tries to understand it as best they can. The problem is documented as ‘requirements’ and a solution is built that fits these requirements. Everything goes smoothly and all sides are left happy and content.
OK the last part isn’t always true, but the bit about requirements certainly is in 99% of projects I have worked on over the years. Requirements might be captured as lengthy technical documents, use cases or user stories, but one way or another they are documented and a solution built to meet them.
Meeting Requirements Does Not Mean Success
But how do you know if your project has been successful? You’ve built the solution the requirements docs asked for, so surely that must be it? Big pat on the back for you? Well not quite. Implementing a solution based solely on requirements doesn't guarantee success. What if the requirements are wrong? What if they don’t exactly detail the issues the client was having? What if your interpretation doesn’t quite tally with theirs? An IT project implemented to meet a set of predefined requirements will do just that, but it won’t always solve the real life problem at hand.
Anyone with any experience in requirements gathering will know it is very difficult, if not impossible, to do the job with 100% accuracy. Everything a client tells you is open to interpretation and ambiguity. Good interview technique, practical demonstrations, prototyping and such can all help but they will never be perfect.
Then you have the issue of multiple users with multiple viewpoints, different needs and contrasting opinions. Getting a good grip on ‘the problem’ is always going to be next to impossible. A good requirements gathering phase, with accompanying documentation, is a vital process to go through, but it is not to be relied upon on its own.
It's About Achieving Results
So how do you know if your project has been a success, if it is not just about fulfilling requirements? Put simply it is all about ‘benefits’. If your new IT system is not bringing its users cold hard measurable benefits, then it isn’t a success. It can be shiny and new, it can meet all documented requirements, it can even be under budget. But if users don’t see the benefit it is a failure.
Now benefits, just like requirements, can be gathered poorly and are open to interpretation. They aren’t a miracle cure that means you can do away with requirements gathering, user testing and the like. But they are vital to proving that your project is a success.
So what is a benefit? A benefit is an improvement to a user or users of the new system. A benefit must be measurable, both before and after the new system is implemented. A benefit is not “the system will be fast”. A benefit is “the system will allow compete orders to be placed in a maximum of 30 minutes’. Benefits can be gathered as the very first act of a new project, from a wide range of users. The project board and sponsors will have a view on benefits, as will managers, admins and end users. Just like requirements, not all will be valid, but all should be discussed.
Benefits Must be Measurable
Benefits should also be distilled down to their base form. A benefit to “reduce wasted time in the office”, or “cut down on social emails”, might actually be to “reduce disk space for email storage by 10TB by the end of the year”. And as mentioned earlier a benefit must be measurable. How can you say a benefit has been achieved if there is no measure in place to prove it? You can’t. Analytics can help us with many benefits. System speed, storage, number of errors or user stats can all be used. For more intangible benefits, user surveys can be conducted. A well designed survey can provide measures before and after almost any aspect of a system.
In effect our IT project now becomes a process of “benefits realization”. At any stage during the project the team are building according to solution specifications, wire-frames, requirements docs or user feedback. But they are also keeping an eye on the required benefits. A wireframe might require a widget top left but if it doesn’t tie in with any of our benefits then why are we dong it? The whole team can keep an eye on agreed benefits all the way through out the project lifecycle. The process of “benefits realization” is also great for dealing with change requests and new features. Are they really needed? What benefits do they bring?
So next time you struggle to deem your project a success, even after you seem to have ticked all the right boxes along the way, why not consider using benefits as a way to measure?