Month: July 2013

As wrote earlier, I have been participating in quite a few digitization projects. Usually, the basic premise for the projects has been to emulate a human based process in a digital manner. Or, we have tried to make the shoe fit the foot. One of the things I have noted, is how requirements seem to be incompatible with the how a system works. In my experience, human processes are very agile and easily adaptable to any problems that may arise. As human beings, we are able to improvise very quickly in order to finish a process that has gone awry. IT systems, on the other hand, are very stringent in the manner in which tasks are handled. They can only handle tasks in a given number of ways. This, of course, presents a problem in some cases, as we will not be able to support all human processes in the system.

My suggestion is to reverse the train of thought. Instead of adapting the human process to the system, maybe we should rethink the human process for starters. I am not suggesting that we ignore user requirements at all. I am suggesting that making changes to the human process may indeed yield increased benefit from the system support, since we will be much better equipped to support our users. Most human processes have been cultivated over several years anyway, and it might actually be beneficial to have another look at them, since technology has evolved so much over the years, and maybe able to better support the users in their daily work, if their processes are changed.

What I am looking for here, is an authentic digital process. Not an adapted one. A good example of this is the Windows Phone operating system. The designers did not look to recreate “real life” on a screen, but rather designed a new digital process, which then supports given human tasks. In my opinion, it makes for a much cleaner and more effective process, which hopefully will support human tasks as well as the other scenario.

For a couple of years now, I have been working on various digitization projects, both in the private sector and the public sector. A common characteristics has always been the pursuit of cost cutting, meaning that the basic premise for even starting the project was to lower cost associated with a given operation or process. Most of the times, a business case has been created in order to prove the actual benefit of said project.

These projects have always been ran as IT development projects, and always with a pretty tight deadline. In my experience, the deadline itself will at some point be the holy grail of the project for pretty much all the stakeholders. Anybody who has been part of a project like this knows that when the deadline approaches, we start to redefine the scope. In SCRUM we will prioritize which features we want first and which features are less important. More often than not, the result is a system that does not live up to the requirements of the business case. Or in other words, the system cannot yield the benefits that the business case assumes, thereby rendering the return on investment calculation invalid.

Now, don’t get me wrong. I am fully aware that there many reasons why we change scope. There’s a resource aspect – if we prolong the project the cost of manpower is going up, if we don’t start production on a given date, we miss savings opportunities etc. My point is just that by going through this exercise we violate the principles on which the project was started in the first place. The next question would then be, are we in a better position after we have released something to production than we were to begin with? We can really only hope so. I would stipulate that the business case is doomed to fail, any which way you look at it.

I suppose it would be possible to apply an equation here that would allow us to determine whether or not to proceed with a project, if the feature benefits are out scoped. Food for thought at any rate.