Solutioneering: Serving the Citizens

Some of us excel at hardware, some at software, some shape services and others products. Some work with data; some with people.  Some call B200 home, while others range the health campus at large.  Regardless of whether you build or buy, type or talk, code or call; everything we participate in is to further the success of those we are accountable to serve - your fellow worker, those in and around the entire health system, and the Citizens of the State of Michigan.

The last category is the focus of this story.  Serving the Citizens of the State of Michigan is a direct inclusion from the MSIS strategy and is one I would like to focus on for this post; a start to a series of blogs that bring to light, what it means to be a “Solutioneer”.  It is not a job description.  It is not location or role, nor is it inherited through a line on an org chart.  It is not the fulfillment of a job description or a series of tasks to complete.  It is simply the everyday interaction with those in need where we can go beyond the walls of function, past the barriers of duty, and into the realm of service.  It is where we embrace that we have a unique opportunity to solve a problem - to provide a solution - where nobody else has been able, or possibly where nobody has taken the time to make a difference.

On May 19th, Sean Quinn, a representative for the Solutions Center on the service desk received a phone call from a Mother in need.  She had been trying to contact someone at the University of Michigan who could help her obtain free/low cost dental work for her un-insured child.  Sean sensed distress with the woman who had been trying to find anyone who could help her.  Sean understood that he is not an employee of the Dental School.  He also knew that he has no expertise in insurance matters and no knowledge of assistance programs.  But he possessed something of far greater value - a willingness to invest our resources in serving a Citizen of the State of Michigan.  

He made a choice.  He did not give the woman a number to call, send her an email,  text her a link, or wish there was something he could help her with.  He became invested.  

Keeping the young woman on the phone, he quickly asked his co-workers for assistance.  While he kept her posted and satisfied, they contacted the Dental School and received community resource possibilities and information about dental school programs that might be of use.  This first round of investigation yielded the fact that the dental school did had a program that could help but unfortunately the funds had run out this year and would not renew until July.  The child was in pain currently and waiting was not an option.  

Keeping the customer engaged and informed, he worked with the dental school, who suggested another option.  Following this through Sean set up an appointment time for her, only to be told at the very end of the process that ‘oh, there might be a $150 fee’.  Consulting the customer, he sensed that $150 might not be within the available budget and pursued a backup plan.  Not wanting to have the customer embarrassed in any way, but also not overstepping her right to privacy, he confirmed the appointment with the dental school while obtaining information on other community options and assistance programs that might be available at no cost.  This surfaced another clinic that did have options available at no cost, and another appointment was secured for her to have two options to pursue.  

Sean did all of this while staying on the phone with her through each step and keeping her satisfied and updated with the path he was taking.  

This woman was not an employee of the Medical School; she was not even an employee of the University of Michigan.  Sean does not work for the Dental School, nor is the Dental School part of the Medical School.  The University of Michigan did not end up providing the dental service or collecting funds from the customer.  

Let me be the first to point out that absolutely none of what Sean did is included in his job description.  

Let me also say absolutely all of what Sean did is the target for which we should strive.  

What Sean did helps to fulfill the mission of the Medical School, through the delivery of Services offered by the resources of the Solutions Center.  Our mission is to serve the people of Michigan by applying knowledge to challenge the present and enrich the future, and that’s exactly what Sean did.  

And that is Solutioneering.

Don't Be a Fragilista

One thing about a collaboration space is: you hear things not intended for you.  This can be good or bad.  About a couple months ago, I overheard Andy Brown make mention of the term "antifragile." I had never heard it before so I looked it up.  To my surprise, it is not yet a legitimate word, but rather the title of a book.  It just so happens that the author if the book, Nassim Nicholas Taleb, also wrote The Black Swan, which was a very eye-opening book for me.

So, I bought the book and started reading it.  Let me be clear -- this is NOT a book review.  This is an "idea review."  Once again, Taleb has found an important idea that seems to have fallen through the cracks of common understanding.  To fix this, he has coined the term "antifragile."  It is an important concept.

What is the definition of fragile?  I think of this as something that breaks easily under stress.  What is the opposite of fragile?  Most people would use words like robust or sturdy.  However, these words imply something that stays the same when under stress.  That's not really the opposite of fragile, which suggests that the subject of fragility will degrade under stress.

