When I took my first programming class in college, my instructor, Mr. Johnson, taught us something that has stayed with me ever since. When writing a computer program, the first and most important step is to thoroughly understand the problem you are trying to solve. Because if you’re not solving the right problem, no matter how good your program is, you’ll get the wrong answer.
Even though I think I've always understood the concept instinctively, Mr. Johnson’s words illuminated my mind like a flash of lightning on a night with no moon or stars. It was almost as if he had uttered one of the great secrets of the universe, and by speaking the words out loud, he cast a powerful spell that lit up all the paths of possibility in my mind for the briefest of moments. What Mr. Johnson said didn't just apply to computer programming; it applied to all problems. The secret to being a successful problem-solver, then, is to take enough time to fully understand the problem before you attempt to solve it. If you do not, you will not succeed. It's that simple.
Over the years, I've seen what happens when an organization fails to take this approach. In this, particular case, the result was a rather expensive failure. I've also experienced what happens when you front-load the time spent on a project with fact-finding and nailing down all your requirements before you do anything else. At the last company I worked for, when it came time to replace our time and attendance software and time clocks, I spent a lot of time putting together the request for proposal, making sure that every single need of our finance, HR, and IT departments was included in the RFP. I also contacted as many vendors I could find whose products looked like they could possibly meet our needs.
The day after I sent out the RFPs, one of the candidate vendors called me. The conversation went something like this:
“Hi, James. We got the RFP you sent us. We can do everything you are asking for. I just have one question for you. Do we have a legitimate shot at this?”
“Yes. Of course. What do you mean?”
“So you’re not already currently working with a vendor on this?”
“No. Why do you ask?”
“Well, it’s just that this RFP is extremely detailed, and what we typically find whenever we get an RFP this detailed is that the customer has already chosen a vendor who helps them write the RFP so that the vendor’s solution fits better than anyone else’s.”
“Really? No. We haven’t had any help. I put the RFP together all by myself.”
“Wow. If that’s the case . . . congratulations. You've done a really good job then. Like I said, we typically don’t see an RFP this thorough and precise unless the customer has had help from another vendor.”
* * *
To make a long story short, once we got the RFPs back from the vendors who responded, it was all smooth sailing from there. Everything just fell into place. We found a product that did everything we were looking for at a price we could afford. Implementation went off without a hitch, and everyone is happy with the new system.
Now, obviously, there is a whole lot more to completing a successful project besides thoroughly understanding the problem; nevertheless, I have yet to be a part of a failed project where the project lead was able to take the time to first understand the problem inside and out before trying to implement a solution. So if your company’s projects have not turned out as well as you would have liked, perhaps it's because you haven't always taken the time to fully understand the problem you're trying to solve. While doing so won't guarantee success, you will at least give yourself a fighting chance.