6 Common Blunders That Cause An IT Project To Fail

Working in the Information Technology field for over 17 years has its advantages. Mostly, the knowledge I've gain from being hired to help an IT project recuperate from failure.  As America struggles to get back on its feet, most companies are working hard not to have a failed project. This is because failed IT projects are very costly in that the company spends money; but gets nothing in return. The following paragraphs list the top six reasons I've seen IT projects fail.

#1. Unfounded Requirements Assumptions

Within IT, we all know requirements are defined by the customer (see my blog article titled: Requirements: Understanding the Customer's Vision ). Requirements may come from taking notes during a meeting with the stakeholder and translating the notes into requirements. Alternatively, requirements may also come from making a list of questions that you ask the stakeholder. You then use the stakeholders' response(s) to define one or more requirements. So, what about assumptions? Even if a Business Analyst or Systems Analyst derives assumptions; the assumptions should also be discussed with the stakeholders. What's not a good practice is adding assumptions to a requirements document; and, distributing the document without discussing the assumptions with the stakeholders. Discussing assumptions with the appropriate stakeholder(s) before adding them to the requirements document is essential. This approach develops trust and shows the stakeholders they are in charge.

To avoid confusion or miscommunication, it's best to make sure all requirements are discussed, especially those derived from assumptions, before they are added to the requirements document.

#2. Making Promises Without Understanding What it Would Take to Keep Those Promises

This is one of the most frustrating problems--especially for those who diligently work hard to ensure all projects they support are successful. Those responsible for negotiating timelines with the customer should always talk to the team about proposed timelines before any promises are made. If short timelines are needed, the best approach is to prioritize requirements. This way requirements can be implemented by priority (understanding that all requirements can't be assigned a "High" priority). Negotiating realistic time-frames is key to successfully completing a project. On the other hand, making promises that include short turnaround times for larges amounts of work isn't a good idea. This usually leads to poor quality work that frustrates the customer and makes the entire IT team look and feel bad.

#3. Using a Role Other Than A Business Analyst/Systems Analyst to Gather Requirements
Requirements gathering is about more than just talking and writing. The Business Analyst/Systems Analyst responsible for defining requirements has learned elicitation techniques to define what the customer needs and wants. In addition, the Analyst has learned Gap Analysis techniques, traceability and other requirements-related techniques. Assuming anyone on the team, including Technical Writers or Developers, can define requirements can lead to costly mistakes. The roles in IT are divided such that each team member brings the specialty needed to accurately accomplish specific activities within the Software Development Life Cycle. When a practice other than an industry best practice is used; unwanted, unexpected results will usually surface.

#4. Releasing Software Without Proper Documentation

Before a new system is released, the proper documentation should be created. Most team members hate writing documentation; but that doesn't minimize the fact that system documentation is crucial. Any new business application should be accompanied by the following:

a. End-User materials - User's guides, getting started guides, quick reference guides and other materials needed to tell the user how to install, setup and use the system is important. (See my blog article titled Technical Writing & Technical Training Materials.)

b. Training Materials - Some systems may be complex enough to require user training. For example, Enterprise Resource Planning Systems (ERPs) should never be implemented without a cohesive plan to provide users with training. Training is important because it ensures users understand how to use the system to do their job. (See my blog article titled Technical Writing & Technical Training Materials.)

3. Re-engineered Business Process Document - If a new business application causes an organization's business process to change; it is imperative to educate the users. For example, to order a magazine users may call the support desk. The Customer Service Rep. do the following:

1. Take the order;
2. Type up a label and invoice; and
3. Send the request to the mailroom to fill the order and mail it out.

But, what if the company installs a new system. With the new system, the customer still calls the support desk. However, instead of typing up the invoice and mailing label; the Customer Service Rep. is now expected to enter the information into the system. The system then creates the invoice and sends a notification to the mailroom. Notice how end-user documentation will tell the Customer Service Rep. how to use the system to place the order. But, also notice how the process has drastically changed. Neither end-user nor training materials typically address the business process changes. This is why a plan should be implemented to document the business process change. The documented process change can be made part of the end-user's training. Or, the relevant documents can be given to employees impacted by the change. This ensures the organization continues to run smoothly with little downtime. It also ensures employees understand how to do their jobs with a new system in place. (See my blog article on Business Process Re-Engineering and Enterprise Architecture, Segment Architecture & Solution Architecture ,)

#5. Hiring a Project Manager Who Doesn't Understand the Project Manager's Role

 The Project Manager (PM) is one of the key people on the project. In addition to managing the project budget, timelines and deliverables; the PM is the key interface between the IT team and the customer. It is important that the PM understand the balance between customer responsibilities and the IT team.

I worked on an important project with a PM who negotiated due dates without establishing "how" the work was to get done. The PM wanted the customer to pick the templates and methodology that would be used to complete the work. With due dates already negotiated, I knew the more time it took to get the project started; the less time we had to complete the work. I knew the longer we "sat back and waited on the customer"; the less likely we were to succeed. Instead of sitting around I put together the templates based on the methodology I thought would be best for the customer's environment. Although I was not the PM; I still did not want to be part of a failed project. I pleaded with the PM to take the templates to the customer and ask the customer to simply review and provide input on what we provided. One meeting between the PM and customer gave us the go-ahead we needed to get started. The customer became enthusiastic because the project began to move forward. Things were getting done and the customer knew exactly what we would deliver and the approach we would use to do the work. As problems arose the PM was stumped. But, each time I used my experience to advise the PM on the best way to tackle the problem to achieve maximum project success.

Not everyone on a project team will have the experience I have. But if the team has a Project Manager who understands the various IT roles, SDLC methodologies, the customer's role and most importantly the Project Manager's role and responsibilities--things should go just fine.

#6. Not Using a Cohesive Methodology to Implement Software

It is not uncommon for a non-IT company to believe IT work can be accomplished without a methodology. The one company I stepped into that did not use an IT methodology to complete IT work experienced failure over and over again prior. The non-IT company hired IT people. But, since the non-IT people didn't know what they were doing; they inadvertedly hired IT people who didn't know what they were doing. So, the non-IT company ended up with an IT Department that had extremely weak IT skills.

Consequently, no one in the company trusted the IT Department. When I interviewed to join the IT team; the IT team assured me everyone (besides the IT Department) was responsible for the project failures. I wanted to discuss the methodology being used to do the work. I was told a methodology had not been adopted. So, the first thing I did was point out that it is impossible to successfully complete a project without using an "established" methodology.

I recommended an approach and created and circulated the templates. I documented the approach using a Visio diagram that everyone could follow and understand. Then I suggested that we try the approach out on a small scope of work, which we did. Everything went smoothly and the project was a success. The company adopted the methodology and greed no IT work would be done without using the agreed upon approach.

In short, never try to complete IT work without using an established methodology. These methodology were established after teams attempted to do work without them.

In Summary

Following is a list of things you can do to keep your IT project on the right track and avoid the blunders that cause projects to fail:

#1. Always have unfounded requirements assumptions approved by the stakeholder before they are stated as requirements.

#2. In IT, always understand what it will take to keep a promise before you make the promise.

#3. Always use a Business Analyst/Systems Analyst to gather and manage requirements.

#4. Always make sure proper documentation has been developed before releasing a new software application.

#5. Always hire a Project Manager who understands the Project Management role in its entirety and has experience successfully filling the role.

#6. Always use a cohesive methodology to implement a software application.

Technical Writing & Technical Training Materials

Getting Started in IT

Technical Writing and Technical Training are two great jobs. If you are a teacher seeking to move into the Information Technology industry, you may want to check out technical training jobs. These jobs relate to teaching, as discussed later in this article. 

My first IT job was working as a technical writer, a career I held for about five or six years.  While working as a technical writer I wrote technical documents for the following types of companies: telecommunications (such as Nextel), systems integration (which design and build complex applications), network security, software development, etc. Although the types of documents written are the same, the most challenging part was learning the terms associated with each company type. Telecommunications terminology is very different from systems integration terminology. This is because different company types use different types of technology. For example, telecommunications companies support wireless phones and other similar products. On the other hand, systems integration companies implement systems such as enterprise resource planning (ERP) systems used to run an entire company. 

Technical trainer and technical writer jobs are closely related. A technical writer writes the user's guides, quick reference materials, getting started guides, installation guides and other technical materials. Technical trainers, on the other hand, plan and design training programs. They also write the training materials and they often stand up front and teach students. However, online training is becoming more common so not all technical trainers stand in front of a classroom and teach students. 

Technical Training Materials

While working for a systems integration company (BDM International), I had to assist with developing technical training materials as well as end-user documents. The technical training materials I created were as follows:

1)    Slide Presentation. The Slide Presentation teaches end users how to perform a task.

2)    Lab Book. The lab book includes learning objectives for each chapter. It also provides instructions on how to perform tasks associated with data already in the system. Or, it provides instructions on specific data the user is to add and manipulate. Each chapter concludes with a list of Review questions to reinforce the learning objectives.