Therefore, antifragile things must get BETTER under stress.  Taleb gives us some examples and the one he likes best is nature.  When the environment stresses a species, it evolves and becomes stronger for it.  How does this tie back to what we do?  Well, we build systems (services, software, etc.).  How will they do under stress?  Will they just be robust and sturdy?  Or, can we make them antifragile?  Is it possible to build software and services that benefit from change?

It is the ultimate challenge.  One point about the species example -- although the species may get stronger from adversity, many individuals may suffer and even die.  In other words, individual sacrifices are often necessary for a system to be antifragile.  What sacrifices must we make for antifragility?  I don't have the answers, but one thing I do know: disruption is necessary.

Leaders often feel it is their job to manage the system to avoid disruption.  Taleb would call them "fragilistas."  These are people that remove the normal disruptions of an antifragile system only to cause it to be fragile in that, when it finally breaks, it breaks in a big and sometime irrecoverable way (think Alan Greenspan and the 2008 economic meltdown).  People who try to remove disruptive forces from a system always mean well.  This concept is very similar to one introduced in one of my all-time favorite business books -- Surfing the Edge of Chaos.  The idea is not to eliminate disruptions, but rather to build systems and processes that are responsive to a changing environment.

In the business world, responsiveness translates to increased profits.  At a medical school, it ultimately means better education for our future doctors.  What might we do to be more antifragile?  In the software delivery team, we can build solutions in such a way that data driven feedback suggesting that something in the process is not working optimally triggers changes that the process stakeholders can control without outside intervention.  In other words, we build things that allow users to adapt it to a continually changing environment.

Once upon a time, robust and stable applications were good enough.  Not anymore.  Now we need to build antifragile applications that allow users to benefit from disruptions.  This will likely require a rethink of the architecture that underlies what we do.  The same will be true for all of our services.  Architectures that benefit from disruption may not be new to the natural world, but they are brand new to human designed environments.  We've spent most of our history trying to eliminate disruptions, now we must learn to embrace them.

INVESTing in good stories

In April, we shared an overview of the User Stories element of the Michigan Agile Philosophy (MAP).  That post provided an overview of how stories use estimates, acceptance criteria and description to frame a discussion around work.

To help continue our improvement regarding story writing, here are a few things that might be helpful:

INVEST

A good user story uses the “INVEST” model:

• Independent. Reduced dependencies  = easier to plan
• Negotiable. Details added via collaboration
• Valuable. Provides value to the customer
• Estimable. Too big or too vague = not estimable
• Small. Can be done in less than a week by the team
• Testable. Good acceptance criteria

We've put together a one-page Invest tool that helps to walk through this model with some details and things to watch out for.  Print this out, keep it nearby and use it often when collaborating on stories. 

Comparing User Stories, Use Cases and Requirements*

The difference between user stories, use cases and requirements is one of perspective.  If we consider the work we are doing as affecting systems and their users, we see clear differences.  

• Requirements describe the work from the perspective of system operations - how do we limit the interpretation to be sure the system does what it should do. 
• Use Cases describe the work from the perspective of the users and how they interact with the system.  Use cases describe - often through text and diagrams - a call-and-response format of what a user does to interact with a system. 
• What makes User Stories unique is their focus on customer value.  They loosely describe  the specification in order to foster a higher level of collaboration with the team.  The acceptance criteria describes the more traditional requirements and use cases to be met, but secondary to the value of the customer. 

Stories != Requirements

A story is not a highly documented requirement of what the user wants, it's a reminder to collaborate about the topic of the user story.  The documentation is secondary to the collaboration.  Stories are just a tool to support underlying values of agile - just-in-time definitions and collaboration.  

Comparison Example

Problem Statement

The client has requested the ability to search for health care providers by provider specialty within a doctor selection site. 

Sample: Requirements Statement

The provider search screen shall provide the ability to search for providers by provider specialty.

Sample: Use Case

The client selects provider search.

The system retrieves a predefined list of provider specialties and populates the specialty list. The system displays the provider search mechanism.  

The client selects a provider specialty and initiates the search.  

The system retrieves a list of providers that match the provider specialty search. [Alt 1]

The system displays a list of providers that match the search. [Alt 2]

End use case

Alt 1:  If there are no matches, the system displays a message indicating that no matches were found.  End use case.

