Ten sure-fire ways to crash your IT project

Although I am sure that you don’t need to learn how to crash IT projects, especially not your own, I would like to suggest this topic for three reasons. First, it’s fun. Gloating over the misfortunes of others may not be noble, but it is certainly edifying. Second, ever since Charles Babbage invented the computer it has been crashing. From blue screens of death to lost space probes, crashes seem to be an intrinsic part of the IT field. Third, we can actually learn from mistakes, even if they are not our own.

(1) Ambiguous specifications
(2) Lack of vision and communication
(3) Planning for disaster
(4) Lack of management commitment
(5) Lack of staff involvement
(6) Arrogance and ignorance
(7) Overambition
(8) Do-it-yourself solutions
(9) Silver bullets
(10) Scope creep

The nature of IT projects is intricate, complex, and sometimes unpredictable. The immense number of failures in the IT industry includes projects that get stuck, projects that never end, projects that overshoot budget, projects that do not deliver, and projects that do all of the aforementioned. The latter is by far most common type of failure. Often such occurrences are discreetly swept under the carpet, by both the customer and the contractor. Neither the customer’s nor the contractor’s reputation is likely to gain from it. This condition of secrecy is somewhat unfortunate since the post mortem analysis of a crashed IT project offers some learning potential.

The author of this article worked in the IT field for almost two decades and has seen a fair number of IT projects come down in a less than graceful manner. It would be presumptuous to claim otherwise. Having had the opportunity to observe and analyse the circumstances of ill-fated projects, it was possible to identify the conditions and patterns that spell failure. Unsurprisingly, all of these are management issues rather than technology or financial issues. This insight often stands in contradiction to what the responsible managers and contractors claim. Of course, it is more convenient to blame things on the “wrong” technology, the “wrong” product, “insufficient” budget, and so on.

(1) Ambiguous specifications

The number one killer of IT projects ought to be poor or ambiguous functional specifications. This is so, because specifications stand at the beginning of a project at a time when important course setting decisions are made. IT projects, like living beings, are most vulnerable in their infancy stage, where wrong decisions have their greatest impact. Sloppy specifications inevitably lead to misunderstandings, oversights, false assessments, and eventually fully grown disputes.

There is no better way to screw up a project than having no clear idea of it and put it out to tender. In order to accomplish this, it is best to assign an incompetent employee to write up the functional specifications. Ideally this would be someone with limited IT knowledge and an incomplete understanding of business requirements and work flow. This person should be asked to scribble up a few pages containing computer buzzwords, obscure management talk, and puzzling diagrams.

An invitation of such make-up will doubtlessly attract numerous bids anyway. After all, contractors cannot be too picky about clients. Some of the tenders may give the impression that they are not completely based on guesswork. These are the ones to present to upper management. Upper management will then select the supplier whose logo resembles that of IBM most closely. Should the supplier have the audacity to suggest a requirements analysis at the client’s expense, this should be rejected with utmost steadfastness and with the hint that further specifications will be worked out along the way.

(2) Lack of vision and communication

The deadly effect of poor specifications is closely rivalled by a lack of vision and communication. The dominant theme is: a problem that is not seen, not heard, and not talked about is not a problem. Naturally, this applies to both the client and the contractor. The client who doesn’t communicate his vision is just as harmful to project success as the contractor who conceals problems. It’s one thing not to have a clear vision, and it’s another not to be able to communicate it clearly.

To achieve the most disastrous results, it is recommended to replace clear vision by vague and unspecific goals. These are best communicated in an opaque language that makes references to features and milestones without actually defining what they consist of. Client participation in the various phases of project implementation should be avoided at all costs. After all, the contractor was hired to solve the problem, so he cannot expect the client to be bothered with answering questions. If client involvement is indispensable, then all work should be delegated to a lower rank executive who may be sacked if things go wrong.

(3) Planning for disaster

Planning for disaster results from the opposite attitude. Instead of putting too little attention to project management, it puts too much attention to project management, or rather the administrative details of it. Hence, the disaster planning attitude has a tendency to generate a lot of paperwork. The principal assumption is that things will probably go wrong. The strategy is then to define a plethora of procedures to prevent things from going wrong, or at least to document how things went wrong in view of ensuing legal procedures. Since this strategy is extravagant and costly, it is preferred by large corporations and government organisations.

