Key 7 - Estimated End Date (MVP): Michigan Agile Philosophy (MAP) Project Key

7.  Estimated End Date (MVP)

MVP?  Is this one of those new texting things those crazy kids are doing LOL?  No silly.  It’s not Most Valuable Player, Most Valuable Primate (this is real), Mitral Valve Prolapse, and it’s certainly not Montel Vontavious Porter.  I guess the best thing to do is describe it, and then we can talk about the letters.

The big idea is to figure out what problem you are trying to solve, develop the minimum product that solves all or part of the problem, and release it to users.  In other words, when some value to the user has been achieved, release it.  That doesn’t mean you’re going to throw junk at the customer, it means the moment you have something valuable that solves the problem you intended to solve.  No gold plating, no cup holders, just raw problem solving stuff.  Hence the name...wait for it...here it comes...Minimum Viable Product or MVP.  The important word here is “viable.”  

The example I like to use is Gmail.  Remember when it first came out?  It looked like this:

It didn’t have all the bells and whistles we see now, but it was enough to give value to users.  There were already web based email tools out, but Google had a different strategy.  Try out this new threaded paradigm and see if it catches on.

Why do we do this?  Well, we want to get the product in the hands of users as soon as possible so that we can learn.  We can validate rather quickly if we built the right thing for our customer and our users.   Google did just this.  They let it out and started to learn.  If you look at where it was and where it is now, it’s pretty clear they learned a few things.  As a side effect in business, first to market often wins.  So even if the whole product isn’t done you can get it in the market, put your flag on it and declare “first.”

The Problem/Trap

So when we ask for an estimate of MVP, this isn’t a hammer we use to tell our customers, “you only get this much.”  Instead, we want to drive them to create some tangible value as soon as possible so that we can get it in the hands of users.  It is a great artifact for a discussion with the Product Owner to determine how many features need to be working before the product has hit MVP.  Please don’t use it as a hammer.  It’s really not.  It doesn’t mean we’re stopping the project there.  It would be downright SILLY to stop unless we have learned, after it was released, that MVP really solved enough of the problem that doing any more work would add little more value.  It’s the point we feel we can release the product into the wild, let the users kick the tires on it and start making course corrections. By using the “hammer” we are promoting a bad behavior that will push customers away from our value of collaboration and more toward negotiation.  

An example of the MVP for a mythical project can be found in the “Burn-up” charts below. 

As you can see, dates are on the horizontal axis and points are on the vertical axis.  This is getting slightly ahead but put simply, teams break up the project into small chunks of work.  They then estimate the chunks of work using a point system.  The magenta colored dotted line represents the number of points completed to get to MVP.  In this case, MVP will be hit when the team has completed approximately 120 points worth of work.  The estimate is “bracketed” by the best case scenario, the green line, and the worst case scenario, the red line.  The likely case is in yellow.  In the example above, you can see that in the best case, based on the amount of work the team gets done when they are at their best, they will finish on 2/24/2014.  The picture below shows the worst case.  This slower rate completion could be due to lower team strength, meaning people are sick or on vacation.  It could also mean there is rework, the team is juggling or context switching, or various other delay causing problems.   For this fake project, the worst case happens on 3/17/2014.  So now we have effectively bracketed the dates that we think the project will reach MVP.  It will be between 2/24/2014 and 3/17/2014. 

In this final burn-up chart, we can see the average case denoted by the yellow line.  This is an average of the points done in the worst and best cases.  We should expect that if everything keeps moving as it has, that the project will reach MVP near the date in yellow, 3/3/2014.

That’s all there is to it.  We’re taking the arbitrarituousness (hah) out of picking dates.  In some cases there will be deadlines.  It’s ok, we just have to plan accordingly.  When we set artificial or real deadlines the Product Owner needs to know that it will affect the number of points that can be completed and thus the number of features will have to change.  Next time we’ll talk about the Actual End Date.

Key 6 - Start Date: Michigan Agile Philosophy (MAP) Project Key

6.  Start Date

A boss tells an <insert ethnicity, gender, age group, or job role> applicant, "I'll give you $8 an hour, starting today, and in three months, I'll raise it to $10 an hour. So, when would you like to start?" 

