Like you every so often I get invited to take a survey. This one was a survey of project risks. The survey author was looking to participants to help by ranking the top risks a project might encounter. All the usual suspects were on the list; incomplete requirements – check, Management might re-assign people working on your project – check, – check, and so the list went on. Nothing too earth-shattering on the author's list. However, it was quickly clear that something big had been left off the list.

The problem the project was intended to address, fix, solve etc. Not just any problem. The Business Problem.

Building on recent work with clients, executive and mangers get really frustrated when they feel the real problem isn't being considered. To them that's the whole point of having the project. Instead, they see the project team is completely absorbed and focused on the solution they are implementing. The unstated assumption – everyone believes that if the solution is implemented correctly, or the customer rep says it's ok then the problem has been solved.

If we're honest, we know it frequently doesn't work out like that. It's one of the reasons why many projects don't quite hit the mark – they've lost sight of the purpose – solving the Business problem. It ought to be obvious, the solution and solving the problem are not generally the same.

In his book More About Software Requirements expert Karl Wiegers' gives a humorous example highlighting the issue. Some scientists asked for a new program be developed for their workstations. At their workstations they often had calculations to perform. It was a productivity issue to go back to their desks to do the calculations. The problem was analysed, various solutions were investigated by developers and their solutions costed. Investigations concluded the best way to solve the problem was not a software solution but use Velcro to attach a $10 scientific calculator to every workstation. Problem solved. The scientists were happy. Learning point; by considering the problem, and not focusing exclusively on solutions, we discovered a different approach.

Another example. One of my clients was planning a new version of their flagship software product. Several iterations of project plans were prepared that hadn't been accepted by the executives and managers. The project manager and the team felt they were doing their best and were feeling that a schedule was being imposed on them. A situation that many people will surface in any discussion on estimation and project planning. By examining the business problem it was quickly apparent that the buying cycle of the target customers was driving management's desire for a particular schedule. The outcome? Faced with a new problem, the project managers and the team were able to creatively solve this problem and deliver what was needed. A project plan that gave management and executives confidence the business plan could be solved. Indeed the team went on to do just that.

In defining a project even PMI's PMBOK doesn't bring in the need to solve the business problem. What about Agile development? Unfortunately many agile teams get stuck talking about how they're focused on delivering 'business value.' When pushed they can't articulate what that means beyond generic statements and examples.

The common thread in all these examples is the problem is viewed from either a process or solution perspective –perfectly natural for technology people. The business stakeholder sees sight of the original business problem has been lost, or worse they're left not being confident their problem will be fixed by the project.

Software types are really creative, and good at solving problem. The good news is that they can be just as creative at solving the business problem. The lesson to learn is we need to be sure that the "business problem" to be solved is not pushed aside when we start discussing the solution. After all when we're focused on solving the business problem – many of the risks in that project risk survey can be collaboratively solved.

To make sure you're not losing sight of the business problem, here are 5 points to consider:

1. Do you engage with your business stakeholders discussing the business problem? Do you emphasise and how the proposed solution will address their problems, or do you just discuss the business case and the features & benefits of the solution?
   
2. Does your project charter or vision document articulate the business problem or does it just focus on the business case and the solution to be implemented?
   
3. When you are estimating the project are you estimating how long it will take to implement the solution, or are you estimating how to solve the business problem?
   
4. As the project is implemented do you have regular review points such as milestones, stage gates, or sprint reviews where you can assess if the problem is on-track to be solved by the solution? Do you expressly discuss it as part of the review?
   
5. When you are considering project changes – do you consider if the project without the proposed change still solves the business problem? Do you ask if business stakeholders are willing to delay having the original problem solved, or risk the project being late, or over-budget in order to have the additional benefit from the change?