The trick is to raise the administrative overhead to an insane level. Project members should at least spend two thirds of their time with meetings, filling forms, and generating documentation. Contracts should be no less than 100 pages. They should stipulate all kinds of provisions for the event of premature termination, breach, default, bankruptcy, death, and natural disaster. For this purpose, a lawyer should be hired from day one. Programmers, system analysts, and technicians must seek approval from their superiors, who must seek approval from top management, who must seek approval from their lawyers.

(4) Lack of management commitment

Every manager knows that “commitment is everything”. Because everybody knows it, managers must make it a point never to admit a lack of commitment. A manager typically says, “I am fully committed to the task, but unfortunately I don’t have time to answer your question right now.” That is an excellent excuse, because everybody understands that managers are very busy people. In addition, it is a diplomatic way of saying, “I rather have dinner with my golf mate than pondering mind-numbing techie questions with the geeks from the IT department.” After all, managers have better things to do than racking their brains over bits and bytes.

To develop this technique to its fullest, one must adopt a feudal view of the workplace, where the manager is the sovereign and the IT department is one of the subordinate departments whose primary function is to serve and follow orders. Since every department needs to understand its proper place in the organisation, it is best to let the nerds know that management cannot be bothered with the trivialities of information technology.

Managers may simply claim to be “non-technical” and confer responsibility to one of the lackeys from IT, preferably a yes-man, who is elevated to midlevel management for this purpose. The new midlevel manager, who is now above the common crowd, does well to cover his back and hire an external consultant. The primary function of this consultant is to serve as a scapegoat in case things turn sour. This configuration allows for maximum passing of the buck and leaves the contractor clueless as to who is in charge of the project.

(5) Lack of staff involvement

Lack of staff involvement is a more academic term for ivory tower syndrome. It is common that IT systems are implemented by people who have never worked in the position of those for whom the system is designed. Although this does not in itself constitute a problem, the situation may be creatively exploited in order to steer a project downhill. It’s best to consider the user an abstract entity, an unimportant appendage to the system, and desist completely from involving him in the design of the system. After all, users are replaceable entities. They have low intellects and they should not be allowed to interfere with the magnificent conception of management and engineering.

Interviews, field tests, usability tests, acceptance tests, and pilot schemes are a complete waste of time. A mere user cannot fathom the big picture. He cannot possibly appreciate the complexities of a multi-tiered architecture or a distributed database system. Such work is better left to the technologists, who know perfectly well what the system should look like. Technologists don’t need to know about lowly business issues. The system can be perfected on the drawing board. If the system looks good on the drawing board, it follows that it will work in practice. Once the system is out of the lab and in the real world, trainers may be dispatched to educate the users about the benefits of the system.

(6) Arrogance and ignorance

We have already moved into the wondrous realm of arrogance. No doubt we can further capitalise on this trait to bring virtually any IT project to a screeching halt. The know-it-all IT manager is just one variation of the theme. A know-nothing CEO may have an even more destructive effect, because there’s nothing quite like arrogance combined with ignorance. This person admits to be ignorant of IT, but he considers himself a top-notch business leader. He has seen company X implementing system Y and doubling their profits since. Moreover, system Y is a market leader and it costs a sum with many zeros. The vendors of system Y wear suits and they talk business, unlike the geeks from the IT department. System Y must surely be good.

This leads us to the topic of gullibility. A fair number of company directors become flabbergasted by IT talk. When listening to expressions like “adaptive supply chain network”, “business intelligence platform”, or “data warehouse”, these great leaders just nod in quiet admiration. Yes, these are wonderful things to have. In the course of time, an organisation with gullible leadership might contract consultitis, an affliction that results either from hiring too many consultants, or from hiring a consultant that continuously dazzles the audience with buzzwords and charts, instead of solving actual problems.

One of the best ways to bring down an IT project early, is to hire multiple consultants to solve the same problem. You can bet your bottom dollar on the consultants fighting a turf war over the client’s patronage. Instead of working on the best solution for a given problem, they will work out solutions to demonstrate how inadequate the other consultant’s approach is, for which they will charge $$$ per hour plus expenses.

(7) Overambition