He/she replies:  "In three months."
MENTAL NOTE:  Jokes are funnier when you don’t have to be Politically Correct! 

We’ll take a break from sexy again to talk about starting projects.  While finishing projects is critical, it’s also important that we understand how to start them. 

Think back to your last few projects.  Do you know when they started?  Was there an event that happened where the whole team was certain that the project was approved and everyone was working on getting it done?  Was there an official kickoff of sorts?  Or was it kind of a nebulous thing that was handed down and you’re now just working on it because it failed before and you were to breathe new life into it?

It’s pretty difficult to know how long a team has been working on a project if they didn’t set off on it together and note the date that it kicked off. 

This kickoff event doesn’t have to have an F-16 flyover, the Michigan Marching Band, or a starting gun.  (whoa, would it be cool though!)  Our usual stance is that the team should agree when the project is starting and take off.  If you want to have a kickoff ceremony, cool.  It’s a good practice to review the Inception Deck, talk about roles of people on the team, and create an initial backlog when you’re starting the project.  You may also want to agree on a workflow to start, whether you are going to use a commitment based methodology like Scrum or more of a flow based system like Kanban. 

I have found that whatever methodology you pick, it’s a good idea to have the team agree on the rules for moving things from one column to another.  For that matter, the team should talk about other rules they want to abide by as well.  I have included some of the rules that the team formerly known as Iron Shrimp team used.  (Click to make bigger.)

Key 5 - Product Owner: Michigan Agile Philosophy (MAP) Project Key

5.  Product Owner

Product Owner is another role rather than a title.  Someone takes on the role of Product Owner for the life of the project.  They are usually one of the more important stakeholders who understands what users want now and typically they have an idea or roadmap of expected trends.

The Product Owner should have a very good idea of what they want to build.  They are often more slanted on the business side because they are expected to understand users, competition, the domain, and how the environment may adapt over time.  The Product Owner (PO) should be available to the team as much as possible, but minimally they should be able to check in with the team at least weekly.  They should be strong communicators as they will be the chief translator of requirements to the team.  Good POs ensure that the other stakeholders remain informed about the status and goals of the project. 

The PO prioritizes project features putting the most important items in stack ranked order.

Occasionally the team may bring up that there are dependencies on the work that needs to be done.  The team works with the PO to reprioritize based on these dependencies.  The team will then either commit to a certain amount of work for each iteration (Scrum) or they will commit to minimizing Work in Process (WIP) and try to maximize flow through the system.

As stated by Mike Cohn,  

“The Scrum product owner's job is to motivate the team with a clear, elevating goal. Team members know best what they are capable of, and so they select which user stories from the top of the product backlog they can commit to delivering during any sprint.

In return for the Scrum team's commitment to completing the selected user stories from the top of the product backlog, the product owner makes a reciprocal commitment to not throw new requirements at the team during the sprint. Requirements are allowed to change (and change is encouraged) but only outside the sprint. Once the team starts on a sprint, it remains maniacally focused on the goal of that sprint.”

Some companies have their Product Owners go through training before they can start their role.  The best description I have seen is in the 15 minute video by Henrik Kniberg.  You can watch or share it here:  http://www.youtube.com/watch?v=502ILHjX9EE

Product & Application Management Responsibilities of 15five

All 15five and no play makes Jack a dull boy

David Glaser will be assuming the product management role for the MSIS utilization of 15five. Please remember that management team requests for changes to the service should be routed through msishelp@umich.edu. Note that the management team has the ability to author individual team questions so that only your teams responds. You manager types.... you should do more of that, or at the very least... some of that. 

Understanding More about the MSIS Strategy : Rigor

 A note from Jack: Below is a post Dave Roberts put together regarding one of the values that MSIS identified last year.  Aside from the reasonably appropriate references to WW2 POW camps and the morose details of our inevitable conclusion to life, it should be noted that this is one of the more ubiquitous topics that I hear we need more communication about. 

(for those keeping score, it is a 5 letter word)

My first post on the MSIS Flotsam blog (I shamelessly admit that I had to look up the definition of flotsam). I appreciate the invite from Jack to use this as a vehicle to increase communication across MSIS, a recent suggestion for the Leadership to improve upon.