Alt 2:  If there are more matches than the user can view, the system will provide the capability to display multiple pages.

Sample: User Story

Title:  Search for providers by provider specialty.

Description:  As a provider search user, I need the ability to search for providers by specialty so that I can more efficiently refer patients to specialists.

Acceptance criteria:  

1. The provider search mechanism has the ability to enter a specialty.
2. The specialty search will have a list of provider specialties from which to select.
3. Searching via the provider specialty will return a list of matching specialists or a message indicating that there are no matches.
4. If there are more results than can fit on one page, the system will provide the capability to view the list in pages or sections.

So? 

User stories aren't inherently any better or worse that use cases or requirements.  It's the individual or team that makes the technique work.  However, within MSIS one of our core values is collaboration and the user story format incentivizes, prompts, and ultimately rewards the discussion around the work to be done.  We believe that user stories allow us to do things that align with our definition of success: (1) collaborate, (2) focus on customer value and (3) minimize non-value added work.  

Thanks!
Michael Warden

jwarden@umich.edu | 734-546-2929

* This section borrows heavily from a great post by William Nazzaro and Charles Suscheck of Process Synergy, LLC who wrote a member article on Scrum Alliance in April 2010 titled 'New to User Stories?'

Taking a swag at Resource Management and announcing a couple positions.

Preamble...
Recently, we created the Delivery team within MSIS which is a combination of the Solutions Center, Data Management Services, M3 and Software Delivery as well as the individual roles of Dan Stuart and Brett Miller. My direction with this team formation is with the intention to work on establishing three practices that are lacking in our organization. I'll be working with the various roles within Delivery to make progress on establishing resource management, capacity management and talent management.These three practices are part of my deliverables for the coming 12 months, starting with resource management.  This post focuses solely on resource management, though I'll communicate more about capacity and talent management soon.

The team of Directors that report to me will focus on the matter of resource management within the Delivery Program. As a team these Directors are not intended to be a day-to-day decision making layer of management over the teams of our program. I would like to exercise caution and be purposeful when creating leadership and management functions in order to ensure they are measurable. I will be sharing these measures with the broader group as they are developed, though in the meantime I thought it a good idea to share some of the decisions that have been made to date by my team of direct reports.

Why bother?

First I suppose it would be worthwhile to define what I mean by resource management. There are a fair number of opinions and approaches for resource management . For me, what is most important right now is to look at Delivery operational budget and staff as our resources and as a team of Directors come together to discuss the highest and best use of those resources. This would be a shift from allowing each individual director being self-deterministic about how prior operational dollars and staff positions were accounted for. In the past we would simply refill positions when vacant whereas now we will discuss 'what is the best use of those resources?' rather than presume refilling is our best option.

This developing practice is best aligned with one of our MSIS Values on rigor but it also is in direct correlation to how I believe the Delivery program should align with the overall MSIS Strategy and our objective to be a more strategy driven organization. Documenting a strategy and then shifting resources and focus to execute that strategy is the only way to make demonstrable progress.

What has changed?
This team of the Directors that report to me has met three times now to discuss resource management.

The first meeting we got together to start discussing our team, how we intend to proceed, and we reviewed the current state of the MSIS budget.

The second meeting was our first true resource management discussion wherein Jim Behm convened us and presented his plan for rounding out the Software Delivery teams. In that meeting we had an excellent conversation about the vision for the software development teams and how we would practically like to approach the hiring and shaping of them. This provided a good opportunity not only for Jim to solidify his vision but also share it with the Directors so that we could provide additional input and support. Some of that conversation informed Jim's recent blog post on staffing strategy.

This week we met for our third meeting Mary Hill , Gary Nichols and John Herlocher brought us together and discussed : DMS positions, Service Desk agents and the open database administrator position. We approved a new role for DMS for a data architect as well as two replacement service desk agents as Greyson LaHousse and Adrian Flynn are leaving the organization in June to pursue their dreams in various degrees. They both depart in excellent standing and with my well wishes. The DBA position we decided to hold back for additional considerations.

