Solving the non-problem
by jed simms on March 3, 2010
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 on the ground floor, they could not deliver our mail. Even badder.
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 you 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 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 really 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 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.
If you have a problem, fine. Now, where do you want to end up? What are your desired business outcomes? Focus on these and your problems are likely to disappear – and then you don’t have to spend the time and money solving them.
© Jed Simms, Australia 2010
2 comments
Hi Jed,
I think you’re in the right church but wrong pew. Projects indeed are to solve problems, take opportunities (which solve someone else’s problem), or meet challenges (which are a form of a problem). Projects fail when they don’t adequately identify the REAL problem that provides REAL value when met. They solve the wrong problem or don’t appropriately solve the REAL problem.
My seminars and book, Discovering REAL Business Requirements for Software Project Success, describe using the powerful Problem Pyramid(tm) to get the REAL problem right and then discover the REAL business requirements that solve the problem and thereby deliver value.
With ProveIT.net we use the same approach as the basis for determining REAL ROI(tm) that overcomes ten common ROI pitfalls.
Robin
by Robin Goldsmith on March 3, 2010 at 11:29 pm. #
I understand your points Robin
It is a case of moving from or to.
I agree you should always make sure that there is a real problem and that you know what it is.
But then, I argue, the next step is not to find a solution but to find the outcomes – where you want to get to.
Once you know your desired destination (your ‘to’), you should identify what has to change to get there
What I’ve frequently found is that the resultant project does not ‘solve the problem’ but find it is irrelevant to the new end state created.
So, it is the difference between solving a problem such as ‘”our approval process is too slow” to achieving an outcome of “approving all valid applications within 2 hours”
There is many a solution to the first problem but only one outcome that meets the second target.
JED
by Jed Simms on March 4, 2010 at 3:39 pm. #