While presenting our MSIS Strategy to different audiences at our Winter Forum in January, 

I consistently received questions about one of our values. “What does rigor mean?”, they asked. 

My answer was, “you know, structure, getting things done”. Having thought about it more, 

I decided to research the official definition. If you do the same, don’t be alarmed if while 

searching for rigor you find derivative words like rigor mortis.

The dictionary defines rigor as, Strictness in judgment or conduct. It’s no wonder why this makes some people uncomfortable, especially in an academic environment where flexibility is valued. Rest assured, MSIS isn’t going to become the next Stalag 13 but we do want to place more emphasis on analysis, continuous improvement, commitment, accountability and delivery which require that we conduct ourselves with a level of rigor.

MSIS describes our value of Rigor as follows: We pursue the University’s mission with focus, discipline and rigor. The challenges we seek to overcome require thoughtful analysis, intellectual dialogue and commitment balanced with our customers’ needs for velocity.  We recognize that we need to constantly change and continually improve. We set realistic expectations and deliver on our commitments.

Our emphasis on rigor is evidenced through various actions taken in the recent year such as establishing: the Delivery organization, financial budget structure and discipline, capital plan, strategic tactics and limiting our work in progress. 

We continue to value flexibility but at this time we have chosen values like rigor to improve upon in order to help us achieve our MSIS Vision. Hopefully this helps to provide some context for the value and why we chose it. Our other values include:

• ·      Community
• ·      Citizenship
• ·      Collaboration
• ·      Relationships
• ·      Rigor
• ·      Innovation

These values appear on our Strategy Map at the bottom as they are a foundational element of our strategy. We also added them recently our MSIS website where their detailed descriptions can be found.

-Dave Roberts (daverob at umich dot edu)

Key 4 - Investment Owner: Michigan Agile Philosophy (MAP) Project Key

4.  Investment Owner

Daddy Warbucks to Little Orphan Annie.  Those gorgeous curls weren’t free.  Someone had to pay for them.  Daddy took care of it along with everything a little orphan girl could need.  All this to say, the Investment Owner is usually the person that is footing the bill for the project.  They are commonly found at a fairly high level and control a budget and a segment of the Medical School portfolio.

If you’re having trouble figuring out who the Investment Owner is for your project there are a few things you can do.  The first of which is ask someone.  So that is exactly what I’m going to do.  I’m going to hand off the rest of this blog to Dave Roberts.  Take it away Dave.

That's right Mark, using your words, the Investment Owner role could be compared to Daddy Warbucks, however it goes beyond "paying for the curls." The investment owner also helps to manage the investment contained in the portfolio to ensure the highest return on value. Officially the definition is:  A single person who is empowered to divert discrete resources to an investment in coordination with the portfolio owner of the portfolio in which that Investment is described.  The investment owner is accountable for measuring the value, tracking costs associated and participating in value reviews to facilitate management of that investment.

There you have it, straight from the Director’s mouth.  Stay tuned.  Next time we’ll take on the other “Owner,” the Product Owner.

Key 3 - Project Manager: Michigan Agile Philosophy (MAP) Project Key

3.  Project Manager

Now we’re getting somewhere...PROJECT MANAGER.  Evil title or useful team member?  Hmmm…let’s start with what a Project Manager (PM) is NOT.  A PM is not the ruler, manager, or Regis Philbin of the team.  Think of them more as Gelman.  They own the process and the culture of the team.  They remove barriers and ensure that the team has what they need to be successful.  The word “manager” throws some people off.  Fear not.  They are a peer on the team charged with helping the project move smoothly and thus enabling the happiness of the team.  Of course Project Happiness Manager is absurd, so we’ll just stick with Project Manager and the definition I have thrown at you.

An important point here.  Project Manager is not a title.  It’s a role.  That means that someone takes on the role for the life of the project.  If you have someone on your team that has the title Project Manager, they may be the logical person to assume the role.  For teams that don’t have a PM title amongst them, don’t fear.  Self-organize, decide who should play that part and go.  There are several ways to get help if you find yourself on a team that is having a hard time either deciding who should be the PM or if you are elected and you need some guidance.  There are several PMs in MSIS that have a great amount of experience running Agile projects.  You can grab one of them.  They are happy to coach.  You can also show up for Agile Coffee and ask questions.   Agile Coffee is once a month on Wednesdays.  Be on the lookout for an email that will describe when Agile Coffee will start up again in its rebooted format.

