If you're an entrepreneur, this is gold. Real data!
This is the stuff I get to read while everyone else is having fun at Catalyst. There's always next year.
Wednesday, June 25, 2008
Tuesday, June 17, 2008
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:
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.
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:
- General info on the app: name, version, app owner, number of users, app function, etc.
- Application type: client/server, web, terminal emulator, java, etc.
- Does the client seek to SSO and/or Context enable this app?
- What is the driver for enablement? security reasons? audit trail?
- Ranking importance level for enablement. I.e., how badly does the client want to enable this app vs. other apps?
- 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.))
- Is the application CCOW enabled ?
- 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.)
- 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?)
- 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.
ESSO and Healthcare, in the Trenches (Part 1)
I've been involved in the early stages of a fairly large ESSO project as of late. Since it's been a while since I've been involved hands-on with a project, I've decided to write a short series regarding my experiences. The goal is to impart some practical lessons that a PM could use the next time they decide to undertake an Enterprise Single-Sign On project, with special emphasis on healthcare.
I love working with healthcare institutions. There's always hundreds of apps to support, disparate teams with fragmented goals, and pushy users with lots of power (clinicians). Sarcasm aside, its always interesting given the unique landscape.
Lesson 1: In-House Homework first, Hold Back the Vendors
The client had been embarking on this project for nearly two years. Out of the gate, they called every vendor under the sun to see which products fit their needs. The problem was that they didn't clearly identify their needs up front. The good news is that the client was smart enough to recognize their mistake. They put the vendor calls on hold (indefinitely), and decided to do some in-house homework. The client identified that improving the clinician's experience was their primary driver, which helped a ton with the steps to come (as I'll demonstrate in future posts). They followed this up with the following very intelligent steps:
* They garnered some serious executive sponsorship
* They completed a thorough application inventory
In my next post, I'll dive a little deeper into the two points above. Anyhow, this experience rang loud, especially in light of the recent storm of articles on KPMG's Identity & Access Management Survey findings (here, here and here):
"More than two thirds (68 per cent) of executives surveyed for KPMG’s 2008 European Identity & Access Management (IAM) Survey believe the effectiveness of projects is hampered because they put too much focus on technology and fail to address the organisational and procedural changes that are required. As a result, only a handful, (11 per cent) are fully satisfied with the outcome of their IAM projects."
Ouch...SIs better do something and quick. (I'm sure that KPMG has nothing to gain from that!)
I love working with healthcare institutions. There's always hundreds of apps to support, disparate teams with fragmented goals, and pushy users with lots of power (clinicians). Sarcasm aside, its always interesting given the unique landscape.
Lesson 1: In-House Homework first, Hold Back the Vendors
The client had been embarking on this project for nearly two years. Out of the gate, they called every vendor under the sun to see which products fit their needs. The problem was that they didn't clearly identify their needs up front. The good news is that the client was smart enough to recognize their mistake. They put the vendor calls on hold (indefinitely), and decided to do some in-house homework. The client identified that improving the clinician's experience was their primary driver, which helped a ton with the steps to come (as I'll demonstrate in future posts). They followed this up with the following very intelligent steps:
* They garnered some serious executive sponsorship
* They completed a thorough application inventory
In my next post, I'll dive a little deeper into the two points above. Anyhow, this experience rang loud, especially in light of the recent storm of articles on KPMG's Identity & Access Management Survey findings (here, here and here):
"More than two thirds (68 per cent) of executives surveyed for KPMG’s 2008 European Identity & Access Management (IAM) Survey believe the effectiveness of projects is hampered because they put too much focus on technology and fail to address the organisational and procedural changes that are required. As a result, only a handful, (11 per cent) are fully satisfied with the outcome of their IAM projects."
Ouch...SIs better do something and quick. (I'm sure that KPMG has nothing to gain from that!)
Subscribe to:
Posts (Atom)
Posts
