The Application of Disciplined IT Processes and Methodologies within Healthcare

Kelly Summers, SVP & CIO, Maricopa Integrated Health System

content-image

Kelly Summers, SVP & CIO, Maricopa Integrated Health System

In previous industry articles I have authored, I consistently begin with a brief description of my experience. In this article, I do the same with the sincerest objective that the techniques, processes, and methodologies I’ve applied throughout my career have been effective across multiple industries.

My first role in Information Technology was as a software engineer and systems administrator within the Aerospace industry. I was hand selected to be part of a highly classified program (at that time) developing software that automated the mission planning for the famed SR-71 Blackbird. I subsequently went to work for a medical device manufacturer, Medtronic. After 7 years of developing software solutions for shop floor control, MES–Manufacturing Execution Systems, I moved to
Semiconductor Manufacturing with Motorola. I then transitioned back to Medical Device manufacturing; where I spent the next 13 years, which led to an interesting stint as the CIO of a publicly traded pharmaceutical company. For the last few years, I’ve been the Senior Vice President and CIO of a long-standing health system, comprised of three hospitals, a world-renowned burn center and 13 regional family health clinics, making this my fifth industry, a healthcare delivery organization.

While the title of my article is “The Application of Disciplined IT Processes and Methodologies within Healthcare” the following can be applied in any industry!

So, what is common in information technology across these five industries and I would argue all industries? It is the application of consistently defined processes in the design, development and deployment of IT systems and applications. Many of my colleagues may debate whether many of us are in the “development” business anymore, but we are!

While it is very true, that many of our organizations are no longer doing “pure” software development where we’re defining, designing, developing, and deploying our own software applications. Many of us are now in the job of defining and procuring COTS “Commercial Off The Shelf” solutions. We’re doing more configurations and “glue” development as I call it; which is the integration of these applications with either API or other types of application/ data integration. Indeed, we may be writing “lighter weight” custom applications that again interface or integrate into these COTS solutions.

It is my contention however, that many of the fundamental processes we’ve used in developing software, are being forgotten or not applied due to the myth of procuring COTS solutions. How many of us have been bitten during late stage deployments of a COTS or SaaS (Software as a Solution), only to find out that there was a missing integration component to a legacy application, or that the “slide ware” the salesperson showed us did not materialize within the application.

In my experience, I have been caught by these types of scenarios far too many times. Further, my customers or constituents don’t really believe we need to do requirements definitions, since what we’re deploying is a SaaS or COTS solution, etc.

I firmly believe that we as CIOs must ensure that our organizations are indeed following disciplined processes and methodologies irrespective of whether we’re applying custom development or a COTS / SaaS application deployment.

Many of the fundamental processes we’ve used in developing software, are being forgotten or not applied due to the myth of procuring COTS solutions


This is certainly further exacerbated if you’re in an industry, like Healthcare, where our systems, applications, and solutions are “mission-critical” or intimately involved in the safe delivery of patient care!

To help alleviate these challenges, I have led the development of a coordinated SDLC, Systems Development Life Cycle framework that coordinates the activities of our PMO, Project Management Office; SDLC methodology; supported ultimately by our ITSM, IT Service Management processes.

This framework is depicted below in figure 1.

The entry point to this framework is the intake & assessment process of our PMO. This process triggers an assessment of any new technology that has the potential of entering our enterprise. As the PMO process matriculates, you can see the interaction and coordination with the SDLC methodologies and ultimately the support of our ITSM processes. At the last three organizations I’ve led, I have mandated the use of the ITIL (Information Technology Infrastructure Library) framework for IT service management.

Every employee in the IT organization at a minimum must achieve ITIL v3 Foundation Certification. This allows a common vocabulary or vernacular when talking about IT Service Delivery. When deploying the ITIL framework, I always begin with Incident and Problem management within the Service Operations area and then work backwards to get to Service Strategy and Definition which would align to the SDLC “Design” process, which then aligns to the Intake & Assessment and Project Initiation processes within the PMO methodology.

The overarching key to all of this is the intake and assessment and the requirements phases. In other words, how do you know if you’re going to give your customer what they wanted, if you didn’t effectively define it in the first place? I find this an extremely valuable and necessary technique in ensuring appropriate business and clinical alignment and ownership when we work jointly in these defining opportunities.

To further illustrate the importance of good design or requirements definition, many of the readers may also be familiar with Boehm’s Curve.

Boehm’s curve is attributed to acclaimed software/ systems engineering professor, Barry Boehm. Dr. Boehm is credited with the development of the Constructive Cost Model (COCOMO), and the spiral model of the software process. I’ve utilized many of these techniques or their subsequent variations over my career. The model depicts the common misconception that if don’t invest much time at the front end of the process the project will “get done sooner”. When in fact the reality is the project never really is completed, due to the amount of rework that typically ensues due to the lack of good requirements and design up front. This is truly the “cost of quality” since the project really is never done!

However, if you invest in better requirements and effort in design it is statistically proven to yield a far higher quality product when deployed and the project/program is completed with much higher quality and higher end user satisfaction!

In summary, while it’s true most of our teams are not developing applications from scratch as we used to; it continues to be my assertion that our organizations are paying a high price in less than optimal deployments, more dissatisfaction and frustration, and ultimately a higher total cost of ownership, due to the fact that we’re not applying the rigor, discipline and consistent processes that we used to.

We absolutely can tailor these processes and methodologies to align to the degree of risk that a program carries, i.e. is it a “mission-critical” solution, high capital cost, etc.; but ultimately, we all want to ensure we’re capturing our user’s requirements completely and deploying the resulting solution effectively, meaning the solution they wanted, with high quality, on time, and on budget!