Solve the Right Problem
“It isn’t that they can’t see the solution. It is that they can’t see the problem.” ~ G.K. Chesterton
A young woman taking a brisk stroll noticed a child looking into a tree. Following the child’s gaze, she saw a cat on a branch, perhaps 15 feet high. Quickly grasping the lowest limb of the tree, she said, “Don’t worry, young man, I’ll get your cat down.” In a moment, the rescuer was handing the cat back to the child, who murmured a “thank you”. As the woman walked away, she glanced back and saw the child put the cat on the tree trunk. It immediately scampered back up the tree to the same branch. The woman asked, “Why did you do that? Now someone will have to go get your cat again.”
The child replied, “But kitty wants to be in the tree. She always goes up there and waits for me. I can climb up just fine, I just need someone to boost me. I can’t reach the first branch.”
We live in a fast-paced world. Our inclination is to see a problem and try and get to the “answer” as quickly as possible. That is often true in life and, more specifically, it is often true with ERP implementation projects. In many, if not most, of the projects I have worked, there is a rush to get to the “how-do-we-do-it” phase of the work. How do we make the software do what we want it to do? The difficulty with this approach is that there is a very real danger of solving the wrong problem.
The problem with problems is that they are not always self-evident. I could not even count the number of times a client has asked for a solution (a customization, a list page, a report, etc.) that, when the project is done, is never used (but it still costs time and money to develop these throw-aways). By the time the users see the full functionality of the system, many of the “quick solutions” are rendered unnecessary.
As I mention in this post, it is critical to start with a solid understanding of the business reasons for the work to be done. This lays the foundation for discussions of any specific problems that stakeholders see as needing to be addressed by the system.
It is, of course, also important not to allow a project to fall into “analysis paralysis.” With apologies to the Moody Blues, it is a question of balance. While each project is different, there is a certain amount of necessary problem definition and understanding that must be done before any really useful implementation work can start.
This need for balance is exactly why we at ArcherPoint use an Adaptive Project Methodology. It allows for quick, iterative work efforts that do just enough problem definition to allow usable work to be done and then validated by the client before additional work is layered on top of it. If the work is solid and moving in the right direction, the next portion can be done. If there are issues, holes in the thinking, etc. this comes out quickly and can be corrected before more work is done on the solution. It really is the best of both worlds.
If you would like to explore ways in which ArcherPoint can assist you in understanding your business requirements or specific business problems, and determining the right problems to solve, contact us today to discuss.