Epilogue... 
This represents a distinct change in how we are approaching available resources. In essence we agreed to shift dollars that were priorly invested in a project manager position for DMS into a data architect position and we agreed that we need additional data and options for how we may invest the dollars that were priorly allocated to an open DBA position. We approved the Service Desk agent replacement positions, but with a good deal of discussion on the Desk's current performance and where we intend to focus more on in the near future. I find it more interesting is that we are doing this as a team as opposed to me working one on one with each Director which I believe makes the process more credible and informed.  This makes the Directors more accountable to each other and the MSIS strategy which is important for us to be successful in our charges.

So now you know a little more about what is going on behind closed doors when the Directors in Delivery meet. I wish I could tell you that it was more like an Ian Fleming novel, but it is really just the nitty-gritty of making incremental changes quietly so that we can support our School more effectively.

I look forward to any feedback or questions you may have.

We Don't Need to be Best Pals, But...

Have you ever worked in a team in which everyone got along so well that you wanted to hang out together after work too?  Maybe you do now.  You just like everyone so much that you look forward to being together.  If you have been (or are) in such a team, you will also note that you were most likely highly productive.  The level of communication that can be achieved is hard to duplicate.

Sometimes there may be just one person that you struggle with.  They are never going to be your best pal...BUT they could become a pal somewhere on your list.  I learned a valuable lesson about this years ago.  At the time, I had become distant from my dad.  We were "estranged."  I was attending a communication workshop (similar to EST if you're old enough to remember that -- if not, watch North Dallas Forty).  As was prescribed, I had an epiphany: there were very specific things about my dad that were causing all the trouble.

The first thing I did when I got home was I called him and apologized for how I had treated him.  Then, I was totally open and honest and told him about the two things that I was struggling with.  I asked if we could avoid having those two things in our relationship.  I explained that if he brought either of them up, I would remind him that they were off limits and if he persisted, the conversation would be over.

We started fresh.  As a result, we became very close and we both gained from our renewed relationship.  I have used this technique of compartmentalizing issues many times since.  I find that once I accept someone's flaw(s) (as I see them) and agree to myself to work around it (them), a good relationship can, and usually does, ensue.  I have also learned that once I open myself up to a good relationship with someone, there is always more good than bad to be had by it.

It's not easy.  My emotions are always pulling against my will at first, but this eventually melts away and I can't remember why I was so resistant to making the effort in the beginning.  Sometimes, people have emotional characteristics that make it difficult to relate to them.  When that happens, I remind myself that if they are struggling with some emotional injury, expecting them to behave the way I'd like them to is no different than expecting a blind person to know what color shirt I'm wearing (pink today -- in case you happen to be blind or off-site).  Some people need some accommodation, but again if you compartmentalize, you will find there is more to like than dislike.

In the end, if you make the effort to build good relationships with people, they will almost always return the favor.  It may take some time for both of you and it may take more time for them than you (it usually does if you're the instigator).  Your patience will pay off in the form of more fun, less stress, and increased productivity.  And, you may just get a new pal out of the deal.

Keeping our Karma While Leaving Zendesk

Admit it, you've got the song
stuck in your head at this moment.

Zendesk is woven into the DNA of our Service Delivery Model. Because it is simple, it helps provide us with the discipline that we use to provide great customer service.  In addition, our customer satisfaction survey results tell a story that I don't think many in our line of work can match.

Customers respond to 40% of our ticket satisfaction surveys.  I want to put this into perspective.  A great response rate on surveys of this type is 15%.  Ours is nearly 3 times that.  This is a feedback channel our customers are using.  It's working, and we need to keep that.

98% of the survey responses are positive.  Here's a sample from just this week.

"I am grateful that your service is available to me when I needed it."

"I was very happy with the support I received. Brandon was persistent in solving the problem to see it to resolution."

"The service we received was excellent. It is so nice to have people come to the lab and get us up and running in a short time. Dan is great person to work with. We appreciate all the work he has done with us over the past year at NCRC."

"Excellent service/assistance in every aspect during that morning; thanks to everyone!!!" 

But the 2% is important to us too.  We have a process we use internally to learn from our mistakes called "Code Blue".  Most of the time when we receive negative feedback, it's not because someone did a bad job, it's because there are problems with services, processes, or products.  We are using this information to help us improve.  Here's a sample of the comments we get.  These are related to services to which I am accountable, so I'm comfortable sharing here.

"I was told that there wasn't a courtesy phone in the classroom, but once I got there, there actually is a phone. The number is ###-####. Would have been nice to have so trainees could contact if they couldn't find the room."

"The only response I remember getting is the auto response one receives when a ticket is submitted. I didn't get support from anyone in MSIS. Apparently the issue resolved itself."

In the first case, it was simple, correct the information in the Room and Resource scheduling service. In the second case, it highlights a process and communications problem within MSIS that we are working to resolve.  Without the customer feedback though, we really wouldn't know that our customers are experiencing pain.

So why are we talking about leaving Zendesk?

We’ve received funding to support Zendesk, but we have an opportunity to use a product that will allow us to work towards implementing user support optimization and provide a significant cost savings.  The purpose of the survey I sent out was to make sure that when we do transition away, we keep the important elements that have helped us improve so much so far, like getting feedback from our customers.  Last week, I gave you the weighted list of business capabilities we needed.

We evaluated different products against these capabilities.  Each product's performance against each business capability was judged from a 1-5 Scale, 1 being terrible, and 5 being terrific.  0 for those who did not have the capability.

Product Scorecard

It's no surprise Zendesk comes out on top.  It's still the best fit for who we are. ServiceNow (in use by ITS) is a very close second, as is Atlassian's Service Desk, although the tools inhabit very different market niches.  Absolute Service is already in use as part of MiHarbor, so it's inclusion is a natural fit. However, it failed in some very important ways to us. Remedy can fulfill most of our business requirements, but it is saddled with decades of feature agglomeration so as to look like a Katamari.

But wait! What about (name of really awesome software)?

Other ticketing and ITSM solutions are out there, and I did look at a ton of them.  In the end, I decided that the rational thing to do was to look at products that are already in use institutionally in some capacity or another.

So, what's the decision?

We haven't made up our minds just yet.  At this point though, it's between ServiceNow and Atlassian Service Desk. If you have more to say, you know where I am, please let me know!

One week left for the Employee Engagement Survey!

As a reminder, the 2014 Employee Engagement survey is open through this Friday, May 16.  We've had a lot of groups report back at 100% completion, but we aren't there yet across the board.  Please, please encourage everyone around you to take the time to fill out the survey.  

What is my WAC Code? 

As a reminder, the WAC codes for MSIS are included below:  

1. 1070 - UMMS CIO MSIS Learning Program
2. 1071 - UMMS CIO MSIS B200 Collab Space
3. 1072 - UMMS CIO MSIS Solutions Center (not in B200 Collab Space)

As a guide to these codes: 

- If you work in the Learning Program (MLearning, IDTT, Enabling Technologies), you use 1070.
- If you work in B200 (CIO, Research, Strategy, SWD, DMS, M3, Services Delivery, Services Quality, Sys Admins, DBAs, some DSAs) you use 1071.
- If you work in the Solutions Center at a remote location (DSAs, Help Me Now, etc) you use 1072.

Providing your feedback and suggestions is essential for creating a better work environment in the University of Michigan Health System.

In order for us to provide the best workplace possible, we ask that you please take 10-15 minutes out of your day to share what makes our organization great, and what could be improved.  We are aiming for the highest percentage response we can, so please take the time to fill out the survey, as we'll monitor overall response rates as the survey unfolds. 

Who takes this survey?

The Employee Engagement survey is for Hospitals, Health Centers and Medical School staff who began working at UMHS before April, 5, 2014. Dual-appointment employees may take the survey, as long as one of their appointments is in the Health System. Any temporary employee that is within the Health System can complete the survey.

Individuals working within the Health System temporarily through a vendor (e.g. Manpower) and volunteers are excluded from taking the survey. Faculty and house officers will have an opportunity to complete a different survey at a later time.

What will I need to take the survey?

1.) Your Work Area Code (WAC), which you should get from your supervisor.  The complete list of work codes is listed on the Employee Engagement website. 

2.) A password will be required to take the survey. The 10-digit password will consist of your 8-digit Employee ID number, plus your two-digit date of birth. (For example, if you were born on June 4 and your employee ID number is 12345678, your password will be 1234567804.)

