Architect Tales: The Misassignment Problem

[Robert Fedoruk]

The following was originally posted to my exclusive ServiceNow mailing list.  If you enjoy this content, see what 800 other ServiceNow resources are reading every week.

It came about as project's usually do.  "Something is wrong here" followed by proposed changes.  Project sponsor passes them to development team.  Today, it was a problem with assignments.

"There's too many wrong assignments" someone said.  

"And its the Helpdesk's fault" said another.  Others blamed frequent re-orgs creating confusing sprawl of assignment groups.  Still others blamed too wide a tech portfolio.  And then the solutioning started.

- "Lets add a choice field with ways a ticket was reassigned &  force population before close!"
- "Lets add a checkbox people can use when they detect a misassigned ticket"
- "Lets build a rule that auto-routes based on category"
- "Lets train an AI to suggest a group"

Before you know it, a PM is assigned & project plan takes shape.  Can you spot the problem?  Stakeholders are right & wrong simultaneously.

HOW THE STAKEHOLDERS ARE RIGHT

"The customer is always right".  True but lacks nuance.  Customer intent is always right.  They want for rational reasons.  The customer's specific request is *not* always right.  The architect's 1st job is fully understanding intent, which is almost never explicitly stated.  In this situation the stakeholder's intent is to improve customer experience by reducing time for tasks to reach correct teams.  They are also "right" in that they've proposed viable solutions to the problem.

HOW THE STAKEHOLDERS ARE WRONG

The stakeholders outran the problem.  They went from gut feel to multiple change intensive solutions while missing a critical step:  quantification of problem.  Why is that necessary?
- Project Legitimacy:  Are the gut feelings are right?  If so, how big is the problem?  We have finite resources & several projects in flight.  Is it worth stopping for?
- Success = Change in Pain Experienced:  We could deploy any of the 4 solutions, but how would we know what worked?  Did it work enough?  There are many ways to measure success, but in this case, success is exclusively reduction in bad outcomes.  We must know how to measure bad outcomes first!

SERVING THE STAKEHOLDER

Clearly we don't leave the stakeholder with nothing but a critique of their approach.  We convinced the stakeholder that Step 1 was quantifying the problem.  With ServiceNow's red hot Performance Analytics tool, we assembled a set of indicators that would objectively show us pain.  Once a baseline period was complete, we'd evaluate which proposed solution was easiest and see its effect on baseline performance.  The stakeholder was *thrilled*.  We *understood* what they were after, and we set them on the right path.

ARCHITECTURE AND GOOD DESIGN

Meditate on the different things each role maximizes.  Stakeholders provide direction but only articulate their requests in a context they know, but they don't have a bigger picture.  Their intent  must be understood, not their specific suggestions.  Developers aren't politically positioned to authoritatively dictate design.  The good ones *DO* anyway, but politically they can be pushed over a lot easier.  The architect alone is paid to consider design first & foremost.  Embrace it brothers and sisters, because the ground is shifting.  More customers see ServiceNow as a top 5 strategic app.  There will be stronger expectation to design and build *carefully*.

SPECIAL BONUS:  PA BUILD

We built a new Dashboard for this initiative along with new Indicators:
- Incidents with more than 2 reassignments (based on assignment count)
- Incidents with more than 2 reassignments missed SLA
- Time to resolve for Incidents with more than 2 reassignments
- Text analytics on indicators to see if different keywords were trending

.... as well as some others but you get the point.  We were measuring negative outcomes on top of a negative outcomes (more than 2 reassignments).  Also, I'll cover this in another post or video: since we had more than 3 Indicators with extra conditions (more than 2 assignments) we also created an Indicator Source for that scenario.


Do you need help with maximizing good outcomes or minimizing bad ones on ServiceNow?  Reach out to me on LinkedIn or Twitter.

Good design needs you to be sharp and alert.  Start your day with Groundshark coffee and build like you mean it!

Extra special bonus

Maybe you read this and thought about how you want to take reporting to the next level at your organization. Maybe you have external stakeholders you're accountable to. Maybe you need better story telling capability than native ServiceNow has. Maybe you're tired of massaging everything in PowerPoint after a ServiceNow export.  If that's the case, you need to check out what the guys at Vividcharts are doing.  Tell them The Duke sent you.