Every person has something unique about the way they go about their work. These styles evolve over a period of time with people picking up practices from experience, co-workers or bosses. Applications are built with the purpose of standardisation of practices for the benefit of the organisation which usually puts a cramp on individual style. Every department has something that is stuck because IT won't provide them that one application. These applications before development are absolutely “critical” for the business. Once developed, there seems to be no urgency to test it and put it into production to save the dollars for which they were ostensibly built. The team that asked for the application finds functionalities that they require missing even though there are signed Business Requirement documents. The IT team goes around in circles trying to achieve closure. The application becomes a sore discussion point at every review meeting with both IT and User teams expressing their dissatisfaction with the way things are. Still there is no progress. Ultimately everybody’s priorities change and the application is forgotten. I am sure most people working in IT will have a few of these on their list. So I thought it may be worth trying to examine why several millions of dollars are spent every year across enterprises in developing applications that finally get relegated to the bin.
Insufficient business case: Some applications are built on a whim - usually someone very senior who thinks that it would be a great idea to automate a process that is close to their heart. One CIO narrated an incident where a senior business leader wanted her team to build a Task Manager so that the leader could track what each person in his team was up to. The plethora of applications available out there and the Task Management tools in MS-Outlook was not enough for this leader. The people who this application was supposed to track “discovered” some or the other glitch with it and the project was doomed for failure. Soon the business leader’s role changed and that was that.
Over engineering: In this case a bunch of people who are not usually the end users of the application provide requirements to IT. They painstakingly build provisions for even the most outlier of situations. For example while developing a Supply Chain application, the team defining requirements spent a lot of time providing for audit reviews. Extensive validations, audit trails and a convoluted workflow made the final product unusable. In another case, there was a need to build a middleware to integrate data between the organisation’s ERP and an E-commerce Marketplace. The business was ambitious. They foresaw a situation where there would be multiple data sources and many market places and the solution was purpose built with this in mind. The ambitions never materialised and the over-engineered solution did not get used even for the one-to-one scenario which was the original requirement.
Sponsor Weakness: The reputation of the business leader who is seen as the sponsor for the application often decides its fate. In one BFSI example, the Business Leader had delegated power to one of his reports, an AVP. The AVP engaged with the IT team for a project to automate a critical area of business. That the AVP was not seen as a powerful enough was one part of the problem. His constant absences from review meetings sent signals that the project was not really important to the business. The project went off track and his team lost interest immediately after the first delivery from the developers. In another example from a different industry, the Sponsor initiated a BI project to take the organisation from an Excel-based reporting era directly to “Big Data”. The IT team at huge cost and effort rolled out the first phase. Initial bugs were quickly squashed and performance expectations addressed. But strangely the Sponsor still found comfort in the Excel Sheets of yore. No surprise that the team below also did not migrate to the new platform.
Lack of user involvement: Many projects are initiated by department managers or people in the Head office while the intended users of the application sit in various locations. Often times these users have no inkling that an application is being designed and developed for them somewhere. On deployment, the development teams often learn of processes that are missing or incorrectly configured in the application leading to non-acceptance of a solution which the users did not ask for in the first place.
Misaligned Expectations: A few years ago, before the advent of cloud solutions in the country, the Sales team at a Pharmaceuticals major initiated a project for a Lead Management System. The IT team after evaluating various options decided that a bespoke solution was the way forward. Since the requirements were not completely straight forward, the vendor selection, negotiation and contracting took more time than envisaged. For the Sales Team, the clock had started ticking the day they articulated requirements. IT did not verbalise the process they needed to follow and missed sending updates. Each team assumed that the other knew their expectations. After following up for a while, the Sales department devised a non-IT work around to resolve their immediate problem. This was quickly adopted by everyone in the Team. Without anyone in IT really noticing a data mart slowly sprouted in the Sales Organisation.
Underestimating Dependencies: The Operations Team at the Head Office and the IT team at this Retail organisation worked well with each other. Their mission was to develop a Mobile Point of Sale (PoS) – a first in their category of retail. The Ops team involved people from the shop floor and made sure that all business processes were completely captured and developed. The stores had existing Wi-Fi points which were used for the current stock taking application. Everyone waited enthusiastically for the delivery which came slightly behind schedule. But no one really complained. This was a biggie and small delays were expected. The Testing cycle was quickly completed and the solution was to be piloted in the first store. They chose the biggest store in the chain. After all you've got to meet those problems head on. Alas, the Wi-Fi access points that served the Stock Take application so well did not work with an application that assumed rock steady always available Wi-Fi connectivity. Intervention by the networking partner showed that the existing access points best suited for home use did not fit the requirement of an enterprise application. Costs for a larger number of more expensive access points threw budgets out of gear. The application was put in the back burner. And it stayed there.
Seasoned IT practitioners can sense projects that are likely to be duds and ensure that situations are aligned in favour of successful deployment before embarking on the project. They do this by exerting the proper rigour during the planning phase and communicating constantly. Usually, these people also have a pretty effective informal network within the organisation. User Experience has been primarily responsible for the millions of downloads from Mobile App stores. Taking a leaf out of their book, several Enterprises have begun the practice of hiring UX agencies for application development projects.
Of course, there could be many more factors that decide success or failure of application development projects. An early understanding of the uniqueness of your own organisation should help you have a more favourable success ratio.
Do you have a favourite Orphan Application Story? Would love to hear it.
Auther's Bio: Ranjit Satyanath has over 21 years of work experience handling Technology and Systems. He has worked across industries such as Retail, eCommerce, Banking, Media, IT consulting and Logistics, and has a significant exposure in both Physical and Digital Retail.