Overambition is one of the most potent poisons for IT projects. It is usually concocted by planning committees who don’t have a realistic idea of complexity and time frames. The leitmotiv is: “Let’s solve all of our problems at once.” The recipe is fairly simple: Draw up a list of all the issues that the organisation wants to automate, from stock optimisation to HR management. Demand that the system should spit out a complete tax return at the push of a button. Throw in the latest hardware and try to use new and unproven application software. Shake. Do not stir.

Alternatively, you may try the following approach: Set artificially tight deadlines for each milestone and include a contractual clause stipulating that the contractor may be burnt at the stake for missing any of them. During project implementation, insist on incorporating many extras into the system. Urge the IT team to respond to each of the manifold itches of the user community. When a day turns into a week, and a week turns into a month, call for an emergency meeting and define new artificially tight deadlines.

(8) Do-it-yourself solutions

Overambition occasionally takes the form of “I did it my way”. The principal motive for the do-it-yourself approach is a distinctive self-image. First you have to assert that your organisation is unique and special. This results in the deeper heroic insight that none of the standard packages fits the needs of your organisation. At this time it is important to maintain self-confidence. Tell yourself how special you are. Don’t listen to advisers recommending to adopt standard software and change your work flow. The rules and procedures of your organisation are sacred. They have existed for decades; they are proven and true. The IT system should adapt itself to your work flow, not vice versa.

The only solution is then to courageously pioneer the field and tailor your own IT system. At this point you are looking forward to an exciting time of requirement analyses, feasibility studies, implementation and test cycles. The IT adventure has begun. On your way to success it is likely that you will wear out a number of IT managers and consultants. Don’t let this distract you. The rewards are great. You will obtain an absolutely unique system that costs a hundredfold of a standard package and takes ages to complete. If this sounds too daring, you should acquire a standard package and customise it beyond recognition. That way you make sure you will have to go through the entire customisation process again at every update cycle.

(9) Silver bullets

Silver bullets are simultaneously popular and infamous. They are infamous, because everybody knows they don’t work. They are popular, because they hold a huge promise and because there is a fine line between methodology and crankiness. “Methodology” simply means the application of a set of defined procedures and work practices. Methodology turns into crankiness at the point where it becomes a mantra. Contrary to a methodology, a mantra is a mere verbal formula. It is often devoid of meaning. But we are proleptic. How exactly does a methodology become a mantra?

Quite simply by chanting it, instead of practicing it. Example: Company X has identified a problem with quality control. Top management has thought long and hard about it and decided that the Six Sigma program is the way to solve it. The promise that Six Sigma holds -less than four defects in one million parts- has enticed the company to splash out on a new enterprise spanning Define-Measure-Analyse-Improve-Control software system. Few people actually understand what it does and what it means, but everybody understands that it’s called Six Sigma. So, everyone joins the chorus and sings: “Define-Measure-Analyse-Improve-Control”. Problems will surely disappear if the phrase is repeated often enough.

The psychology of the silver bullet is based on faith. A problem analysis is usually suggestive of certain approaches and solutions. Some of these solutions may be championed by leaders or highly respected individuals in the organisation. This gives it more credibility. When the solution is finally approved by the CEO, it gains even more credibility. People start to believe in the method. If the experts say it’s right, and the bosses say it’s right, then it must be right. People within the organisation stop questioning the solution. At this point, the solution becomes a silver bullet.

(10) Scope creep

The phenomenon of “scope creep” actually deserves to stand higher in this list, because it is quite an effective IT project crasher. It’s also deceptively simple. Scope creep means uncontrolled change in the definition and scope of a project. The best way to achieve this is to have no clear idea of the project from the outset. Just let your nebulous thoughts guide you and resist any attempt to concretise scope and define clear boundaries. Practice the philosophy that the world is in a steady flux. You need to be flexible. Then, during project implementation, demand the same from the people who implement it, and throw in manifold additions and alterations. Your motto is: I need more features.

Then sit back and watch the spectacle unfold. The project plan gets redrawn after every meeting. Deadlines are constantly missed, and teams get reshuffled. A few months into the project, the initial requirement analysis will look like a cryptic document from ancient times, which has little resemblance to the current state of affairs. Contractors will jump off, consultants will come and go, and the project starts to develop a life of its own.