3)    Facilitator's Guide. The Facilitator's Guide is written for the instructor. It includes the information (that should be conveyed to students) for each slide in the presentation. It also includes the answers to the Review questions. Typically, technical trainings will include time for the instructor to discuss the Review questions and provide the correct answer.

4)    Survey. Surveys are typically created to gather information the company needs to make training decisions. These surveys are usually handed out about 10 minutes before class ends so students have a chance to complete them and leave class on time.

Technical Documents versus Technical Training Materials

The key difference between the user's guide and the training materials is the user's guide provides general instructions while the technical training materials include instructions about one or more specific records. For example, a user's guide might include a topic called "Adding a Customer Record". This topic would include general instructions as follows:

-------------------------------------------------------------------------------------------------------

1. Log in.

2. Select Add from the Main menu. The Add page displays. 

3. Select Customer from the Add page. The Add Customer page displays.

4. Enter the customer's information (including first name, last name, etc.)
Note: Fields preceded by an asterisk are required and must be completed prior to saving the record.

5. Once you have completed all information click the Save button. The record is saved and the Add Customer page closes.

Note: If you click the Save ​button before you have completed all of the required fields, an error message will display. If this happens click the OK button on the error message. The error message will close so you can access the Add Customer page. Red text (required field) displays beside any required fields left blank.

