Risky Business

In the movie that turned Tom Cruise into a box office success, he plays a young man who has his eyes opened to the infinite possibilities of those who are willing to take risks.

In our world here at MSIS, risk underlies everything we do.  We want to be successful, so each decision is weighed against the probability of a positive outcome.  It's only natural.

What factors do you use to weigh risks?  Do you only consider the immediate effects or do you consider long term effects as well?  Let me give you an extreme example of what I mean.  Consider World War II.  This was by any definition a horrible event in human history with unimaginable amounts of death, suffering and destruction.  Yet, good arguments have been made to support the theory that many of mankind's greatest technological accomplishments, such as nuclear energy and modern aviation, were born out of this tragedy.

My point is that when we evaluate risk, it is important to weigh the cost of failure against the longer term benefits of having tried something.  Look, few people actually want to fail and they don't set out to learn from mistakes.  On my team, we are faced with choices almost daily.  When a support request comes in or a recurring task needs to be handled or we need to incorporate a business process change, we need to determine if we should do the minimum required to handle the situation or if we should go beyond the isolated instance of the requirement to the broader ramifications.

Should we automate something that we currently do manually?  If we do, we risk breaking other functionality.  We risk spending more time than we had planned and jeopardizing our schedule.  We may even risk investing in something that will never return the time it took to make the change.  These decisions carry an increased risk for us because we know the curriculum will be changing, but we don't know if or when products in our current portfolio will no longer be viable.  Will our investments return benefits for one more year?  Two?  Three?

This week, we decided to spend some extra time to redo the interface on a page of the M4 Handbook application.  We know that we could create problems and we know that we're using a day or two of our precious time.  However, the team is learning new ways to build better applications.  The short term risks are manageable and the longer term benefits could be considerable.  There was no math involved in the decision.  There are too many unknowable variables.

Sometimes, you just need to follow your instincts and the knowledge you have.  I believe good teams will end up making good decisions most of the time.  I believe I am on a good team.  Decisions are always risky business.  Sometimes, you just have to say "what the..."  If you saw the movie, you know how the story ends.

There are heroes among us

Post by Michael Warden

Thank you!

Every day, we are presented with a unique opportunity - to help our customers to return to productivity.  Our customers - the faculty, staff and students of the University - are here to change the world.  Whether we replace a faulty keyboard, fix a bug in a web application, help them understand their educational mandatories or provision virtual infrastructure - we are helping them to either start or get back to work.  Their ability to change the world depends on our ability to keep them productive and in doing so I believe we are heroes.  We are doing something meaningful, something to take a great amount of pride in.  We are not exaggerating when we feel we make a direct difference in the quality of young doctors who are trained, the staff who serve the community, the discoveries that are made or the patients who are healed.

This section from our MSIS vision speaks to these opportunities:

MSIS is uniquely positioned to understand our customers’ needs.  We recognize that we play a key part of a much larger system of organizations and individuals.  Every day we help our customers to create, teach and use information.  As a result we learn more about our customers than anyone else and we influence the environment from this unique, well-informed perspective.  We can initiate projects that deliver value others haven’t recognized, and we know where we can help by learning from the services we provide.  We do this with a deliberate focus on who we are, what we do and exactly what value we deliver - striving to increase that value in tangible, meaningful ways.  

Every so often, our customers take the time to let us know how much of a difference we make.  It is right to recognize and celebrate them for taking the time to do so - I know it  has motivated me to put in extra effort or go the extra mile.  This quarter, MSIS once again had many instances of this act of recognition - 39 in total.  Specifically, we had the following activity in the Making a Difference award program:

Awards By Team	Number of Awards
AV Support	2
Barracuda BigEye	7
Barracuda SharpFin	3
Data Management Services	2
Database Administration	1
Instructional Design and Tech	1
MSIS Administration	3
Med Campus Support	2
NCRC Support	7
Performance Improvement and Management	1
Research IT	1
Service Desk	5
Services Delivery Administration	1
Software Delivery Administration	2
Strategy and Governance	1

I'd like to add to these specific congratulations my heartfelt appreciation for all everyone does here at MSIS.  You all help to make Michigan great, keep it up!

New Position Posted : Continuous Delivery and Automation team

In my last post I made mention of a new position the resource management group approved to provide a full time team member to the Continuous Delivery and Automation team. This position has been posted to the umjobs.org site and can be found here. Dan Stuart, as lead of this team, will be leading the hiring effort and should you have any questions for him.

Updates on the Delivery Program Resource Management Progress (part 2)

