Disruption vs. Value: Keeping your Office 365 Initiative Afloat

As Office 365 practitioners, we need to consider the speed with which we roll out app capabilities to our organizations. Yes, some of our advanced users can make use of a wide array of Office 365 apps quickly and with relatively little discomfort. But most of our users are disrupted by the rollout and onboarding process for new technologies. The delicate balance of success hinges on generating enough disruption to change user behavior without alienating the very users we’re trying to engage.


Disruptions are not always a bad thing. Disruptive ideas and events are often credited with bringing about periods of great change and innovation. Office 365 provides an opportunity for your users to rethink the way they work and drive massive gains in their personal productivity. The intelligent form capabilities of PowerApps, the workflow automation of Microsoft Flow, the connected teams communication vehicles in Microsoft Teams, and the mobile capabilities of OneDrive and OneNote can be leveraged to drive a stronger digital workplace.

But how much disruption is too much? And how do you balance the executive “value” question with the impact of disrupting your users? This blog post examines this delicate balance of value versus disruption.

Note: Before you can evaluate how to roll out Office 365, you need to validate WHY Office 365 is right for your business. After all, technology is secondary. Our business drivers and employee needs come first. For more information, check out my blog post It’s not about the technology. It’s about the use case.

Determining your path
Every organization is unique. While there is a plethora of guidance on how to approach your Office 365 rollout, you should not blindly implement a “one-size-fits-most” strategy. Your approach needs to reflect the culture of your organization. If you work for an innovative think tank that prides itself on offering cutting-edge technology, a slow-and-steady Office 365 rollout is ill-advised. On the opposite end of the spectrum, organizations with a high degree of technical debt and a user base that is averse to change should carefully plan and communicate their Office 365 deployment.

I recommend creating formal personas for each of the key user groups that will leverage Office 365 in your organization. Ideally, these personas should be granular enough to account for each of the different Office 365 applications you roll out. You may have a business user persona, for example, that leverages Microsoft Flow to drive departmental process improvements. You may also have a customer service technician persona that leverages Yammer to respond to user questions and drive reductions in support desk calls.

Each user persona should identify:

  • High-level work objectives
  • Technology pain points the user faces
  • The user’s appetite for adapting to change
  • The speed with which the user adopts new technologies
  • Technology learning preferences
  • Preferred training and communication mediums (e.g. brown bags, video-based learning, self-service knowledge base, etc.)

These user personas should inform your Office 365 rollout strategy and form the basis for your user adoption campaign. The personas can also be used to build adoption targets for each of your Office 365 applications. Adoption targets estimate the rate at which users will leverage your new Office 365 capability. If you have 1,000 Office 365 users, for example, you may target having 10% of your users adopt Microsoft Flow within the first 12 months. Your Microsoft Flow rollout plan should account for driving this user growth, and monthly checks should be performed to measure your adoption efforts against your defined goals.

You must also determine what criteria your executive leadership team will use in determining the success or failure of your Office 365 implementation. Start by assessing the key business drivers for your organization and industry. Are your executives driven by financial metrics like margin, lower operating expenses, and total cost of ownership? Or are they swayed by productivity optimization (e.g. shortened business processes, workforce innovations, etc.)? The goal is to clearly articulate the value Office 365 is providing to your organization. Substantiating these value claims with appropriate supporting evidence (e.g. usage statistics, Office 365 success stories, user testimonials, etc.) is important. Executives are discerning, especially when it comes to business value claims. Your success depends on your ability to thoroughly back up your Office 365 value assessment.

An interesting debate
At Microsoft Ignite 2018, a set of REgarding 365 experts debated whether organizations should turn on all the Office 365 apps at once or take a slower rollout approach. The debate commentary brilliantly summarizes the disruption challenges organizations face. Take a look at these quotes from the debate:

“Not everybody needs everything…think about what you’re doing, what business challenges you’re trying to address” – Loryan Strant

“Experimentation is the lifeblood for innovation…I have to have all the availability of the things I want to use to be able to create solutions. I don’t want to be halfway down a path of a solution and then fall into some type of a trap that I can’t complete the solution based on the fact that I don’t have access to a certain tool” – Liz Sundet