-------------------------------------------------------------------------------------------------------

The lab book (which is comparable to the user’s guide) will have the Adding a Customer Record lesson. However, the lab book will also include the learning objectives. Below is an example.

-------------------------------------------------------------------------------------------------------

In this lesson you will learn the following:

• How to add a customer records
• How to recognize fields that require information
• How to save a record
• How to respond to an error message.

-------------------------------------------------------------------------------------------------------

The instructions in a lab book are written differently from the instructions in a user’s guide. Below is an example of the instructions in a lab book.

-------------------------------------------------------------------------------------------------------

Instructions:  In this lesson you are going to add Mr. Wyatt Johnson as a new customer. Please follow the instructions below to complete this lesson.

1. Log into the demo account using the following credentials:

User Name: Jane Doe   
Password:  P@ssword22

2. Select Add from the Main menu. The Add window displays.

3. Select Customer from the Add window. The Add Customer window displays.

4. Click in the First Name field. Add the following: Wyatt.

5. Leave the Last Name field blank. Notice that this field is preceded by an asterisk. This means this field is required. However, leave this field blank for now. This will give you an opportunity to see the error message and learn how to respond to it.

6. Click in the Address 1 field. Type the following:  2244 Yellow Stone Park Rd.

7. Click in the Address 2 field. Type the following:  Suite 260

8. Click in the City field. Type the following:  Pasadena

9. Click in the State field. Type the following:  California

10. Click in the Zip Code field. Type the following:  91101

11. Click the Save button. An error message displays, "You must complete all required fields".

12. Click the OK button to close the error message. Notice red text (required field) displays beside the Last Name field because it is required.
13. Click in the Last Name field. Add the following:  Johnson

14. Click the Save button. The record is saved and the Add Customer page closes.

CONGRATULATIONS: You have completed the Adding a Customer Record lesson.

-------------------------------------------------------------------------------------------------------

Notice the lab book provide specific log in information and tells users what data to add. When a system is built and it is determined that training will be provided on that system; the technical trainer usually provides the content that must be added (if applicable) so users can use the system for training. Based on the technical trainer’s request, the developer will create a demo account that can be used for training and/or customer demonstrations. Therefore, more planning is required for training materials then for technical documents such as user’s guides.

In short, user's guides provide instructions so users can perform a task using any data the user wants to add or update, search or delete.  Technical training provides more specific direction by telling users what records to add, edit, delete or search.

User's Guides - Technical Writing

I learned how to write a user's guide by looking at various users’ guides for products on the market. To practice developing user’s guides I would go to www.downloads.com to select and download various types of software  (i.e., change request, enterprise resource planning, customer relationship management, help desk, etc.). The more I practiced; the better I got at organizing the topics. Eventually I came up with a standardized outline that I could use for the user's guide. I only deviated from the standard outline when I had to. Using this rhythm made it easier for users to understand how the topics were organized. This made it easier for users to find information. For example, my table of contents would look as follows:

-------------------------------------------------------------------------------------------------------

Table of Contents

Managing Customer Records

• Adding a Customer Record
• Searching for a Customer Record
• Editing a Customer Record
• Deleting a Customer Record

Managing Orders

• Adding an Order
• Associating a Customer Record with an Order
• Associating an Employee Record with an Order
• Searching for an Order
• Searching by Order ID
• Searching by Customer Name
• Searching by Employee Name
• Editing an Order
• Canceling an Order

Managing Employee Records

• Adding an Employee Record
• Searching for an Employee
• Editing an Employee Record
• Deleting an Employee Record

-------------------------------------------------------------------------------

How it All Adds Up

Although technical writer salaries started out paying $75,000 or more (depending on experience), annually salaries have dropped. Now, on the average, technical writers earn around $75,000 - $85,000 (and that amount may further drop in the coming years). Those who earn salaries in the $90,000s have very strong technical skills and a lot of IT experience. Technical training salaries are still pretty competitive paying around $85,000 to $90,000 annually. A technical trainer with years of industry experience could probably earn more. However, people with that level of experience usually start their own technical training company to target government contracts and earn millions for their knowledge and experience.