AMA: Deel Team Lead, Salesforce Development, Bridget Hudacs on Stakeholder Management

1. Work with a sense of urgency. If a project can be completed quickly (no downstream impacts), then get it done. Those little projects build a lot of goodwill. 2. Communicate clearly and often. Perhaps that's weekly or monthly meetings to align on current/future projects. In addition to touch-base meetings, I like to use Confluence dashboards to show where a function's work is in-progress so those stakeholders have a centralized place to get simple questions answered. 3. Don't play favorites. Any stakeholder working with me or my team knows that the same cross-checks will be made for their request as with anyone else's. 4. Be a resource. Be available for questions. Give insight into the process. 5. Own your mistakes. If a deployment had unintended impacts on a function, apologize and correct it quickly. If you misquoted a timeline, acknowledge it and work with the function to get the project on track.

First, when I look at ownership, I look at “who is accountable for the success of the solution?” If there is a conflict, I ask a few questions of the group to determine ownership: 1. What is the problem we’re trying to solve? 2. Who is most directly impacted by the outcome of the decision being made? Who is the CEO going to call if the solution goes sideways? For example, when streamlining a manual process for sales, there are several problems to solve: * Identify the important information to capture in the process * Ensure automated data is captured and attributed accurately * Enforce adherence to the process * Ensure automation works as expected Each of these problems could be owned by an individual department — or by the same department. By identifying the areas of accountability - and asking for accountability - it is easier to iron out which department should be responsible for aspects of a solution, versus one area owning everything.

* Agree on the in-scope and out-of-scope elements for the project with the key stakeholders. * Set clear responsibilities and timelines for in-scope project outcomes. * Identify dependencies so the team knows how adjustments to timeline impact the project as a whole. * Set up a regular communication cadence related to the project (ie weekly updates) to ensure that deadlines are met and expectations are managed. * Hold the team accountable for communicating and completing their areas of responsibility. Stuff happens; the only time it’s a problem is when the team doesn’t know about it to plan around it.

1. Value Stream Mapping, especially documenting the current state, is an invaluable tool to identify key stakeholders for the project and to see the work required to create the future state. 2. Once key stakeholders are identified and the current and future states are mapped, hold a scoping meeting with all stakeholders (functional and technical). * Document the decisions related to in-scope and out-of-scope elements for the current timeline. * Identify who is responsible for the in-scope elements and the delivery timeline. * Keep the document in a centralized location where it can be referred to by all stakeholders. With those 2 tools, you can: * See who is impacted by the changes (whose feedback to incorporate); * What the agreed scope of work is (whose feedback to "ignore"/save for a later project phase).

Whenever possible, have all stakeholders in a scoping meeting to agree on the project fundamentals: 1. What is the problem that we're trying to solve? 2. What is in-scope for developing the solution? What is out-of-scope? 3. What are timelines for delivery? 4. Who is responsible for various aspects of the project - and what are the agreed delivery dates for those elements? These elements are documented and put in a centralized place. They're referenced at every follow up meeting. And, if there are adjustments to scope, those adjustments and their impacts on timeline are addressed with the group.

I typically defuse tense relationships with clear communication and a little humor. For background: I've inherited historically tense relationships and, in listening to the complaints or assumptions made by the function, identified the issues that require increased communication. These issues are almost always related to actions by my team that increase work for their teams or reduce visibility into areas where their team has oversight. Once those sticking points are identified, I make it a point to improve my team's process to minimize those issues. Whether that's: * Communicating changes/additions to fields that may impact integrations prior to the work being completed; * Coordinating projects to ensure that all teams are able to manage the change together; * Ensuring that the right stakeholders are at the table during project planning. Notably, in repairing relationships with some functions, you may increase tension with other functions because suddenly those "simple changes" that were handled quickly require more coordination. I also ensure that my team -- and functional areas working with us -- know and understand that a process is not improved if it solves 1 problem, but creates 10 more somewhere else.