Jag Venugopal's Blog

March 12, 2010

Solving The Right Problem

Filed under: Project Management — Jag @ 5:03 pm

In IT, we are quick to jump to solutions. We are technologists, we know computer software well, and cannot wait to get started. We are also naturally excited about the latest technology that is available in the marketplace, and are eager to implement it.

Sometimes it helps to have a better understanding of the problem before we dive into proposing a solution. There are many problems that don’t need a solution. There are others for which a solution is not economical. Some problems can be solved in very simple ways – without all the bells and whistles we would have thrown at it. For some, we may find that the solution is not politically feasible.

To help project managers and business analysts better understand the problem or opportunity, before they dive into solving it, I offer below a few checklist questions. If a team is confident it has the answers to these questions, then there is a reasonable chance that it will come up with a satisfactory solution.

The list of questions below is not original. Various versions of it have been floating around in problem solving textbooks and training courses. Use it, enhance it, and pass it on.

What Is The Problem?

Frequently, we do not understand the problem in business terms. We specify our problem in terms of our pre-determined solution. Thus, we may come up with a problem statement such as “We need an underwriting data warehouse to …”, which already presupposes the solution. A better idea is to state the problem in purely business terms: “We need a better way to identify occupancies and geographies where we are making poor underwriting decisions”.

An interesting challenge, one that we can perform within a group, is to generate multiple problem statements. Break the group into three or so subgroups, each with some business and IT people, and send them away to define the problem. Review the different statements that emerge. You will be surprised that different people within the client/business community see the problem very differently.

When Does The Problem Occur? When Does It Not Occur?

If we plotted the problems in our underwriting example above, and found distinct times during the year that disproportionately accounted for errors, we could investigate what was special during those time periods. It could be that the department was understaffed. It could have been the case that there was pressure to meet year-end/quarter-end/seasonal goals.

An amusing and instructive case of a problem occurring only in specific circumstances was the case of the 500-mile email. Rather than dismiss the users’ concerns out of hand, Trey Harris built a hypothesis based on when the problem occurred and when it didn’t. Ultimately, with a better knowledge of the problem, he was able to trace its cause.

Another example of plotting timelines is that of un-closed sales, whether in a car dealership or on an Internet website. Were there specific times that the close ratio was very good? Were there other times when it was poor? What was common to those times when the close ratio was good? What about when it was poor?

A valuable group exercise would be to create a timeline relevant to the problem (day/week/month/year) and plot the incidents with the time-stamp of their occurrence. Breakout groups would then be assigned a task to generate a hypothesis that would explain the distribution.

Why Should The Problem Be Addressed?

Not every problem needs an automated solution. There is likely to be an entire class of problems for which a workaround is a perfectly acceptable solution. In the underwriting example, one question to ask is whether existing reports (perhaps with some small modifications) are sufficient to provide the required answers that.

 I was responsible for an application that sourced multiple data feeds from a data hub. One particular data feed was not sourced from the data hub but directly from the transactional system. This was against architectural guidelines that were in effect, which directed that all data feeds had to originate from the data hub.The data feed was working well, and providing the desired business benefits. Yet, we had a project in the works to redirect the source of the feed from the transactional system to the data hub.

 Asking ourselves why we wanted to perform this redirection helped us cancel the project entirely. We recognized that we would be disrupting a working solution, incurring unneeded cost, and increasing the risk of defects by tinkering with the feed. We felt pretty happy with our deliberate decision to not make the change.

 Group facilitated solutions with clients are a useful vehicle to develop a reason to address the problem. The gathering can be broken up into an even number of teams, with one-half coming up with arguments for why the problem deserves a solution, and another half providing reasons to the contrary.

What Is The Cost Of Fixing The Problem? What Is The Cost Of Not Fixing?

Even if a problem is worth fixing, the cost of addressing it may outweigh the benefits to be derived. Simple workarounds may be sufficient to address the problem.

 As an example, in one of my applications we had a database of training that our clients had undergone. We had complex logic to figure out what client the trainee worked for (traversing time-variant departmental hierarchies). The logic was erroneous in a few specific instances where the trainee worked for a department that was once part of a larger conglomerate but was now its own independent company.

 There was initially a great push to solve the problem – because this was “just plain wrong”. Further investigation revealed that the cost of rewriting the module, in terms of both opportunity cost and incurred risk was not worth fixing it. This problem seldom occurred, and even if it did, there was no real damage done. The cost of living with the problem was less than the cost of fixing it. We elected to postpone the fix indefinitely.

 In planning/scoping situations, the PM can work with a small subset of individuals to identify the cost of not fixing the problem – whether it is in lost efficiency, sales or profits. The cost of fixing the problem will need to be addressed for each proposed solution.

Who Is Affected By The Solution? Who Is Not Affected?

This question is Stakeholder Analysis 101. For any problem or opportunity, there are constituencies likely to be positively and negatively affected by the solution.

 For example, implementing a large ERP-style application in a union shop will likely make a few jobs redundant, and change the work patterns of a number of members significantly. Thus, the union becomes a stakeholder in the solution, whether management likes it or not. A solution that does not address union concerns is likely to have a very difficult time seeing light of day. Even if there are no union issues, similar concerns may be voiced from other departments, who might see their influence truncated or workload enlarged as a result of the implementation.

 Understanding all the stakeholders who are positively affected by the solution is equally important; it is from this list that one can find champions for the cause. Having a champion high enough in the corporate hierarchy works wonders in getting things done. Equally, having grassroots evangelists who are well respected can allow the project team to leverage their influence with fellow workers.

When Should The Problem Be Solved By?

Some problems are worth solving only if the solution can be implemented within a set timeframe. The best business case has a “use by” date. For example, a system to capture an emerging market opportunity cannot take forever to build, or the opportunity will be lost to the competition. A system that was being built for Y2K remediation would have been useless if it was rolled out in February 2000. Similarly, a problem with the website of a candidate for political office would need a quick solution. The most elegant solution to the problem would be useless if it did not help him get elected.

 How Do We Validate That The Problem Is Solved?

Many teams launch into solving a problem without understanding how the solution is verified. For our problem with underwriting decisions, how do we validate? Do we compare post-implementation underwriting profit with pre-implementation profit? How do we control for other variables such as competition, and the general state of the economy? In one project I was involved with, the solution involved improving the usability of the product. The validation criteria for the solution involved a specific reduction in the number of mouse clicks needed for a user go to through the application flow.

What Are The Different Ways To Solve The Problem?

There are multiple different ways to solve any business problem. As IT professionals, we are sometimes caught up in the latest technology trends, and see the platform du jour as the one hammer for all the nails of the world. A current (2010) example of such a hammer would be Microsoft SharePoint, which seems to be the be-all and end-all solution to most any IT problem.

 Some thought given to brainstorming multiple solutions, each with its tradeoffs, will help in arriving at the most optimal. Some thoughts, specifically related to IT are:

  • Do we need an IT solution or a manual process?
  • Do we go open source or proprietary?
  • Should we outsource, or solve internally?
  • Which vendor’s offerings shall we use?
  • What are the time/cost parameters for each solution?

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: