Hindsight sometimes gets the better of us. That poor storm trooper. If only he had the advice before Obi-Wan Kenobi showed up. Clearly the Galactic Empire don’t learn lessons. Perhaps consultants use the Jedi mind trick to persuade their customers?
I’ve recently completed an 18 month project that rolled out Office 365 to an ASX Top 30 company. This project successfully rolled out Office 365 to each division & team across the company, migrating content from SharePoint 2007 and File Shares. It hit the success criteria, was on-budget & showed positive figures on adoption metrics.
Every project is unique and has lessons to learn, though we rarely take time to reflect. This post is part of the learning process, it’s a brief list of lessons we learned along the way. It adds credibility when a consultancy can honestly say – Yes, we’ve done this before, here’s what we learned & here’s how it applies to your project. I believe Professional Services companies lose value when they don’t reflect & learn, including on their successful projects.
Don’t try to do too much
We often get caught up in capabilities of a platform and want to deploy them all. A platform like Office 365 has an endless list of capabilities. Document Management, Forms, Workflow, Planner, Teams, New intranet, Records Management, Automated governance…the list goes on. Check out my recent post on how you can use the power of limitation to create value. When we purely focus on capabilities, we can easily lose sight of how overwhelming it can be to people who use them. After all, the more you try to do, the more you’ll spend on consulting services.
Choose your capabilities, be clear on your scope, communicate your plans and road map future capability.
Design for day 1 and anticipate future changes
People in the business are not technology experts. They are experts in their relevant fields e.g. finance, HR, risk, compliance etc. You can’t expect them to know & understand all the concepts in Office 365 without them using it. Once people start using Office 365, they start to understand and then the Ahah! moment. Now the change requests start flowing.
Design for day 1 and anticipate future changes. Resource your project so post go-live activities includes design adjustments and enhancements. Ensure these activities don’t remove key resources from the next team you are migrating.
Respect business priorities
It’s easy to forget that people have a day job, they can’t be available all the time for your project. This is more so the case when there’s important business process like budgeting, results and reporting are on. You can’t expect to migrate or even plan to migrate during these periods, it just wont fly. If you are migrating remote teams, be mindful of events or processes that only affect them. There might be an activity which requires 100% of their time.
When planning & scheduling, be mindful of these priorities. Don’t assume they can carry the extra workload you are creating for them. Work with senior stakeholders to identify times when to engage or avoid.
Focus on the basics
Legacy systems that have been in place for years means people are very comfortable with how to use them. Office 365 often has multiple ways of doing the same thing – take Sharing for example, there’s 20+ ways to share the same content, through the browser, Office Pro Plus client, Outlook, OneDrive client, Office portal etc.
Too much choice is bad. Pick, train & communicate one way to do something. Once people become comfortable, they’ll find out the other ways themselves.
The lines between “Project” & “BAU” are blurred
New features & capabilities are constantly announced. We planned to deliver a modern intranet which we initially budged for a 3-month custom development cycle. When it came time to start this piece of work, Microsoft has just announced Communication sites. Whilst the customer was nervous with adopting this brand-new feature, it worked out to be good choice. The intranet now grows and morphs with the platform. Lots of new features have been announced, most recently we have megamenus, header & footer customisation plus much more. This was great during the project, but what happens when the project finishes? Who can help make sense of these new features?
Traditional plan-build-run models aren’t effective for a platform that continuously evolves outside of your control. This model lacks value creation & evolution. It makes the focus reactive incident management. To unlock value, you need to build a capability that can translate new features to opportunities & pain points within business teams. This helps deepen the IT/Business relationship & create value, not to mention help with adoption.
What have you recently learned? Leave a comment or drop me an email!
Con
Con.Efessopoulos@kloud.com.au