8 months into a 10 month automation project is a terrible time to discover that the Wi-Fi coverage is spotty, one of the proposed routes conflicts with a zombie project begun 5 years ago, and maintenance has concerns about being able to support the system.
The biggest danger to a smooth automation implementation isn’t technology failure, buggy software or challenging brownfield warehouses. A lack of stakeholder buy in will sink a project faster than almost anything, as the people needed to fix the issue are often completely out of the loop. Setting an implementation up for success has as much to do with securing early buy-in from key stakeholders as it does with selecting the right technology.
Why is stakeholder alignment important?
Any project will have better outcomes when it begins in a place of consensus; we want all the oars pulling in the same direction, everyone on the same page, the team in lockstep, etc. We have so many metaphors for this concept because it’s so important to almost any human endeavor. This blog is not designed to support the idea of consensus—it’s to provide some ideas of WHO these stakeholders are, and why they are important.
Executive Sponsorship
A good starting point is an executive sponsor. Transformation is an act of creation, and creation can be a messy business. An executive sponsor can provide air cover for the internecine struggles that inevitably arise, as well as calling balls and strikes as the organization revamps workflows and settles into a new routine.
A mandate to automate is a key component to the process an executive sponsor often provides. This should be a clear, unambiguous statement that gives the many departments and teams from within the customer organization and without a North Star through the process.
What is a project champion?
While executive support is critical, there is no person more important to the long-term success of an implementation than the project champion. This is the person on the team who is going to be overseeing the day-to-day of the project both during implementation and after go live.
The product champion needs to understand how the automation will do its job, what to do if there is a problem and how the implementation will affect adjacent processes. They should also be instrumental in assembling a multi-disciplinary, cross-functional group, which we will call the project team.
Who should be on a project team?
Depending on what the implementation is designed to accomplish, the project team will look very different. However, it should include every vendor, the project manager, operations, IT, etc. Anyone whose workflow will be touched by the automation project should be included and kept in the loop.
In general, assembling this team early is considered best practice. The nature of the team will uncover challenges sooner and find solutions more easily. The IT department may be aware, for instance, of dead areas in WIFI coverage that will need to be addressed. When this is discovered early, it’s a simple fix with plenty of time. If it’s discovered later in the process, it might still be a simple fix, but it can stop the work dead in its tracks. This team is designed to avoid those kinds of issues.
What does the project manager do?
As critical as the rest of the team is, the project manager is the nexus of all information, and as such, is responsible for keeping the trains running on time. This typically means liaising with vendors, internal teams and others to keep the project running smoothly and ensure it’s completed on time and within budget.
A great project manager, either working with a program manager or without, can make a rough road smooth and keep the smooth road from turning rough. Ensuring necessary resources are available at the right time, creating red lines and easing decision making are just a few of their responsibilities.
The Team in Action
Just like every implementation is different, so too is every project team. This is as must be; each team must have the requisite members to overcome the inevitable challenges. So why create this team so early?
Buy-in, for one. Teams that find themselves thrown into a project at the last minute, long after they could have materially assisted, tend to be less enthusiastic. Seeing the suboptimal result of decisions that could have been made with more information and being asked to address them (without the aid of a time machine) can be disheartening.
But, aside from buy-in, having a project team assembled and working earlier means a smoother implementation and a better result. The most dedicated integrator or vendor will never know a facility like the folks who work in it every day. Their institutional knowledge is invaluable, and together with other experts, set up an implementation for success from the very beginning.
For more information about how Rocrich handles implementations, check out this longer guide to building a project team or contact us for a discovery meeting.