The Five "Don'ts" of Systems Implementations
BY Bill Huber
Look at implementations as IT projects, adopt inflexible time frames, and operate with inadequate IT leadership -- NOT!
Does the idea of implementing or upgrading your system make you cringe? If it does, you certainly aren’t alone. We’ve all seen and heard horror stories of cost overruns, missed deadlines, and failure to realize the promised benefits of the new system. The majority of IT projects (66 percent, according to the Chaos Report) still receive failing grades.
But the reality is that IT systems play an irreplaceable role in the efficiency of operations throughout your business. A business owner who delays a technology upgrade may be depriving the business of efficiencies that would increase profits. Worse yet, a competitor who is an early adopter of powerful technology may leapfrog over you and gain a significant advantage in the marketplace.
So what do you do? First, be aware of the classic mistakes that doom many technology undertakings. Keep them in mind and avoid these traps.
Don’t #1: Think of this as an IT project, rather than a business project. Once you’ve made the decision that a systems upgrade is necessary, you can’t just assign the project and walk away. The new system has to support the business operations and help advance the strategy, which means IT cannot be working in a vacuum. An executive sponsor, such as the owner, president, CEO or COO, should actively provide high-level oversight and support to the project team from start to finish.
The executive sponsor must make sure the specifications that are agreed upon are the true business imperatives. The sponsor also has the perspective required to spot faulty business processes uncovered by the detailed work of developing new system requirements. If this exercise reveals process issues you may as well fix them now, rather than trying to “band-aid” them with the new system. After all, automating flawed processes just produces bad results more efficiently.
Don’t #2: Work backwards from an implementation date. Many project plans are determined by an ambitious project leader choosing an aggressive date and circling it on the calendar. All implementation requirements and timelines are then worked against this date. This sounds good in theory, but this approach often puts extreme pressure on implementation teams throughout the process. These teams should be questioned prior to implementation to determine what timelines are appropriate, so you don’t wind up cutting a lot of corners to quickly implement a system that doesn’t really support the business.
Be realistic about a deployment date that is both achievable and logical for the business. For example, if the project is going to take 90 days and 75 percent of the company’s business activity occurs in the fourth quarter, then don’t try to squeeze it in by starting in August. Fourth quarter imperatives will arrive mid-implementation and both will suffer.
Don’t #3: Adopt inflexible timetables. Many, many projects fail because IT managers and executive sponsors develop an emotional attachment to the deployment date. If bonuses are tied to completion dates, the project managers will be tempted to sacrifice functionality in order to “go live” on the magic date. If business priorities have changed, the right business decision may be to delay a project.
The motto should be “do it right,” not “do or die.” Trying to fix a botched implementation after it has gone live causes pain throughout the organization, possibly for years.
Don’t #4: Proceed with a lack of methodology. The project management process should be defined early-on to ensure a happy ending. System selection and implementation become more difficult, time-consuming and expensive if you don’t have a methodology guiding this complex undertaking.
System implementations often require cross-functional teams to work together closely, with several departments supplying resources to the project. This makes it especially important to have a sound methodology so that these matrixes operate as efficiently as possible.
The methodology should include how changes will be tested and rolled out, and how various versions of software are managed. Failure to do this “blocking and tackling” can torpedo your project, or ensure that it can never be properly supported post-implementation.
Don’t #5: Operate with inadequate technology leadership. Let’s face it, IT departments are not overstaffed. Employee resources are scarce, especially among people with the technical knowledge to undertake a large project with significant business implications. The staff you have in place is already working full time or more, asking them to carve out the time to accomplish a large, mission-critical project without incremental leadership is likely asking for trouble.
You may want to consider the Enterprise Program Management Office (EPMO) approach, in which a full-time person (staffed internally or externally) serves as the project lead. This person focuses on keeping the project on target for the business strategy, providing support and expertise to implementation teams, and mentoring IT staff to improve project quality.
The competitive landscape is unforgiving of a botched system implementation. Downtime, decreased efficiency and deteriorating customer service can be especially detrimental to a small or rapidly growing business. The smart executive overcomes the urge to cringe and walk away, but stays watchful for the most common roadblocks to success.
Bill Huber is a Technology Solutions Leader for Tatum LLC. Tatum is the nation’s largest executive services firm, providing financial and technology leadership nationwide.