The Discipline of Project Justification - Part 2

Second in a multi-Part Series
By Tom DeVroy
VP of Sales

In the last post I discussed a methodology for justifying a capital project to management. My proposition here is that there is a process involved and some discipline required for a successful conclusion. In this post I'd like to address the first requirement of project justification.

The Pain Statement
The first step is defining the problem you are trying to address. If you can't articulate the problem you definitely can't make a case for the money to fix what (apparently) isn't broke. There isn't any reason to buy a system, or acquire new hardware, if you can't clearly indicate the pain caused by the current status quo. The definition of your problem is what I like to call the "pain statement". The bigger the pain statement is, the easier it will be to ask for the financial means to fix it.

For example, if your business consistently missed customer expectations in customer service, this would drive down customer satisfaction and cause you to miss out on new business opportunities for product sales. This pain statement, although intuitive at this point can probably be backed by financial justification later down the road. Pain statements don't always have to be so complete though.

Another example could be something along these lines: Our current system is old, it runs on hardware no longer supported and much of the technology is aging. It is forcing us to not change anything. First, this makes us very vulnerable to catastrophic failure, and secondly, this forces us to remain in a status quo for operating procedures and business processes. Our infrastructure needs updating or we run the risk of not being able to support our own environment. Once again, the pain is intuitive and it opens the door for further justification down the road.

The nature of the problem probably will dictate who will fund the solution to the problem. My first example is an operational issue. The solution to the problem probably comes out of a departmental budget within Service Operations. The second problem is likely an IT problem that should be funded from the IT department, although both problems affect the business directly.

The Hypothesis
After creating a pain statement a hypothesis should be developed for solving the problem. The hypothesis defines a possible outcome and perhaps defines a potential solution. Although the person that develops the hypothesis should be careful not to be too forthcoming with a solution. This might imply that the author has an agenda and has pre-determined an outcome before adequate research has been performed.

If we go back to the first example, a proposed hypothesis might be that we look for an integration strategy or solution that combines our contract SLA's, our customer master, and our problem tracking system. We can then have visibility between the customer contract commitment, their currently reported problem, and what levels of service we owe them to resolve their problem. Notice that I don't suggest a "new" system, although such a suggestion might be the final solution.

Further into the evaluation, you likely will be asked for one or more alternatives that address a solution to the problem, to financially justify it, and to create a coherent business case. We'll save these topics for future posts. Next post, establishing the business case.

View Part 1 Here
View Part 3 Here
View Part 4 Here
View Part 5 Here