Dealing with Problems

Posted by on Oct 15, 2013 in Blog, Featured | 0 comments

Perfection is a laudable goal,  but in the real world something always happens.  Mistakes by technologists, missed or evolving requirements, flawed assumptions – no project can escape reality. In fact, the entire discipline of Project Management aims to mitigate those risks by putting in place processes and procedures to add structure to creation. That’s not to say that problems won’t happen, but a good project management structure can not only anticipate issues and work to avoid them, but respond to them constructively.

Much of the implementation of technology projects focuses on getting a project to completion, at least to a certain phase of it. A well designed, iterative project includes collecting data and using that data to drive the next phase, with the aim of spiraling toward a better and better product. But those focused on implementation often give short shrift to post implementation support, and using that information to make a better user experience.

The best public example of a failure  is the rollout of the website. The technical issues certainly got the lion’s share of the press and in an ideal world it wouldn’t have happened.  However, the stark lack of communication as to the problem made the user experience even more frustrating than it should. No where on the website did it talk about the issues being faced. Nowhere could you find a link to explanations or ETAs for the resolution of the problems. You had to rely on an overburdened help and chat system, which increased the level of frustration.  Many users (including myself) threw up their hands and abandoned the site altogether, hoping that maybe a couple of weeks later it’ll be better.

In another example:  recently, a client of ours moved from an internally hosted email system to a cloud based system sold by  While the focus on value, the vendor chosen was well-known in the industry. As expected, there were several challenges in the migration from the user perspective, most notably  differing expectations on how an externally hosted solution operates as opposed to the internally hosted one.  However, a week into operations on  this system, the vendor experienced significant performance issues, to the point where the IMAP services provided were simply not working. Public sites such as as well as that vendor’s public forums started accumulating user feedback that there were problems,  but their support page showed all green, no significant issue. Multiple inquries into help and chat were no help. After a few hours there finally was some acknowledgement that there was a problem but then it was reported fixed (on the status page), but people still had problems. Private inquires to the help staff indicated that they knew of the problem, was working on it but had no ETA and had no mechanism to inform the users when the problem was fixed.  The problem indeed was resolved at some point, but there was no formal notification that it was and no communication of any kind on what the issue was, what was done to resolve it and any reassurance that the problem couldn’t or wouldn’t happen again.

The takeaway from these experiences is this: Overshare. Have a problem with your implementation? Be proactive. Tell  your users. Even if you dont know why or when it will be fixed, let them at least know YOU are aware of the problem. Don’t let your user think the system owners are less up to date than they are.  Users can be understanding of issues IF they believe you’re on top of it.  And once the problem *is* fixed, be proactive in communicating to your users that the problems *are* resolved.

Leave a Comment

Your email address will not be published. Required fields are marked *