Modern workplace transformation: Think big, start small, grow fast

Companies everywhere are reassessing their workplace strategies. Topics such as digital transformation, new work, digital natives, productivity enhancement, user experience, and employee satisfaction are front of mind as businesses deal with ever-changing challenges and try to build workplaces that align employees with the corporate goals and vision.

The technology you pick and how you implement it are key to a workplace strategy. According to recent research conducted by The Economist Intelligence Unit and sponsored by Citrix, more than 80 percent of IT leaders surveyed believe that badly chosen or badly implemented workplace technology can have a negative impact on employee experience.

Source: The Economist Intelligence Unit

As more companies and organizations reassess and transform their workplace strategies and as employee experience becomes a key competitive advantage, getting the technology right is an imperative. But how can they ensure a successful transition to the modern workplace and what should they consider when planning for and execute their transformation?

Since joining Citrix in 2011, I’ve worked with hundreds of customers across a variety of verticals. My key takeaway from all those years? Customers are suffering because of complexity, dependencies, culture, processes, external factors, and legal matters. Compared to these topics, design challenges and technological issues can usually be fixed quickly.

Therefore, in this post, I’m not going to cover technical insights or do a deep dive into how to easily migrate your environment to a modern workspace. Instead, I’m going to focus on how to effectively execute large-scale business transformations and what, in my experience, has worked well and what you should avoid.

How to Build a Minimum Viable Product

I spent all of 2014 designing a Citrix Virtual Apps and Desktops platform for one customer. Why did it take so long? We were stuck in analysis paralysis. We made a detailed, low-level design that considered every configuration for an architecture that included two data centers. At that time, the second data center wasn’t available. Guess what? They still have only one data center. We also ran into many unknowns that required additional discussions and clarifications. Beyond that, we discovered a number of factors that led to delays and higher costs than the customer had planned.

Eventually, we decided with the customer to launch what’s in place today. We started with a minimum viable product aligned to the customer requirements. To be clear, a minimum viable product doesn’t mean low quality. It involves providing a product that includes only the most relevant requirements, not attempting to “boil the ocean.” Afterward, we made adjustments and extended the environment as necessary when we onboarded additional departments and use cases.

The results?

• The customer was able to launch the environment quicker than expected, which enabled the line of business to benefit from the new apps and processes sooner.
• At the same time, new requirements were introduced quicker because our Citrix team was able to focus on a subset of items for a limited number of departments.

Since then, my ultimate approach to success has been based on the “Think Big, Start Small, Grow Fast” approach.

Think Big

It’s important to have a comprehensive, big picture view. This enables you to design and build a baseline framework that will support growth and ensures you don’t have to completely modify the entire environment if the customer requests major changes. Returning to my Citrix Virtual Apps and Desktops example, you’d most likely design the access layer to allow an extension (e.g. GSLB). But is it necessary to specify user mapping details, site aggregation configurations, or delivery group settings for the second Citrix Virtual Apps and Desktops site? No. You can add them later.

To get a proper big-picture view, you have to have foundational requirements and a high-level design.

Start Small

Gathering requirements is essential for any project, but it’s even more important to prioritize them and to focus only on what’s most relevant. This enables you to start small, with minimum complexity. The more you want to achieve, the greater the dependencies with other technologies, teams, and processes. That means your risk of failure is bigger, and project delays are more likely. Even if your workstream is on time, other teams could cause a delay in your progress, as well. Think in phases, and get rid of as many dependencies as possible. Not only will this help you get started in a timely manner, it’ll ensure you consider requests only when they become necessary. Irrelevant requests might not be needed at all. Why waste precious time on them?

Grow Fast

You should aim to grow as fast as possible. If you don’t, the likelihood is high that the environment won’t fulfill the expected needs, which could lead to lack of adoption and acceptance. Stay engaged and plan all your small steps. Focus on your phases and increase the frequency of your iterations to support faster growth.

Continuous (but Small) Iterations

Workplace transformation projects are never really finished (or at least they should be ongoing). I’ve seen customers reduce the resources they devote to a project to a minimum once it’s rolled out. After all, they want to keep costs as low as possible.

At first glance, not putting additional effort and investment into the product could seem like a way to reduce costs. But after some time, the environment is no longer state of the art and needs a wholesale refresh. This is exactly why many companies face seemingly insurmountable challenges with the implementation of new solutions or products. The projects are usually so big and complex that even small changes can take ages to finish and the costs and efforts can be exponential and difficult to estimate, similar to a CapEx model.

As the diagram above shows, continuous small iterations make it easier to control and predict the costs and effort that go into an environment. You won’t have spikes, because the scale of change is limited. Instead of upgrading the entire environment at once, which often has an impact on connected systems, small changes have fewer dependencies and less complexity.

Additionally, small iterations enable you to fail fast, which is probably the biggest advantage to this model. With big projects, a failure might be noticed only after the rollout of the entire solution and could lead to significant troubleshooting or, even worse, architectural change. Continuous, small iterations enable the team to focus on problematic situations and the relevant components.

This is exactly what Citrix and vendors such as Microsoft are doing. With Citrix Cloud services, for example, we introduce a small number of changes at one time. This enables us to make completed features available without waiting on other project streams, ensures that the impact of a change is low, and helps us to react fast in case of an issue. Microsoft has changed its operating system upgrade model to semi-annual releases for the exact same reason. Major upgrades like Windows 7 to 10 are just way more complicated compared to smaller, semi-annual upgrades.

But does this approach apply to all kinds of projects?

The short answer is no.

If you aren’t facing the challenges listed above or if you have a small environment, I’d recommend that you continue with the processes and methods you’ve already established. What I’ve covered in this post is usually best for environments larger than 1,000 users, which typically have characteristics where a “think big, start small, grow fast” approach can increase efficiency.

Summary

Most of these recommendations should sound familiar if you have experience with Agile frameworks. I’ve seen many successful (and some failed) transformations in my career, and I’m convinced that while big transitions make you think big, they also require you to act small, though continuous iterations that help you grow fast. And while I’ve given you guidance on how to do this, your organization has to have the right culture and mindset in place to execute.

Thanks for reading, and a big thanks to my colleagues Robert Wölfer, Michael Roog, and Sarah Steinhoff for helping me to shape this post. Connect with me on Twitter at @petrovicsasa, and please leave your thoughts in the comments below.