“Are you operational-ready? Are you able to support all of the requests that are going to come at you all at once when you turn everything on?” – Daniel Glenn

“Office 365 is a suite. It’s not really individual products…so you’ve really got to go for it and turn everything on” – Steve Collier

“The company does not have (an) appetite for that which it does not understand” – session attendee

“We were challenged by our boss to get it (Office 365) out in 90 days. So we basically turned everything on, got it all out there, and then realized we have no governance whatsoever in place. And it was a disaster. We have group names, we have 5,000 SharePoint sites that nobody ever uses. And it’s just out of control. That’s one of the problems with turning it on without having the governance. Once you get the governance and all your framework in place, turn it on. Let people innovate. But make sure you’re there before you turn it on” – session attendee

You can watch this session in its entirety at Turn it all on in Office 365 – RE365 Debate (BRK1092).

The bottom line
Office 365 implementations are disruptive, and that’s OK. Success isn’t about avoiding disruption. Success hinges on driving business outcomes that outweigh and outlast user disruption. How much time you have to drive those business outcomes and how much allowance you have for causing disruption is going to be unique to your situation. The key is determining what business value looks like at your organization and building user personas that can help you limit the disruptive force of your rollout.

You also need to ensure your executives understand your approach and expected adoption of Office 365. If you have aligned your Office 365 rollout strategy with your business goals and clearly understand the value your executives want to see from your implementation, you’re on a solid path to success. Misalignment of expectations will fracture and limit the efficacy of your results.

As you roll out Office 365, keep your executives apprised of unexpected delays or changes in your forecasted adoption rates. Any gaps between your executive’s expectations and your project’s realities should be identified and communicated quickly.

Webinar recording: Creating effective business process solutions

The recording of my November 2015 webinar on usage of SharePoint as a business automation platform is available! If you are a VisualSP subscriber, you can view the recording at (For more information on VisualSP’s content and subscription model, visit )

In the webinar, I summarize the business process challenges we all face, identify the forgotten layer of content management in our organizations, explain how I built a successful SharePoint automation practice with an annual ROI of $550,000+ and provide a roadmap to get you started on your business automation journey. You’ll learn how to design solutions for voluntary and involuntary users, how to find that ever-important first project and how to effectively gather requirements for your new business automation solutions.

Session abstract:

Are you caught in an infinite loop of overgrown, outdated processes? Are your end-users stuck in a rut, copying data between an endless string of Excel spreadsheets? If so, this is the conference session for you! We’ll explore common process engineering methodologies, outline the “universal truths” that will help you relate to your business users and expose the “forgotten layer of content management” that exists at most organizations.

Then it’s GO TIME! We’ll outline a formula for finding your alpha project, provide a streamlined storyboarding/requirements gathering process and show you how to incorporate ROI valuations into your project timeline. You will leave this session with a “couch-to-success” plan for building effective business process solutions.

Land of Confusion: Why are our business processes so bad?

Work processes, like road signs, should be clear and direct. They should evoke a series of concise responses to effect a specific, desired outcome. The problem is, humans are organic. We start out defining a new process that will make our work lives easier. The new process may look like our straight line here–simple, efficient and productive.


But then we’re asked to do more and more things. In an effort to meet business objectives, be more efficient and manage our time, we load up our processes with too many steps and too many desired outcomes. Unable to stand under the weight, our processes devolve. They morph into a convoluted string of manual tasks that everyone performs but no one understands. The result looks like this:


In the end, we hate the very processes we hoped would save us. But the underlying need for the processes doesn’t disappear. So, inevitably, the cycle starts again. We abandon the overgrown processes we have come to hate, clarify our business needs, and voila! A new process emerges. Sound familiar? This is proof you are not alone! Process pain and mismanagement are epidemic. They exist in all industries, in all organizations and with a wide variety of toolsets. To prove the point, let’s go back to our road sign analogy. Here’s a road sign that works:


When you approach a STOP sign, you know what the process is:

  1. Bring your vehicle to a complete stop.
  2. Wait for traffic to clear.
  3. Proceed.

Are you ever confused by these steps? No. Do you ever think you should add additional steps to this process? Maybe get out and check your tire pressure or check to see if your brake lights are working? No. The purpose of this sign is clear, and there is no value in adding additional steps to the process. Now take a look at this road sign:


