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!