Guest post by veteran eCommerce leader, Scott Rademaker. Scott has some unique insights into how to manage internal and external teams, determine priorities and get your project launched.
I have been in the technology industry as an engineer/developer/programmer, scrum master, and product manager for quite some time, as well as having managed product managers. The common thread that runs between all of my experiences is digital transformation. From selling downloadable libraries or executable files for sales enablement to moving a print focused business into the digital world, I have had my share of both great and challenging experiences. I say that because, while having met some great people along the way, there have been times where the challenge wasn’t the technology. Instead, it was the 'business', keeping it on track while educating stakeholders about why digital transformation was needed, and what it would take to get there.
Business stakeholders can often be a mixed group of personalities. Some are technically adept, while others are not. Some are more creative and love the customer experience and don’t care how the sausage is made so long as it is delivered on time! Others get caught up in the minutia of security, legal contracts, and other compliance related requirements and gum up the entire process causing it to come screeching to a halt. And the rest meet at the beginning of a project and you don’t see them until you have shipped the product. So, how do you go about managing all of these different types of stakeholders at the same time, if that is needed?
Change management - You have to ensure that all communication regarding shipping new code, rollbacks, shift in priority of features, etc. is sent out and understood. Email, Slack, intranet, etc. can all be used. But you don’t want to cc the world, right?
Starting out on a project with multiple business stakeholders can seem daunting but it can be managed if you ensure that the necessary parties are included in your communications. Who is necessary? I have used a RACI chart in the past and have found it to be one of the best tools to accomplish this. At the kickoff meeting (and there should be a kickoff meeting), it must be determined at that point, or very shortly thereafter, who belongs in what column on the RACI chart. The entire chart itself doesn’t need to be completed as some items may take some additional discussions with regard to development teams and structure of those teams, but you should have a decent picture at this point.
Determining if your development resources are strong enough in-house or if you should run through an RFP process to bring in a vendor will depend on several factors - budget, skillset, goal of project, etc. I have seen poor decisions made by business owners for very simple reasons - former teams they have worked with, friends, etc. Other times, decisions were made based on lack of trust towards the internal team to determine the right path simply based on level of seniority.
Suffice it to say, once a bad decision has been made, you won’t see the result until it is too late. I was on a project some time ago and my manager made it their point to be the sole decision maker in selecting an outside vendor to bring the business into the digital world. This manager had no trust in the existing technology and product teams regardless of the feedback based originally on this manager’s requested evaluation.
While I can't get into details, I can say that one year and a few months were wasted due to the vendor's eventual inability to deliver. And this was the time when I was fortunate to meet with Slatwall Commerce, who eventually came in and allowed us to pivot in 6 months, and achieve what we could not achieve previously. I learned a lot during this critical moment. Not just looking back but looking ahead from that point, I failed in some areas of stakeholder management and excelled in building products.
Although the project did eventually succeed due to hard work and patience by Slatwall Commerce and members of the internal tech and product teams, it was still a valuable lesson in how to manage stakeholders properly.
Everything was green lit! We shipped and went live. Nothing worked! No one could understand why. Eventually, it was discovered that a certain configuration needed to be done on a fulfillment part of the overall system. The stakeholders who were supposed to have made that change in the production environment - never did. It was a disappointment to say the least, and I didn’t manage it well and while it was something they failed to do, I didn’t take ownership of the overall failure and I should have. Sometimes it’s not just about team updates or communication protocols, it can be the ability to focus on the specifics, managing relationships and setting expectations.
This is something, I believe, you can only learn over time with experience. You can be great at what you do, and be passionate about your mission and role, but if you don’t take the emotional investment and attachment out of achieving your goal, when you fail; it will be that much more difficult to learn from it and your relationships with your stakeholders will suffer.
So, here’s a tip when dealing with stakeholders - they come in all different varieties, so get to know them, if possible. Educate them in your processes. Keep up the communication and be consistent. And finally, get out in front of whatever you might see as a potential hazard, even if they are that hazard!
Amidst the management of stakeholders during a digital transformation project, there's also the vendor relationship, and other team member relationships you need to manage. It’s a balancing act. There’s cost, timing, code management, planning, grooming, etc. Multiple and sometimes parallel paths of development are usually the norm in any large scale project and this is where setting expectations is crucial. Again, the RACI chart can be used, and I do use it, but you may have another tool and that’s fine. But, you must have something. Email won’t cut it. Slack won’t cut it either.
At some point, you’re going to come to an understanding that not every item in your deliverable list will be achieved and so you need to shoot for the 80/20 rule. There will be stakeholders who believe an item in the 20% column should be moved to the 80% column and there will be developers who will argue that it can’t be done even if it is in the 80% column…. So what does one do? Well, this is where transparency and listening comes into play. Bring everyone to the table, ensure they are all on the same page, and come to an agreement. That’s a very short description and probably too simple of an explanation of what could take weeks to iron out - and I have been in this boat - but that’s the only way to move forward.
Digital transformation doesn’t happen overnight. And one’s ability to manage it well, execute on time, forge strong relationships with stakeholders and other team members, vendors or internally, takes time. There will be failures but there will be successes as well. You just have to be able to learn from mistakes - think in terms of it being a retrospective about yourself - and keep moving forward.
Lastly, I have been in this industry for almost two decades, and what I have come to realize is the following and it’s my main rule and play book:
Learn more about Scott Rademaker