Are you confused? You’re not the only one. What are we supposed to do after seeing this sign? What’s our process? It looks like we should be sitting, but then do we wait to be impaled by a rectangle? I have no idea.

Now relate this back to the processes in your organization. Could you create a clear diagram or roadmap that outlines all of your common processes? What about stakeholders, key steps and end goals? All too often, our processes are nebulous. They don’t have a clear start, a clear end or a clearly defined singular purpose. As these inefficient processes grow in length and number, our employees start feeling boxed in (both literally and figuratively). They face a wall of work each day that keeps them from doing higher value-add tasks.

We also tend to forget the underlying cost of our inefficient processes. Every hour spent on a wasteful process costs your organization money. Money that goes to benefits, salaries, license costs, hardware costs, facility costs, etc. And let’s not forget the opportunity cost of having your time taken up with these arduous processes. Time spent circling the process drain is time you can’t spend on other value-add tasks. In many cases, that loss of time can result in a loss of revenue for your organization.

Calculating the cost of your inefficient processes

Every process in your organization has a dollar value. If you knew the dollar value of the processes you completed every day, would it change your perspective? Do you think your management team would want to “buy” those processes if they knew their true cost? For many of our required work processes, the answer would be a clear YES. Yes, we need to follow regulatory processes like HIPAA and PCI. Yes, we need to get payroll out regularly and file taxes. But what about all those processes with nebulous results and purpose? The ones that get bogged down with lots of additional steps that everyone follows but no one understands? Would your management want you to keep those processes if they knew their ultimate cost?

Here is a simple formula you can use to estimate the cost of your work processes:


Here are some definitions for this formula:

  • Time to complete 1 iteration = The amount of time (in hours) it takes to complete the process one time end-to-end.
  • # of iterations = The number of times per year the process is completed. For a monthly process, the number of iterations would be 12.
  • Hourly rate = This is what an hour of time costs at your organization. I recommend working with your Finance department to arrive at this number. It should represent all appropriate costs, including salary, benefits, hardware and software costs, facility costs, etc. The rate should also be an average that spans all job grade levels and covers both full-time employees and contractors. (Having a single hourly rate to use in all process calculations will provide uniformity and enable you to easily compare process costs.)

Let’s walk through a simple example to show you how the formula works. Pretend you have a weekly process that takes 4 hours per week to complete. Let’s also say you’ve worked with your Finance department and determined that an hour of someone’s time at your organization costs $50. We’ll plug this data into our formula as follows:


Based on the data provided, this weekly 4-hour process costs the company $10,400 per year. Now for the key question–can this process be optimized? Can you use a tool like SharePoint to eliminate manual steps from this process, thereby shortening the 4-hour time frame?

Let’s say you were successful in optimizing this work process. You eliminated a bunch of manual copy/paste steps by moving the data to SharePoint where everyone can access it. You structured the data in a single SharePoint list and built a workflow that notifies people when they need to take action. You also built filtered list web parts to give employees a work queue. This enables them to quickly find the tasks that are assigned to them. In the end, you were able to cut the process time in half so now it takes only 2 hours per week to complete. When you plug these updated process numbers into the formula, you now get a process cost of $5,200/year.


If you take the difference between the BEFORE cost of $10,400 and the AFTER cost of $5,200, you determine that these process improvements save your organization $5,200/year. Now for the key questions–how much are your processes costing your organization? And can you use SharePoint to streamline them?

“The celery effect” and other lessons learned from The SharePoint Governance Manifesto

sharepointgovernancemanifestoA few weeks ago I read Ant Clay’s new e-book The SharePoint Governance Manifesto. The book takes a refreshingly honest look at the failure rate of SharePoint projects. On the surface, it appears many of these failures are caused by ineffective governance, antiquated project staffing models and a myopic focus on SharePoint’s technical features. If you peel all that aside, though, you’ll find the crux of the issue–that we (as practitioners) often fail to tie SharePoint firmly to our business goals. As Clay writes, “we need to be stating projects in terms of ‘what difference will this make’ to our employees and more importantly to our organisation. If we can’t define that, then we shouldn’t be doing the project.”

