Let’s start with an analogy
It’s one I use when explaining how change occurs in Office 365. It might need some polish!
The super-freighter in the image moves deceptively quickly and it will cross the Atlantic in around 10 days. Whilst though it is slow to start, it takes a long time to change direction and often needs help doing so.
The vessel runs on a schedule and its movements within controlled waters are published so all mariners are aware
When out at sea, normal waves have no impact upon it and radar is constantly scanning so icebergs and other debris are foreseen and avoided.
The containers it carries change regularly and very occasionally a “reefer” falls off and is lost at sea.
Now consider Office 365 to be the super-freighter, the containers a mix of product features.
The service is evergreen – that is Microsoft updates it on a monthly cycle. Some of their Roadmap is published (schedule), some of the changes are communicated (published shipping movements), some of the changes are just imposed (containers fall overboard), new features are added whilst others are taken away (containers are loaded and others unloaded.)
As a consumer, the bulk of this is out of our control. In addition, A/B testing can temporarily add / remove functionality for specific users (or in freight terms, a container gets temporarily misplaced).
How do we monitor and react to change
To stay agile and proactive, we have established our Ships Bridge in yammer and have created an O365 Change and Strategy Group. Members of the group are encouraged to #workoutloud in order to share their thoughts, observations, alerts as quickly and as honestly as possible. The group contains key stakeholders from across the IT service and we can invite others in as the need arises. We monitor and react to change by:
1. Identifying the potential changes
For this we have a network of inquisitive radar operators. We use a combination of:
- the Microsoft Monthly Service Update ‘newsletter’ (which is issued by our Microsoft Technical Account Manager)
- weekly reviews of the Message Centre
- conversations with companies that we are working with
- a near constant eye on the Office 365 Yammer Network
- the Office 365 Roadmap (which some of us consume using a RSS feed)
- plus some other sources that we’d not like to reveal
All of the knowledge is discussed in the dedicated Yammer Group and when we know the MSG ID (from Message Centre postings) we tag the conversations with it (as well as adding links to threads on the O365N etc.). We also maintain a tracking spreadsheet (as you’ve got to have a spreadsheet). To be honest it is too much like hard work and Yammer and Microsoft should make this easier.
2. Discuss the potential changes
We have an allocated slot in our weekly team meetings to discuss roadmap items and how we intend to tackle them. Significant items are reviewed with projects and/or change tasks created.
The tricky part is not knowing exactly when the change will arrive. I usually take actions to try and get more information. For example, Yammer announcements are usually pretty light on actual detail. What really helps is the Change Alerts group in the O365N as customers typically in North America get the change days or weeks before it arrives in our UK tenants. By following that group, we get an early warning of impact, mitigation and customers we can talk to.
3. Test the change
Fingers crossed it arrives in our First Release* tenant. At that point we play and test it, grab screenshots and prepare the communications for it. Every Office 365 feature has a dedicated space in our Intranet. We typically prepare a new page that describes the feature and briefly explains how staff might use it.
An exception to the rule is Yammer as from this day to the next and one user to another we sometimes do not know what is an A/B and what is a feature release as they seldom use the Message Centre (though I understand plans are evolving to improve that).
4. Communicate the change
Obviously the greater the impact the more we do. Massive change means staff briefings, board meetings etc. The bulk of changes are communicated using our Intranet – we use the page created in step 3 as the news item. We also push news out across yammer – again with links back to the article. Sometimes a targeted email blast is employed and we have a dedicated service alerts banner that we can enable in our intranet. In time we will start to surface the service announcements from the Office 365 Admin Centre within our Intranet using the Office 365 Management API.
* As an aside, we operate a second tenant with a small amount of content in full First Release mode and our Production tenant has Selective First Release for named users – sometimes the change is hard to test as we do not have enough content or numbers of users in our test tenant – we are looking at using ShareGate to snapshot our production instance and replicate the content in test, though this will not replicate the number of users which is vital for testing items like people search and profiles