Key 2 - Description: Michigan Agile Philosophy (MAP) Project Key

2.  Description

Again, maybe not the most thrilling topic, but one that provides value. 

Imagine you are the CEO of a millinery.  Don’t worry, I had to look it up too.  A millinery is a place that designs, makes, trims, or sells hats.  You have lots of designs (ascots, akubras, beanies, berets, fezes (fezi?)), internal projects to set up a POS system  (...no it stands for Point of Sale!), a website that takes orders, a site that allows people to choose the kind of hat that will be best for them, and much more.  In this case, a project name may not be sufficient to inform the CEO of the goings on in the company.  An additional, robust description would be helpful.  

A good way to start is to borrow from the “Elevator Pitch” slide from the Inception Deck.  We’ll talk more about the Inception Deck throughout the next 16 weeks, but simply it’s an easy way of defining important parts of a project such as scope.  The “Elevator Pitch” slide goes like this:

For [target customer]
who [statement of need or opportunity]
the [product name]
is a [product category]
that [key benefit, compelling reason to buy].
Unlike [primary competitive alternative]
our project [statement of primary differentiation].

You simply have to fill in what is in the [ ].  After you have given the overview, it’s not a bad idea to give a few more details. 

Pillaging again from Ebay:

Writing an informative description

• The description is your opportunity to provide buyers with more information about the item. Be sure to use complete sentences and correct spelling and grammar.
• Organize information in paragraphs with similar information grouped together.
• Start with the most important details that buyers need first, such as additional details about your item.
• Include specific information like size, shape, color, age, manufacture date, company/artist/author, and notable features or markings.
• Clearly state the item's condition, such as new, used, or still under warranty. Be sure to mention any flaws or repairs.
• Be clear about what's included and the type of packaging.
• Make the description as readable as possible.
• In a separate short paragraph, consider including a story about the item, or why the item is appealing. Many sellers have found that adding a creative, human approach to their descriptions boosts bids and sales.

Key 1 - Name: Michigan Agile Philosophy (MAP) Project Key

1.  Name of Project

Welcome to the official kickoff of “Getting to know the project key…”  Yeah, ran out of creative ways to name this already.  Anyway, we start with the first key “Name of Project.”  It isn’t sexy, but it is worth a few minutes to get us on the same page here.

A lot of times there is confusion about the work we are doing because we know a project by multiple names.  For example, Contact List, Dial Tone, and MSIS Roster.  Another example from the Iron Shrimp team: Orange Card, CME Orange Card, CME, or something else?  GPP, Grateful Patient, or Grateful Patient Program.  PIBS or PDEP?  Dr. Eval or Clingrade Replacement?  They are all the same thing yet I hope you see that it is possible to confuse these different names.  Where it gets really contentious is when Management thinks we are doing triple the work because a project is known by three different names.  In general the practice we should adopt is to standardize on what our customer calls the project so we can eliminate the confusion from the start.

The name should be written consistently as well.  Sometimes we’ll see update charts, inception decks, emails, project names in JIRA, or other artifacts that have shorthand names of the projects.  I’m not talking about acronyms.  Heaven knows we won’t be getting rid of those any time soon.  I’m talking about totally different names.  Because we work with the project daily we sometimes come up with “pet” names for it.  Seems fun and harmless until someone overhears and starts propagating the madness.  It’s not a good idea to use those names on written or oral communications, reports, updates.  I’m all for creativity, but we have to be selective about where/when/if we call a project by an alias.  The best scenario is to use your creative influence when a project is being created so that everyone is on the same page.

Some things to think about as we name a project.  It would be fantastic if we got into the habit of using a verb in the title.  Something like “Upgrade of SAN Firmware” at least gives us a glimpse of what is going to happen.  “SAN Firmware” or “Project SF” or “Project Catching Fire” doesn’t do much in the way of reminding us what the project is about. Remember, we want a name that clearly describes the project.