Offshore development

Thinking about moving software development abroad?

You have heard of other companies employing offshore software development firms to achieve significant cost savings with their IT projects. You may have heard of some of the issues they confront in realising offshore projects. You want the cost advantage but aren’t ready for the risks involved and you don’t want to trade off quality for price. Here are some questions you should ask yourself (and your offshore partner) before you begin:

  1. What are the risks involved in offshore development?
  2. How can offshore projects be managed efficiently?
  3. Isn’t there a big overhead involved?
  4. How big are the cost savings?
  5. Is offshore always better than onsite?
  6. When is it worthwhile to outsource IT services?
  7. What about the language barrier?
  8. What about cultural differences?
  9. What about the time difference?
  10. What is the legal framework for offshore projects?

What are the risks involved in offshore development?

The risks are basically the same for offshore and onsite development. The major issues are always (a) time-to-market, (b) cost, and (c) quality. The questions are: When is my project completed, how much will it cost, and will it comply with my quality standards?

However, there is one big difference in offshore outsourcing: the way you control these issues. The challenge added by taking a project offshore is therefore a management challenge. Due to the geographical distance, you cannot simply look a programmer over the shoulder or call spontaneous meetings.

If this challenge is ignored, the business risk of software development becomes unmanageable. Hence, suitable methods of communication and control must be in place to manage offshore projects.

How can offshore projects be managed efficiently?

The key to successful project management across continents lies in effective communication and effective control. Your offshore team must be able to connect to you and vice versa. You probably need to deploy special technologies that allow you to monitor ongoing projects at all times. Besides phone and email, these technologies might include VoIP/online conferencing, instant messaging, online collaboration software, and probably a project management system. A professional offshore contractor has respective procedures and technologies in place.

The three aspects of communication that need to be observed are (a) transparency, (b) availability, and (c) response time. Communication partners should be appointed, communication channels must be chosen, and the forms of communication must be defined at an early stage. Clearly structured specifications and instructions are just as essential as regular front line feedback and quality control.

Isn’t there a big overhead involved?

The criterion that defines overhead is the quotient of time used for project management and the time used for implementation. The overall goal is to keep this quotient as low as possible. This ratio increases when either the implementation task is small in terms of man-hours, or the management portion of a particular project is large.

Experience shows that certain projects are suitable for offshore execution, while others are not. Very small projects and projects where the desired outcome is not well defined, such as research projects, are less suitable while projects with a well defined output are suited best. Of course, overhead can also be cut by outsourcing project management along with the implementation.

How big are the cost savings?

The cost savings can be substantial. How big are the they? – Of course, it depends on the project. Example: Let’s assume that your offshore contractor’s rates are 40% lower than those of your local onshore vendor (which is conservative!) and that management overhead increases from 10% onshore to 20% offshore, meaning that productivity decreases from 90% to 80% by taking the project offshore. The latter results in a cost increase of factor 1.125 to achieve the same output. Let’s further assume that the project’s volume is 40,000 USD and that you finance a 3,000 USD business trip for a meeting out of this budget. The cost for achieving the same results offshore are thus (40,000 USD * 0.6) * 1.125 + 3,000 USD = 30,000 USD. Your cost savings are 10,000 USD, or 25% of the original volume.

Is offshore always better than onsite?

Certainly not. Not every work can be outsourced profitably. Some types of work involve a large portion of communication and management. These can only be outsourced if management is outsourced as well. Furthermore, economy of scales defines a minimum project size. Since management overhead tends to increase logarithmically rather than linear, the management / production cost ratio is high for small projects and it may thus eat up cost savings. On the other hand, this means that your savings are even bigger if the outsourced volume is large. It is difficult to pinpoint an exact threshold value for project size. As a ballpark figure, you should look at outsourcing when the project size exceeds 1,000 man hours. But even smaller projects can be outsourced successfully if the team members play well together.

When is it worthwhile to outsource IT services?

The key criteria:

  • Is the project rather large in terms of man-hours?
  • Is the output well defined?
  • Are there written specifications, instructions, rules and other guidelines?
  • Are these in English or in a language that the contractor understands?
  • Does production involve a large portion of labor-intensive work, such as coding, debugging, data entry, etc.?
  • Is overall complexity manageable?
  • Is the involved technology fairly close to industry standard?
  • Can output and productivity be measured?
  • Do all involved parties communicate comfortably in English?

