February 26, 2008

HIMSS 2008 Perceptions - A first glance

HIMSS does a great job of organization for this event. I arrived on Sunday Morning for the CPHIMS Review Course. The course was a quick overview, covering material and questions. Good News, is it looks like HIMSS is coming out with a book of knowledge and best practices mimicking PMI or IIBA. It is definitely needed as some of the material is dated. All in All it was a comprehensive overview, but it lack smooth synchronization of the materials. Additionally, the update moves the certification to a global perspective instead of the current US-centric view. Perhaps more of HIMSS as an organization's focus?

From the Education Sessions on Monday, I attended Marketing IT, Physician Portal, and Portable Computing. Marketing IT had some great insights, like an IT department should have a finance expert, and a communications expert. Additionally branding and marketing significant clinical workflow enhancements - like E-Signature. The Physician Portal overview of Catholic Health West Portal had an excellent CMO Presenter, candid and realistic. Main lesson learned, is for the portal to be personal, a single single-on solution is needed first. Additionally a portal can be used as an attraction mechanism for physician practice specialties. Want to attracted a Cardiology department, integrate the portal view. (Including all the cardiac imaging solutions would be ideal). Finally the case study with the motion computing C5 at John Hopkins was insightful. It is nice to see a company work with the nursing staff to come up with a good solution. For a wireless laptop, one should at least pilot the C5. I'm assuming the next version will really be ready for primetime, if they encompass all of the lessons learned from the C5 deployment. Best Quote is for this presentation, turning nurses into lamas on legs - oh so true!

The vendor demonstrations on the floor are simply massive. It takes some time to walk the floor. I'm going to focus on a couple of insights, first truly eye catching booth is the Siemens Booth. There was a wonderful eye-catching 30 ft long, 10 ft high thin computing screen on a white background. This very high tech solution caught my eye marketing the innovative MedSeries 5 solution, which surprised me. Innovation and Legacy is centralized view. All in all there was a lot of broadcasting Partners long term partnership with Siemens especially the revenue management, interesting since I don't think the install has started yet. Soarian is powerful with the workflow rules engine, it is a great concept to build a product around. I wonder if the functionality is up to the level of the more senior products. Maybe they even have plans to offer electronic signature within the product, like Cerner's profile.

Cerner has one of the best booths, they took their Kansas City Cerner DisneyLand on the road. The Director of Emerging Technology was sharing the vision of the Cerner Future. He took the time to listen and understand everyone's questions, and provided clarity of the vision. He did a great job! For the inpatient room, medical device connectivity was portrayed. A smart bed connected to millennium for patient alerts, ie a fall prone patient is one the edge of the rail unscheduled. The patient ID had an ultrasound tracking mechanism about the size of a quarter. Apparently RFID has too much interference for a reliable range currently. Wave Form Monitors where serially interfacing into a USB Bus converting the signal into the Cerner Millenium System. Motion Computing's, C5 display was offering up a Cerner Millenium Session through citrix for nursing and physician documentation. One large computer screen mounted behind the patient had all needed information, authentication was still via a login id. Although it would be cool if there was some mechanism to identify who was in the room via badge employee ids, maybe next year. On the other side of the room, where the patient TV normally is, there was a smart TV, displaying who was the attending and his information from the credentialing system. Choices ranged from, My PHR, My Care Team, TV, Movies on Demand, Games on Demand. (Remember the average gamer is now 41) It was a great vision of the future.

Posted by Elyse at 1:05 PM | Comments (1)

February 23, 2008

Our best intentions and the effects of not collaborating

It should of been a slam dunk, it is a good endeavor. It isn't technically challenging, operationally challenging, and has a lot of benefits. Everyone was well-intentioned. But we collaborated as silos and not as a team, and the project was never setup for success. Organizationally, all IT resources were over committed to bringing up the new hospital. However, in order to improve physician communications, the CMO was eager to listen, to what the vendor had to say. Honestly, it is just another reason to have a vendor management policy with all vendors, preferably included in the MSA. Or just having demand management discussions with the senior execs would of helped. At the project kickoff, our outsourced telecom manager sat in the meeting, and escalated it back to IT.