Christian Buckley echoed this sentiment in his recent blog post Aligning SharePoint to Your Business Goals. To quote Christian and Dan Holme, “The Business Matters. SharePoint doesn’t matter.”

For many, this focus on business value–and the resulting need to quantify or qualify SharePoint’s contribution to the bottom line–is daunting. We’re not sure how to tie SharePoint’s features to our broader business goals, so we proceed with implementing SharePoint as a software project.

The key is to think differently about SharePoint from the start. So instead of focusing on SharePoint’s features or its internal infrastructure, we should be identifying ways SharePoint can help us increase our speed-to-market or enable our employees to share information more easily. Business goals and business needs must take center stage. After all, SharePoint is merely a tool to enable business success. So if you have a weak (or non-existent) return on investment (ROI) for SharePoint, you’re behind the times.

??????Clay goes one step farther in The SharePoint Governance Manifesto, likening SharePoint projects to eating celery. A stalk of celery is roughly 8 calories. The physical effort required to pick up, eat and digest a stalk of celery burns 14 calories. Do the math and you find that celery has a net negative caloric effect.

Many SharePoint projects have the same net negative effect. If you compare their “real costs” (including costs for infrastructure, licensing, staff time, training resources, etc.) to the demonstrable business value the projects generate, many projects return a negative ROI. As Clay states, “implementing SharePoint in an inappropriate way, without proper governance and without aligning it to business needs and vision, is the same as eating celery; it’s no good, and there’s no value in it.”

Want to know more about Clay’s model for SharePoint governance? Buy The SharePoint Governance Manifesto at For help quantifying or qualifying the ROI for your SharePoint projects, check out my SlideShare presentation DeMystifying ROI for SharePoint.

And remember: SharePoint shouldn’t be a diet plan. So stop dieting and do SharePoint for your businesses’ sake.

The one book you shouldn’t live without…

I’m incredibly excited about the publication of Ruven Gotz’s new book, Practical SharePoint 2010 Information Architecture. If you’ve been fortunate enough to see Ruven speak at a conference or SharePoint Saturday event before, you know he’s a whiz at explaining metadata, leading groups through mind mapping workshops and building out quick (but effective) wireframes.

Now you can learn the details behind Ruven’s information architecture magic. He’ll walk you through the agenda and methodologies for his discovery workshops, introduce you to mind mapping and what it can do for your SharePoint projects AND explain the basics behind findability and putability, metadata and taxonomy, etc.

Ruven was one of the first SharePoint experts I started following on Twitter. And when I got the chance to meet him at the 2009 Best Practices Conference, I was elated. From the get-go, Ruven and I shared a common information architecture world view. We believe in the power of analyzing content, involving end-users in the requirements gathering process and leveraging SharePoint as a case for effective change management.

When Ruven confided that he had committed to writing this book, I was thrilled. I knew he’d do a fantastic job turning his popular conference sessions into a guide for kick-starting SharePoint projects. I was a bit more trepidatious when Ruven called and asked me to contribute a chapter to the book, though…

After some discussion, I opted to focus my chapter on The Art of Creating Business Process Solutions. This chapter provides a holistic view of SharePoint as a business process re-engineering tool. It outlines the “universal truths” that will help you relate to your business users, exposes the “forgotten layer of content management” that exists at most organizations, guides you through the search for your alpha project and describes how you can measure the Return On Investment (ROI) of your new solutions. Consider it a “couch-to-success” plan for building effective business process solutions.

I’m incredibly proud to be a part of this book. For more information on the book, author bios, reader reviews, etc., check us out on Amazon. And don’t forget to visit the book’s Facebook page at

Using calculated fields to prioritize your SharePoint projects

I have to admit it…as a SharePoint practitioner I’m often guilty of overthinking. It’s easy to get drawn into designing complex solutions while overlooking simple features that generate a lot of user interest. I think this is a predictable problem, though. As we gain expertise in understanding how a platform like SharePoint works, we often gravitate to looking at complex, highly detailed solutions rather than focusing on the quick wins using “simple” functionality.

