Two (+ 1) reasons why internal IT projects fail

When was the last time your IT department introduced shiny new technology that promised to “make your life easier”? How smooth was that transition, and did you end up seeing any benefits or improvements?

Having worked on countless projects, both internally for my employers and externally for clients, I’ve seen it all. Whether you’re a start-up with five employees, a multi-national with offices all around the world, or a consultancy that delivers projects professionally as a service, the same issues arise time and time again.

These issues usually have nothing to do with skillsets, budgets or timelines, the ball drops in one of two places: stakeholder engagement or change management. Let's explore what you can do to avoid these pitfalls.

Stakeholder Engagement

Step 1, know your audience. Who is instigating this work? What are they hoping to achieve? What’s the business outcome they are seeking?
This answer will normally be a decrease in costs, increase in revenue, improved efficiencies or smoother user experience. It is CRITICAL to keep these key stakeholders engaged all the way from ideation through to support. They’re going to be your strongest asset.

You must also remember that your stakeholder matrix will usually extend beyond the project instigators. I find that mapping them all on something like the below really helps to understand who you’re dealing with and how best to achieve the desired outcome:
DBgraph.JPG
Make sure you’re involving a representative from all affected groups, and plot them in the appropriate spot above. Remember that Influence doesn’t always translate from an organisational structure. A confident team lead or even particularly vocal team members may be your most important stakeholders as their influence and interest put them in the top right corner. This leads into the second troublesome area. 
 
Change Management

Once you’ve identified your stakeholders and where they sit on the matrix, traditional Project Management techniques will dictate that you go through design, build, test and launch.

What most neglect, is the importance of effective change management. In this age of digital disruption and transformation, Forbes Insights tells us that 85% of executives agree that this is critical to project success. You can have the shiniest tools on the market, but they’re no good if nobody is using them!

The best way I’ve found to manage change is with a Change Impact Analysis like the below:
Item # Now state Future state Affected People Assessment/Mitigation
1 Invoices are all processed manually. They are printed, checked against MYOB, stamped, scanned and then filed on Level 3 in the office Invoices will be received and triaged by System X. Discrepancies will be highlighted to Finance staff and they will follow-up with vendors. Once discrepancies are resolved within the system, they are processed with 1 click and archived on a cloud-server Finance Team Finance will need to be consulted during Design to ensure all iterations of the process are covered.
Representatives will also be required during the Testing phase, and all Finance staff will need classroom training on the new system as well as a FAQ guide to refer to for the first 2 weeks
 
The aim is to go through every stakeholder in your matrix and assess the level of impact this change will have on them. Large changes (e.g. shaking-up a day-to-day process) will require more effort. Small changes (e.g. your file server is now in Azure rather than on-premise) requires less, as the users will not see a noticeable change. Change Management is more than a simple change request form that nobody will read. It’s a thorough, thought-out process involving a deep understanding of your stakeholders that is essential to any successful IT project.

There’s actually one more reason I see internal projects fail, and you’re not going to like it. It’s because internal projects are usually run by internal staff. Yes it’s the +1 or third wheel of project failure.

The alternative of course, is to hire outside help. Employing a large consulting company with expensive consultants implies superior expertise and grandeur in terms of skillsets, experience and knowledge. I have no doubt that such consultants know what they’re doing, but I also think a lot of companies have plenty of perfectly capable in-house staff already that can do just as good a job. 

In reality, the consultant you’ve just hired may have never worked in your industry before. Whereas your staff member likely knows the industry like the back of their hand, may have all the right skillsets and then some. On the other hand however, the familiarity of your staff can be their downfall: “how are you going to implement X? You normally do Y!”.

Internal staff struggle to have the same impact as external consultants as they don’t have the benefit of anonymity. The only way to avoid the conundrum of “in-house vs external” is to have an honest look at your team and company, and decide whether this project will be more successful with the devil you know or the one you don’t.

So there you have it! Two (+ 1) reasons why internal IT projects fail. I’m curious to get your thoughts on this. Have you witnessed other common pitfalls? Are there better ways to navigate projects? Do you disagree with the ECSC (Expensive Consultant Supremacy Complex)? If you are looking for project advice, we’d love to help, get in touch today.