If you recall in a previous post to this blog , the Delivery Program directors now work together on a process for resource management. That is to say, the budget and positions that are broadly invested into our part of the MSIS organization are discussed and decided within the protocols of this group. We have taken the next steps since my last posting to outline a workgroup charter as well as a set of rules to abide by.

The charter is available for viewing here : MSIS Potentates Resource Management Charter

In our most recent meeting, which is the fourth time we have convened, we discussed:

-Device Support Agent position postings, two of which have since been posted on umjobs.org under this posting link.

-Business Analyst Intermediate posting, this position posted here will be for the time being reporting to Jack Kufahl as a supplemental effort of needs analysis across the Delivery Program projects and initiatives.

-UX Analyst position, which has yet to be posted, will be opened up in order to further provide user experience design effort within the Software Delivery teams. We also decided that there will be a future initiative within MSIS to help aggregate and create a community of practice or tribe around UX so that the distributed UX specific roles can collect together and further develop their methods and means within the School.

-DevOps Engineer position, which will join the Continuous Delivery and Automation team lead by Dan Stuart, is to be posted soon. This position will be the second full time member of on that team in addition to Dan. Together with the partial effort Vasile Negrea and Dave Glaser provide, that team will continue their efforts which are primarily focused around improving the delivery of application services between the software and operational teams of the Delivery Program.

-Systems Administrator position, which was recently vacated, the group decided to hold off on an immediate replacement so that we can further investigate the highest and best use of those funds and where within MSIS we should best apply them. There have been a number of changes recently within the Systems Administration team and rather that changing too much in a short period we are opting to make smaller changes, measure, analysis and proceed.

In a short amount of time, I am satisfied with the progress the resource management team has been making. We are acting together in good faith for these reviews and assignments of resources. With each person and team struggling with a large amount of work and limited capacity, I am proud to be working with these directors to have the difficult conversations and honest prioritizations at an investment level so that we can together make progress on that which is strategically important for the School.

This matches closely with our MSIS Strategy in becoming a strategy driven organization and increasing the value of our portfolios while relying on our shared values of rigor and collaboration.

To tolerate or not to tolerate...

Counterpoint: We should tolerate tolerance!  
by Michael Warden (a not-too-distant portfolio manager for MSIS)

Apologies for the poetic license, Bill:

To tolerate, or not to tolerate, that is the question—
Whether 'tis Nobler in the mind to suffer
The Slings and Arrows of outrageous Fortune,
Or to take Arms against a Sea of troubles,
And by opposing end them?

Tom - I appreciate your thoughts on the blog and you take an interesting perspective on this one.   Should we tolerate investments?  Is there something better we can do on behalf of our customers?  What would that be?

I don't believe we intend to use the word Tolerate as an act of submission to fate and to the interminable status quo.  As part of Portfolio Management within MSIS, we are using Tolerate to expose a decision that is being made.  We want to be sure we understand what is happening with an investment.  It should make us queasy.  It should make us uncomfortable.  It should make us wonder if this is the best situation.  All of these are good questions to ask, and our Tolerate portfolio action is intended to draw these questions out to be sure we are delivering the right value for the organization.
Let me step back:  Broadly you are referring to our chosen dispositions for investments within MSIS, which fall into the rubric of TIME - Tolerate, Invest, Migrate, Eliminate.  In your outline you reference four options - however they don't match to our 4 dispositions within the portfolio.  Each of our Portfolio Owners are working with MSIS to make discrete decisions about our best path forward given a scarcity of resources.  There is more demand than we have supply - so some places require resources to sustain them in order to prevent them from failing.

In your 1-3 (build, refactor, buy) are all variations of 'Invest' - meaning we are going to put more resources into this area than others as chosen by our Portfolio Owners.   Your #4, Tolerate, is a choice our Portfolio and Investment Owners make - to put the minimum necessary resources into an investment to keep it operational.

It's important to note that these are temporal decisions - to Tolerate 'for now', generally a period of at most 6 months before we revisit that.  These are better than the past because we are making conscious choices.  We used to give a perception of constant investment everywhere and under-delivery due to that being unreasonable.  This was not due to lack of architectural design or tooling, but a lack of focus within the same scarcity of resources we face today.

Consider, however, that there are two additional options when choosing how to handle our investments:

• We can Migrate the investment to an existing solution that meets their needs.  (Note that this is specifically one of the MSIS IT Principles:  'Leverage existing platforms'. ) We can often help someone use something else simply by helping them realize it is available.  
• We can also Eliminate our investment.  This is a choice made by our portfolio owners - not by us - but we have a role to prompt an honest discussion.  Just because we 'can' use IT to solve something doesn't mean we 'should'.  We often don't expose the resources it takes to use IT to solve a problem vs. the resources it would take to do the next best alternative.  This may be the best option - to set them free and be honest that it isn't the best idea to have us solve their issue. 