Takeaway:  Names are important.  We want them to be clear and we want them to describe what the project is/does.  Once we settle on a name, we should stick to it.

Extra Credit

As a bonus I’m going to give you a life tip courtesy of Ebay.  When you’re trying to sell something on Ebay, here are some tips.  Coincidentally, most of them could be useful when naming a project.

Writing an effective title

Make a clear, compelling first impression by writing a great title for your item.

Here are some elements of an effective title:

• Use descriptive keywords to clearly and accurately convey what you're selling.You're allowed up to 80 characters, but you don't need to use them all.
• Include the item's brand name, artist, or designer.
• Include item specifics. For example, include size, color, condition, and model number.
• State exactly what your item is, even if your title repeats the category name.  
• Don't use multiple synonyms or plurals. It's not needed for search and may make your title less attractive to buyers.
• Omit punctuation marks and asterisks.
• Don't include words like "wow" or "look." Buyers don't search for words like these.
• Use correct spelling.
• Don't worry about creating a grammatically correct sentence.
• Don't overuse acronyms.
• Don't use all caps.

You’re welcome.  :)

Acronym Anxiety : AAMC

We work in a field dominated by acronyms. Arguably we work at the confluence of three fields (technology, healthcare, and higher education) which in their own individual rights are dominated by acronyms which puts us on top of the acronym anxiety heap. All of us at some point started working here and were befuddled by the seeming ease that a litany abbreviations being spoken to us somehow laced together to form a coherent message. I would like to take the opportunity to hopefully diffuse some of the anxiety by walking through some of the our field's shorthand a bit at a time.

AAMC: Association of American Medical Colleges (vulgate: 'Double A M C')

What is it: It is a professional association organization that helps create a community between the medical colleges and teaching hospitals of the US and Canada. It also acts as a broad coordinative service that helps focus joint efforts around the shared initiatives of these groups and associations.  AAMC also provides some services that are specifically geared towards our customers. These often shape what products and services we develop in tandem. Some additional history and purpose statements can be found here: AAMC About us.

What does that have to do with IT?:  IT is of course a pervasive element in most fields and industries, but what makes the AAMC special in it's approach is it's formation of special member groups. While there are interesting subjects in many of the some 23 special member groups it is the GIR or Group on Information Resources that is probably most relevant. The GIR has a series of subcommittees that focus on particular topics, but in the broadest sense, the group provides a forum for discussion on the application and integration of technologies for academic medical institutions. Of note is the AAMC GIR Leadership Institute which is a four day experience that UMMS regularly sends candidates.

Use 15five to make someone else feel appreciated.

The new 15five changes are out and available based on employee engagement feedback from the all-staff meeting.  Again the highlights are:

1. Fewer organization wide questions and they are tuned to be a bit more open ended and relevant using your suggestions gathered in prior 15five surveys.
2. Spacing out the frequency of the questions. The organization wide questions now occur bi-weekly and a couple quarterly. So.. hooray! 
3. The entire management team has the ability to create custom questions designed specifically for your teams that only your team can answer. Talk it over with your team leads and supervisors. If you want custom and relevant questions; put in a ticket and we will get it available for you and your teams.

I also noticed that 15five provided the ability to use the @username option so you can throw a shout out to someone  in comments that has helped you or that you want recognized. It didn't seem to work the first couple times I tried it, but it recently seems to have corrected. As a reviewer role in 15five, it's a good way to make someone else know you appreciate them. Give it a try, it's a good thing. 

http://success.15five.com/article/86-how-to-use-mentions-in-a-report

Med School Network Upgrades are in...{buffering.....buffering}... Progress!

Last year MSIS in conjunction with MCIT,  Med School Facilities, and ITSComm performed an assessment of the networking (wired and wireless) for the Medical School buildings. We created a detailed description of the current state and detailed quote of what is required to bring everything up to current standards. We also took this as an opportunity to consider future needs and capabilities, for example support for Cisco IP phones, a complete wireless redesign, communications closet room upgrades, and power improvements. The wireless upgrade will include moving access points from hallways and locating them in labs, rooms, etc.

 

