The BIG Secret to Solving BIG Technology Issues

How many times have you been faced with some thorny technology or integration issue to resolve?

Maybe it’s getting your identity management system to integrate with your directory server. Or maybe it’s getting that web “SSO” proxy to actually protect your test website. Or maybe, you have a portal that is supposed to pull in bits of information from multiple applications and sites. Only…it doesn’t….

So you get your best people together and set up a big huge bridge call. Then vendor A points the finger at vendor B’s software or equipment. Both vendors point the finger at vendor C. Your internal people collectively point the finger at all three vendors.

What happens? Nothing. Or should I say, frustration happens.

Sure, there may be a few dozen calls, chats, emails, about the problem. But does it get resolved? Does the project move forward? I think you know the answer.

If any of this is sounding familiar, it does to me too. That’s the subject of today’s brief, but solution-oriented article.

There is one universal secret to solving the most difficult technology problems. I really want to keep you in suspense….but since it’s Monday….

The answer is painfully simple; so simple that organizations can’t bring themselves to do it until it’s almost too late.

Ready?

*Get your best internal technical people on the phone with the single most important vendor. Set up a screen-sharing conference, make sure everyone can see the problem displayed on screen, and that everyone can access it, and go to work. Then stay on the phone until the issue is resolved. *

In other words, set up a 2 – 4 hour call and stay put until done. That’s it. You’ve learned the “secret” to working through any complex IT integration, regardless of industry or technology.

Sounds so easy doesn’t it? On the surface, it is. But such a valuable call often doesn’t happen until the project is in real danger — if at all. So before I offer up a few hard-learned tips from the field, here are a few reasons why these meetings are sooo….. hard to make happen in the first place:

The “BIG 8” barriers to successful debugging calls

1. Your technical people want to keep working the issue themselves. They don’t want to talk to the vendor, or admit they can’t solve the issue themselves.
2. You don’t have the right level of technology expertise working the problem in your organization.
3. The vendor hasn’t committed the right level of resources to solve the problem.
4. You are unsure which vendor(s) should be on the call.
5. You maybe have the right vendor, but they make excuses why they can’t get on an interactive troubleshooting call.
6. No one is willing to commit to a 2 – 4 hour block of time.
7. Problem ownership is not firmly established and owned in the right place within your organization.
8. Too many stakeholders are on the call.

I could make a longer list, but the “big 8” apply to most situations. So what can you do about it? Enter the “barrier busters”.

10 barrier busters for creating useful, solution-oriented calls

1. Clearly define the problem to be solved. What exactly is the system doing or not doing?
2. Clearly define what pieces are involved. If you’re integrating 10 different pieces (servers, OS, middleware,. multiple networks and data centers, custom code), map the role of each very clearly. Often, the creative solution to complex technical problems is not what you think it’s going to be.
3. Clearly define the desired outcome. What exactly must happen, — or no longer happen — for the system to be defined as “working correctly”. Realize that the solution may only go as far as pinpointing the problem. Be prepared to schedule follow-on calls as needed.
4. Carefully manage the call attendee list. If the integration problem has enough executive attention, you or your project manager may be pressured into inviting non-essential stakeholders. This is not a project or work group meeting you’re scheduling. It is a hands-on, heads-down, technical meeting. The only possible non-technical or moderately technical attendee should be the project or program manager.
5. Get one vendor to own it. Some technology vendors are real troopers and will take strong ownership in resolving a problem. Others won’t. The key is to finding — or delegating — the vendor most likely able to solve, or help solve, the problem. Focus on one vendor at a time, no matter how many technologies are involved.
6. Get executive sponsorship on the problem if necessary. Executives can apply vendor pressure that you cannot. Carefully get them upset enough at the vendor side of the issue, to bring the vendor to the resolution table.
7. Be polite, but firm when scheduling with vendors. Many vendors do not want to commit hours of phone time to a focused solution. You may need to escalate.
8. Bring only your “A” technical players to the table. Politically, this may be difficult to do in some companies. But it’s vital to resolving the issue quickly. Realize that who you invite to the call may be different than who has been working the problem all along…
9. Don’t set a hard time limit for the troubleshooting call. This seems counter-intuitive in the project management realm. And I almost never (I said “almost…”) recommend it. But the technology debugging call is one exception. An open-ended call emphasizes to all players that the solution is the star, not the timetable. You’re perfectly willing to stay on the call as long as it takes to solve it. You’d be surprised how many issues are resolved quickly when the possibility of unlimited phone time comes into play… Plainly stated, the goal of this whole call approach is to get the right people together and put them on the spot for a solution.
10. Make the solution / debugging call your first line of defense, and not your last. Too often, the “all-hands debug call” happens late in the game, after the problem has gone on for a while, schedules are blown, and stakeholders are frustrated. But if you reverse this scenario and schedule the call early in the project cycle — after investing no more than 2 hours of internal troubleshooting time on the issue — you can save days or even weeks in some project schedules.

What is the recommended call setup?

You can keep it simple or complex (try simple). Universally accepted screensharing services such as GoToMeeting, WebEx, and Skype are great places to start. Anyone, on almost any system, can access a meeting using any of these technologies.

The main thing is to have a method to switch presenters, and give local control back and forth. This allows vendors or other team members to take control and make configuration or development changes as needed.

The secret of solving big enterprise technology issues is now revealed.

Your turn: what big technology or integration debugging tips work for you? Share your thoughts in the comments below.

Happy implementing!