First, get the process right

Instead of using IT to initiate change, focus on the process and people first. Put the customer at the center, reorient the processes to delight the customer, then create the IT system to support the improved processes. Managers and IT developers, take heed!

* * *

Here's one trick I've learned in developing an IT solution. First ask, what process is our IT solution going to enable or support? Then, we build the IT system to fit that process. I've found this to be very effective in increasing the chances of success. And by increasing chances of success I mean making the software really useful, enticing users to use the system and get attached to it.

After a couple of IT project failures, I reevaluated our development approach. We hinged our hopes on the thought that employees will use software because it will make their work easier. But most employees are not naturally techies at heart. Instead, they think, "New software = more work." I've seen this happen many times that I thought we should start approaching development in a different way.

To change the approach, simply reverse the premise and assume that employees are usually averse to technology solutions. This opens up a different development approach. It forces us to design and develop around the needs of actual users. It requires us to understand the work process that users and actors go through, and how our IT solution could facilitate that process. It also involves working more closely with the users/actors, which in turn brings more buy-in for the solution.

One of my earliest clients to agree to this approach did not take a lot of convincing. She knew that their different branches used different procedures to perform the same job. She saw the sense of first seeking to standardize the different office procedures before attempting an IT solution.

So first, we embarked on writing down the steps for each core process, noting the variations. Next, we took a look at their policies, guidelines, and legal documents to find the minimum requirements. Then we improved the procedures by asking the question, "What value does this procedure give to the office?" With this filter in place, we were able to remove non-value-adding steps, redundancies, and outdated activities in the process. We closely consulted the users/actors who were involved in the processes.

The result were improved office procedures that were leaner and faster. The manager issued a memo introducing the new, standardized procedures, and tied these to the incentives of branches. Hence the motivation for adapting the new procedures was not IT itself.

When time came to build the IT solution, we simply got the improved flowcharts and used them as bases for the software. And since we worked with the users/actors to define the new procedures, the people  saw how the IT component snapped in place to facilitate the new procedures. This in turn built more enthusiasm and anticipation for the coming of the new software.

In traditional IT development, we often neglected to focus on the processes and the value that these processes delivered to the office and the employees. But the revised development approach, we gain a new lens on managing an IT project -- one that allows us to focus on the things that matter and to treat the client as development partners.

This demonstrates how, in many cases, management complements IT. Management's strengths can make up for the shortcomings of IT,  and vice versa.


Related article: IT is not the solution.