We recently moved into new offices. Great.
But our mail was being ‘returned to sender’. Bad.
We contacted the Post Office and they said that they did not deliver to individual floors and unless there was a post office box or reception area on the ground floor, they could not deliver our mail. Even worse.
However, being good process consultants, we scouted the ground floor for a suitable spot for post office boxes and found an ideal spot. Problem solved.
But…
Then I met the post lady in the lift. “Oh,” she said, “there’s someone on level four now, is there? Would you like your mail delivered?” She delivers to every floor every day.
There was no delivery problem - only an information gap – that the person who actioned the process (delivering the mail) did not know we had moved in and the people at the Post Office had no idea of what really happened on the ground and so gave us the wrong advice albeit in good faith.
This is illustrative of what happens when projects focus on solving problems when defining their requirements.
- They often spend a lot of time on non-problems
- They get advice that is well-meaning but wrong
- They don’t get close enough to the ‘real people’ to find out what is going on
- They focus on solving the problems instead of eliminating or avoiding them altogether.
We find that many of the problems identified at the beginning of, say, a business simplification exercise are not solved at the end. They’ve disappeared, been eliminated or no longer exist.
Whoever said that, “Projects exist to solve problems” should be shot! This is exactly the wrong mindset with which to approach projects.
In Conclusion
If you have a problem, fine. Now, where do you want to end up? What are your desired business outcomes? Focus on these and many of your ‘problems’ are likely to disappear – and then you don’t have to spend the time and money solving them. The result is simpler, cheaper, and can be delivered quicker. A win-win-win.