I got the project in late January, very late to the party. Project documentation was a listing of 80 phone numbers, most of which were call centers. Needless to say it is hard to identify which phone needs the quick push button, when there is 20 to choose from. We needed to dig down and clearly mark the phones. The other component was we needed VOIP phones, about 80. We only have infrastructure support for another 30, before we are at capacity. Our plan was to request the remaining infrastructure in the capital planning process this year, since the pilot was so successful. We decided to regroup.

We regrouped about a week later beginning of February, our phone listing has now gone up to 235 quick dial locations. Our communicated process for VOIP phone turn in had a total of 7 phones, all from the IS staff. Current discovery was we need to do the assessment, but with commitments to the new hospital, moves/relocations, and break/fix. The telecom consumption rate was already above what was contracted for monthly allotment. We looked to contracting the solution from our outsource partner. The labor for programming the phones/ plus needed phone upgrades and replacements was plus $100,000. Of course, this physician's communication service was paid with risk contingency monies from last year, so there is no budget.

We regrouped again a week later, the first the calendars would allow. Concern about meeting the live date arose. (February 27) I tried to consider, where my communications faltered surround the scope needing to be identified, so we would know what work needed to be completed. Additionally, we didn't have any resources to do the work, so we would need to wait. Of course, if there was a work around. We had a pre-meeting to the vendor call with the project sponsor, so we would have a plan. Really wasn't much of a plan to be had. If we stopped all moves for the institution (doesn't work bringing up a new place), we gain an extra 4 hours a week. This would leave a 22 week duration. Of course, the nurses could dial the number and then mimicking a page, place the call back number. However, apparently our technology constraints had never been communicated to the vendor. One can hear in the voice and tone the frustrations. Especially the nice comments, well back in December we said. Spilled Milk doesn't help in project rescue. The executive sponsor, really clearly portrayed, the behemoth of the new hospital coming on line, and consuming all the resources. A desire to build a successful partnership with the service, the weighing of the decision of making sense to use the manual solution versus doing it right the first time. It was a great executive sponsor speech. The vendor was getting back to the sponsors; again our IT role of collaborator was not included. Fair though, since we haven't collaborated. Next day afternoon, we decided to walk the floors to come up with the phones to be identified. The team walking the floors, identified 7 of the 235 phones, before they all decided it was too tedious. No one from a nursing stance new which phones. Deployed Phones, where not tagged, so we needed to call telecom and use magic to get the id number. The project was delayed, but communications needed to go out to the physicians. CMO wanted a new date to set expectations for the physicians who had been promised the new system. The additional telecom resource for the new hospital resigned. We still didn't even have scope for the telecom guys or resources to walk around to get the new scope. Again the voip phone turn-in project still has the 7 from IT.

I'm working on crafting an email to clearly depict the risks, and steps needed to get a schedule together. (Preferably including the vendor, the sponsor, IT, telecom as the project team)

Lesson Learned are quite a few:


  • We need to do a better job at demand management and conveying the plate for information services to our senior management.

  • We should also leave capacity or at least have agility to assess a new vendor solution.

  • Senior management should be aligned on the goals.

  • We also have to determine the project plan through benefit realization.

  • We have to identify ownership and the risks for implementation on the timeline.

  • We need to understand our resource availability at planning.

  • We shouldn't have project kickoffs for technology with only our outsourced vendor.

  • We should have had weekly project status meetings across the team.

What is really sad is we all know better, but just didn't have the time to dedicate to the politicking to convey the point.

Posted by Elyse at 11:04 AM | Comments (0)

Quick Little Risk Management Checklist

Here is a little checklist of what it means to do Risk Management during project management.

  1. Use a risk-discovery process to compile the risks lurking about to impact the project
  2. Make sure the entire core risks are represented on the risk register.
  3. All risks should be analyzed and be reviewed with the following information:
    • A risk title and a unique number
    • An early realistic indication of the risk becoming real. In other words find all transition indicators.
    • An estimate to the cost and schedule impact of the risk occurrence.
    • Estimate of the probability the risk will occur
    • A calculation for the risk exposure to the schedule and budget for the risk.
    • What contingency plans can be put into action if and when the transition occurs.
    • What mitigation actions can be taken in advance to make the desired contingency action is feasible.
  4. Designate showstoppers as project assumptions. Please the assumptions on the risk register, negotiated the risk ownership to the appropriate management (this sometimes necessitates managing upwards)
  5. Make a first pass at schedule estimation by assuming that no risks will materialize with the group of individuals responsible for the work. The goal here is to determine the nano-perscent date, the earliest date by which you can't yet prove to yourself that you won't be done.
  6. Portray the uncertainty factions and use a monte carlo risk diagram with intersection at N.
  7. Express all commitments using risk diagrams, explicitly showing the uncertainty associated with each projected date and budget.
  8. Monitor all risks for materialization or expiration and execute contingency plans whenever materializations occur.
  9. Keeps the risk management process going through out the project to cope with late-apparent risks.
Posted by Elyse at 9:59 AM | Comments (0)

February 11, 2008

Tasks, Projects, Programs

As the development of a methodology persists for a PMO, there is a vagueness surrounding the conceptual differences between a project, program, and task. For the project description, simply having a temporary unique endeavor with a beginning and an end is almost too general and simplified. At times, I believe the disconcerting part is that the realization everything is a project comes to light. Projects are large, medium, small, and tiny. As clarification occurs, realization that the manual running of the report every day at 8:30 am really isn't a project, those additions of doctors to the doctor master, really isn't a project. In my experience, the difficulty embracing the concept derives from something deeper.

Organizationally, if you don't know what a project is at this day and age, then here is probably what is occurring in your HIT shop. First, there is no work approval or authorization mechanism for requesting work. Everyone probably has their own lists. Additionally, customization of the environment is spreading like a Californian wildfire sweeping through your ambulatory, clinical, revenue cycle, integration and financial systems. The inpatient billing manager says hey this would be easier and save me some clerk hours. The system analyst says sure, and adds it to her listing. All of a sudden, you have an outside billing interface controlling the system edits in a duplicative manner. Customization spreads. The problem with understanding the concept is not the concept itself. The problem is the realization, that most of the work your department engages in is pet projects for "preferred customers". The work doesn't relate to the strategic value of the organization, and conceptually you are investing your high quality talented resources in penny ante tasks. This is why the simple definition is a double edged sword.

As we struggle with this concept, comments like. "Well my work really isn't a project, it is just a bunch of tasks." Arise. To which my favorite response is, "Okay, well maybe we should group those tasks under a project or program. Can you tell me what benefits these tasks are bringing to fruition?" Afterwards, we continue the learning conversation.

The main purpose of a program is to deliver benefits which will help the organization realize its strategic objectives. Programs are strategy-oriented. Programs have a wide scope, so that the organization can change to meet the benefit expected. As a program begins to deliver the incremental benefits, these deliverables are often accomplished by projects. Obviously, within the project there are tasks to get the project completed and implement the deliverable.

Posted by Elyse at 6:15 AM | Comments (1)

February 8, 2008

IT Value: Is it an Expense Center or a Value Center

Historically in most healthcare enterprises, IT is viewed as an operational expense. In order to change how IT is used, one has to have executive agreement to change the way IT is viewed and used.

There are some key indicators in how IT is utilized. First, a common item is to identify the percentage of the health system’s operating budget dedicated to IT. Standard is between 15 – 30% of the capital dollars and 2 – 3 % of the operating budget. Another comparison is if IT is being asked to cut expenses?

Another key component is the level of IT participation in the strategic planning process. One level of the organization’s maturity is where IT is included in the strategic plan. Is the CIO a partner in developing the strategic plan, or after all is said and done, does someone say, hey implement this to the CIO.

Discretionary dollars to keep the lights on are another indicator of how the organization views IT. As budgets come out, are there discretionary dollars to perform needed system upgrades and replacements? How long has that telecom equipment been in the closet? Are there broken piece and parts? A quick check is to see how far behind you are on core system updates. Are computers and equipment charged back to the departments?

Another “red flag” is that the IT steering committees are separated from and not integrated with operational and clinical IT decision-making groups. Are there even IT steering committees? Or does IT just decided to consolidate the clinical system, because it is expensive? This type of decision would need to be reviewed and discussed with a clinical leadership. Is there a clinical IT decision making group? Or is it general anarchy? Do cardiologists just email the CIO asking for a completion date to projects not even budgeted?

From Beyond Return on Investment, here are key difference is the expense center versus value center

Expense Center

Value Center

It is an expense to managed

IT is a driver of strategic value

Cost is the primary metric

Multiple criteria measure IT value

IT is deployed to support operations

IT is an investment and a strategic asset to be leveraged

IT operations reflect captive internal monopoly

IT operations acts as solution integrators for business requirements

Short term, budget cycle time frame

Long term, multi-year planning horizon

There is also a signification distribution of IT Resources Compared to Customer Needs. This cyclical because of the treatment of It, when It is viewed as an expense, the sophistication level of the resources or integration of different components are just not there. So a significant amount of resource utilization is done as break/fix and operational maintenance.

 

 

How does one grow an organization from an expense center to a value center? Well it takes a team and a guiding vision. The place to start is with governance leading the IT principals or IT maximums based upon business strategy. (Along with decision rights)

 

First, organizationally determine what is important to your corporation and weight the ranking appropriately:

  • Cost-effective use of IT
  • Effective use of IT for asset utilization
  • Effective use of IT for growth
  • Effective use of IT for profit.

 

If cost effective comes up as the key weighted criteria, then you have an opportunity education and coaching at the exec level. For clarity asset utilization is the approach to share and reuse IT across the business units, process, and region. An approach would be to first reuse, buy, then build. Enterprises seeking profit tend to have a centralized governance approach, often having a centralized coordination and approval of IT investments. Leaders on revenue growth walk the tight walk on the entrepreneurial spirit with the enterprise’s business objectives. However, given the spirit of intent and strategic goals, clearly defining principals of IT, will clarify corporate usage and change the usage from an expense to a strategic partner.

Posted by Elyse at 1:07 PM | Comments (0)

February 6, 2008

Planning and Managing Risk

A corporation's ability to plan their work and work their plan is the key difference between success and failure. If your enterprise doesn't understand the interdependent nature of departments, a component which can help bring a project in and deliver the benefits proposed is risk management.

There are areas of uncertainty to any project. Items to consider are:

1. Requirements: What exactly is needed to be done? What is desired? Where is the stretch goal?
2. Usability: How will the application interact with the end users?
3. Change Management: How will the business process be transformed after live? How will everyone be prepared for these changes?
4. Resources: What skills will be available as the project proceeds? What environments will be available as the project proceeds? Will the project sponsor be available?
5. Management: Will management be able to establish a productive team, maintain morale, minimize turnover and coordinate a complicated set of interdependent tasks.
6. Supply Chain: Will resources perform to the level as desired? Are the resources available? IS there a consultant contract in case such an item is unavailable? Is the procurement process understood and repeatable?
7. Politics: What political gambits and power plays will trump reality and impose constraints which place project success in jeopardy?
8. Conflict: How do members of a diverse stakeholder community resolve their individual (silo) goals when essentially the goals are incompatible.
9. Innovation: How will technologies and approaches unique to this project affect the outcome?
10. Scale: Have projects of this breadth and volume been successful based on past performance.
So as a starting point, I have a project today, which is an individual goal of our chief medical officer. We are going to walk through a risk discovery process reviewing the area's of uncertainty and identify all risks, ascertain our project's level of exposure to the risks, and develop contingency plans for those risks where warranted.


Posted by Elyse at 7:30 AM | Comments (0)

February 4, 2008

Graphical Hospital Quality Ranking by Locale

The Healthcare IT guy has a link which nicely illustrates Hospital Ranking linking HHS hospital database and Google Maps. Capitalizing upon the publicly available information from the Department of Health and Human Services, it portrays an interesting picture. It quickly places hospital quality information at one's fingertips with the ability to check out more data within the drill down if desired.

Check it out: Hospital Ranking for Jacksonville, FL

Posted by Elyse at 8:32 AM | Comments (0)

February 3, 2008

Risk Management & Healthcare IT

Surprisingly, it is simply amazing how essential the practice of risk management is in Healthcare IT projects and how often this practice is abandoned. As organizations mature and grow from a reactionary mode of operations to a proactive mode, risk management is often utilized in proactive organizations. However, when it is most needed in reactionary status, the organization isn't sophisticated enough to follow this practice.

For example, suppose you are a newly anointed project manager in an integrated delivery network, a local hospital system with a new practice structure. Project Management is a fledging practice. Organizationally, there is no work authorization practice. Requested Work is kept on individual lists for the application managers, (finance, revenue, clinical), application director, and the technology directors. Additionally the nuts and bolts of technology are outsourced, and technology managers (networking, telecom, desktop, client server) also have their own listing. Your morning visits to the local coffee shop are plagued with follow-ups in requests lost or misinterpreted on one of too many lists. The IT investment of the day goes to the business partner with the largest voice. Organizationally, the interpretation of the bottleneck is of not having project managers to manage the projects, not the lack of resources to do the projects. Often, project manager end up running the project, but also designing, constructing, testing, and deploying the solution. These considerations are constantly on your mind. After all, it's the technology investments of the organization you are responsible for delivering with your project sponsor.

You and the project team can easily manage some of the possible problems. These just need a quick tweak to a technical design or modification of workflow when the problem occurs. For example, there is no need to have an elaborate plan in place to add a field or two to an interface. Any technical pm worth their mustard should know how to handle that one and act accordingly.

However, it is obvious that there are graver risks, which are going to require some serious planning in advance. Resources being overloaded and pulled for other projects is such a risk. You should be aware that at any time, those who control the resources would pull the resources back to handle a fire, or support a higher priority project from their concern. In order to prevent such an occurrence, you need to do a significant amount of due diligence, including finding out other initiatives for resources needed for the critical path. Possibly even evaluating contract work for the integration work, and having the vendor solution analyst work with the sponsor as much as possible. There are many different routes to handle this risk although they all will require additional money.

The actual occurrence of a resource extraction will be invisible when it first happens. There aren't a lot of gates for the development of the interfaces, so you need to put in place and monitor some kind of control to highlight when a resource isn't dedicated to the project. You decide to note, that the team mates participation in the weekly meetings, and a stagnant status for a week are your indicators to enact an outside consultant. You choose to have the resources managers report status of the interface builds in a weekly review meeting. You also get outside estimates for how long a billing interface should take to build for a system with this level of customization.

Realizing resource extraction is only one of the risks requiring advanced forethought; you call a meeting with your project sponsor, executive sponsor, and key stakeholders. You review the potential problem with them, suggesting having a risk-discovery brainstorm, and develop a definitive list of potential problems, which need to be managed.

This is the ideal, however it is a good exercise to start the process of risk management. A risk is a potential problem. Once the risk occurs, it is not a problem. The point at which the risk materializes is the moment of risk transition. Once transition occurs, the project manager should act upon the plans to mitigate the risk. For every risk there is a transition indicator. For our risk above it is the lack of movement on the weekly status.

However, remember to educate and coach the organization. Persistants also helps to bring enlightenment.


Posted by Elyse at 10:49 AM | Comments (0)