How to have a good failure

The other day I got an email about an old conference room I'd had set up in Exchange.  Nobody remembered how it came to be except me and the guy sending the email.  We'd both moved on to other jobs, so that's why we'd been asked about this thing.

If you don't use Outlook/Exchange, this is what I'm talking about: you set up a "user" that's actually a room or classroom.  They're called "resources" in Exchange, and when you're setting up a meeting with a group of people, you can list that room as your meeting room.  Depending on how the resource is set up, you're automatically booked, automatically rejected because of overlap, or a human reads an email and gets back with you.

Someone thought that setting up room schedules via Exchange was a better option than the shareware program we'd been using (and that was going away), and in some ways, that was true.  In other ways, not so much.

Our previous program was going away because it was insecure, out of date, and on a server going out of warranty.  We'd been working in SharePoint for a while, so the decision was made to do scheduling of rooms there.  At the same time, I and a few others looked into the Exchange option.

A lot of times there are more than one set of audiences or customers to consider.  As IT, my interest is in keeping the servers humming and the services moving their data around.  The end users wanted a simple way to book a room and to know that the room they're after is actually free.

The other customer to consider is the department actually responsible for the room(s). In this case our building manager.  He needed to know more than how many people would be at the meeting. He needed table set up information, video/projector information, and other specifics that would not fit on to the Exchange forms, but that could easily be added to the SharePoint calendar forms.  (Modifications could also be made to Exchange, but at a much higher cost in time and coordination).

So after a review, the building manager - the real owner of the service of booking rooms - made the decision that we would stick with the SharePoint calendars. If folks wanted to avoid overbooking, they'd have to check the calendars first.

I changed jobs not long after, and so I got the email, asking if it was OK if that old room was deleted.  I said sure, nobody's using it.

In the process he'd learned about customizing forms, I'd learned about customizing Exchange, and the limits of what's available to a single department in a large enterprise.  Even if we'd gone up a blind alley, we'd come out with more knowledge than we'd had before.  Failure isn't always a loss.

But like every other job, there needs to be a cleanup afterwards.

Wherever you go, there you are

So there are a few sites that have Ten Questions for this and that.  This site is about problem solving.  Specifically, you ask these questions in order to focus your attention on what's important to you.

The "Plus One" came after all the rest.  It's the top question, the first one to ask: What problem are you trying to solve?

It's not original to me, others have made the same point - asking this question helps you to not insult someone who's out of their depth when they're asking you about something you know a lot about.

The problem I'm trying to solve with this blog is to have a place to discuss problem solving, demonstrate the use of the questions, and get feedback on all of it.