This blog post is all about the quick win, though. If you’ve seen me present at conferences or SharePoint user groups before, you know I’m passionate about documenting ROI for SharePoint projects. I follow up and formalize the business value of all my implementations (see my previous blog post I need some ROI…but I have no idea where to begin! for details). But I use ROI as more than just a means to summarize the value of projects I’ve completed. I start capturing ROI data during requirements gathering and rely on ROI estimates to prioritize my SharePoint project queue. This blog post walks through the simple SharePoint solution I built to use ROI estimates to auto-prioritize my projects.

First, let’s look at the completed solution. In the screen shot below, you can see a “SharePoint Requests” web part that displays my SharePoint project queue. Notice the Priority column. This is a calculated column that automatically assigns a low/medium/high priority to each project based on an automated ROI calculation. I use this priority rating to manage my queue of projects and determine my build/deploy schedule. 

Here are the steps to build out this project prioritizer:

  1. Create a new custom list in SharePoint.
  2. Add in the fields you need to track your Sharepoint requests. My list contains the following fields:
    • Project name – text field
    • Requestor(s) – person/group field
    • Request type – choice field
    • Team – text field
    • Request date – date field
    • Status – choice field
    • Collaboration owner – person/group field
    • Estimated ROI per year – currency field
    • Estimated hours to implement – number field
    • Start date – date field
    • Due date – date field
    • High-level goals – multiple lines of text field
    • Detailed requirements – multiple lines of text field

    NOTE: The Estimated ROI per year and the Estimated hours to implement fields must be set up in your new list. They will be essential for the priority calculation.

  3. Now that your base list is ready, you can set up your automated priority calculation. Go into your List Settings and create a new Calculated column named Priority (raw). Copy and paste the following text into the column’s Formula field:

    =IF(ISERROR([Estimated ROI per year]/[Estimated hours to implement]),”-“,[Estimated ROI per year]/[Estimated hours to implement])

    Specify that the data type returned by this formula be a number and press OK to save the settings for this new field.

  4.  Now you have an automatic calculation for your project priorities. But as you start entering data into your list, you’ll see that these numeric results aren’t terribly helpful. Depending on the values you enter into the Estimated ROI per year and the Estimated hours to implementfields, you may end up with raw priority numbers like 6,250 or 71.428571428571.

    I’m no math whiz, but I know I can’t make sense of these numbers. In fact, their only inherent value is their position relative to each other. Fortunately, we’re not done yet! There’s still one more calculated column to set up…

  5. Go into List Settings and create a second Calculated column named Priority. Copy and paste the following text into the column’s Formula field:

    =IF([Priority (raw)]=”-“,”-“,(IF([Priority (raw)]<650,(IF([Priority (raw)]<300,”Low”,”Medium”)),”High”)))

    Specify the data type returned by this formula to be a Single line of text and press OK to save the settings for this new field.

  6. View your results. As you enter new projects and specify their estimated annual ROI and estimated hours to implement, you will see a raw numerical priority value and a subsequent priority ranking of Low, Medium or High.

If you like, you can even change the default numerical thresholds that translate your Priority (raw) values into Low, Medium or High rankings. Just tweak the “650” and “300” numerals in the Priority field’s formula to alter the default thresholds and find the specific differentiators that will best meet your needs.

Next steps I’ve been meaning to try include color-coding my prioritizations and building a fancier dashboard. But that’s for a later blog post 🙂

Easy. Obvious, even.

So I have this pattern. I get an idea, implement it and then think “Hey, this is so obvious. Why haven’t I done this before?” Looking back now, I can see that 3 or 4 of these “patterns” have significantly shaped my trajectory through life. No, they haven’t led to personal epiphanies about how to deal with complicated family issues or led me to the perfect parenting principles. But they have led me to make some changes in my work and in my thoughts about work. And these changes have made all the difference.

But then I look at these “patterns” and think, these are so obvious. So elementary. How can such “obvious” ideas generate such a fundamental shift in my universe? Thanks to Derek Sivers, I now have a good answer to these questions. But first, let’s examine some of these watershed moments.

