If the design and support staffs are segregated in your department, you’re in a fairly typical shop. Each function has a very specific and intense focus, and it’s sometimes difficult to integrate them. However, if senior IT management doesn’t make use of both groups in considering new design approaches, a major opportunity could be lost.
Your support staff can be invaluable in the design process. Whichever side of the fence you manage, you can bet that if you were to go to the support team and ask whether they think they could add a lot to the design effort, they’d give you a resounding Yes!. And that yes would go beyond the usual resentment felt by support personnel that they are undervalued and unappreciated (which they often feel, and justifiably so)—it would bring an important point to the fore: Your support people can often see where a new system will go wrong.
This isn’t to say that your design people are any better or worse at anticipating weak spots. It’s just that support staff often see more of the breakdowns and screw-ups than the design people do. They view your in-house systems from a different perspective, and their viewpoint is well worth including in your design thinking.
Let’s examine how you can involve them in the process.
Before the first cut
Here’s a possible first step. When a new project is launched, a summary of the system, its components, what it must do, and whom it will service is usually disseminated before a detailed design is undertaken. Those who will be involved in the design, including the customer, usually receive this, often before tasking for the design phase has even been done.
The customer is included in this effort with increasing frequency. In fact, modern design methodologies require the customer’s deep participation. Why? Put simply, today’s user is far more sophisticated than in years past and able to offer suggestions and process-critical input that the system’s designers find indispensable.
Doesn’t the same reasoning apply to your support personnel? Don’t they have a more intimate knowledge of your company’s production cycle, the foibles of its servers and databases, the communications bottlenecks, and interfaces beyond the company than your design people? They, like the users, can offer critical input that can head off collisions and production/communication issues before they ever start. Bring them in up front; let them review the system requirements before design begins.
Make support the customer
Once design meetings begin, invite your support people to the party. Often, a design group will walk through a new system with the customer/user present, in a kind of role-playing exercise. This helps everyone to focus on what will and won’t be done at various stages in a business process, providing the design people with peripheral information they don’t otherwise have that will light the way to the best possible design.
Try holding one such meeting without the customer (have the customer meeting later; don’t omit it). Instead, have your support people, specifically, the ones who service the customer/user who will use the new system, sit in as a replacement. Let them play the role of customer.
You’ll get a lot of the same input. Because they’re familiar with the user’s existing systems and problems, they’ll raise many of the same objections and suggest many of the same streamlining moves. But you’ll get something from them that the customer can’t give you; they can tell you the cost of not taking their advice, which the customer/user can’t. They can tell you what the maintenance burden or negative impact on other systems will be if you accept a particular design compromise or fail to take some seemingly innocuous factor into account. This is great input for the design group, because it attaches measurable weights to their trade-offs. Dialogue with the customer/user alone can’t deliver this with much precision.
If you have veteran groups with considerable tenure, you can go even further, if budget allows. Consider assigning a few dozen person-hours to letting support have a preliminary stab at the design. Let them meet on and off for a week, then present a tentative design suggestion to the design group—and let the design group find the support holes. (You would only want to do this, of course, if you felt you had personnel on both sides who could do this kind of role reversal without any kind of over-the-top competitiveness emerging.)
You’re unlikely to get anything deep out of this kind of exchange, because support staff generally aren’t sufficiently familiar with the design environment, or the rationale behind many of your core configurations (communications, servers, database tables), to offer a meaningful fit up front. What you will get is a tentative design that anticipates potholes. Support staff clean up corrupted database tables, track down runtime errors in communications, and do all manner of similar repairs. The suggested design they offer at this point will address these problems up front, rather than relegating them to afterthought. And the design group, sitting in the opposite chair, will have the importance of these matters emphasized before they put together the actual system design. Everybody wins.
Mitigate the meeting
You know your people and fellow managers, so you have a sense of how well this kind of interaction will go. Design staff and support staff often work together harmoniously, but they just as often don’t. Will it be a problem? If so, make certain there is someone in the sit-down meetings who is of appropriate rank, or particularly skilled as a facilitator, to keep things flowing smoothly.
Finally, once communication is happening, keep it happening. Choose the most appropriate support staff for continued input in the design process, and keep them in the loop. You’ll not only get a more robust, fault-tolerant system design in the long run; you’ll also bring about some effective cross-training and goodwill in the ranks.