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.

Enterprise Architecture, Segment Architecture & Solution Architecture

What is an Enterprise Architecture?

There are a variety of definitions for an enterprise architecture. However, a general description might define an enterprise architecture as a framework that results in the production of a set of documents that define the enterprise. The enterprise architecture information collected includes the core mission areas, goals, principles, business capabilities/functions and processes. In addition, business solutions and technology are planned and implemented to support business capabilities and processes--no business decisions are made on a whim.  A properly defined enterprise architecture should, at a minimum, provide information that allows an enterprise to do the following:

1. Purchase the right tools and maximize their use through stated needs, services provided by the business, strategic objectives, etc.

2. Understand shared services/processes to request and purchase tools that are implemented for the greater good.

3. Identify opportunities for process improvement to resolve bottlenecks (through automation or process re-engineering), retire redundant systems, identify and resolve threats and risks, and maximize opportunities. 

EA Resources

Enterprise architecture is a topic that many organizations (federal, commercial and non-profit) have touched on. A few of the resources available online are listed below:

• The Federal Segment Architecture Methodology (FSAM) -  FSAM includes a toolkit developed by the federal government. It provides steps along with the inputs/outputs to be collected and documented for each step. FSAM also provides templates to plan the project and document information collected from requirements gathering sessions. The templates also provide direction to define the target enterprise architecture. FSAM includes insight on recommended analytical activities and useful matrices that should be created. 
• Federal Enterprise Architecture (FEA) Practice Guide - The FEA Practice Guide can be used to learn about segment architecture including what a segment architecture is, how to define a segment architecture and who should be involved in the project. It provides the ability to understand (at a high level) the steps that should be used to understand the agencies business problems, needs, strengths & weaknesses, etc. The guide presents understandable, best practices that provide the direction needed to implement an architecture in a way that supports federal government-wide initiatives including data sharing.
•  Department of Defense Architecture Framework (DoDAF) - The DoDAF website provides a wealth of information for anyone seeking to gain expertise in defining a framework for a Department of Defense agency. It outlines the models that should be created; the roles needed to define and implement the DoDAF; specifications and matrices to be created; along with the level of detail that should be captured.

The above list is far from all inclusive; however, it does present enough information for even a novice IT professional to conclude that EA is a hot topic. Organizations that accurately define their enterprise architecture and use the information to make decisions will save money and operate efficiently.

Segment Architecture

As previously mentioned, the FEA Practice Guide provides an overview of EA concepts. But most importantly it provides best practices for implementing a segment architecture. It references the FEA Consolidated Reference models and how the BRM is used to define the core mission areas (vertical segments) and the supporting business services (horizontal segments) and enterprise services implemented across the agency to improve collaboration, knowledge, etc. The FEA Consolidated Reference Models are discussed in the following section.

FEA Consolidated Reference Models

The FEA framework includes 5 key models. These models include the Business Reference Model (BRM), the Performance Reference Model (PRM), the Service Component Reference Model (SRM), the Data Reference Model (DRM) and the Technical Reference Model (TRM).

Business Reference Model

The BRM provides four levels, enabling enterprise architects to break the agency into segments by navigating from the BRM Business Area (pertaining to Services for Citizens) to the LoB to the lowest-level sub-function (or segment). The Mode of Delivery component enables agencies to map the delivery mechanism. For example, the "General Retirement and Disability" would map its Mode of Delivery to (205) Federal Financial Assistance: 081: Direct Transfers to Individuals.

Not all agencies have segments under Services for Citizens. GSA, for example, will not map LoBs to the Services for Citizens Business Area since their customers are federal government agencies. However, most other agencies will find the sub-functions needed. 


The BRM also includes the Support Delivery of Services Business Area and the Management of Government Resources Business Area. These two business areas are for agency support LoBs. Both are used to identify business services supplied across the enterprise. The business services are listed horizontally while the Services for Citizens segments are listed vertically. This provides a tool architects use to identify LoBs that perform the same business functions. For example, an agency may have LoBs to manage policy for Health Care, a separate LoB manage policy for Business Industry Development and Conservation, and different LoB manage policy for Marine and Land Management. Collecting information about the business functions helps identify policy work the LoBs do that is the same. This enables stakeholders  to agree on one target process to do the same work the same way. And, the stakeholders can agree on a single system to support the work. This one act helps streamline business operations. Hence, all three groups are not separately managing processes with each making changes to the process when change is required. Instead, one LoB manages the process, makes the change and provides the updated process to all LoBs.

