For years now, we’ve bought into the idea that being efficient means delivering work by repeatable, well-designed, and managed processes. However, technology departments can easily err by building out a process and just expecting the staff to abandon their manual process to use the new automated one. Successful automation doesn’t just appear out of thin air. Certain elements need to be in place within the organization for this type of advancement. Here are a few I think are necessary:
A grounding in process- For organizational purposes this means how we do things around here. If your IT department’s first impulse is to look for documented procedures when something goes awry and if the documentation doesn’t exist, the employee documents the new procedure—you’ve got this one locked down. In contrast, if your organization “solves” every issue as a one-off; it can be problematic. This “hero” approach assumes the person working the problem has all the legacy knowledge they will ever need to make the fix, when often they might just be using a half-baked idea.
Clearly understanding the difference between processes and practices- A process is a set of tasks, executed according to a defined sequence and flow, that produces repeatable, predictable results. A practice is a level of abstraction that describes the activities necessary to achieve the implementation of an individual technical task. Processes are great for manual tasks because they are like a recipe. All the ingredients and steps are detailed for the user. With a practice, the beginning and end are known (AKA the objective) but the steps in between are based on the skills or knowledge of the user. Automating a practice is much more difficult because it would require almost an infinite level of flexibility. Almost to the point where you’d have to write a set of new workflows for every situation. Which, obviously, is impractical. Project management is an example of a process. There are too many variables to rely heavily on automation.
The ability to design, test, manage and iterate on the process- Speaking of project management. Your IT department needs to be fluent in the basic principles of project management. While it’s not necessary to follow a formal process such as Six Sigma, at minimum, use a Gantt chart to track tasks. I had an interesting conversation with a former private-sector application developer who moved to a government agency. He said that for government it’s about the service delivery as an end result--NOT the workflow product. He thinks that’s why in some agencies there can be resistance to formal project management.
Openness to change and trust- Many, many, many organizations have issues with change. Wanting things to stay the same is a very human reaction. There are quite a few books on change management. I like this one by Chip and Dan Heath, Switch: How to Change Things When Change Is Hard. And there are many other books about change within specific environments or industries or processes, equally as good. Trust is a not-surprising-but-not-often-addressed component of change. Lack of trust has real consequences. Distrust causes the group testing a version of the process to assume it is defective. This leads to complaining, delays, wasted time, arguments, and other terribleness. An aspect of Agile Project Management that tends to foster trust is feedback gathering and then iterating on that feedback. This method shows the person who lacks trust that they are being listened to and their feedback is included in product builds.
These four principles make the difference between an IT organization that delivers and one that can’t. If you’d like to read more about automation check out our resources here.
Comments