Are my survey results confidential?

Yes, your responses are secure. No one in UMHS will have access to data that can identify specific individuals. Responses have always been anonymous and using an external vendor adds an extra level of security. By requiring a survey password, we are ensuring that each UMHS employee takes the survey only once. Staff with official dual or multiple appointments will be contacted separately for instructions on taking the survey more than one time.

How can I access the survey?

• If you are taking the survey from a computer within the UMHS network, go to: http://www.med.umich.edu/i/empengage. 
• If you are taking the survey from home or a non-UMHS computer, go to: http://sitemaker.umich.edu/empl.engagement/ (Level-1 authentication required)

When you complete the survey, you can register to win free UMHS prizes so don’t miss this opportunity to contribute toward positive changes in our Health System.

What if I have questions about the survey?

Ask your manager or visit the Employee Engagement website for a complete list of frequently asked questions. I am serving as Survey Ambassador for MSIS and can address any issues you may encounter. 

Thank you!

Michael Warden

(734) 546-2929 | jwarden@umich.edu | skype:  jmichaelwarden

Software Delivery – Staffing Strategy

The software delivery organization has a vision for how we expect the staffing of the organization to evolve. 

There are two parts to the software delivery organization: M3 and software development. This blog post addresses the software development teams. There are four teams as part of software development all seated in the west wing of B200. You might enjoy their team names – as each team chose it.