By choosing to Tolerate, Migrate or Eliminate we are seeking to expose conscious choices and business decisions - recognizing that often we - and IT in general - may not be the best way for the Medical School to solve a particular challenge.   And that raises the broadest question - how are we expending the resources of the school to deliver value?  Does it require us to Invest to achieve the best value to cost balance?  Should we help them to Eliminate or Migrate that investment to something else?  It takes time to figure this out, and it takes time to understand our options - until then, it is appropriate to make as transparent as possible that we are going to Tolerate the investment until we have enough information to determine the right trajectory for the investment.

Let us be careful, though, not to let conscience make cowards of us.  We use these TIME dispositions to direct action - and that action is really what I believe you are calling for.  I agree - wholeheartedly - that an orientation toward action that is in the best interest of our customers should be a quiet, persistent impatience within us all.  Let us take that action - enterprises of great pitch and moment - and continue to make the Medical School great through our efforts.

Thus Conscience does make Cowards of us all,And thus the Native hue of ResolutionIs sicklied o'er, with the pale cast of Thought,And enterprises of great pitch and moment,With this regard their Currents turn awry,And lose the name of Action. 

Should We Tolerate Tolerance?

One of the reasons that I wanted to come to work for MSIS is that it seems like an organization not only willing to change but motivated to have it.  Change is not always good, but you can't get better without it.  Change comes with a certain amount of risk -- much of it borne by the change agent.  If we want to be change agents, we'll all need courage to step out of the pack and say unpopular things.  Here I go again!

We use the word "tolerate" a lot at MSIS.  Tolerance is built into the culture of the University and our country in general.  Lately, I've been thinking a lot about this word and I've decided I don't like it much.  Let me be clear, I don't happen to think that "tolerate" and "accept" are synonyms.  "Accept" implies that you've thought something through and despite a philosophical disagreement, you recognize the right of the situation to persist; you accept it.

Tolerate means you put up with something without confronting it.  Confrontation either brings about a change or at least a deeper understanding of both sides of the "thing" being tolerated.  Ultimately, confrontation brings about change or acceptance.  At least it provides closure of some kind, unlike tolerance which is an unresolved emotional condition.

Whether or not you agree with my semantic distinction, you will hopefully recognize the emotional differentiation between denying unresolved emotions and living with things you cannot change (having made the attempt).  This idea can have lots of implications for all sorts of human interactions, but I'd like to focus on a specific usage of the word "tolerate" within MSIS that started me thinking about it.

In Software Delivery, we have a large product portfolio.  Many of our products were developed years ago without the benefit of modern architecture and design techniques, let alone modern tools.  They can be difficult to maintain and even harder to enhance.  Faced with this situation, we ultimately have four choices:

1. Build something new
2. Fix (refactor) what we have
3. Buy something to replace what we have
4. Live with what we have

It is my understanding that if we think that we will eventually choose options #1, #2 or #3 for a product, we automatically put it into option #4 mode.  We call this "tolerate."  The problem is, we are not the only people being forced to tolerate applications in mode #4.  Our product owners and stakeholders must tolerate them as well.  And, they don't always get a vote.

Awhile back, I met with one of our product owners who has a product in "tolerate mode."  While she appreciated my attention, it was clear that she was both saddened and angry that her needs are being neglected.  We both understand that we don't have the resources to create software that does everything all of our users would like.  Yet, with one word, we think we can sweep the emotions behind our decisions away.  We cannot.

Tolerance is an act of denial.  It is an unwillingness to confront an uncomfortable situation.  We may be forced to accept a bad situation, but we should never tolerate it.  Doing so is an attempt to disavow the negativity associated with it.  In the case of our products, it means not facing each choice of whether to expend effort to improve the situation (for the stakeholders of a particular product) or accept that they will need to live with the deficiency.  My team grapples with these choices regardless of the mode the product is in.  Sadly, we have been known to hide behind the "tolerate" status and it always makes me uncomfortable.  I don't like unresolved situations.  Call me intolerant.  I probably deserve it.

Next time you find yourself tolerating a situation, ask yourself why you're doing it?  Are you afraid of a confrontation? Do you feel you need to have the answers before exposing your dissatisfaction with the status quo?  Do you fear possible reprisals for exposing your dissatisfaction?  Whatever your reason, know this: pent up emotions have consequences too.  They are rarely beneficial.