Once the BRM sub-functions are identified; they can be used as segments to map the segment architecture data--starting with the business architecture components. The business functions performed by the segment; and, the business processes used all provide a picture of how the work is currently done. However, the business problems stated point out that improvement is needed. If an industry best practices analysis was performed--a look at the principles,  practices and tools adopted by "top performers" is insightful. Hence, the EA team already has ideas on what the "target" business architecture should look like.

Performance Reference Model 

The PRM includes performance measurement areas, measurements categories and measurement groupings that map to the BRM LoB segments.  Agencies must define the indicators that will be used to measure performance for the IT Investment/Program, etc.

Service Component Reference Model

The Service Component Reference Model (or SRM) provides a tool to define reusable software components without referencing a technology. This enables agencies across the entire federal government to define components that would ultimately enable them to share more than just data. When building a model from which to categorize the organization, the SRM presents the categories that can be listed as Enterprise Services. Architects can then easily identify services to be implemented across the entire enterprise.

The SRM is also used to define reusable software components. A list of software is used to break down the business applications into a list of reusable software components. The related capabilities are also added and associated with the supported business functions.  Once the list is completed, a matrix is developed. The matrix shows the software components that provide the same capabilities. Agencies can then eliminate costs by decommissioning redundant systems. In addition, the tool can be used for governance. As change requests are received, the capabilities requested can be queried against the software component capabilities data-source. If a match is found, the Governance Board can then request further justification as to why duplicate capabilities are being requested.

Data Reference Model

The Data Reference Model (or DRM) provides a tool that is used to classify data. The primary objective of the DRM is to provide a framework that allows data to be shared across an agency or with a Community of Interest. The DRM calls for data to be classified by Subject Area and Information Class. Once the data is standardized and organized, it can then be reused and shared.  To share the data, the Data Description (or Entity) is associated with a Data Exchange Package (DEP) that includes not only the data; but also relevant information such as header/trailer information specific to the data (or payload). In addition, provider/consumer information and interface that will access the data is also provided. Documenting the data includes associating it with the relevant information system(s) and segment(s).

Technical Reference Model

Until the Technical Reference Model (or TRM) is used; the SRM is not associated with any technology. However, to reflect the true enterprise; the service components must be related to technology. The TRM provides the ability to describe technology-specific components that may include code-behind classes (i.e., Visual Basic .Net (VB.Net),  Active Server Pages .Net (ASP.Net), etc.) the service; but also the technology used to deliver the service. Business logic services can be described as Enterprise Java Beans (EJB), Web Services for Remote Portals (WSRP), etc. Data access layer data providers, relationship to mechanism presentation delivery--whether it be a web browser or other mechanism. The technology is also associated with the segment to provide a complete picture of the technologies providing the support.

Federal Segment Architecture Methodology (FSAM)

FSAM provides the guidance needed to develop artifacts in support of a segment architecture project. There is a rapid approach that can be used to shorten the length of time it takes to document the Business, Information, Application and Technology architectures. The FSAM artifacts include fields that request elements from the FEA Consolidated Reference Model for example the Segment Code (taken from the BRM) is requested. The FSAM Business Function Model is based on the BRM structure. The FSAM Service Component model requests the service domain and service type; both elements are taken from the SRM. 

Lastly, FSAM includes a logical data model and data dictionary, which can be used to build an EA Repository. UML models can be stored on a shared drive with the Repository providing the path to the model. Alternatively, a tool (see the Federal Enterprise Architecture (FEA) Practice Guide for recommendations) can be used to generate the EA Repository. The FSAM EA Repository, once populated, enables agencies to generate the Exhibit 300 Investments Part 1 Section A, Integrated E-300 Milestones, Integrated Performance Information, AIT Investments (Exhibit 53) as well as Segment, PART and PAR Performance Reports.

Solution Architecture

The Solution Architecture is used to implement individual IT projects. Adopting the Solution Architecture Framework ensures the FSAM artifacts developed remain current and useful. As business applications are updated, the FSAM Service Components model, for example, is used to add the new service components. The Solution Architect works with the EA team to ensure EA-related artifacts (such as updated/new business process swim lanes, use case and activity diagrams, interface diagrams, logical data models, service component diagrams, etc.) are incorporated into the Repository it can serve as a knowledge center and does not become outdated.  The Solution Architect also uses the existing FSAM Repository to extract data for IT project documents. For example, the FSAM Risk Capture template provides a list of risks for the segment. Relevant unresolved risks are complied and added to the IT Project Risk List and Mitigation Plan. 

n