Blogs

Blogs

How to Build a Successful Platform Rollout Strategy

My wife has always given me a great amount of grief when it comes to doing even small improvement projects around the house. Almost always, I see the opportunity to get something else done "while we're at it." "Going to be doing some drywall? This is the perfect time to get some extra insulation in that wall." "While we're at it, I don't like the wiring back in here. We need to redo that in conduit." My wife hates it because what was a small budget, quick task has now become a weekend long endeavor.

Applying our two approaches to an enterprise IT rollout, you essentially get what I would like to cover here: 1. roll out in a phased approach applied department by department or 2. jump right into it and execute company wide.

Which of these is the right one for your organization? The answer to that question lies in what you plan to facilitate as part of your project and whose day to day they impact the most.

Horizontal Rollout: The "Big Bang" Approach

Horizontal Rollout Strategy - Big Bang Approach - Enterprise IT Project, Liferay Portal

This rollout strategy is essentially taking the broadest approach in application that you can take across the company or, for multinational companies, a division of the company (such as MyCompany of America versus MyCompany of Japan). For example, no matter where we are in our particular company--sales, marketing, services, support, engineering--we have a common set of benefits, employee guidelines and compensation mechanisms. If we are changing the process for accessing those materials and systems, we are affecting the horizontal use cases that apply to all groups. 

  • A few examples of these horizontal functionality and usage models include:
  • Enterprise-wide identity management and single authentication mechanisms.
  • Tool accessibility through both the use of WCAG compliance and responsive design.
  • Connecting like organizational roles throughout the company into a center of excellence with associated tools and templates.

Pros

The benefit of this "big bang" approach is that the campaign for adoption is generally more effective and accepted as an official change. It cuts through all of the noise the constituents typically hear and they pay attention. It may also be easier in some organization to make the case, and obtain budget approval, for a single large scale project.  Lastly, this approach has the ability to coincide easily with other parallel activities or tie in with a defined strategic statement. In short, it's easier to coordinate and understand the roadmap using this style.

Cons

It does come with its drawbacks however. A company/division-wide rollout only provides you with a single opportunity to get the message right. And without a history of these kinds of rollouts, you may be the one establishing that history with a load of missteps.

