Joseph Drasin is the director of University Process Innovation, Division of Information Technology, at the University of Maryland. In a recent article for Educause, Drasin described his dealings with the university department known for being inefficient and difficult to work with. “Their processes were perceived as cumbersome, costly, frustrating, and antithetical to their stated objectives,” said Drasin. “Several IT systems had been purchased and implemented to address these issues, which actually exacerbated the problems.”
Drasin and his team worked with the department in question to develop an overarching process that improved service and reduced administrative costs. After ensuring that all practices were consistent, aligned, and adding value, the group was able to implement a complementary technology solution.
Reflecting on the redesign process, Drasin shared words of wisdom that likely apply to most readers here. “When an organization buys a shiny new piece of technology and then tries to implement it without first having looked hard at its own processes and people, the vast majority of the time, the project doesn’t live up to expectations,” he said. “Even when successful, too many times the new technology looks a lot like the prior technology in terms of how it works.”
Drasin went on to share process excellence lessons from his journey, some of which were inspired by Alec Sharp, the author of Workflow Modeling: Tools for Process Improvement and Application Development. I’ve cited several of them here and also included some additional gems from Velaction blog author Jeff Hajek.
Issue 1: Getting ahead of yourself
“It is easy to let the conversation go straight to the details before describing the environmental context and determining what the individual processes are and how they relate to one another,” said Drasin. “Everyone needs to be on the same page contextually, and you’ll need to emphasize the importance of discussion — or the project can derail quickly.”
Issue 2: Decisions by consensus
“You should never vote on a process or other business decision,” said Hajek. “Those should be grounded in facts, not popular opinion. If there are two competing choices, decide on the criteria you will measure them by, but let the options go head-to-head against each other on their own merit.”
Issue 3: Placing stock in the law of averages
“It is very uncommon for averages to help you improve processes,” explained Hajek. “For instance, the average ship time compared to your target time tells you very little about on-time delivery. The average size of the component may make it look like a part is in tolerance when in reality it has a high defect rate. Make sure you have some way of looking at the spread of your results rather than just the average.”
Issue 4: All hail the artifacts
Drasin described physical deliverables like diagrams and flowcharts as artifacts. Problems occur when teams focus on artifacts to the exclusion of the processes and conversations that build them. “If the tools themselves held the value, you could simply borrow flowcharts from a similar organization and implement them. But developing artifacts alone, without the necessary context and commitment, rarely results in effective recommendations,” Drasin said.
For more where this came from, have a look at the QuickBase Fast Track blog.
Comments