I was every parent’s nightmare. The bright kid floating through college with a commitment problem. Oh, I could pick a major. The problem was staying committed. And graduating with a degree. My parents went along with this trend for the first 3 years, but eventually they’d had enough. And since I was skating through college on their dime, I can’t say I blame them. So here I was, looking through the student course guidebook for inspiration. (And yes, I’m old enough that the guidebook was a book. No jokes please.) I found a field of study I’d never seen before–technical writing. And I thought, how hard can this be? I can write. I’ll just write about technical things. So I took an introductory class. And the class was easy. Obvious even. So I went to my professor to see what I was missing. Dr. Wilma Clark gave me some of the best (and most elemental) advice I’ve ever received. “If it seems obvious to you, then you’d better do it.” I left her office and declared a new major. Technical writing led me to my college internships and my first job. And it has served as an outstanding foundation for everything that has come later. Even if it did seem obvious.

Flash forward 8 years. I’ve been working for an enterprise-resource planning (ERP) software company creating documentation. I’ve created manuals, online help and training guides, but I was getting tired of creating the same content in a variety of formats. Enter JoAnn Hackos and the “new” idea of Single Sourcing documentation. Single sourcing is all about writing content once and re-using at the point of implementation/need. So rather than writing content in book format, write it in granular concepts that can be strung together to create books, online help or whatever else you need. This “single sourcing” principle led me to think about my work differently and connect with others in my field in a new way. And I said – hey, this is easy. Obvious even. With JoAnn Hackos and my mentor Roz Tsai’s help, I started sharing our single sourcing story with others. I spoke at conferences, taught seminars and found a new passion for training and connecting with people.

Skip ahead another 6-8 years and I have an idea for using SharePoint in a new way. I want to build SharePoint sites that help people automate their manual processes. I want the sites to rely on SharePoint lists rather than just document libraries. And I start coercing people into going through an information architecture and content review process prior to creating a SharePoint site. All this worked pretty well, but then my boss and I had a stroke of genius. What if we calculated the return on investment (ROI) on these sites? If I looked at how long a process took before SharePoint entered the picture and then looked at how much process time I’d saved with SharePoint business automation, I could calculate how much of a difference I’d made. So I calculated ROI on my first SharePoint project. And it was easy. Obvious even. But after sharing my ROI calculations with others, I discovered how unusual this kind of ROI evaluation was.

There are many more examples, but they all follow the same trend. I stumble onto something (often without much original thought on my part) and think “hey, this is easy. Obvious even.” And I scratch my head, trying to figure out why I’m not surrounded by others thinking the same thing. I never assume that I’m on the leading edge. Quite the opposite, I assume I’m the thought laggard. But then a few weeks ago I saw a YouTube video that explained it all. It is Derek Sivers’ video “Obvious to you. Amazing to others.”

This video is about me and the way I think. I’m guessing it’s about you, too. Take a look.

Want to see more of Derek Sivers’ deep thoughts? Check out his site ( or follow him on Twitter (@sivers).

I need some ROI…but I have no idea where to begin!

I’m creating/delivering a new presentation at SharePoint Saturday Twin Cities this weekend. It’s all about ROI. What it is, where companies go wrong in their quest to find it and how individuals can get a jump-start on quantifying it.

I’m passionate about ROI. It’s a game-changer. It’s the final step that many people forget to take after implementing a successful solution. But pulling together my thoughts on ROI and how to get started finding it in your SharePoint implementation has been tough. After spending a few frustrating hours trying to force the issue, I took a step back. That’s when I realized what I had missed. This focus on ROI has nothing to do with SharePoint. Rather, it has to do with successful product and project implementation–regardless of the platform you are using.

After resetting my context, I broke my session down into 3 basic parts–what is ROI, methodolgies/units of measure for tracking it and how to get started quantifying it. Once we have this base in place, we’ll look at how companies currently measure SharePoint ROI and compare that to how they could/should measure their ROI.  We’ll examine the costs of not focusing on ROI and take a look at industry trends around BPM and ROI.

Then we’ll move on to examining the types of ROI that can be tracked and look at real-world examples of each. Along the way, we’ll discuss calculation formulas, review minimum requirements for quantifying ROI and lay out a roadmap of how to get started on your ROI journey.

This could be a 2-day course. And I’m delivering an overview of it in 75 minutes. Strap yourselves in, folks!

Update (Sept. 7, 2011) – I’ve updated this presentation. Get a copy on SlideShare at