cloud circling a mountaintop
With Office 365 based in the cloud, Microsoft now delivers updates on a regular basis, leaving companies scrambling to keep up PHOTO: Alex Iby

Many technology leaders recognize that migrating to the cloud is inevitable, and now they’re tasked with devising plans on how to transition their organizations successfully. An organization’s intranet, being a communication tool, is frequently looked at as a first candidate to move to the cloud because of its relative simplicity in comparison to line-of-business applications.

Underneath the hood, things aren’t always so simple. Many intranets are tightly integrated with line-of-business tools, CRM systems and external data connections, making a cloud migration much harder than expected. Beyond technical challenges, there is also a human factor. IT teams accustomed to two-to-three-year release cycles are facing massive struggles with Office 365’s seemingly unpredictable release schedule.

One of my customers commented that monitoring Office 365 release announcements weekly via Twitter has become a way for them to keep their own road map up to date.

But the problem is not with how often Microsoft makes changes to Office 365, or what kind of changes it makes. The problem is that Office 365 has gone agile but many organizations are still using waterfall development processes.

Many companies tend to focus on a snapshot of currently available features when they’re developing their technology road maps. But with Office 365, you have to make your road map agile. Features may change; it’s how you respond to those changes that matters.

Here’s a look at several methods that worked very well for organizations transitioning to Office 365 from on-premises systems.

Plan Around the Business, Not Around Office 365

Your business is what should matter in your road map; technology is there to support the business. It’s unlikely that anyone will fundamentally change how their business runs just because Microsoft added a few bells and whistles to Office 365.

Here are few ways to help keep the focus on the business needs:

  • Avoid the false-consensus effect when it comes to what’s important to business users. Speak to key stakeholders to determine what the most valuable business functions are.
  • Use design thinking methodology to empathize with your business users and focus on improving their experiences.
  • Prioritize your Office 365 enhancements to support business users and their experiences.

Once you build and prioritize features, it’s time to get started on your flagship project.

Start Small

Shifting to fully agile environment is a big change. The key is to have positive impact and minimize the impact of failure. Before you decide to, say, move the whole intranet to Office 365, consider starting with a smaller undertaking as your pilot project.

You may want to introduce Microsoft Teams for a specific group within the organization. I recently worked with an organization that was a bit apprehensive about starting to use the Office 365 extranet but had no problem rolling out Teams for its support staff.

Microsoft Planner is another great tool for a pilot project. It’s relatively self-contained and great for any number of scenarios — from tracking deliverables and tasks on individual projects to tracking marketing efforts or planning all-staff events.

A project site would also be a good candidate for a first project, assuming it’s a pilot group and information stored on the site is compliant with your policies. Avoid picking a site for a project that uses confidential information; it would be hard to get everyone on board. Great candidates are sites tied to corporate responsibility initiatives, event sites or idea sites.

Here are several reasons why it’s a good idea to start with a smaller project:

  • Communication channels are easier to manage because the stakeholder group is relatively small.
  • If the project is successful, it instantly demonstrates the technology’s value to the rest of the organization.
  • If the project is unsuccessful, the impact of failure will be relatively small and you will learn valuable lessons.
  • You get exposed to potential governance, compliance and audit processes on a smaller scale and are prepared for the challenges of a larger initiative.

Once you select a flagship project, you can start the implementation using a microservices approach.

Introduce Functionality Through Microservices

The idea behind microservices is that, rather than customizing Office 365 features directly (which could put its functionality at risk of breaking during upgrades), you build and package your logic separately and reference it in Office 365.

Windows Azure offers function apps and logic apps. Similar offerings are available from Amazon and other vendors. You can build enhancements of any complexity that can run completely independent of core Office 365 features. You can surface this functionality using Microsoft Flow and add-ins.

The microservices approach is powerful and flexible, and it’s up to you how deep the integration should be. You can connect on-premises systems or third-party services to Office 365 while always keeping business logic under control.

Keep the Road Map Current

Because things are agile in the cloud, you must keep your road map agile. Avoid long development cycles. Break down annual transformations into quarterly releases, and quarterly enhancements into monthly releases. Your organization will gradually get on board, so you can take advantage of all the new features Office 365 has to offer while keeping your line-of-business integrations intact.