Something else that you must consider is that each of the constituent groups needs to see value in the rollout--what many call the WIIFM (What's in it for me). Without it, a user is going to log in for the first time, see nothing particularly interesting and useful, and never come back again (at least not without a revitalization campaign).

Also consider that this WIIFM is typically consumption-centric initially. It needs plenty of fresh content and staffing to continue that trend until it reaches a point at which the users themselves become invested in the platform and help in generating some of that content themselves by way of using it.

There is an alternative however.

Vertical Rollout: The Targeted Approach

Vertical Rollout Strategy - Targeted Approach - Enterprise IT Project, Liferay Portal

For this strategy we target a set of functional use cases that have a common concern and objective. You can even execute this as what some term the wave approach and stagger the rollout. (Note that we'll talk about this later in the series as we discuss parallel rollout strategy and activities.)

A phased rollout will typically lend itself to more vertical usage models versus the horizontal models noted above. In this, the use cases go deeper into their specific need, and this lends itself to a department, organizational unit, program or specialization.

For example, a process for our Global Services Engagement Managers to understand and allocate consultants to a project is not going to be useful for our human resources, engineering or enterprise support departments. It still makes sense to include this as part of our company-wide platform however, to make it a one stop shop for daily information and activities.

A few examples of these horizontal functionality and usage models that we have encountered are:

  • Establishment of a knowledgebase for frontline support teams.
  • Sales enablement tools and collateral systems.
  • Team workflow management and collaboration.
  • Multiple systems of record migration and consolidation.

Pros

One great benefit of an incremental, release focused rollout is that it lends itself well to iterative improvement. Much like the agile process that we use in house, we are able to get something out quickly, gather feedback from our users, and evolve our platform and our rollout process.

With a focus on a particular vertical audience, we can also do greater diligence around defining the WIIFM and by executing on this with a smaller group, we achieve that activation objective (adopted and self sustaining) much quicker.

Cons

Just as our company-wide rollout has some drawbacks, so does the phased rollout, however.  A phased vertical rollout suffers from lack of visibility across the company. It also requires your selling people on the project outside your immediate target group even if they are not impacted right now. An initial platform rollout may be successful by itself, but others for whom that rollout may not be targeted still need to be kept informed and a clear vision identified and sold to them. If the project leaders leave this message to the initial constituent group, they lose control of the message and it can become diluted or misconstrued.

An Alternative: The Hybrid Approach

Hybrid Rollout Strategy - Enterprise IT Project, Liferay Portal

You may have come to the same conclusion as we usually do when it comes to weighing the pros and cons of each of these approaches. It's typically not one of them, its both. We found the same thing in the creation of our own own adapted agile development methodology: we start with a waterfall-like discovery and architecture period, to lay a foundation, and then flow into iterative development sprints.

By executing on a hybrid strategy  you can cancel out the negative risks that come with either of these alone. We facilitate a more sticky engagement with each of the vertical target groups each phase addresses, but maximize on the platform visibility inherent in a horizontal rollout.

For example, the building of a platform that provides a foundation for both a front line support system knowledge base as well as a sales enablement tool would benefit from this hybrid approach. The project would include some of the cross-cutting characteristics of single source identity management and accessibility. The difference is that it would focus on the most valuable functional use cases in each vertical (e.g., FAQs, presentation templates), or even across more than one vertical (e.g., customer install base knowledge), rather than going too deep and attempting to be a comprehensive tool for a single vertical. 

The added benefit is that you've steered clear of a myopic view of the architecture which will feel more laden with additional concerns as the scope expands with each new constituent group.

The hybrid approach does raise the following question: Where does the line get drawn between the two approaches? Here are some tips to help you navigate at key points in your rollout:

  1. Start with a foundational phase for your enterprise IT platform.
    This phase will be the most horizontal and should address enough of your horizontal use cases to whet the appetite of the user base for more. Messaging needs to be clear that this is a foundational release however, and that a perfect solution is not expected. The intention is to learn and adapt to user feedback and assimilate a greater amount of deeper level use cases as the platform evolves.

     
  2. Start defining the WIIFM using the constituent group that most closely aligns to the company-wide usage model.
    If the foundational elements of your platform speak to the horizontal rollout example of a benefits and compensation knowledgebase, then that initial target group may be the HR department. 

     
  3. Don't try and be everything to everyone.
    Though the possibility is certainly there, identify the primary value proposition for your initial platform and sell the platform based on those merits. It can be difficult to determine what is going to be the most valuable and important functional use case in a phase approach.  It is flexible.  Making promises around a phase for which you're not immediately planning usually leads to a monstrosity which seems tacked together.

During this next series of blogs, I will build on the three strategies introduced here and walk through best practices used by the Liferay Global Services team when building out a comprehensive rollout plan of a lightweight digital experience platform for our multinational customer base.

 

Horizontal Rollout

Vertical Rollout

Hybrid

Pros

  • Attention grabbing and effective for adoption.

  • Easier to gain budget approval.

  • Platform rollout is in parallel with other strategic plans in company roadmap.

  • Allows for iterative improvements.

  • Quicker, more agile development.

  • More rapid adoption and self-sustainment by target group.

  • Combines the positives while removing the negatives of either approach.

Cons

  • One opportunity to get it right or risk losing momentum

  • What's-in-it-for-me syndrome: each constituent must see the value

  • Consumption-centric at outset

  • Lacks visibility across the company.

  • Must sell project to those outside immediate target.

  • Risk losing control of messaging

  • Architecture may become strained by new pressures and direction

  • Requires the highest level of team facilitation and prioritization during the planning phase to build an effective roadmap

Recommended for:

  • Platform establishment

  • Small scale companies or organizations addressing a common need or paint point

  • Large scale companies addressing a specific need or pain point in a single department

  • Any size company looking to establish an enterprise wide platform while addressing the most valuable specific group needs

We know organizational support is key to the success of your solution. Get more tips on how to launch a successful platform at your company with our whitepaper Portal Best Practices.

Download the Portal Best Practices Whitepaper

Roguen Keller is the Director of Global Services at Liferay, Inc.

Good post!

Platform change is a tricky situation at best and certainly QAD IT dept has experienced wins and losses as we migrated from OpenText to Liferay. The vision and leadership pieces can't be underestimated but at the end of the day we really needed to execute in order to gain and maintain trust and build momentum.

We have put a lot of focus on defining our IT architecture for: portal, java, knowledge management and enterprise search and challenged the other business units to review and understand the benefits. While at the same time we (IT) have not tried to oversell one platform for everything.

Upcoming we will need to raise the bar to design and deploy a customer support site. This will have the greatest horizontal impact to date. It will be good to hear your views on moving toward a more comprehensive rollout as I know we need to mature to support the business requirements the next couple of years.