If your IT department seems to be suffering from a stress epidemic, you may want to take a close look at the design of your business processes and whether poorly designed processes may be part of the problem. People encounter stress from their immediate environment, and that includes the nature and quality of interactions with coworkers. Frequent frustrating or demoralizing situations and mundane, repetitive tasks can bring on the symptoms of stress, including irritability, increased absenteeism, and decreased productivity. To address the problem, you should analyze your processes to identify and address the stress points.

Identify the trouble spots
Reviewing all of your business processes is a huge undertaking, but you don’t have to detail every aspect of your organization to identify problem areas. Ask yourself these questions to identify signs of operational stress among your employees:

  • Is there grumbling in general from one of your business arms?
  • Do you have high turnover in a department or specific job role?
  • Is there a noticeable drop in attendance or production from a particular group?

You can also identify problems visible from a process standpoint. Do you have too many errors in your final product, or does a particular task seem to take inordinate amounts of time? Processes may be redundant or missing in places, putting pressure on employees to try and correct the problem by their merits alone. If the problem is with one of your business processes, this strain will tap your resources and cause employee burnout, and that’s no good for anyone.

Look for stressors
For each potential trouble area you’ve identified, evaluate the possible stressors within the local environment. Some questions to discover common ones include the following:

  • Are management or lead roles effective?
  • Do your employees have issues dealing with other departments?
  • Are there problem employees within the team?
  • What are the expectations for the group?
  • Do the resources exist to meet expectation?
  • Does the physical environment show any need for improvement, such as air or light quality?

Determine if each question is relevant to your situation. Evaluate the relevant question on whether or not operational processes play a part in the problem area, or if another cause is apparent. If multiple problems are centered on a single individual, you probably have an employee issue to address. But don’t be surprised if you find that several people have similar complaints about operations in general or in particular, or if a task or set of tasks are consistently not being completed on time or to specification.

Sometimes it is difficult to distinguish between general gripes and a business-oriented issue, but if the team members in question are displaying signs of stress or unhappiness, and you’ve eliminated short-term or one-time problems as the cause, then it’s worth the time and effort to review the group’s procedures.

Operational stress
The easiest way to approach process analysis is to study the relationships between roles that appear to be closely related to the problem. You should review any operations documentation available, but generally speaking, verbal descriptions of “how things work” can be closer to reality and will help you pinpoint the problem.

This example illustrates how to uncover a process malformation between Account Executives (AEs) and software developers, where accuracy to specification has declined, and the AEs have complained that they are having difficulty working with the developers. Turnover amongst developers is high. The following is the current process for issue resolution:

  • A developer completes a piece of code, and turns it over to QA. If no issues are found, QA passes it on to be placed into the production environment and informs the AE and PM of the release.
  • AEs raise development issues with the Project Manager (PM) once they’ve reviewed the live final product.
  • If the PM is not available or does not act quickly enough, the AE goes directly to the original developer or Lead Developer to get the issue resolved.
  • The developer, under duress from the AE, the PM, and likely the Lead Developer, corrects the problem and releases the changes back to QA.

I’ve seen variations on this nightmarish time bomb in several companies. First, let’s address the AE complaint about it being difficult to work with the developers. Presumably, the developer normally gets his or her instructions from the Lead Developer or PM. This means that the first time the developer has interactions with the AE is when there is a critical and immediate issue. It’s highly likely that the AE isn’t happy to be having those encounters in the first place. If this is happening with increased frequency, the developers are constantly being bombarded with work-interrupting complaints—a highly stressful situation. This could be a cause of the high turnover in the development department and the root of frustration for AEs.

Now look at the other issue: accuracy has fallen. If a situation like the one above exists in a company, then expectations are probably very high, and the environment is fast paced. The problem here may center on QA. There could be a disconnect between expectation from the AEs, and the delivery from QA. One obvious solution would be to require AE approval on a staging server prior to deployment. In that situation, QA would likely bring up any discovered issues with the Lead Developer. Since a hand-off already exists between the developer and QA, it makes sense to use the relationship that is in place, rather than introduce a new one between the developer and the irate AE.

The QA process should also be reviewed to determine why accuracy has declined. Higher throughput, incorrect assumptions during development, or any number of other issues could exist and must be identified to improve product quality. By having QA post to staging for the AE, hopefully a relationship will form that facilitates inclusion of QA on product changes early. This also accomplishes an additional buffer for your development team, protecting them from disrupting requests from numerous people.

Be cautious and selective
The illustration above is one example of how a minor process change can reduce stress seemingly built in to business practices. Obviously, there will be exceptions and situations that still may cause some stress among employees, but by removing the day-to-day strain, your employees and employment environment will benefit, and productivity will increase.

By applying common sense and looking at a situation from each party’s perspective, needed process changes will be apparent upon inspection. However, before investing in a company-wide venture to root out stress-causing eddies in your practice, you should realize that change itself can be stressful to employees and damaging to your workflow. Be cautious and selective about your changes, and be sure to use an evaluation period to determine if the change has been successful.

Operational stress has been a military concern for decades, to evaluate when conditions must be addressed or changed in matters of life or death. By applying some of the same vigor to your internal processes, you can help ensure the health of your organization.