Don't hesitate to change directions if you find yourself going down the wrong road

Learning the hard way... 

Particularly when dealing with complex technology solutions, it is not unusual to start off following a problem-solving approach that doesn't bear fruit.  But an even greater mistake would be failing to acknowledge the original error and then compounding the initial failure by waiting too long to reassess your technical strategy. MSA Vice President Bob Vishneski has been there, and shares what he learned.

By Peter Longini, Managing Editor

The great Achilles heel of most ideologues is that when their dogma doesn't seem to be producing results, they become convinced it's because the ideology hadn't been applied with sufficient zeal, so they redouble their fervor, only to realize even greater failure.  The thought that their philosophical pathway may have been wrong in the first place never enters their minds.

But you needn't be a fanatic to find yourself persisting along the wrong path toward a sought-after goal.  It can happen to anyone.  Just ask Bob Vishneski of Management Science Associates, whose flagship product Gabriel, an enterprise-wide software application designed to help customers in the television business manage their cable television networks, began experiencing problems.  

Although the product had already won strong acceptance and the company had earned the confidence of its specialized clientele, some customers were beginning to experience performance problems in the field.  Their problems became particularly acute during peak times, when the number of users logging onto the systems would reach their highest levels.  So MSA's programming staff, systems engineers and product support staff orchestrated a concerted effort to determine the root cause of the issue and develop a service patch to fix it. 

The incremental pathway

They followed a rather incremental approach, chipping away at the problem one piece at a time.  And it took them much longer than expected.  But when the fix was finally released, nothing improved.  "We put out a service pak that we thought would address some aspects of this problem," Vishneski recalled.  "But when the time came to put it into operation, it simply made things worse, so we had to roll it back.  We had deluded ourselves into thinking that we were getting closer to solving the problem when in fact we weren't." 

That was when the light went on for Vishneski.  "I started looking a little differently at all the time that had been spent until then.  We had kept going at this incrementally - another day, another week, etcetera.  And we really weren't getting closer to solving the problem.  We had indulged that a bit too long.   We needed to say: ‘wait a minute.  The team is putting a lot of work and long hours into it, but the fact is we're not solving the problem.  And we don't have a good reason to think we're getting closer to it, either.' "

"A lot of times people involved in software development have a significant pride of authorship," Vishneski observed.  "It's their baby.  So when something goes wrong with it, they naturally think they have the best set of eyes to look at it and figure out what's wrong.  It's certainly fine to give them first crack at it.  But you have to time-bound these things." 

Plan B

"That's one of the lessons I learned - to time-bound it:  We'll give you guys a chance to look at it, fix it.  But this is causing our customers some serious problems.  And if we don't solve it by a certain date, we need to know what Plan B is, in detail, upfront," he said.  "As you get closer to that date, if it works out, great, you won't need to execute Plan B.  But if it doesn't, you better have Plan B laid out and be able to tell both your clients and your staff what you intend to do next to solve that problem." 

Where does Plan B come from?  And at what point should it enter the scene?  Right from the outset, according to Vishneski.  It's almost as though you had entered into an upfront agreement with your preferred strategy; if things don't work out by a certain date, everyone agrees to drop it.  "In these types of situations, you may want to have a Plan B at the outset - not to admit failure of your first plan, but to acknowledge that sometimes in software problem-solving, given the complexity of what the software does, going down a particular road may or may not yield fruit.  So it might be helpful at the outset of a significant problem-solving exercise to spend some time upfront saying: okay, if we take this approach and it doesn't work out, what's our next step?  And we failed to do that.  We kept going at this incrementally.

Getting from here to there

"It's similar to traveling from Point A to Point B.  You get into you car, you start going down the road, a certain amount of time passes, and you're not getting where you need to be.  So maybe you press down on the gas pedal a little bit harder.  Well, the truth is you may be going down the wrong road.  No matter how fast you go, no matter how many people are in the car with you, it's just not going to get the job done if you're going the wrong direction.  At some point, you've just got to stop and ask yourself: am I going in the right direction?  And if I say the answer's yes, then challenge one another to say why we really believe that.  What demonstrable facts can we point to that tell us that we really are closer to solving this problem? 

For Vishneski and his associates at MSA, several other valuable lessons were learned as well.  For one thing, it is easier to see a problem through the customer's eyes if you actually go to the customer's workplace.  "A lot of times you fall into the trap of thinking that because there are all these connectivity options nowadays, you can get on the client's machines and do all the local diagnostics remotely," he said.  "But in certain situations, there's nothing like being there, on site, with the client, sitting down in their environment.  It opens up the opportunity to catch something that the client didn't articulate, that maybe you can't see from a remote location, and to engage the client in the sort of dialogue that can't be done remotely."  So after just three days on site, the visiting MSA associates were able to identify the problem and, in just one additional day of programming, to fix the most critical performance issue. 

Extra eyes

But they also had help: the client went all-out to make its technical staff available and to create an environment supporting the problem-solving process.  MSA also engaged an independent third-party consultant who arrived knowing nothing of the problem or of the attempted solution.  Retaining an independent expert had become part of MSA's hastily-assembled Plan B.  "It was pretty much bringing in an outside party to put a fresh set of eyes on the issue and give us a little different perspective," Vishneski said.  "We were all a little bit too close to it.  So focusing a second set of eyes on a problem you haven't been able to solve in a certain period of time can often yield good results.  There's always a little resistance to that, but by and large, you can overcome that - particularly if you keep in mind that we're here to solve problems for the customer, and if you can't do it in a timely manner, the team has to be willing to change its approach.

"So don't be afraid to reassess your strategy," he said.  "And if a different course seems like it's called for, take the chance to go down another road."

About the Author:

Peter Longini is the Managing Editor for Inside Product Strategy™. He can be reached at This e-mail address is being protected from spam bots, you need JavaScript enabled to view it

To read our latest articles in Inside Product Strategy™, click here.