Margin Of Error: Why Do We Care?

AssumptionsRuiz

While I was working on a project, it was determined that we must perform a specific equipment configuration. The problem we ran into was the additional stakeholders that were required for that task to be completed successfully. We had a need that was a requirement but we did not consider the external stakeholders that would create a threat to the deadlines we were predicting. A Service Level Agreement was missing in order to get those stakeholders to meet our needs. It was vital to our successful implementation goals and for our customer satisfaction.
As the project progressed there was a lot of pushback as we opened trouble tickets with those WAN service providers. Their fulfillment was not sufficient for our needs. However, for their normal business process and mandates, there was a margin of error that was acceptable for their business needs. What do we do now?

 

At that implementation intersect with our discovery that we had failed to consider our external stakeholder needs, we postured and argued our stances. Some of us demanded that we are the customer and as a service provider, it was their job to make us happy. However, what about the time, money and resources that it was going to take to meet our demands? Who would compensate for that extra time when we, the customer, are having an impact on their revenue and expenses?

 

It became a mad scramble with upper-level management arguing their stances. As the single point of contact Wireless Network Engineer, how was I supposed to drive this project towards the milestone targets when we failed to engage key stakeholders? As the service provider argued their stance with their margin of acceptable errors, I argued that our equipment would fail if our requirements were not met. As every trouble ticket was closed we opened new tickets to gain their assistance with solving the problem. The additional assistance came from their network engineers that were noticing alarms at rapid rates because I chose to turn our equipment on despite the risk of customer dissatisfaction.

 

At some point after that, the powers that be came to an agreement of how to meet our needs. Our timelines slipped but as a group, from network engineering to field engineers we scrambled to complete the mission. Some of the WAN stakeholders were resentful while our management marveled. However, one of the lessons I learned through that failure was the benefit of conveying that you understand why they are so upset. When we can sympathize and empathize with their problems and their vehement consternation, we can be surprised with how those same people can become your ally. Not because they agree with you, but because they feel heard and understood. In turn, the reciprocity choices from cross-functional teams can surprise us and help us with successful project goals.

 

2607-character

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s