Based on the extent of work and expense involved it has been decided to break this work down into a 5 year plan. Our starting point for the current fiscal year will be on mandatory improvements and worst environment areas. Based on those criteria we will start with MSRB3 and the VSS (Virtual Switching System) Core rooms. One VSS Core is located in MSRB3 A231P and the second one will move from MSRB1 A533P to MSRB1 2536P.

 

Next up after MSRB3 will be MS2 and likely MSRB2, though this is subject to change based on ever shifting priorities.

Kudos to Buzz, Cindy and all those involved to pull the plan together. 

Michigan Agile Philosophy (MAP) Project Key

Intro

Over the next 18 weeks we would like to take you on a journey.  A guided trip where we can share what we think is important as we monitor and track projects at the team and management levels. Hopefully this 18 week journey will be challenging, interesting, and occasionally whimsical.

At the last leadership retreat, Management came up with 18 “project keys” that give us guidance about what they want to make transparent and what information project teams should have at the ready.  Each week we will discuss one of the “project keys.”  Some of them may seem obvious at first, but we will explore them, peel back the layers of the project key onion and truly get to know them.

Here are some things we know about projects (as defined by MSIS).  A project:

• is temporary
• has a beginning
• has an end
• has a clearly articulated goal
• is composed of a sequence of tasks/stories/chunks of work
• has a defined outcome
• has defined deliverables
• is constrained by at least one of the following:  time, quality, budget, or scope
• has allocated resources of
• time
• people
• money
• equipment
• facilities
• is completed by a team (A team is at least 3 people working together consistently.  One member takes on the role of PM)
• has overhead and it must be considered if the work should be done with this overhead or if it should be done another way (a ticket).
• is validated by an approved MSIS decision filter
• is aligned with the MSIS strategy
• has value to some audience
• stakeholders
• users
• requires an inception deck or other approved project charter document such as an A3.
• may have risks
• should be approved at Director level
• should have a product owner
• adheres to the service delivery model of MSIS:  (link to definition of service delivery model)
• maximum length of a project is 6 months

If you have questions or comments, feel free to leave them after this post.  Share with friends and colleagues if you think this information would be helpful to them.  We know that projects aren’t 100% of the work we do.  We are choosing to focus on projects as the first phase of our strategy to provide transparency into the work that we do in MSIS.

Never fear, in true agile fashion, we will adapt as we see the need.

If you’re anxious to dig in, you can take a peek at all the project keys in the graphic below.  Next week we jump in.

It's time we had the talk...

The loss of BrioQuery and innocence

As some may have heard, our friend BrioQuery is going to be going away soon. There is a lot to say and learn about BrioQuery, but it is safe to say that this transition impacts the UMHS citizens in a number of ways and unfortunately it is not perceived as all that positive. It is necessary to move to new technologies but it is equally as necessary that you are equipped with some basic knowledge about why the transition must occur. We as IT boffins probably do not use this application all that much, but it is at the core of many customer's functions and it produces quite a large number of operational and research related artifacts that many other people depend upon here.

What is BrioQuery?: BrioQuery is a product that at one time was produced by a nifty little company called Brio Technology . It was a functional, not really glam, but trusted utility that could make quick and easy SQL, database table joins, and assist statisticians with data mining efforts. Through a number of tactical decisions in MCIT and MSIS over the past decade or so, BrioQuery found it's way into our customer base and while it wasn't ballyhooed, it was adopted as a de facto standard tool for performing these functions. Quietly and diligently we provided some distribution and technical support for the package and merrily along we went.

What is that important to UMHS?: UMHS has an incredible amount of data. Seriously... we have a mega-fun-ton of both structured and unstructured data. Data collection and manipulation is the lifeblood of how all three missions of the UMHS function. To that end MSIS: Delivery has a significant talent and investment in Data Management Services led by Mary Hill and her team. This team develops these data solutions and products for the Medical School and are but one part of a lattice of data management teams and efforts spread across the Health System. Without them, the place simply would not be able to function or progress. From financial data to patient care outcomes research to faculty affairs, data management services gets us through the day and prepares us for tomorrow.

