The Death of SDLC


In the early days of IT computing, many organizations had custom systems built to meet their specific needs. Programmers adopted the System Development Life Cycle (SDLC), which guided their actions during the various code development phases until the system was fully built and tested.

Over time, organizations realized they could benefit more by getting out of the custom system development business in favor of implementing pre-built Commercial-Off-The-Shelf (COTS) applications. Unfortunately, the basic methodology used to help organizations implement, adopt, and realize benefits from COTS systems still follows the SDLC, which was created to facilitate the technical development of computer code. So, what’s wrong with SDLC? Why do we need to consider alternatives?

  • SDLC is focused on addressing technical development challenges, not on driving user adoption and measurable business benefits.
    • User adoption and business benefits are primarily human performance challenges.
    • SDLC was not created to address human behavior, and it does not do so effectively.
  • Most IT projects only include limited “change management” as a bolt-on to the end of the SDLC cycle without critically examining if this is effective. Typically, it’s not.
  • Many IT projects following the SDLC are structured such that once the technology is live and stabilized, the project is complete.
    • Change Management is typically treated as a “one and done” focused on the initial deployment.
    • Ongoing efforts are required to drive and sustain user adoption over the life of the system. These are typically absent from most change management efforts.

Consider This

Organizations need to view IT projects as human and organizational performance projects that just happen to involve deploying new technology. They should not view them simply as technology projects. Changing the way we perceive, approach, structure, and execute projects will improve benefits realization and help organizations achieve measurable business goals.

  • Organizations need to move beyond just following the technical SDLC and instead adopt more robust human performance improvement methodologies. These methodologies need to address the myriad organizational and human performance challenges that affect how people use technology.
  • User adoption methodologies should NOT be dictated by technology experts or by people who blindly following existing methodologies without understanding how to change their approach to address the deficiencies of current efforts.
  • The people who develop and execute user adoption methodologies should have a firm grounding in the fields of psychology, organizational behavior, and human performance such that they understand the theory, research, and practices upon which sound change and user adoption methodologies are built. It is not sufficient to simply know how to apply an existing methodology when the methodology itself may be part of the problem.

Things to think about

  • Do you primarily follow the SDLC approach to your IT projects, or have you updated your methodology to better address the human and organizational performance challenges ignored by the SDLC?
  • Do the people who are defining your change management and user adoption methodology have expertise in the relevant theories and practices from the fields of psychology, organization development, human performance, etc., or are they primarily technology specialists? Could they develop an effective human performance improvement program if there were no new technology being deployed?
  • If you were brought in 3 years after the system is live to address user adoption challenges (without changing the system or processes), what specific things would you do to improve adoption and increase human performance? Have you included these activities in your initial change and adoption approach?
  • Does your current methodology include developing the structures, processes, policies, and activities required to measure and sustain benefits realization over the entire life of the system? If not, how will you ensure user adoption & benefits realization continue 1, 3, 5, 10, etc., years in the future?