‘Mr Corleone is a man who insists on hearing all bad news immediately.’ | ||
| --The Godfather | ||
Modern organizations today require myriads of IT equipment like computers, telecom devices, data and voice lines, security devices, firewalls, software, etc. Proper selection, installation, configuration and maintenance of those IT environments are of crucial importance. Implementation, configuration and handover of such equipment can be considered as an IT project. For example, installing a new local area network with the necessary servers, e-mail, Internet, desktops, preloaded software, etc, for a new office can be classified as an IT project. Dozens of factors must be considered during an IT implementation. Some of the common, and most important, factors to be considered in an IT project are:
Proper selection of the right equipment
Design and capacity planning
Cost factors and budgets (one-off and ongoing)
Inter-dependencies
Software licensing issues
Ongoing support, maintenance and staffing issues
Training and support requirements
External and other factors
Vendor contracts
Miscellaneous issues.
Many companies outsource their internal IT work, and may also serve as service providers to external clients. Organizations are heavily dependent on external service providers to implement, maintain and support their IT infrastructure. They also outsource entire IT projects to external service providers and consultants. For example, a number of industries depend on external hardware vendors and software firms for developing and implementing IT projects.
IT projects can fail in a number of ways, however, and such failures can affect an organization severely, eg:
Costs: Improperly designed, or poorly-chosen, equipment can result in a lot of wasted costs. For example, buying cheap unbranded computers instead of reputable branded machines may seem cost-effective, but can cause long-term damage and wasted costs. Sometimes more money is wasted by not killing an improper project on time, causing a cost spiral and loss of jobs later.
Reputation losses: Failure to implement an IT project that meets a customer’s requirements can cause reputation losses for the service provider as well as losses for the client. For example, poor project deliveries to customers can affect the reputation of an organization, causing loss of new or existing customers.
Legal issues: Clients may also sue service providers if they goof up critical projects. For example, external customers may sue software development companies for delaying or messing up the implementation of a critical software project.
These are all disasters from a business perspective.
As with any project, there are a number of risks associated with an IT project. These days IT projects are more likely to affect a business than non-IT projects. This is because organizations are more and more dependent on IT for all their data, communications, connectivity, etc. Secondly, organizations have to constantly upgrade and implement newer and newer technologies to remain competitive. Implementation of such technologies will normally involve constantly creating and managing new IT projects. But there are many reasons why such projects fail, eg:
Poor capacity planning: For example, some new multiuser data entry software may not be able to handle heavy data entry loads. Or, a new network connection between offices may not be able to handle the level of data traffic between the sites.
Bad technical designs: It is possible for an entire IT project to have a bad technical design. For example, service providers or IT departments may select wrong or unsuitable IT equipments due to budget constraints, political reasons, insufficient knowledge, sales gimmicks, fancy marketing brochures, etc. The entire design may be technically flawed or may not be the right solution for the need. In such cases, the technical implementation may be successful but may not meet business requirements later. In other words, it leads to an ‘Operation successful, Patient died’ situation.
Political reasons: No organization is free from internal politics and back-stabbing of various sorts and degrees. In addition, there are more culture clashes these days as workforces become more and more culturally diverse. A project initiated by the head office located in one country may cause job losses to employees situated in another country. Such projects have the risk of failure or delay caused by employees of service providers who may be negatively affected.
Budgets and timelines: Projects can also fail to meet business expectations due to inadequate budgets or unrealistic timelines. It is a well-known fact that most projects are given insufficient budgets and timelines by the management. Secondly, many projects have inaccurate estimates to begin with. This is because of the way most IT projects are sold to senior management within organizations. Tell the truth in many organizations and projects don’t get funded. So project managers and sponsors lie instead to buy time and somehow start the project but cause dogfights and bloodbaths later.
Bad managers: According to various workplace surveys, studies, etc, bad or weak managers account for a large percentage of project failures. The badness can be in terms of abusive behaviour, poor knowledge, inadequate experience, lack of professional guts, etc, leading to various kinds of workplace and team disorders. Bad managers can cause projects to fail by causing resignations of key talented staff, unachievable deadlines, over-commitments, etc. Believe it or not, many employees prefer not to report potential problems to senior management, whether because they don’t want to appear to fail or because of past bad experiences. Even today many managers do not like to hear bad or expensive news. Very often a ‘shoot the messenger’ attitude is displayed, instead of appreciating the gesture, so staff avoid or delay telling bad news to them, resulting in catastrophes later.
Example . Real-life example
In a particular organization, electrical fuses used to blow often due to erratic voltage and other uncontrollable issues. So the electricians of the firm frequently used ordinary wires instead of proper fuses. One day a power surge meant that the entire system was destroyed. The electricians knew they were supposed to use proper fuses, but did not use them. The reason was that those electricians were reluctant to deal with a foul-mouthed supervisor in charge of buying fuses and other essential parts.
Business decisions: In many medium- to high-profile projects the objectives, scope, budgets, timelines, people, etc, are decided at very senior management levels. Next such projects will be forced downwards with a tremendous amount of pressure, clout, secrecy, veiled threats, etc. Very often, the top guys will refuse to accept or listen to any real world issues or specific problems that might affect the project. Frequently the messengers of bad news are punished or pushed out of the projects, leading to a fear psychosis, covering up of bad news, cost escalations, etc. Often bad news identified at the lower levels gets sugar-coated and presented as non-issues, or even good news, to the top management. Soon reality kicks in and it will be too late to prevent the impending project failures.
Organizational inadequacies: Not all organizations are capable of flawless project execution within agreed costs and timeframes. It doesn’t matter whether the organization is big or small. Sometimes big organizations may not be able to fulfil a small organization’s needs because of the inherent way in which big organizations function. Long timeframes, elaborate processes, lavish overheads, etc, may cause lot of grief to small organizations. Conversely, a small organization may not have the resources and bandwidth to handle IT projects for a large conglomerate.
External factors: Projects can also fail due to external factors beyond the control of the company, eg, political disturbances, vendor issues, regulatory issues, etc.
In spite of significant progress on project management methodologies, best practices and the availability of new technologies, the success rates of medium- to large-scale IT projects are still poor. It has been observed that fewer than 50% of all such projects are actually successful in a true sense. The rest are either cancelled completely, delayed beyond acceptable limits, over-budget, or go completely haywire and do not meet even the minimum business or functional requirements.
IT projects, as the name suggests, are always technology-related, and can be simple or extremely complex. The quirk of IT projects is that if the projects are managed by pure technical experts they could turn out to be a great technical success but may not meet business expectations. On the other hand, if a pure business manager runs the project, it can lead to a technical failure caused by lack of expertise. It is often difficult to get a balance between the two. This is where the role of a CTO or a CIO is most important. He or she must interface between the business and technical experts for IT projects.
Some of the ways to avoid IT project disasters are:
Customer requirements: The heart of any IT project lies in clearly understanding and documenting the customer’s requirements. The requirements must be agreed in writing and clearly signed-off. More often than not, customers may not be very clear as to what they want. They may just give vague or superficial requirements, but expect something more dramatic after implementation. The trick is to get the correct requirements from the customer before the project is started. New requirements during the course of a project must also be captured and properly processed.
Commitments: In the face of reckless competition many organizations over-commit on their product or services. Such commitments will normally not be achievable due to real world constraints. Organizations must commit only what is really achievable under any given circumstances. The reputation of an organization increases if they under-promise and over-deliver, rather than over-promise and under-deliver.
Budgets: Though it is impossible to get approvals for a luxurious budget, it is absolutely necessary to have all IT-related costs like hardware, software, telecom, installation, cables, support, upgrades, licences and other essential costs clear, with a reasonable buffer for each. In addition, other costs like taxes, transport, travel, insurance, people, fees, etc, must also be adequately covered to arrive at an overall budget. Every single bit of cost and effort should be accurately documented and a budget presented and approved. Provision must also be made for escalations in budget should the original requirements suddenly change for any reason.
Project deliverables: The project manager of an IT project must have a clear and detailed picture of what is being achieved or delivered to a customer or the project sponsor. Commitments must be very clear and fully understood by both parties. Large projects have a particular tendency to change track, so it is always better to involve the customer at regular intervals to ensure that the project is on the path of achieving its objectives.
SLA: It is always recommended to establish a clear SLA between the customer and the service provider to ensure that every aspect of the project is covered in writing. A typical SLA should cover the following main points:
Name of the project or implementation.
Number: a reference or a contract number.
Description of the project.
Client details.
Parties to the agreement.
Legal jurisdiction.
Scope of work: detailed scope of work to be done by the service provider.
Customer obligations: For example, providing electricity, computers, workspace, access to building, etc.
Out of scope (both parties).
Non-disclosure details.
Obligations of both parties.
Budget: who is going to pay for hardware, software, telephone bills, etc?
Timeframes: start date, end date for the project.
Assumptions.
Constraints.
Risks.
Financials: budgets, taxes, payment terms, approvers, penalties, etc.
Service windows: hours of work, days, holidays, etc.
Communication methods: agreed methods of communication, eg, e-mail, fax, telephone, etc. For example, it may be mandated that all technical changes to the original specs must be communicated via e-mail and also via fax.
After-hours support and costs.
Staff involved and their roles.
Managers and their roles.
Training requirements.
Incident-handling procedure.
Problem-handling procedure.
Change management procedure.
Reports and metrics: what standard reports will be exchanged?
Escalation procedure.
Project termination clauses, notice period.
Signatures.
Appendix.
Service level agreements must be prepared by involving the following departments from both sides to avoid complications and misunderstandings later:
Technical departments, for understanding and defining the IT deliverables.
Finance departments, for defining the financial implications.
Legal departments, for understanding and minimizing legal complications should there be a legal battle later.
Others: if required.
Critical projects are often started without establishing proper documentation, leading to all kinds of misunderstandings and confusions later. SLAs don’t prevent project failures, but they do minimize the impact of a failure due to expectations mismatch, cost factors, post implementation hassles, etc.
Killing projects on time: Many projects run into rough weather for various reasons. Killing a bad project may actually save reputation and further wasted costs. However, it is not an easy job to kill a project, and the people involved in the actual project work can rarely take such decisions. Such decisions can only be taken at senior levels and the biggest problem is to convince them to do so. Secondly, there could be various official and political compulsions that prevent bad projects from being killed. However, it may always be in the best interests of an organization to recognize and kill bad projects on time before they cause further damage.
Learning from past mistakes: Experienced project managers know that there are many things that can go wrong in spite of detailed planning. Some can be predicted, many cannot. However, it is important to learn from known mistakes and problems faced in the past. Project managers should cultivate the habit of learning from others’ mistakes in order to avoid repeating the same mistakes themselves. For example, many organizations routinely over-commit on various aspects and end up with problems later. IT project failures are often devastating to an organization. Abnormal delays, bug-filled software, missing features, expectation mismatches, etc, can mean the end of a project, organizational reputation or even financial ruin for a company.
Resource backups: Projects can fail due to resignations, accidents, health issues, etc, of key people adversely affecting the project. A project manager must ensure that all risks related to key people, including the project manager himself, are adequately covered by a suitable backup plan. Resignation by a key member of staff is hard to prevent, but good knowledge management and role sharing would reduce the impact on the project.
Training: Lack of appropriate training for project team members can also be a big issue. Training and qualifications, for instance in Prince 2,[3] would also help ensure the project runs correctly with staff who know what they are doing.