November 18, 2009, 6:55 AM — Attorneys might get a bad rap for being a rather demanding group of professionals, but they often do have a lot riding on how successful they are in making their cases. Bob Pate, Network Operations Manager at New Orleans-based law firm McGlinchey Stafford, certainly knows how critical keeping data available and communications flowing among its eight offices can be for his users. Likewise for Joe Moore, Applications Support Manager at the firm, who also is a Project Management Institute-certified Project Management Professional. The last thing either of these counterparts wants is a botched project that leads to inaccessible systems or downed applications. In this interview with ITworld contributing writer Beth Schultz, Pate and Moore reflect on …
KEEPING USERS IN THE LOOP:
Pate: Early on in my career, we'd start our implementation and we'd be nose to the grindstone throughout an entire weekend, say. We'd be so focused on finishing the project by the time Monday rolled around that we were leaving our customers in the dark. That's one of the things we worked to correct. Now I can point to a recent major upgrade of our accounting system. Throughout the course of the weekend, one person would send out an e-mail to the firm upon certain aspects of the project being able for them to use. In our case, we bill time. So when they were able to enter time, that was acknowledged to the group so those who needed to enter time could. Then further in the weekend we notified the group that works with more deeply-seated accounting functions for forms updates or things of that nature when those were ready for them. Another example is when we upgraded our VMware infrastructure. When we did that, we made sure that e-mail was available first, and we immediately sent out the notification when that became available. Then our accounting system was next in line, and we sent out those notifications, and so on.
STRIKING THE RIGHT BALANCE:
Moore: We don't want to overload the user community, but we certainly do want to make everyone aware of what's going on. The fewer surprises for users the better we’ll be in the end. So from the software perspective, very often the first thing we do is create a plan that lists all the communications that we want to use during the project among the project team itself as well as to the end users. And then we keep the proper audience informed through e-mail and sometimes from our intranet home page.
GETTING USERS INVOLVED:
Pate: You learn early on that you need to get buy-in from your customers. Get their input, especially from the application side. Now that I’m on the infrastructure side, I'm shielded from that to some degree. But I think back to when I used to do software development -- you’ve got to get user input even for something as simple as a screen design. It just makes the buy-in and acceptance of a project so much easier. The first five years of my career, I was still putting together a screen based on what I thought worked best, but, in all honesty, 75% of the time, I was way off base.
HOW TO PICK PILOT TESTERS:
Moore: We learned from a document management system upgrade we did earlier this year to make sure users in the pilot group are geographically dispersed--meaning that we’ve got users from all of our different offices as opposed to in just a few focus offices--and that they represent the different positions--attorneys, secretaries, admin staff and so forth. In other words, get a broad range of pilot group members. You're much more likely to uncover any issues when you paint that broad picture as opposed to staying focused. For this upgrade, we had focused the pilot group in the New Orleans office, which is where I'm located, and we found out that there were slight differences that we could have uncovered had we gone out to a broader audience. That’s not to say the upgrade didn’t go fairly smoothly, but we could have done some things better. This is because of differences in cultures at different offices and not so much the software or the hardware platforms.
IT FRIENDS AND FOES:
Pate: You can’t just work with people who are IT-friendly; we involve people who are sometimes critical because those criticisms can be constructive and can help make the overall product implementation better. We have some people who are very resistant to change. We have other people who want the newest technology--now. And it's good to get a cross section of both groups so you can create an environment that's good for the entire firm as opposed to a group of gung-ho users.
OVERCOMING RESISTANCE:
Pate: You can't satisfy everybody, so you have to walk a fine line. But by bringing in that diverse group of customers in the early phases of a project, as well as making users part of a pilot, you're able to stem off some of the resistance.
THE IMPORTANCE OF A GO-TO PERSON:
Moore: When you’re in that situation, or are dealing with users who have different opinions about something, having someone in place in the user community who can make decisions really helps. The person in IT should not be making the decision.
GETTING OUT AND ABOUT:
Moore: The first day or week after a software implementation, we make sure we’re very available and that the user community knows who to contact for problems. We also often do walk-arounds. We make ourselves very visible so if people are having problems we are readily accessible.
THE PROJECT WRAP-UP MEETING:
Pate: We've implemented project wrap-up meetings to go over lessons learned. That gives us a good, solid base so we don't duplicate mistakes.
Moore: And then one of things we do before commencing any large project is go back and look at any other projects we've done in the past that are similar in scope or in content and look at those lessons learned. We look two to three years back and see what things we did then that could be helpful or, conversely, things that we didn't do that we now know we need to do.
CLOSING THE LOOP:
Moore: We'll occasionally do user surveys afterwards. "Does the software work as advertised?" "Did we do a good job in the implementation?" We ask them, "Did you know what was going to happen? What do you think of the changes?"
Pate: We also recently started sending out more in-depth and technically detailed surveys for those people who have been involved in the actual projects and implementations -- meaning, primarily, our own team members. We tell them to go ahead, be blunt and frank because that helps us tremendously in identifying weaknesses in our project process or even in some areas of our management style.
BRUTAL HONESTY:
Moore: We do make these surveys anonymous, but even if they weren’t, I think people would still be blunt. There's an understanding that there won't be any recriminations. We're just trying to get information so we can do better next time.
Pate: We've got to brag a little bit about the team we have here. We’re brutally honest with each other. That's because we know we're not going to be taking potshots at each other, and that we're working to find a better way to get things done.
And that's just a good team environment. I've been in a couple of pretty cutthroat organizations and there have been those who have taken those steps and do those types of things. Now, granted, they are few and far between and, in my experience, those people are already disgruntled employees for whatever reason. But here at McGlinchey, I don't recall that ever being a problem.
Moore: I wouldn’t put myself in that position. Nobody wants to work like that.
What do you know now that you wish you'd known then? Share your tales here or contact Beth Schultz, at bschultz5824@gmail.com
