A Guide to more successful IT Projects

Some IT projects never make it to the finish line. While many other IT projects may be viewed as failures even though they were launched and are in production every day. Although much of the risk has been taken out of software deployments using repeatable processes, cloud-based data centers and software as a service, this does not necessarily mean the software is making the positive impact you expected for your business.

So, what types of things can you do to make your projects more successful?

Knowing your target

Perhaps the number one reason projects can drag on and on is because of unknowns. If a legacy system is being replaced, amazingly no one likely understands everything the old system does. The ‘subject matter experts’ around the company who have worked with the current system for the past 20+ years have never needed to have a complete understanding of what the software does internally. The IT staff may have a good understanding of what the system does, but not a great knowledge of how the business uses the software. So the requirements of the new system are built around these two groups, both with an incomplete picture.

Impact: After the project is far down the road, departmental staff members start looking for features and capabilities they simply ‘expected would be there’. Or worse, they suddenly remember ‘must haves’ that were never mentioned during requirements gathering. Your project grinds to a halt while the staff determines 1. If these features are a must have for go-live or 2. They can wait until post launch. Either way, the costs go up, the expectations go down and compromises occur.

Your ability to accommodate change

Your old system controlled how your company ran in many ways.?Company operations are frequently built around accommodating limitations. Many of these are system limitations. Old systems would do things in batches overnight, would require manual input from staff members, provide limited user feedback or have limited access only ‘when I get back to the office’. Of course, this seems old fashioned today, but your 30 year old system may still work this way.

So, as you launched into swapping out your dinosaur for a shiny new system, your departments had an expectation that the new system would simply be a better version of the old system. It was not anticipated that change would need to happen across the organization in order to reap major benefits of the new technology. Worse yet, power struggles can happen as some departments gain new functions and others lose their position. ??

Impact: In hindsight you needed a Change Manager. The new system doesn’t seem to provide the benefits expected because the staff hammered the new system into the shape of the old system. Procedures didn’t change, departmental functions didn’t shift and the overall processes look a lot like they did before.

The new system has even more limitations than the old one

You built special features and functions unique to your business into your old system over the past 30 years. The sales pitch to the board was that the new system would be more ‘off the shelf’, vendor maintained and cheaper to operate. Yet your staff is disappointed that the new more generic Software As A Service system requires much more accommodation to the way the software works. It would be impossible to build into the new software 30 years of customizations.

Impact: It has been my experience that middle managers will justify why they are unique over all the other businesses out there and need specialized capabilities. In some cases they are right. In many cases, this only serves to drive up costs and extend the project time without providing any real benefit to the organization. Companies need to understand what is their real market value proposition vs. a department function that would be better served by accommodating the system’s generic capabilities.

Staffing for success

Companies launch into a systems implementation project because they have a big move forward plan. The company has a new President, was acquired by a new owner, or was given a new infusion of cash. Whatever the reason, the company is looking to move from a cost controlled operational entity into one of new markets and expansion of services. But most of the staff are the same operational people. These can be highly reliable, long term team members. But they don’t necessarily think like change agents and may consider the old system ‘just fine’. New ‘change agent’ type personnel can’t wait to implement something new, but may not have the depth of understanding of the business processes and all the hard won lessons of the past.

Impact: Projects will suffer without a proper blend of staff. Operational people may battle against any change, for whatever reason. They will do their best to make the new system look like the old system and enforce stability over change. Change agents may want to discard the past completely and disrupt operations in favor of the new. If you are a start up, fine. Build your team with all change agents and move fast. But most companies cannot afford to upset their revenue streams and need a balance between types of staff members. Successful projects learn how to respect both types of personalities. ??

Vendors, vendors, vendors

Companies will frequently look for two types of vendors to help implement a new system. First is the right software vendor. Second, is typically a “Systems Integrator”, which will implement the software for their company. Sometimes they are one in the same.

Impact: If you choose products and vendors that are not a good match for your needs, your project can suffer greatly. Finding and selecting appropriate software is a skill set in its own, as is sourcing the right integrator. There are plenty of examples of projects that need to be rescued not from internal staff problems, but from the hands of an inappropriate combination of product and services vendors. Make sure you have the right IT leadership in place to lead this effort from the beginning.

Turns out I should have not done this project in the first place

Be careful with this one. Business change eliminated the need. Your project implementation occurred too near to other business activities such as a company sale or merger. You would have been able to negotiate a better deal except for the long tail of amortization for implementation of the new system.

Impact: ?The new owner is going to move your book of business onto their system and throw away the system you just implemented. You had to price the write-off of your new system into the sale price.