•  BigEye Barracuda – Primary responsibility: medical education student performance (assessments and evaluations)
• SharpFin Barracuda – Primary responsibility: medical education – admissions, curriculum, and student portfolio. (Barracuda used to be one team and split into species as they split the work)
• Blue Runners - Primary responsibility: MARTA (evolution of M-Recruit and M-ACE)
• Mana Kai - Primary responsibility: HBO Data Request Tool

Each team also as ongoing maintenance and enhancement responsibilities for a variety of applications.

Our vision is to have a fully staffed set of agile teams well versed in building software applications, leveraging appropriate tools, and applying advanced software and agile practices and techniques.

We have a number of roles we expect on each team with the number of individuals fulfilling the role varying.

• Project Manager
• 4 Developers including at least 1 lead
• At least 1 Business Analyst (BA) and/or User Experience (UX)
• Service Manager & Product and Application Manager 

There are occasions where one role may overlap with another or one person may fulfill a joint assignment. For example, a project manager might be skilled and expected to contribute as a BA. Similarly many of the UX activities are also analysis activities so there are times when a UX analyst might also be doing business analysis. We need the freedom for teams to adopt roles as needed.

Our goal is to staff the teams with the roles and needed capacity as outlined above. Doing this will allow each team to tackle both small and larger projects. Importantly, it also allows the software delivery organization to flex resources between teams when necessary. Our belief is that staffing in this way will enable us to better meet the mission expectations of the organization!

So don’t be surprised if you see postings to fill a number of positions in software delivery!

Please stop by NCRC Collab Space and find me if you have any questions.

Recession Proof?

Years ago, when my father was still an attorney, he invested in a friend’s business.  It provided temporary clerical and light industrial staffing.  The business did okay and my dad stayed out of it.  

About the time my dad was getting fed up with the legal business, his friend’s business (called Tempco) started to falter along with the economy.  As businesses faced a tough economy, temps were the first to go.  My dad decided to step in and try his hand at being a businessman.

As Tempco’s troubles mounted, my dad wracked his brain trying to figure out how to save the business.  He was not content to find a way through the current recession.  He wanted to find a way to avoid the deleterious effects of the next one as well.  One evening, when he had reached an all-time low, an idea came to him -- medical!  

He realized at once that the medical industry was essentially impervious to economic cycles.  Healthcare is a basic human need.  People will spend their last dollar for it.  So, he renamed the business Medco (and later Arcadia) and started offering temporary nursing and hospital staff.  The business branched into home care and eventually grew nationally.   It never suffered another recession.

Amidst budget cuts and diminished staffing levels, it is easy to forget how secure we are relative to other industries.  The healthcare industry has enjoyed somewhat of a bubble over the last 20 years or so.  Just as the manufacturing industry was forced to pursue efficiencies after offshore competitors ate away their profits, the healthcare industry must now do the same.

MSIS is at the epicenter of the effort to drive out cost.  While we may not always succeed, our goal should always be to find ways to make medical education better, faster and cheaper.  As is the case in the private sector, organizations that are more successful will receive greater funding.

