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.