The deployment process plays a critical role in the rollout of a product and builds a necessary base for its success. Deployment consultants work closely with clients, learn their processes, and implement the product with all the specifics in mind. Consultants deal with many common challenges, which could lead to compromised deployment results or, in the worst-case scenario, a complete failure. Often these challenges are due to mistakes made either by the deployment consultant or the client. Today we’ll discuss these mistakes with Natalia Cherednikova and Brett Bellon, who are both deployment consultants here at Wrike.
What is the ultimate goal of a deployment?
Natalia: The ultimate goal of any deployment is to build a platform and base for successful implementation. This is not only for products but for new processes
Brett: We want our clients to be happy with Wrike. To do that, we aim to lead the client to a successful configuration that will scale long term. This can include teaching how to think about project management strategically, and training users how to logistically achieve such success using the platform. The short answer is: It’s all about how to think through configuration decisions, build out the infrastructure, and then utilizing the platform.
Is it possible to use the product efficiently without deployment? And if yes, under what conditions?
Natalia: I don’t think it’s possible. We can talk about deployment handled by an external consultant or team. Or if, for example, a client for whatever reason refuses to purchase an external consultant’s time, someone on the client’s side will handle that deployment anyway. So the success of the implementation of any product is in the rollout. It’s in how the team is introduced to the new product, to the new system. And it doesn’t matter whether the deployment is being done by someone external or internal. In the end, a time frame will be dedicated to familiarizing clients with the new product, procedure, habits, and then getting the team on board.
Brett: I’d say it’s possible, especially if you have experience with similar tools previously. But an analogy I like is that even if you’ve used PCs before, there’s still a learning curve to switch over to macOS. And if you’ve never used a computer before, macOS is still relatively intuitive for anyone with software experience, but the more help you can get from someone with experience, the better and faster the onboarding experience will be. So it’s doable but is significantly more time consuming to teach yourself that new language, and Wrike is almost like learning a new language. It’s always going to be a better experience having a tutor with years of practical experience than trying to figure things out on your own.
What are the common reasons for deployment failure?
Natalia: Number one is choosing the wrong product initially. This is a global mistake. What’s the reason? For example, one person in the client’s organization was responsible for purchasing the solution, and then they delegated the deployment to someone else. The person handling deployment could lack the necessary information about the product and demand of using it in the first place. It could also be the case that the product had been purchased because there was a budget remainder at the end of the quarter and had to be spent. Sometimes the clients also think that if they purchase the product, it would solve all the company’s problems with the wave of a magic wand.
Brett: Not asking enough (or the right) questions can be a challenge. We need to understand enough of the big picture of what our clients are doing to be able to anticipate future roadblocks and challenges. Another is keeping clients accountable and moving. Our deployment leads typically have full-time day jobs competing with the deployment for their time and attention, so making sure we hold them accountable and push when needed can be tough at times.
What are the common mistakes clients make during the deployment process?
Natalia: The first one is the wrong choice of the champions, or people responsible for the rollout of the product. It could be the case that the people don’t have sufficient influence in the organization. They could lack the necessary knowledge about the company’s processes. They could simply not be tech-savvy enough. Another common mistake is making the wrong evaluation of necessary resources — time and money — required to implement the solution. For example, a great champion who has a great understanding of the processes, all the necessary skills, and influence could be selected to drive deployment, but lacks the time to manage it.
Brett: I think it comes down to clients wanting something built out, but not committing the time and energy. Wrike can operate incredibly flexibly from basic task-based management to complex campaign and portfolio management. Often clients want something complex, but it takes time to build these more complex use cases. The more data and analysis you want to be able to pull out of the system, the more you need to build into it. There’s a balance point between simplicity and granularity that a lot of clients struggle to find, which is where our deployment services can really help.
Beyond the configuration issues are also typically change management concerns down to the end-user level. Data out is only as good as data in, so we need to ensure we explain to our users the importance of using the platform properly, or we’ll never be able to get the value and benefit out of it that we want. This leads to a need for successful training, governance, and process and procedures that can be skipped over when not thinking holistically about the entire life cycle of the platform without a proper deployment to guide you.
But there are lots of other things that can lead to a lack of success: clients getting lost in other work and not prioritizing the configuration, not understanding processes they’re trying to build out or not having the right people involved, team members not buying in, etc. Typically our consultants are able to identify these challenges quickly however and adjust accordingly, but it can require a change from the client as well.
What are the common mistakes deployment consultants make?
Natalia: I’d say they sort of mirror the ones the clients make. The first would be the inability to raise a red flag if the wrong champions were selected on the client’s side. They can be reluctant to honestly tell the client that it’d cause problems and should be addressed. Another is the lack of ability to demonstrate the necessary flexibility and keep up with the client’s speed. The client may have overestimated their ability to finish everything quickly and not have enough time to go through all the stages of deployment according to the schedule they originally agreed upon.
Then the consultant should discuss the situation and adapt the plan by increasing the deployment duration. Or, on the contrary, when the client is moving forward quickly. They could’ve finished the initial setup during the trial period and move forward with the advanced steps. In such a case, it could be a mistake from the deployment consultant’s side to insist on sticking to the original plan no matter what. So flexibility is a big thing. And even though we do have best practices, every client’s situation is unique, so we need to take the time to understand their resources, demands, and potentials, and update our plan.
Brett: That’s a great question. I think that every good deployment consultant will make mistakes and continue to make mistakes. The important thing is to learn from those mistakes and try to improve constantly no matter how long you’ve been doing it. I think that the common ones we typically see from newer consultants are falling back on product knowledge and being more trainers than consultants. There’s a fine line between training and consulting; there’s a lot of overlap. In both situations, you’re teaching and helping somebody build something out and how you use something. And I think the difference is giving recommendations versus giving options. As consultants here we do want to give options; I don’t necessarily want to force the client down a specific route of how they use the platform or how they run their projects.
But our job is to understand their use case, what they’re looking for, and how they do their jobs, and then recommend the pros and cons of each decision and our preference between these options. I think at the beginning it’s very hard to be confident in these recommendations as there are so many different Wrike use cases. Knowing the long-term ramifications of the decision that’s made early on can take experience. So I think an easy mistake is falling back on that product knowledge and being more of just an “I wanna help teach you and train you,” and not as much of the consulting on how I’d go if I were in your shoes. I think that’s the biggest strive any consultant can work towards.
And how, in your opinion, can you start distinguishing that line between training and consulting?
Brett: Well, I say this to most of our new consultants: The second you start working with a client, forget about working for Wrike and imagine that you work for that client. And it’s your first day working in your client’s office and they’ve hired you to help them with work management. And now you’re coming in and you’re trying to ask questions on what is it that we do, what is it that we need, what are we doing right, and what are we doing wrong, and then you work towards trying to fix it.
That’s kind of the mentality that needs to happen. I think getting there does require some comfortability with the product to be able to start acting like that. I think more specifically though it’s understanding the use cases and being comfortable with keywords, and doing enough research and homework to know the ramifications of those decisions long term.
Thank you! That was very insightful!