Most articles you’ll read within the pages of Canadian Government Executive will provide you with best practices and tips on how to effectively identify and implement cutting-edge technologies. While there are many factors that go into the success of an implementation, there are some considerations that will definitely cause your project to fail; these are rarely discussed. Too often, government leaders are preoccupied with the day-to-day logistics of a deployment – when do we start, how many seats do we buy – that they make major strategic mistakes that can hamstring their project.
To highlight key areas to sidestep, I’d like to use Canada Post’s organization-wide implementation of an electronic management solution that featured SharePoint and a few key add-ons such as harmon.ie, a workplace productivity app. The goal of the project was to help us manage Canada Post’s 10+ terabytes of (mostly unstructured) data. The initial aim was to make it easier for employees to store and manage within SharePoint. Research conducted by my team demonstrated some privacy and compliance concerns where corporate information was being stored. Worse, we found a significant number of documents that were beyond their required retention period as determined by our retention and disposition schedule. This chaotic environment made it difficult to find specific information so workers were often forced to unnecessarily – and sometimes unknowingly – recreate documents because they were unaware that the information already existed. It was a big, complicated and messy project so it was imperative that we sidestep any of the common pitfalls that agencies can fall into.
Mistake #1: Death by Consultant
I’ve always been fortunate to have ultra-talented project teams but Canada Post, like most government agencies, lacked the in-house expertise to roll out large-scale IT projects. That’s not the problem. The problem arises when a government leader hires external help and essentially hands over the keys to the project. Agencies must have a great internal team managing and participating in the work alongside their external partners.
Consultants can have more technical skills and know-how than the internal team, but they don’t know the internal culture, workflow and specific requirements of each department. External partners should be willing to adapt their formal methodology to meet the unique needs of the project, as opposed to taking a hard stance. That said, partners must be more than just arms and legs; outside firms must be empowered to offer their expertise to ensure the best ideas from the entire project team are utilized. As long as you’re looking to achieve the goals of the project, you have to be flexible in how you implement your methodology and willing to compromise.
It’s also imperative that both parties speak the same language. I’ve always found that outcomes-based language – “I need a 95 per cent adoption rate for this tool” vs. “I need 400 seats” – is much more productive because it allows the consultants to flex their strategic muscles and make recommendations on the most efficient way to achieve project goals. IT projects are fluid and even the best-laid plans often undergo significant changes. External partners that are willing to take the journey along with you – including all of its ups and downs – are valuable assets. However, if you keep hearing the phrase “change request” uttered, I recommend you change consultants.
Mistake #2: One Sales Pitch, Many Departments
A successful technology project – at its heart – is about convincing people that the impending change is not only required but a step in the right direction. A wide variety of departments within Canada Post would be using this new functionality but would have a different set of problems that would need to be resolved. The project team has to execute what would in the political realm be called a “hearts and minds” campaign. The fact of the matter is that workers don’t want to change the way they work and so, therefore, must be convinced. Government IT leaders need to accept the fact that the only individual that wants change is a baby and even they cry during the experience. If you go one-size-fits-all, you’re doomed to failure.
This was a major motivation for using harmon.ie in this particular project. harmon.ie is an Outlook plug-in that presents SharePoint directly within the Outlook window, so workers don’t need to toggle between the two apps to upload document attachments and email messages to SharePoint. And since we knew the majority of Canada’s Post’s office employees used Outlook as their primary working portal we wanted to provide tools that would facilitate that workflow. With harmon.ie, employees were able to use the drag and drop interface to tag and store files within our SharePoint system right from Outlook. Our employees needed very little training because harmon.ie fit snugly within their existing workflow. Choosing user-friendly software like harmon.ie helped us sell the project is a non-hindrance to their workflows.
My teams used a “franchise in a box” model. We had a core methodology that we used to create a continuous learning curve so we could improve the outcomes of each departmental rollout. Accountants are going to have wildly different interactions with the project team than the engineering team. These input sessions allowed us to introduce the project and start to build the trust necessary for employee buy-in.
Over the course of the project, we discovered a number of other pain points that needed to be resolved. Workers were using a number of unconventional methods to store information so we needed to work with them to get everyone back in the fold. It’s important that government IT leaders be willing to adjust their goals to accommodate serendipity.
Mistake #3: When it Comes to Mass Document Migration… Don’t Do It!
This may be a niche problem but it’s worth mentioning: mass document migration is a nightmare and should be avoided wherever possible. Records management projects typically require some kind of transition from one platform to another but there’s typically a high proportion of unnecessary, duplicate and very old documents to justify the tremendous amount of work, resources and headaches required to execute. At the end of the day, the team will be spending a ton of time and effort to move documents no one will ever open again.
This is a great example of where changing your methodology makes sense. We started the project thinking that we were going to migrate all of our documents to SharePoint and then discovered the complications this would create. Our decision to change saved significant heartache and, utilizing harmon.ie, allowed us to make this change and save our project considerable costs.
In compliance with your retention and disposition schedule, my recommendation would be to encourage workers to ruthlessly remove all unnecessary documents. Instead of migrating everything, harmon.ie enabled workers to easily choose which documents they themselves required and thereby execute low-volume migrations without any complications.
It’s important for project teams to understand that not everyone cares about their project. It’s up to the project team to prove that the tools being implement provide value to their everyday work lives. Project teams that don’t make tech easy for users to learn and use will find their brilliantly executed implementations flop. Systems and processes must be easy and intuitive or else failure is imminent.