If you can answer most of these questions with ‘Yes’, you should think about outsourcing. If you answer some of the questions with ‘No’, outsourcing may still be an option, but you should look carefully at the project parameters. Types of work that are well suited for outsourcing are:

  • Software adaptations and maintenance
  • Porting existing applications to new platforms
  • Development of software components and plug-ins
  • Traditional application development
  • Web development, web design, and Flash development
  • Multimedia development and CD-ROM productions
  • Data entry, archiving, and image processing

What about the language barrier?

Language is an important issue. You should make sure that you can communicate comfortably with all team members, especially with the responsible project manager. Programmers mostly speak some English, because computer books and technical documentation are often in English. Make sure the level of fluency of your partner is adequate, especially if you outsource to a location where English isn’t widely spoken. It is important that your team understands the requirements and functional specifications exactly. You don’t want to spend time and money on correcting human communication errors. If the developers are fluent in English or in your native language, then the language barrier really does evaporate.

What about cultural differences?

From the management perspective, some cultural issues are important. Cultural differences can mean increased difficulty in communication and work process organisation. Keep in mind that different cultures have different ways to get things done. You should be at least somewhat familiar with the culture of the country you are outsourcing to.

Let’s assume you are outsourcing to Asia. Asia is both geographically and culturally farther from Western cultures than, for example, Eastern Europe. The Asian business culture is very service-oriented and pragmatic. However, you might find that your Asian partner appears to be less frank about problems and difficulties. Although Europeans and Americans often perceive this as a lack of transparency, from the Asian perspective this is actually a matter of courtesy. It would be impolite to confront the customer with too many problems and questions, since it is the contractor’s job to resolve these in the first place.

Probably the most important thing is to keep the team focus positive and to make sure that your team understands your requirements. In doing this, you need to take the cultural peculiarities into account. This may sound more difficult than it actually is. People usually enjoy working in an international team. Once the initial barriers are overcome, it may be just as easy and pleasant as working with your home team.

What about the time difference?

You need to look at the office hours overlap of your and your partner’s location. If you are in Boston and your partner is in Beijing, there may be zero overlap. This means you won’t be able to do online meetings, phone conferences, or instant messaging during your usual office hours. If you are in Germany and your partner is in India, you will have 3 to 4 hours overlap. On the other hand, the time difference might work to your advantage. When you begin your work day in the morning, it’s already afternoon in Asia if you are in Europe, or evening if you are in the US. Most of the day’s work is done at this point, perhaps already waiting in your mailbox for you to review.

What is the legal framework for offshore projects?

The legal framework is normally provided by a consulting agreement (or a development contract) that governs the cooperation and defines all its details. Such an agreement is often accompanied by functional specifications which describe the technical aspects of a project. It may be supplemented by additional agreements, such as non-disclosure agreements.

One important question in international contracts is jurisdiction. If the place of jurisdiction is not agreed upon in the contract, it will either be the country where the agreement is executed, or where it was signed. If you want the contract to be governed by the jurisdiction of your country, you must state this in the contract. Whether this makes sense is another question. If a dispute should ever goe to court, it is unlikely that your contract partner will show up, unless he has a representation in your country.

The terms that govern compensation are probably the most sensitive part of the agreement. You should strive to build some risk protection into the payment terms. At the same time, you need to find terms that are acceptable to the offshore developer. This is not always easy. There are a number of models to choose from, including lump sum agreements, fixed cost and date, time and material, limited time and material, and other options. Which one you finally choose depends on the nature of your cooperation.

Risk reduction is in the interest of both parties. You should avoid large upfront, interim or final payments, and choose smaller more frequent payments instead. It is also wise to define milestones and agree to make payments dependent upon the fulfilment of these milestones. Some customers may feel the need to build penalty clauses into the contract for additional protection. This is not always a good idea. Penalty clauses offer little protection if you are not sure whether they can be enforced.

It is probably better to prepare for success than for disaster. This means you should invest more time into defining the technical aspects, responsibilities, deliverables than into defining the subtleties of legal protection. A qualified lawyer may be able to help you with this.