ESSO/Context and Healthcare, in the Trenches (Part 2)

In my last post, I focused on the first lesson: In-House Homework first, Hold Back the Vendors. In this post I'll go on to speak about the importance of executive sponsorship as well as the application inventory.

Executive Sponsorship

I think a ton has been written about this so I won't go into detail. I'll give two live examples. The first example was from a client that was seeking a Provisioning solution. We spent significant time with the right folks, or at least we thought they were the right folks. According to titles and apparent job function, we had an executive sponsor on board for the project. We identified a solid road map, the right resources on both sides of the fence, everything seemed dapper. At the last moment (and I mean legal approved contracts, pens were drawn), the CIO pulled the plug on the project by simply stating, 'I don't like this solution.' Everyone was baffled.
Example number two has a more positive ending. This time, the correct executive sponsor in place. The organization is going through a massive re-org, and it seems that the project will continue running smoothly. The project hasn't completed yet, but so far, so good.

A lesson learned:

Lesson 2: Validate 'Executiveness'

Just because a sponsor seems like he or she has leverage, it's important to understand the dynamics of the relationships in the organization. Each company is different with vastly different cultures. Does the sponsor's superior respect his or her decisions? Does the person have a track record of pushing projects forward?


Application Inventory

On to application Inventory. What is an application inventory and why is it important? I have yet to meet a Healthcare organization that has less than 50 apps. The last one I've dealth with has 1400+! That means that for clients who wish to ESSO/Context enable their environment, we need to identify which applications exist in their infrastructure, how important they are for ESSO/Context Management enablement, the technical difficulty to enable the application, etc. This information will help provide relevant context for the usage of the applications and which applications to focus on first.

Here is a list of things to document regarding each application:

1. General info on the app: name, version, app owner, number of users, app function, etc.
2. Application type: client/server, web, terminal emulator, java, etc.
3. Does the client seek to SSO and/or Context enable this app?
4. What is the driver for enablement? security reasons? audit trail?
5. Ranking importance level for enablement. I.e., how badly does the client want to enable this app vs. other apps?
6. What are the processes around this app? (Login Screen(s), Login Success Screen(s), Login Failure Screen(s) - Note Different Screens based on User Role (Physician, Nurse, Admin, Staff, etc.))
7. Is the application CCOW enabled ?
8. Application Credentials - Does this application have it's own credentials repository or share one with other applications? Application Credential Submission - Does this application use auto submit? (Some applications require users to select printers-ESSO can not auto submit.)
9. Is Change Password functionality supported by the application ? (If Yes, does the application have a configurable expiration timer? What are the valid characters? Do you want to automate Change Password and Auto Generate Passwords?)
10. What is the Business Process of the application Change Password Feature Change Password Screen(s), Change Password Success Screen(s), Change Password Failure Screen(s) - Note Different Screens based on User Role (Physcian, Nurse, Admin, Staff, etc.)
    

This should give you and your team a good handling on your existing application infrastructure vis-a-vis ESSO. In my next post, I'm planning on taking a step back and talk a little about the technologies.