Is technical brainpower needed for defining a problem?

I got some interesting feedback on my earlier blog on Problem Definition. One particular feedback that intrigued me was

“Do you need technical brainpower for defining a problem? How early do you decide that you need the best techie out there to get out there for your problem?”

While the person who asked this question was from the IT industry, I believe that this question is applicable pretty much across the board. Technical brainpower is absolutely a must for solving a number of problems but the quantum and the real need for the same definitely varies depending on the situation and phase of the problem solving life-cycle.

In my view, technical brainpower is really not needed for defining a problem most of the times. Problem definition can be done pretty well by somebody asking pointed questions by looking at the symptoms that have come up. As a matter of fact, the entire industry of management consulting has originated by just focusing on problem definition. There is a popular joke about Management consulting which goes like “ A Management Consultant borrows your watch to tell you the time”. I think this statement is extremely profound and in my mind, is a good appreciation of what a Management consultant does. The person who is wearing a watch (in some cases, this can even be the CEO of the firm who has been in the industry for decades) knows that he is wearing a watch and knows that it is showing the time except that he can’t read it because the time is buried under a halo of symptoms/speculations/politics/numbers etc., The consultant’s job is about asking questions logically so that the mist is cleared and the problem gets defined clearly. Very often than not, once the problem is defined, the solution becomes a no-brainer. I have seen in a number of cases, the person who has helped define the problem has not been part of the team that has been grappling with the problem. Not being part of it, helps the consultant to assess the situation with an unbiased/unemotional perspective. The example in my previous blog is a clear case of technical brainpower taking over and completely diluting the problem definition exercise.  The above diagram gives a view on how a systematic problem solving model should work. One should however falling into the trap of applying this for every single issue as there are enough problems where the problem definition/fixing are reasonably seamless without going through such a process.

Once the problem has been defined, the next step is to evaluate multiple solutions to the problem. Somebody with the right technical know-how would definitely help at this stage as that person would have the ability to present the business case as to why a specific solution is the best available solution for a problem.  The key caution at this stage would be that some really passionate techies fall the trap of focusing their attention on the benefits offered by the solution as opposed to focusing on whether those benefits are really relevant to the problem at hand. I have seen a presentation where a SAP consultant went into an over-drive on how the MM(Materials Management) module of SAP offers a number of benefits and is the best in the world in terms of how it integrates with the FICO(Finance & Control) module. Somebody had to remind that the pitch was about implementing the FICO module and the client was a Financial Services Client(in this case a Mutual Funds firm).

The next step is about solution definition and this is a case where the technical brainpower is required significantly. The solution very likely is very specific and how well the technicality is going to be used to solve the problem does require the best of experts. One would find the architect fraternity jump into the game at this stage. A number of projects, both IT/Non-IT have gotten into trouble because the right technical brainpower was not injected at the solution definition stage and had subsequently lead to the overall solution not solving the problem that it was intended to solve. Careful and Meticulous design of a solution will go a long way in solution implementation and subsequently problem resolution

The next step which is solution implementation does require occasional bursts of technical brainpower specifically when the implementation runs into issues that for some reason where not thought of during the solution definition phase or even simply to enforce the principles that were defined during solution definition (and contain deviations, if any). The need here is more for good project/program managers who can ensure that the solution is implemented as designed. They need to have sufficient technical knowledge to gauge and guide the progress of the solution and also to take a judgment call on when the technical brain power needs to be infused. The folks implementing the solution also need to have the discipline to follow the right engineering/quality processes.

The last step is about the team that helps run the solution so that the benefits (one of which is the problem resolution) are achieved. These folks do have some technical knowledge and as they get better at their jobs have the potential to become good problem definers. Technical brainpower may sometimes be needed if the service runs into serious issues primarily because of something not properly designed into the solution.

While none of the above commentary is revolutionary or new, the way the right brainpower is wasted in activities where it is not needed or lack of infusing the same where it is really something that baffles me. I think the lack of problem definers is the reason why this catharsis happens and if some of us can get to be better problem definers, the quality of the solutions can go up drastically. In fact, I have started appreciating the Sherlock Holmes books a lot more these days. As a matter of fact, Holmes’ method is all about focusing his energy on problem definition by observing every single item that a case throws up. His clarity of thinking is best amplified by the way he reconstructs a person’s entire life history by analyzing his walking stick in the “The Hound of Baskervilles”. We just have to remember that we don’t need a surgeon every time we have a medical problem. The family physician can help diagnose the condition systematically by just talking to us about the various symptom before deciding if a surgeon or a specialist is indeed required. The best of the doctors do exactly that. However in a fast paced world, where getting into details is considered taboo, poorly crafted solutions for poorly defined problems continue to rule the roost.