Top 10 Pitfalls of Implementing IT Projects

It’s a dirty secret, many IT projects fail; maybe even as many as 30% of all IT projects.

Amazing, given the time, money and mojo spent on them, and the seriously smart people working in IT.

As a vendor, it is painful to see this. We see it from time to time (often helplessly from the sidelines), we think about it a lot, we’d like to see eliminated along with malaria, cancer and other “nasties.”

They fail for a lot of reasons, many of them unrelated to software.

At EventTracker we’ve helped save a number of nearly-failed implementations, and we have noticed some consistency of why they fail.

From the home office in Columbia MD, here are the top 10 reasons IT projects fail:

10. “It has to be perfect”

This is the “if you don’t do it right, don’t do it at all” belief system. With this viewpoint, the project lead person believes that the solution must perfectly fit existing or new business processes. The result is a massive, overly complicated implementation that is extremely expensive. By the time it’s all done, the business environment has changed and an enormous investment is wasted.

Lesson: Value does not mean perfection. Make sure the solution delivers value early and often, and let perfection happen as it may.

9. Doesn’t integrate with other systems

In almost every IT shop, “seamless integration with everything” is the mantra. Vendors tout it, management believes it, and users demand it. In other words to be all things to all people, IT project cannot exist in isolation. Integration has become a key component of many IT projects and it can’t exist alone anymore.

Lesson: Examine your needs for integration before you start the project. Find out if there are pre-built tools to accomplish this. Plan accordingly if they aren’t.

8. No one is in charge, everyone is in charge

This is the classic “committee” problem. The CIO or IT Manager decides the company needs an IT solution, so they assign the task of getting it done to a group. No one is accountable, no one is in charge. So they deliberate and discuss forever. Nothing gets done, and when it does, no one makes sure it gets driven into the organization. Failure is imminent.

Lesson: Make sure someone is accountable in the organization for success. If you are using a contractor, give that contractor enough power to make it happen.

7. The person who championed the IT solution quits, goes on vacation, or loses interest

This is a tough problem to foresee because employees don’t usually broadcast their departure or disinterest before bailing. The bottom line is that if the project lead leaves, the project will suffer. It might kill the project if no one else is up to speed. It’s a risk that should be taken seriously.

Lesson: Make sure that more than just one person is involved, and keep a new interim project manager shadowing and up-to-date.

6. Drive-by management

IT projects are often as much about people and processes as it is about technology. If the project doesn’t have consistent management support, the project will fail. After all, if no one knows how or why to use the solution, no one will

Lesson: Make sure you and your team have allocated time to define, test, and use your new solution as it is rolled out.

5. No one thought it through

One day someone realized, “hey we need a good solution to address the compliance regulations and these security gaps.” The next day someone started looking at packages, and a month later you buy one. Then you realized that there were a lot of things this solution affects, including core systems, router, applications and operations processes. But you’re way too far down the road on a package and have spent too much money to switch to something else. So you keep investing until you realize you are dumping money down a hole. It’s a bad place to be.

Lesson: Make sure you think it all through before you buy. Get support. Get input. Then take the plunge. You’ll be glad you did.

4. Requirements are not defined

In this all-too-common example, half way through a complex project, someone says “we actually want to rework our processes to fit X.” The project guys look at what they have done, realize it won’t work, and completely redesign the system. It takes 3 months. The project goes over budget. The key stakeholder says “hey this project is expensive, and we’ve seen nothing of value.” The budget vanishes. The project ends.

Lesson: Make sure you know what you want before you start building it. If you don’t know, build the pieces you do, then build the rest later. Don’t build what you don’t understand.

3. Processes are not defined

This relates to #4 above. Sometimes requirements are defined, but they don’t match good processes, because these processes don’t exist. Or no one follows them. Or they are outdated. Or not well understood. The point is that the solution is computer software: it does exactly what you tell it the same way every time, and it’s expensive to change it. Sloppy processes are impossible to create in software making the solution more of a hindrance than a help.

Lesson: Only implement and automate processes that are well understood and followed. If they are not well understood, implement them in a minimal way and do not automate until they are well understood and followed.

2. People don’t buy in

