What is the problem the project is trying to solve?  Think about your current project.  Can you answer that question?  Why is it even important?

Every project is trying to solve a problem.  The problem may be:

• We cannot cross a river
• There is an opportunity to claim a niche market
• Our software is no longer supported

If the problem is identified, the outcome can be identified.  It is not the solution.  There is a difference.  Taking the first example, the outcome is that we need to cross the river.  The solution may be a tunnel, a bridge or a ferry.  We might select a bridge as the solution, but it may not necessarily be the only or even best solution.  A business case needs to be developed to look at how we can achieve our outcome and nominate the most suitable solution.

Too many people focus on the solution rather than the outcome. In the second example we might say let’s build a new product to meet a niche market.  Perhaps the solution could be to have someone else build the product, or to patent the solution and sell the patent.

This particular lesson came from a review of a project in crisis.  A stockbroking firm were building a new client information and transaction system.  They had employed a company to build a web based solution.  There had been numerous prototypes built but they could not settle on the final product.  The CIO called me in to try and resolve the situation.  My assignment was to last a week.  I was gone in two days – very poor form for a consultant.  This is how it happened.

My first interview was with The Financial Manager.  They were providing the funding and were co-sponsors of the project.  I asked what outcome they were trying to achieve.  The response was that they were trying to provide better customer service and retain their client base.  In fact I think they were trying to keep up with their competitors rather than surpass them.  In order to do this for the minimum cost, as things were tight financially, the solution was to develop a simple interface that allowed customers to undertake basic transactions and see core information.

My next interview was with the other co-sponsor, the Marketing Director.  I started by asking the same question.  His outcome was a bit broader than the Financial Manager.  He also wanted to provide better customer service but also wanted to attract new customers from his competitors.  In order to do this, his solution was to build the best, most sophisticated customer interface in the industry.

In the afternoon I spoke to the company building the system.  It took a while to get to the truth but the crux of it was they built prototype A and showed it to the Marketing Director.  Add more bells and whistles said the Marketing Director.  They did and showed prototype B to the Financial Manager.  Take out the bells and whistles said the Financial Manager.  We can’t afford them.  Back and forward they went from one to the other adding and removing features.  It was a bit more subtle than how I explained it but the software developer was happy.  They were being paid by the day so variations were all paying work.

By the end of the first day I went back to the CEO and said this.

“The problem may be that you risk loosing existing customers.  In this case the outcome may be to improve services to existing customers.  The problem may also be that you need additional customers to build the business.  One solution may be to attract customers away from your competitors by offering more attractive services.  Both have a potentially different solution so until you decide the problem and outcome, you cannot set the path forward. “

Day two started with a meeting between the CEO, Financial Manager and Marketing Director.  The two co-sponsors explained their perceived problems and desired outcome independently.  There was considerable discussion on which problem was relevant, and it was decided that for this project, we only wanted to look at the problem relating to retaining existing customers.  We then matched where the outcomes were the same and highlighted where the outcomes were different.  Different included outcomes where only one of the co-sponsors had a desired outcome.  It took several hours of debate, and a few directions from the CEO before they had an agreed, common outcome.  That outcome did not include stealing customers from their competitors.  We then worked on the best solution, and by lunch time we had an agreed solution which formed the scope of the work required.  We invited the development team in, and matched their work to the scope statement.  By the end of the day, a conceptual prototype was agreed.  It was in fact a stripped down version of the most recent prototype.

Ready to go home at the end of the second day, I was drawn aside by the Marketing Director.  He asked “If we have another project, and the outcome is to attract our competitor’s customers, what would be the solution?”  I had to point out that there were many solutions.  He had to identify the solutions and evaluate which of those had the best business case.  It may be to enhance the basic customer information system or it may be a new product to attract those investors.  I think the lights finally came on.  He got it.

I did hear from him a few months later when he asked me to facilitate a meeting of his key managers.

“We want to talk about outcomes” he said.  “I want my team to brainstorm solutions and then we can go away and develop business cases for them.”

I asked him how the new customer information system was going.  It was in place, and getting good feedback from the existing clients.  He said he couldn’t understand how it had taken so long to get started.  Sometimes you think you have broken through and then the person confirms there is still some way to go.

Neville Turbit is principal of Project Perfect.  Project Perfect sell Project Management Software as well as consult on projects and undertake Microsoft Access Development