Technically Successful Failure

The Technically Successful Failure

Technically Successful FailureTell me if this story sounds familiar to you.  You work on a project for a major new initiative at your organization.  You approach it by gathering requirements from the Subject Matter Experts.  Those requirements may, or may not, be documented.  The new system is designed, built, tested, deployed and then…no one uses it. Technically it works flawlessly, but because no one adopts and uses it, the project is really a failure.

Why does this happen at all, and more importantly, why does it happen often to technical projects?  One answer is that an extremely important part of successful projects was not included…Organizational Change Management.  There is a common assertion that projects are about 80% doing something and about 20% teaching and communicating what you did to the organization.  So, in a typical project that burns 2000 hours, we should be spending about 400 hours on communications planning, training, and how we will manage the change in the organization.  Unfortunately we tend to spend almost no time on managing change because we don’t see it as critical to our success.  How wrong we are, in fact 91% of organizations think that end user acceptance of a project is vital to the projects success…so, why do we ignore the end users?

From the very beginning of a project, we have to think about how the new system we are implementing will effect our organization, and how we should manage that change.  In short, we are going to move someone’s cheese and if we do that without consulting them first, they are not going to be happy with us.  Let’s look at two similar projects, migrations to Office 365, that both were delivered flawlessly technically, but overall had vastly different successes in the organization.

Project A was implemented in a traditional manner by IT.  They researched how to implement DirSync, migration methods, engaged with the Fast Track center for the mailbox migrations, and prepared to setup Skype for Business, OneDrive for Business, and SharePoint Online.  They stood up their tenant, tested all of the technical aspects of the roll out and then migrated users to the Cloud.  They turned on OneDrive, SharePoint, and Skype and then waited for the praise to roll in.  What they got instead was angry and upset users.  The email change was relatively simple, but users weren’t prepared for changes to their email on their desktop or mobile devices.  This meant that some users were left without email while traveling and didn’t get important communications.  Since email was the primary communications for the project those users were unaware of how to get to their email and ended up calling the help desk.  After the initial change-over email became smooth, but the project team was surprised that after a month, no one was using OneDrive for Business, SharePoint, or Skype for Business.  Most users didn’t even know it existed, or what it should be used for.

Project B was also an Office 365 migration, but in this case the project team started out by looking at how the users currently made use of the major workloads to be migrated.  They looked at what impact the change to online email would have to end users and developed a plan to allow users to opt-in to the migration over a month long time frame before they would be forced to migrate.  This allowed travelling users to pick a good time for their migration.  They looked at how users were storing and working on their files and developed a training plan for OneDrive use that looked at the common work scenarios that users face on a daily basis and showed them how using OneDrive would improve their work experience.  They delivered the training course multiple times and recorded it so that others could watch it if they missed a live session.  For Skype for Business they also developed a training class and quick help videos that highlighted the new product and how it would address common usage scenarios in the company.  Lastly, for SharePoint, they looked at how it was being used and developed a new offering that enhanced the way that people were using SharePoint by including socialization and a coordinated navigation and information architecture.  Oh, and they delivered all of the technical aspects as well.

Both projects were technically successful…but only one actually effected change in the organization because it built that change management into the project itself.  Project B cost more to implement, but the value that the organization gained from the migration was far in excess of what Project A delivered.

Leave a Reply