Any solution with no users is a very lonely piece of software. It’s also a very expensive use of 500Mb on your server. Most IT projects fail because they just aren’t used by anyone. They are a giant database of old information and spotty data.  That’s a failure.

Lesson: Focus on end user adoption. Buy training. Talk about the value that it brings your customers, your employees, and your shareholders. Make usage a part of your employee review process. Incentivize usage. Make it make sense to use it.

1. Key value is not defined

This is by far the most prevalent problem in implementing IT solutions: Businesses don’t take time to define what they want out of their implementation, so it doesn’t do what they want. This goes further than just defining requirements. It’s about defining what value the new software will deliver for the business. By focusing on the nuts and bolts, the business doesn’t figure out what they want from the system as a whole.

Lesson: Instead of starting with “hey I need something to accomplish X,” the organization should be asking “how can this software help us bring value to our security posture, to our internal costs, to our compliance requirements.”

This list is not exhaustive – there are many more ways to kill your implementation. However if your organization is aware of the pitfalls listed above, you have a very high chance of success.

A.N. Ananth

Always Enable Auditing – Even for Logs and Systems You Don’t Actively Review

I have two rules of thumb when it comes to audit logging:   first, if it has a log, enable it. Second, if you can collect the log and archive it with your log management/SIEM solution, do it – even if you don’t set up any alert rules or reports.

There is value in these rules; you really never know when audit log data will be valuable in a forensics situation and there is no way to reconstruct log data after the fact. The most obscure or seemingly unimportant systems and applications may end up being crucial to determining the extent or root vector of an intrusion, and can be critical to building a case during insider threat investigations. Security events that aren’t necessarily monitored may also be valuable in providing documentation certain actions were performed as part of a compliance related matter.   Standard audit recommendations for Active Directory should include auditing and archiving events related to the disabling and deletion of accounts and group membership removals.   Generally these events do not need to be reviewed; but when an audit is underway, these can be used to document that access was adjusted in response to changes in employee status and role.

Finally, even if audit logs are not reviewed, they can serve as a powerful deterrent against malicious actions and policy violations by end users and administrators.   If they know that their actions are being recorded, there is less likelihood that they will commit an illegal action.   Audit logs need to be collected and archived to a system separate from the people being monitored to prevent deletion or tampering by administrators with access to the logs.

Common logs should be enabled and added to the log management process for collection and archiving.   Obvious candidates include domain controller security logs, but don’t ignore appropriate auditing on member servers and securely archiving them with DC logs as well.   Many of the most critical security events on the network are only caught by the member servers.   This would include attempts to break into member servers with local accounts, security configuration changes, programs executed and files accessed.   There is a wealth of security information in the workstation security logs; it may be a challenge to collect and archive so many logs and the amount of data, but setting maximum log size to 300MB helps to ensure that the audit data will be there when it is needed even if they aren’t centrally managing them.

Other than the Windows security logs, enable DHCP server logging because many other security logs list the IP address but no other information to identity to identify the client.   If DHCP logs are enabled, they can look up the IP address and date and time against the lease events to figure out the MAC address and the computer name of the system with that particular IP address at the time of the event.   If RRAS (Routing and Remote Access Server) is used, be aware that it has client authentication and connecting logging capabilities which record important events not sent to the Windows security log.   This is also true for IIS[JOHN:   what does IIS stand for?].   IIS can log every incoming request to any web based application hosted including URL, verb, result code, client IP address and more.   This is critical for tracking down attacks against the website and other web based applications.   More and more companies are beginning to store and process security and compliance critical information in SharePoint and it has an audit log capability.   Exchange 2010 has a new non-owner mailbox activity log and a new administrator audit log.   VMWare has an audit capability that is critical to ensuring accountability over the virtualization infrastructure.   SQL Server 2008 has a new audit log too.   Even Microsoft Dynamics CRM 2010 has an audit capability.

It seems like every software vendor is seeing the need to provide audit trail capability which is good news for information security but it also means that these new audit features need to be turned on. There’s also a good reason to enable auditing even if the logs aren’t being regularly reviewed or monitored.   If at all possible get these logs out of the systems and applications where they are generated and into the separate and protected log management/SIEM solution so that the integrity of these audit trails in ensured.