But If it's so darn important then why is it going away? You Barbarian!: Brio Technologies is now part of the Oracle Inc. corporate family and the BrioQuery product was put out to pasture. Our version of BrioQuery isn't fully functional on Windows 7 and since we have to say goodbye to our friend Windows XP as well, we have ourselves a bit of a problem. Unfortunately Oracle and Microsoft did not talk to each other the night that this was decided and while they were heating their homes and lighting their cigars with the aggregated millions of the UMHS dollars they have; we have to determine some course of action.

But I know BrioQuery DOES work on Windows 7 You Liar!:  Well... kinda. The BrioQuery version we have will install on Windows 7 but if the saved query used calculated fields, then it blows up a bit. I can't advocate that we continue to install an old version of software onto Windows 7 that just kinda works.

But I know the there is a version of BrioQuery that will work on WIndows 7 WITH calculated fields You Human Paraquat!:  Well... kinda. There is somewhere out there alien-life in the universe and indeed somewhere out there with it is BrioQuery that works with Windows 7. However, we don't own it, Oracle won't sell it to us and we can't find it on craigslist or ebay.

But we are the University of Michigan Health System! Go make them do our bidding! You Coward!: Well.. I can't . Even with all the might of the blessed UMHS... we don't have that kind of pull with Oracle. Tis the way it is.

What will replace it?:  Well...not one single thing will replace it. Remember BrioQuery did a couple things really well, and there is not a big market for user-friendly, table-joining, data mining, decentralized, ad hoc reporting app. We are working on some recommended alternatives, but with the Windows 7 and the MiChart and the whathaveyous there is a lot to consider and adjust to.

What is being done about this?: A joint team between UMHS Finance, MSIS, and MCIT are working together as we speak and I participate in that along with equally motivated IT people from across the UMHS. It is really a good example of us working together. We have a project manager leading the effort now, we have done half a dozen demos of different software packages and end user consulting is on going in the development of a recommendation for Brio users to consider.  We have scoured SCCM looking for users, spoken with key areas that we know to be heavy data users, and surveyed the Health System. We know that this is not really a welcome transition but we have an obligation to help in any way we can to assist our users in a positive way while making progress on this inevitability. When there is more to report, I will be sending out additional information. Should this topic come up in conversations with your customers, try to help carry the weight of this sensitive matter and ensure you are not throwing either MSIS, Finance, or MCIT under the collective bus in the conversation. It is just the nature of IT that we sometimes have to carry the ire of our customers even when the circumstances are somewhat out of our direct control.

Be subject to each other and Good Morning

Sometimes I don't think about IT.

If you do not know about or you have yet to frequent this establishment, I recommend you check it out. http://www.bier-camp.com/ . They have wonderful things there. They have hot lunch sandwiches as well.  If you or a small group of you want to talk about work things and have a delicious hot luncheon sandwich sometime, let me know and we will plan it.

Ice Caps, High School arts classes, & Sitemaker

Created in 1998, Sitemaker was an innovative platform developed on cutting-edge technology and it has served us well since that time. However, 15 years represents several generations of advancements in computing and there are now potential performance, security, and opportunity risks in maintaining this legacy system.

For this reason, ITS has established a Sitemaker Retirement Project to transition active Sitemaker accounts to alternative services. Here are some key activities:

The project team will seek guidance and input from a broad cross-section of the university community throughout the planning, evaluation, implementation, migration, and decommissioning phases of this project. 

ITS is being guided in their efforts by a pilot user group evaluating other services and the Sitemaker Steering Committee. These groups have representation from the Medical School, Engineering, Public Health, Pharmacy, Public Policy, LSA, the Language Resource Center, ITS, and the University Library.

The project team is currently assessing alternative solutions for accommodating the currently active Sitemaker sites. We are nearing the completion of the pilot and will report out our findings and recommendations by early March.

Based on input from a broad cross-section of stakeholders, the following retirement roadmap for Sitemaker has been recommended:

June 2014 - No new sites
May 2015 - No site edits/read only
July 2015 - No site access/archive only
Nov 2015 - Decommission Sitemaker

A website for the Sitemaker retirement project is currently under development. ITS will add content as the project plan develops including a project overview and FAQ, an updates feed, a feedback form, links to support materials, a calendar/timeline, and a list of key project personnel. 

The ITS plan is to begin communicating directly with site owners and the general U-M community in March 2014.