Whatever we do, whether it is keeping a laptop operating at peak efficiency, improving the performance of a database, answering a question that gets someone back to work, or writing new software to improve the efficiency and quality of analyzing curriculum performance, we are contributing to one of the most important goals of UMMS.  It is easy to lose sight of this when you are in the trenches, but remembering it gives us purpose and allows us to make better decisions about what we should be doing.

Like any industry, healthcare is evolving.  Evolutions require some disruption, but we can all take a lesson from my father.  If we do our jobs well, we can avoid the effects of the next recession...and any that follow.

Finding Enlightenment - Zendesk and What it means to MSIS and our Customers

Before enlightenment; chop wood, carry water.

After enlightenment; chop wood, carry water.

- Buddha

Zendesk has provided us with capabilities that have helped us measure and improve our service delivery. Sustaining Zendesk for the foreseeable future is untenable. This is a report on the project work we're doing to find a new tool to replace Zendesk.

I recently asked MSIS and some of our key stakeholders and customers to participate in a survey to help us continue improving the way we deliver customer service. This was to help us better understand the capabilities that we’re using in Zendesk today, and what we need for the future, should we decide to leave the tool. Here is the result of what you and our customers provided. The survey has helped me capture a few things I would have missed otherwise, and I am grateful to you for taking the time out of your day to help in this effort.

Survey Results

Question 1: Where do you work?

Question 2: Describe your Role
 

Capabilities Ranking


The open ended questions
What do you want to keep? What do you want to change? Anything Else?

There were a lot of you who put some thought into this, and it was a pleasure to read through your responses. I have summated similar requests and ranked them below. As I found collections of more than one feature or capability, I added it to the list. I’ve scaled the responses to match the scale of the results above for comparison.



Weighting and Analysis

I applied some weighting to the two results above to best reflect what a successful product for us would look like.  In order of most weight to least weight: customers, key stakeholders, MSIS.  With that weighting I get a capabilities list that looks like this:

Survey Ranking	Weight
Customer Satisfaction Feedback	415
Measuring and Reporting Performance	317
Seeing Tickets I am Copied On	273
Having a User-Friendly Interface	267
Clean Email Formatting	261
Customizable Views	245
Manually update contact information	215
Escalations for Pending and On Hold	205
Merging Tickets and Customers	180
Knowledge Base Integration	177
Macros	171
Integrating with other Systems	167
Searching Previous Tickets	153
Tracking Orders	145
Mobile Access	132
Auto-Completion	99
Scheduling	54
IT Asset Management	18

Additional Bits of Flotsam

There were a lot of requests for training on the tooling, but also on the process by which we manage tickets. There were also requests for things which aren’t in keeping with our service delivery model.

Multiple Assignees: It is important to understand that as soon as more than one person is assigned to a ticket, accountability for that work utterly breaks down. It’s not in keeping with how we manage performance, and look to ticket information to help us improve our products and services.

Additional Status and Ticket Types: In Footprints we had 20 different statuses and ticket types. Some which were statuses which seemed like ticket types and ticket types that looked like statuses. For example, it was possible to have a service request pending in active status.

Next Up: Evaluating solutions against the capabilities you provided in the survey.

MiHarbor launched

MSIS is excited to announce the beginning of the MiHarbor deployment across the Medical School! 

MiHarbor is a complete end-to-end device management system, providing virus scanning, data and disk encryption, remote patching and data backup for Windows and Mac workstations. It has been developed in partnership with MCIT and it will give our customers options that address their specific research and academic needs. 

MSIS is deploying MiHarbor across MSA throughout May 2014. Our focus is on replacing Windows XP users with the MedSchool Core Image. MedSchool Core is supported by the Solutions Center and is the first product to be made available within MiHarbor. It includes the use of Credent for disk encryption, MicroSoft Forefront for virus protection and Crashplan for backups. In addition users of the MedSchool Core can request and use any of the Medical School or U-M licensed applications, including the Adobe Suite. Upcoming MiHarbor products will include MacLite and a Minimum Security version for both PCs and Macs that offers basic disk encryption and antivirus protection.

A lot of work has been done across MSIS and MCIT to make this possible, but as these rollouts begin we’d like to specifically recognize the work of Andre Latzman (MiHarbor Product Manager) and Sue Boucher (Project Manager) for their herculean efforts to make this a reality.  Please be sure to take a moment to congratulate them on this accomplishment next time you're in NCRC B200.