Healthcare: More on I.T. Capabilities

I realize the need to be a bit more specific with respect to capabilities. I have seen a virtually unbroken string of capabilities discussed that related to the practice of medicine or the business of healthcare delivery, but in almost fifteen years of experience in healthcare I.T., I have yet to see a capability goal that is about I.T.

An example may help. Suppose you are the city planner. You could take one of two approaches.

1. You could develop a comprehensive plan for the city that takes into account various expansion directions and encourages some while discouraging others. The plan would include both residential and business expansion.
2. You could attempt to satisfy each request that comes before you. You could allow various developers and politicians to set the agenda for the next six months and continuously play one against the other for priority.

In the second approach, a deft manipulator can get by for quite a while. The city, on the other hand, will always be in turmoil and unable to staff its various departments effectively. Budget dollars will go to the current top project(s) at the time of the budget approval process. But, because project priority will be ever changing with the political situation, those projects may start and then go into hibernation. Workers with specific skill sets will find themselves with little to do while the new high priority project has tough going because there is no money to bring in the right skills. Equipment winds up sitting in a warehouse or worked far beyond recommended maintenance cycles.

In the first approach, remarkably modest effort goes into an expansion model. Productive and non-productive alternatives emerge. The productive ones are fleshed out and the unproductive are set aside for contingencies. Potential streets, sewers (storm and sanitary), gas, electric, phone, Internet, and other necessary utilities are blocked in. Alternatives and contingencies are identified and capacities are established. With all of this in place, it is now relatively simple to budget for the next year's projects and all will be well as long as we don't cave into to political expediency and begin to allow projects outside the scope of the plan.

There is no problem as long as all negotiation goes on in broad daylight. If a particular out-of-scope project has popular appeal, it will be a simple matter to say, "OK, here's what it will mean for our other projects, for our long term plan and for the budget. If it's still popular, we do it.

Back to I.T. capabilities; server capacity, mass storage capacity, network bandwidth and access points, space, cooling—these are all obvious capacity planning considerations and for that reason they are at least on the radar for everyone. More subtle but no less important considerations include the architectures (technology, network, data, and communications) that we want to have, skills required as we work within the architectures and, not least, the standards architecture that will be the governance glue that holds everything else together.

Depending on your own experience as a technology worker (rather than as a manager), you may not have a "feel" for the people, skills, and experience that will be required, nor even for the implications of various architectures. Again, this is no place to guess. Get your direct reports together. If they don't seem sure or can't tell a story that is meaningful to you, then get some outside advice. The skills and attitudes required for a successful SOA (service-oriented architecture) are much different from those needed in a more "traditional" approach.

If you intend to rely on vendors for everything, you will still need to be able to tell which vendors fit into your architecture and which don't. They will tell you that they are "architecture-agnostic" or that they can fit into any architecture--don't believe it. Know about the characteristics of things that will fit and things that won't. Attempting to force-fit something that doesn't belong is the quickest way to throw everything you've built into turmoil.

If you're uncomfortable, I apologize for being so open. The answer to getting comfortable isn't avoidance, though, it lies in making a concerted effort to bootstrap yourself. No budget, no resource plan, no allocation discussion--management of one thing is not the same as management of anything. Technology is to big, too complex, too fast-moving to be brought into line by the classic "cost management and allocation of resources" approach. It needs a team approach because there's just too much for one person to know.

Do what you're able to do and know what your boundaries are. Be honest with yourself first of all and with your peers, reports and management. You may wonder if you are the only one at times, but it is not possible to manage technology without honesty. Unlike people, technology can't be coerced or manipulated.