Information technology systems comprise software and hardware purposely designed to aid in accomplishing business tasks and objectives. They collect, process, organize, communicate and store information for smooth, effective and efficient running of an organization.
IT systems simplify complex business processes and cut down latency that manual systems generate and other attendant issues. Systems have become relevant because more than ever, the business community wants to do more with less and in the shortest possible time, to cut cost and serve as many customers as they can. Moreover, the technological advancements of the 21st century has also provided the womb for such desires to be birthed.
Systems can be purchased off shelve or specifically made to suite the need of a particular entity. The off-shelf systems hardly fail because they have been designed with a predetermined environment in mind. The only problem that may arise from using an off-shelf system is, if the organization has outgrown its use, the organization will need more fitting software to address the new challenges expansion brings about. The focus of this article however, is on customized systems that fail and factors that account for the failure of this systems.
Once a contract is signed for a software developer to develop a customized system for an organization, to fit a particular need, the software development has become a project and must be recognized and managed as such.
The Project Management Institute has three constraints by which project management professionals are to measure the success or failure of their projects: scope, time schedule and cost. This means that, any project which does not meet any of the triple constraint is a failed project; any project that meets scope and misses out on time schedule and cost is challenged and any project that meets all the three constraints is a successful project.
In recent times, project management professionals are trying to revisit and redefine the benchmarks for measuring the success or failure of projects upon realizing over the years that the triple constraint is a very narrow gate to pass.
IT projects to build systems for organizations whether large, medium or small over the years have mostly been failures and resulted in huge liabilities to the organizations.
The Standish group regularly reports through its annual reports of the status of IT system projects and shows whether there has been improvements or otherwise. In its 2016 CHOAS report, the group reports that, 71% of IT system projects in 2015 either were challenged or failed. The purpose of this article is to discuss why IT system projects either fail or are challenge for readers to take a cue from the discussion and revise their approach towards IT system projects and deliver successful projects and reap the benefits thereof.
1. Wrong system requirements. System requirements are the premise on which systems are built. Just like the premise of every building is its foundation and the very strong buildings have very good foundations, so does it relate to systems development to. Most failed systems have come about because the organizations themselves do not know what they want.
As the initiating party, an organization must specify to developers the requirements to which the system must be built, taking into consideration their entire business process and the portions if not the entire process that the system is needed to augment, and communicate this need to developers in clear, precise and concise language devoid of ambiguity for the project to fit purpose. The reality though, is that, organizations are not being diligent enough to make a full and correct assessment of their processes and adequately determine their requirement and end up communicating half-truth requirement to developers. The system ends up solving only a fraction of what is expected of it and this complicates the processes ahead.
Many organizations also outsource the duty of requirement determination to the system developer and the outcome is often disastrous. This has also contributed to the determination of wrong requirements leading to the development of failed or challenged systems because, the interpretation the developer might have of your processes could be completely different from the organization’s and if not resolved before development, the system would have been dead even before development.
2. Wrong scoping. Just like the old teaching that don’t ever lie because, you will tell another lie to cover the first lie is exactly the scenario here. The scope of the system is determined on the requirements provided and if the requirement is faulty, the scope can never be faultless. This translates to the revision of scope which mostly results in cost sky-rocketing while leaving more and more demands unmet.
Scoping of project means assessing the requirements and determining the size of work to be done to fulfill consumer requirements. Scoping entails information gathering, consultation, discussion with stakeholders and monitoring of existing events. All of this is done to determine the boundary of work – what must be achieved. If all of the preceding functions are premised on an inaccurate requirement, the system thereof will not be fit for purpose. This is one of the key reasons why IT systems are challenge or fail.
3. Wrong feasibility study. After scoping to determine the scale of work to be done, developers together with the consumer need to make a feasibility analysis to determine whether the system can be delivered, putting in mind economic, political and technological and all relevant factors internally and externally, which can change anytime and have a bearing on the system development. The feasibility study answers the question of whether the project is attainable or not and how the project scope can be implemented to fit purpose for consumer satisfaction. This critical decision is premised on the scope done and scope is premised on the requirement given.
Given this intertwined chain of events, once the requirement and scope is wrong, feasibility study will also be inaccurate in no uncertain terms and this implies that the to be developed system has failed or is challenged even before arrival.
4. Poor communication between developers and customers. To be able to develop a system that fits purpose, there must be enough or even more than enough communication between the developers and customers. There must be a project team which comprise of key professionals from both ends who need to work hand in hand at every stage to birth a successful system. This does not always happen. After initiating the project, most customers wash their hands of it and leave it to the developers alone to figure out. No project team is setup to liaise with developers to guide and achieve milestones. This leaves developers to produce systems as they understand it which might not be a true reflection of what the customer wants and will result in a failed or challenged system which will either be redundant or partially fit for purpose.
5. Inadequate financing. Financing is an issue in every circumstance of life and business, given the limited availability of financial resource. This is what has prompted the desire for efficiency in business where managers want to do more and do it well with very little resource but this does not always work. Sometimes, organizations need to go all out with their expenses to achieve the best they want. Developing a system costs a fortune. Because, programmers are going to sacrifice their all to program the system and the revenue the system will aid the consumer to rake in in the long run will be in no comparison to the payment made for its purchase.
Also, other production factors like the size of the organization etc. drive up cost. Organizations normally want the best of systems to augment their processes but are not willing to spend good funds on them. Developers end up providing what they are paid for because if at the end of the day certain cost elements which will realize a successful system is not provided, they are constrained to make do with what they have and this results in a failed or challenged system most often.
6. Factors of change. Change is inevitable. Change can be as a result of external or internal factors which can have a bearing on the project and determine its success or otherwise. Technology is ever changing with the speed of light and if there is a change in the tech requirements of the system and it is not communicated and managed, the system at whatever stage of the development process it may be could become redundant or challenged. Some of the change factors can be political factors; could be change in management or regulatory factors; could be demands from the industry regulator or there is a change of workstations and operating systems on which the system will be deployed. All this can affect the outcome of the system project.
7. Isolation of stakeholders. Stakeholders are interest holders in a particular venture. They seek the success of the venture they hold the stake in order to protect their interest. Where there is financial gain to be made, they seek to ensure profitability to increase the financial reward that is returned on their interest. Stakeholders are key pillars in every initiative. There can be many stakeholders, but the prime and foremost is the consumer to whom the service or good is provided then management and the bank rollers who drive the business with funds.
In taking the decision of getting a system, many organizations, entirely, do not consult, or consult enough relevant stakeholders, like consumer groups, for opinions and suggestions before making a crucial decision. Consumers are the ones who patronize the good or service these organizations provide. So, when companies contemplate augmenting their business processes to aid in effective and efficient delivery of goods and services, it is prudent and sound that those they provide for are a part of the process and make inputs about where they think adjustments should be made.
But for whatever reason, organizations isolate consumers in the decision making of getting a system. Most of the organizations only take the decision from the viewpoint of management and neglect the impact of the system on the consumer, and this mostly results in failed and challenged systems because, the system might end up satisfying management’s need but create a bottleneck for consumers which will hinder turnaround time for accessing the good or service which ultimately defeats the purpose of the system, and all investments made in realizing the system becomes a waste.
What they have also failed to recognize is that consumers are the ones who bear the brunt of discomfort in long winding queues, delay in accessing the good or service, loosing revenue and time, hence, they must be involve in deciding for systems and their concerns must be appropriately factored in the system development process. Not just what suites the comfort of management.
8. Unrealistic expectations. Reality is reality, and in business, decisions must be taken based on the reality of conditions than assumptions and ideal situations. In digitizing, computerizing or automating your business processes with the help of a system, stakeholders must have realistic expectation of whatever system that is billed to be procured. They must understand that, systems are aids and technology has limitations of its own. The prevailing technology in their domain might not allow for exactly what they may need, and they must be realistic enough to appreciate what they can get. This will give developers a relaxed mind to do their best to deliver a successful system. Systems are challenged or fail sometimes because, there are unrealistic expectations from organizations and they refuse to appreciate the available options and developers are pressured to meet their unrealistic expectations and end up messing the entire system and wasting scarce resources. The differing expectations are mostly not properly managed and communicated for cohesion to be realized.
9. Technical incompetence. To deliver a successful system needs technical competence which is womb to clear understanding of the problem before providing a solution. Some developers lack the requisite technical competence to fulfill the system but accept the challenge anyway and this mostly results in the project being failed or challenged.