Managing Modern Software Projects

“Technology is a useful servant but a dangerous master”, said Lange in his Nobel Prize lecture about the advancements of technology in the 20th century.

In the early days of the tech revolution, the number of products in the market were limited. The business had to search for products, settle on the closest fit, and then adapt their processes for the software to function optimally. Change management became the buzzword as did Business Process Re-Engineering (BPR). Teams were measured on their adaption rate and slogans like “the only constant is change” was heard everywhere.

Today, we have an almost infinite amount of products available, many with an almost unlimited ability to be customised. The bottleneck is no longer available technology, but rather a business’s ability to figure out what they want the software to do. Yet, old habits die hard. The IT departments and product vendors are still intimately involved and often lead implementation projects. Sometimes a representative from the business will sit in the project meetings, but often their role is negated to that of coordinating training and downtime. Mostly IT will explain the software and the business will then change their workflow to adapt to the software. IT still act as the adjudicator who will decide if customisation requests are technically feasible. Think about this: people who know a software product tell the people who know the business how to run their business.

The reasons are simple to understand: we still believe that technology is complicated and limited. Managers just do not have the time to study software or hardware infrastructure. These projects are time-consuming and business managers are normally glad to cede it to a technical department. And as these technical departments tend to communicate in a different language (technospeak) they find it more difficult to talk to business than just do the project and accept. Unfortunately, as they often admit, IT often do not fully understand what it is that the business really needs. Further, many managers are not aware of how technology can improve their throughput. They are so focused on dealing with the day to day operations of their department that they reserve strategic thinking for the annual strategic workshop which often do not provide solutions for current problems.

So everyone just settles on changing their processes and systems as prescribed by the product vendor.

Should the situation not be reversed? Should the people who work in the business unit and know it best not decide how they want the software to function and what it should achieve, aligned with the strategic goals of the organisation? By ceding control of projects to IT departments, vendors and consultants, the business becomes passengers on projects that have a fundamental impact on the way they operate.

Business processes should not be re-engineered with a new software product in mind, but rather aim for the best possible outcome. Russell Ackoff, an organisational theorist and pioneer of management science, did a lot of research on this topic. He developed a system called Idealised Design. The premise is simple: what would the system be like if we were free to replace anything and do things any way we want? Together with the theory of constraints (best expressed by Eli Goldratt in his book The Goal”), we have a set of tools to find our bottlenecks and design new optimal workflows.

Instead of taking software to the business and say “change your department to fit that”, analyse your business, design the best version it can be, then go to the market with a specific brief: find me a product that will allow us to do this. Then you will have the best business and not just the best software.

Leave a Reply