The projects that most IT professionals dread are the thankless yet essential tasks that garner little acknowledgment or respect.
Patch management isn’t glamorous, but fail to keep up and your organization could suffer a massive security breach. Cloud migration projects aren’t often sexy, but running email servers on premises in 2018 is a bit like using rotary phones. Enterprise resource planning (ERP) implementations and upgrades have been the posterchild for IT project failure for more than a decade, but most large organizations can’t survive without some kind of ERP system.
Technology is almost never the root cause of hellish IT projects. More often tech initiatives fall into disarray thanks to unrealistic expectations, a failure to adequately scope, cultural clashes, procrastination, or a lack of adequate support from on high.
The solutions to hellish IT projects are usually straightforward, but the devil is in the details.
1. Enormous patches at the last minute
Patching is one of those essential chores nearly every IT pro hates to do. But put it off too long, or fail to ensure that all your machines are up to date, and your organization could end up like Equifax.
“We are constantly being thrown big projects where patching has not taken place for months or years,” says Oli Thordarson, CEO of IT services provider Alvaka Networks. “Sometimes it can be hundreds of production servers, along with dev and test servers. Knowing that if something goes wrong we can blow up a big internet presence for a brand name is stressful. That’s why internal staff sometimes procrastinates on patching, until all of a sudden management looks at the situation and realizes it is overwhelming.”
A few years ago Alvaka was doing a big Windows patch job for a city police department, says Thordarson. Everything went fine for the rank and file’s desktops. But the PCs for the chief of police, captains, and lieutenants were all down for the count — and they were not happy about it.
“Top brass at police departments are not shy people,” he says. “They’re calling us and they’re PO’d because they can’t log in and do what they needed to do.”
Turns out they were using slightly different machines with third-party apps that were causing a conflict. Thordarson’s team was able to roll back the patches, isolate the problem, and fix them in about 30 minutes. But it was a tense and stressful half hour.
The worst patch jobs are the ones where systems have been neglected for years, adds Alvaka CTO Unnar Gardarsson (who says he is one of the rare IT pros who actually enjoys patching).
“The ‘oh sh*t moment’ is when I’ve patched something and the servers take abnormally long to come back, or don’t come back at all,” he says. “In some cases I can go into the virtual machine recovery console and look at the server. In other environments all I can do is patch and pray.”
Lessons learned: To avoid worst case scenarios, take extra care to make sure you have a thoroughly tested backup plan that accounts for every single system, says Gardarsson.
“For every patch job I do I have a project plan that takes into account everything from normal backups and additional snapshots to notifying people and stopping services,” he says. “Some systems are really finicky and there’s a very specific process to taking them offline. Being prepared and thinking through every possible scenario is key.”
2. The great email migration to the cloud
Moving from an on-prem email solution to the cloud sounds simple in principle. It’s anything but, says Mike Meikle, CEO of SecureHIM, a healthcare IT security consultancy.
For one thing, users are hoarders, says Meikle. They have gigs upon gigs of messages they should have deleted years ago, so the sheer volume of data is daunting. If you’re moving from a legacy system like Lotus Notes (shudder), you’ll have a lot of data conversion on your plate. Some of the information in those messages is highly sensitive and regulated, so you need to make sure you’re in compliance with HIPAA, GDPR, SOX, or other regulations.
And of course, you’re dealing with a system that people rely on virtually 24/7 for communications, scheduling, reserving meeting rooms, and so on.
Meikle says he’s worked at companies where the cloud migration took more than a year and required a lot of hand-holding.
“Since email is so ubiquitous, if the migration falls down in any way IT immediately gets stabbed,” he says. “Even in the age of Slack and other team chat apps, email migration is one of those projects IT definitely dreads.”
Lessons learned: As with other IT projects from hell, doing your homework ahead of time is essential. Have the system or device requirements down cold, and recruit a core group of power users to run proof of concepts and pilots so you can iron out most kinks ahead of time.
“It can’t just be IT going around saying, ‘Oh, this looks good,’” he says. “You really have to know your user requirements and what they’re going to tolerate.”
3. Compliance mandates orphaned at birth
There are two kinds of IT projects: those that receive strong sponsorship from top management because they’re strategic to the organization’s success, and everything else. But the most hellish kind are those where employees must be dragged kicking and screaming into compliance, with little support from above.
“Regulatory-driven projects that are mandated by executive leadership but don’t get their full-throated backing are the worst,” says Sheldon C., a director at an IT services firm. (Sheldon is not his real name; he asked to be anonymized to avoid being identified by former colleagues.)
Until about a year ago, Sheldon was a tech VP for a large financial institution on the West Coast. When he joined the company it was already in the cross hairs of regulators, in part because of an inadequate disaster recovery plan. Activist shareholders were pushing the institution to clean up the mess, and while top management was behind the project, department directors had their own priorities. DR was not at the top of their lists.
So they didn’t participate. They failed to submit departmental requirements for fail-over and recovery priorities, or identify mission-critical data and apps. They didn’t take part in preliminary or advanced testing. They ignored Sheldon’s emails.
Because the requests were coming from IT, department heads felt comfortable relegating them to the bottom of the pile, and project sponsors did nothing to intercede on Sheldon’s behalf.
“I mentioned over and over to the CIO that this was happening, please help me out,” he says. “I was like, ‘Hey, there’s this problem.’ Crickets. ‘I haven’t gotten an answer back yet.’ More crickets. So the project moved forward with those risks not being accepted or acknowledged.”
Lessons learned: Documenting the entire process — including every unsuccessful attempt to get the necessary parties to participate — is fundamental. But you also need to distribute the information to the right people, so project sponsors can’t claim ignorance later.
And if that doesn’t work, cut your losses. In Sheldon’s case, that meant leaving for a new position at the soonest opportunity.
“The funny thing was, the CIO held the DR project up as a great success,” he says. “I got accolades for getting it done. But I knew when the auditors actually looked at it, the people giving the accolades would have to defend what happened. When the company culture is setting you up for failure, that’s a good sign it’s time to leave.”
4. ERP is a four-letter word
Probably no single type of project has inspired more angst or induced more heartburn than implementing a new ERP system.
Having to interface the ERP with legacy hardware is always fraught with peril; throw in language and cultural barriers and you have a recipe for a disaster of epic proportions, notes Dan Coleby, director of business performance and consulting for IT Lab, a technology services company based in the UK.
In the mid-2000s, when Coleby was working for a Big 4 consulting firm in London, he was called in to help the Japanese branch of a large multinational roll out its global ERP system. By the time Coleby arrived, the project was more than two years old and considerably over budget, in part because some of the hardware was truly ancient.
“One of those systems was so old we had to borrow a power supply from an exhibit at the National Computer Museum in Tokyo in case the one they had failed,” he says. “We only had 8 hours every night to refresh the ERP system with new data, but the interface took 20 hours to run, making it essentially useless.”
But the biggest barriers weren’t technological; they were personal and political. Coleby had to figure out how to make the system go live without anyone losing face.
“I wasn’t allowed to question the architecture, the strategy, or the company’s global approach to technology,” Coleby says. “I ended up persuading the Japanese to change their business processes so they used less information. I cut out around 90 percent of the data so the system could run in less than 8 hours.”
Lesson learned: Technology alone isn’t the answer; people and process are just as essential, Coleby says.
“At IT Lab we always tackle organization, structure, process, and the governance side of IT, because that’s always as important as the technology itself.”
5. Under scoped and over promised
Whether it’s from excessive optimism, a desire to impress the boss, or a failure to properly scope projects, underestimating the time and effort required to deliver an application can turn a challenging project into a hellish one.
“You see people being very optimistic about what they can deliver in a short period of time, especially in fast-moving companies,” says Alan Zucker, founding principal of Project Management Essentials.
In the late 1990s, Zucker was working as a project manager in the accounting department for a Fortune 100 telecom company. The carrier was billing more than $1 billion a month and using hundreds of interlinked spreadsheets and databases to keep track of it all. The solution was to build a single application to close the books each month, using Sybase on the back end with a Power Builder interface.
After a company re-org, responsibility for the project fell to Zucker’s group.
“The IT group came up with a really elegant idea, which was to load everything into a database and let the accounting people build their own business rules,” he says.
But they’d promised to deliver the app in nine months. When Zucker inherited the project, four months in, not a single line of code had been written. The IT group was still collecting user requirements. And they were discovering that the job was much more complicated than anyone had anticipated.
That’s when the finger pointing started, Zucker says.
“My counterpart in the IT organization started to get very defensive,” he says. “He would write these emails that went on for pages and felt like police investigations. ‘On this date at this time, so and so said this…’ and so on. It became this escalating situation where there were just no constructive conversations to be had.”
It was only after the IT manager was reassigned and Zucker got a new partner and a more forgiving timetable that the project moved forward. The app was ultimately a success, but it took another two years before it was finished.
Lessons learned: Zucker says he realized that, in the future, he needed to step back from confrontation and find a way for both parties to come out with a win. He also learned that it’s OK to ask for more resources and reset the original terms of the project. And finally, it was a lesson in how changing a single resource — or one person — can totally improve the team dynamic.
6. Special requests from the C-suite
You may have standardized your global organization on Android, but you’ll have to pry the CEO’s iPhone from his cold dead hands. Or perhaps a director with the ear of the board requests a custom solution for her department.
In the ideal scenario, project requests are scored against strategic plans and determined necessary for the enterprise to meet specific goals before they’re approved and budgeted.
“Most organizations are not like that,” says Meikle. “A lot of times it’s whoever has the most political juice that gets their stuff done.”
Even the most locked-down companies can fall prey to the whims of those who wield the most influence, he says. In many cases, that happens because the CIO lacks the political power to push back.
“When push comes to shove, they usually fold like a cheap suit,” he says. “They’re still at the kid’s table at Thanksgiving, eating the canned cranberry sauce.”
Lessons learned: If you don’t have an intake process for IT projects, expect those with the most clout to ride roughshod over your priorities, says Meikle. You need to learn who your key governance, risk, and compliance stakeholders are, and make sure IT has a seat at the table on each steering committee.
“You need the C-suite in your camp to effectively manage IT project intake and workflow,” he adds. “If not, you’ll be funding every executive whim out of your IT budget while sucking your resources dry, leaving crumbs for less glamorous but critical projects like infrastructure and networking.”
SOURCE: CIO from idg https://www.cio.com/article/3283646/it-strategy/6-most-dreaded-it-projects.html
