Align Your Stakeholders
Ultimately change is about people and the more actively you engage stakeholders the more prepared you'll be for the evitable bumps that come with change. Stakeholders may be different than your project team; they are the folks who will be impacted by and benefit from, the platform. While many of your stakeholders were at the table during the buying process, there are likely additional stakeholders at different levels of your company (hint: end-users of the platform) who you'll want to make sure are part of your team.
Tip: challenge yourself to bring on stakeholders who represent the diverse backgrounds and perspectives of your company. This will help with user adoption in the future.
Align on Your Why
This may seem a little too existential for a software implementation, but understanding your WHY gets us to a better HOW. WHY is not about technology....technology will just make delivering on your vision a whole lot easier! With this, we recommend that you do this away from technology and perhaps even go analog to a whiteboard (virtual counts).
What problem are you solving? Who does it impact? How will it make an impact? What does NOT going through this change mean? (yes, change means disrupting the status quo). Why is this change important? This is what we call the Toddler Phase of change; asking a lot of questions, perhaps being a little annoying with your team, but ultimately getting to the root of your WHY.
Tip: get your stakeholders to answer these questions independently and then come together as a group to discuss. This minimizes Group Think and ensures even the quiet ones are sharing ideas and perspectives. Explore similarities in ideas and really poke into differences.
Disclaimer: the amount of time for this discussion is proportional to the degree of change. If you are a small team, it could be 1 hour. If you are a large team with multiple locations /processes going through a digital transformation, this will be multiple conversations over multiple weeks (and when you say multiple this much it's because this is a form of conversational math).
Establish a Vision
Now that you've had a great discussion, it's time to step back and make sense of your scribbling. This is where you establish a vision. Your project vision should be aspirational and focus on where you want to go as a team in the future. This will be your guiding light as you go through your implementation. It will also help with how you communicate the corresponding launch and integration of the platform solution into your company.
Acknowledge and Understand Resistance
Change typically comes with some form of resistance. It can show up with, "this won't solve things", "users won't do it", "you didn't include me, so I don't like it" (although that one usually isn't articulate quite that directly). To understand where the resistance is coming from, ask yourself: do Resisters align with your vision? If this the answer is yes, then help them focus on the common goal. If the answer is no, why? Does their perspective change anything in your vision? If yes, great perhaps evolving your vision is necessary. If the answer is no it doesn't change our vision, then having a direct conversation about the WHY is needed.
Tip: Don't shy away from Resisters. Understand them and have conversations to understand their perspective. The earlier you do this the better.
Define Your Processes
Technology makes adherence to your company's processes easier. With ease comes better data. With better data comes better insights....you can see where you're going with this! Our Resolver Project Team will share industry best practices on processes, but we always recommend that you go through an internal review first.
Tip: draw out how you would LIKE your internal processes vs. how they currently are. There is no time to improve and ideally simplify your processes than when you're going through a change.
We can't stress simplicity enough! Simplicity facilitates end-user adoption. It also minimizes the barrier of training and administration in the future. Ideally, you can get to the point of standardization across teams and locations. In doing so, you'll remove silos and have the opportunity for really meaningful data and insights.
If you have different business units, usually from different locations (countries), sometimes this isn't possible. Aim for consistency vs. uniformity. This means that the overall objective is the same, but there is room for a difference in flow.
Iteration
Some software implementations use the "waterfall" approach. This meant go get some requirements, go away and do work, come back a few months later and hope there is no broken telephone. You can imagine the margin of error that creeps up--and that's not fun for anyone! Having your project team understand the iterative approach can help align both your stakeholders and resisters.
Our approach is iterative which means that we work beside you in short sprints: design, configure, test (with you), feedback, improve (if necessary), repeat. One of the key benefits of this approach is that we can learn more about your WHY and the vision you're tracking towards through our platform. If not we're not hitting the mark, we can easily make the micro-correction.
The Resolver Project Team is here to help you through the change. We have a lot of learning and best practices to share! That said, the journey of change starts with your WHY.
Assembling the right team is a large factor in ensuring a successful project. Here are a few roles and responsibilities you want to think through as you begin to get your team ready for the project.
Executive Sponsor
Identify an active executive sponsor who will ensure that your project goals are aligned with the overall organization strategy and that you have access to resources and support from the senior executive. The Executive Sponsor does not need to be involved in all the meetings but a key to success is ensuring they are provided updates throughout the project's lifecycle.
An all too common problem we see is Executive Sponsors not being updated regularly and we find out too late in the project that the Sponsor and Lead's decisions are not aligned. We then need to go back to the start of the project to make new changes which results in more dedicated time from the business team to retest and retrain as well as leading to a poor customer experience.
We recommend:
✔️ Include Executive Sponsor on the project kick-off meeting. This ensures the project team is aligned on their goals and priorities for the project and what success looks like.
✔️ Update Executive Sponsor regularly. The Project Lead should book dedicated time with the Executive Sponsor. The objective of the meeting is to align on key decisions and project updates like budget, schedule, and resourcing. Is the Project still on track? Is it still on budget? Do we have the right resources and SME's? Is there anything internally stopping the team from meeting the project schedule?
Project Lead
The Project Lead acts as a single point of contact to manage and coordinate internal resources for the day-to-day project execution and decisions. We find the most successful projects are lead by more of a functional lead, someone who has dedicated capacity to work on the project and ideally has experience in leading projects before. For larger projects, it can be common to see projects lead by a Project Manager from your IT department.
One of the most common mistakes we see is when a Project Lead has too many projects on their plate and they cannot dedicate the time to ensuring the team has what they need to keep the project moving. This means the project risks being put on hold and we end up repeating application overviews for new team members which eats into the budget and causes schedule delays.
We recommend:
✔️ Dedicated Project Lead. Ensure the Lead has time to work on the project and isn't already overloaded with Projects.
✔️ Communicate with the Executive Sponsor early. If a Lead feels the project is slipping because their time is limited, let the Sponsor know early so they can help deprioritize other projects or responsibilities internally or can quickly allocate a new lead to the project if necessary.
Business Subject Matter Experts
The Business SME's role is to have intimate knowledge of use case requirements to provide critical input in making decisions and validate project deliverables. This team will be on the project from start to finish and will be the people actually using the application after go live. They will be responsible for testing the application and ensuring it meets their organization's goals as well as ensuring user adoption after go live. They will be the go-to team helping answer questions when the application is live within the organization.
We recommend:
✔️ 3-5 Subject Matter Experts. When we have too few SMEs there is a risk of a single point of failure. That expert becomes inundated with business priorities and can't dedicate time to keep the project moving. As a result, new experts are brought in too late and a lot of the work needs to be repeated. Any more than 5, there is a risk of too many cooks in the kitchen. We have too many opinions and the project calls become unproductive and results in many takeaways and the project stalls waiting on decisions.
✔️ Differing expertise and experience. We see success when we have a broad range of expertise. Newer team members bring a differing perspective to existing processes and can help simplify and challenge the status quo.
The most common question we hear is "Can we start on anything now to get a jump start when we sign?" The answer is "YES! Data." Many of our customers have their data in a few different places so it's important to take the time now to make sure you have the latest information. We find customers have an easier time understanding and following the application when they can see their own data in it. Having the information upfront as we begin the project means you can start seeing it in the application sooner and we potentially decrease our project timeline and as a result, we increase time to value.
Here are some questions to help you get started:
- Where is the data located? It is in a central location or dispersed across the organization?
- Is it relevant and does it need to be in the application?
- Is it the latest information?
As we embark on this change together, think of us as your guide. We've walked the path before and have the badges and bruises to show for it! Your Resolver Project Team will focus on the following our partnership with you and your team:
- Share best practices: Over hundreds of implementations and many consultations with customers ranging in size, complexity, and location. We've helped bring visions to life.
- Be the challenger. Many customers build based on what they're currently doing. We'll challenge you to look forward: Could we simplify? Could we think about processes in a more streamlined way? Again, based on our experience with best practices we can help you.
- Engage in radical candor: We care about you (and your results), so we will be direct. Made famous by Kim Scott and part of Resolver's culture; we believe in honest conversations. While challenging the status quo can feel awkward at times; awkwardness is temporary, so we'll speak to the issue rather than around it. If there are times were we have conflicting perspectives, assume positive intent. Assume we are engaging in candor to deliver on the greater vision.
- Have fun: we spend a lot of time doing work, so why shouldn't it be fun? Many of you have "Resolver Project" as an added item on your to-do list, so we want this to be something you look forward to. Plus your brain is more open and creative when you're having fun (there's science in there) and that tends to lead to better results.