Dieter SteigerDieter Steiger Lifecycle Management – no Pain, no Gain!

06/24/2008 by Dieter Steiger

Successful IT Planning & Control must include not only IT Service Management and Project & Portfolio Management, but also Application Lifecycle Management in order to be of lasting benefit. The following illustration by Gartner clearly demonstrates this.

IT Planning- & Controlling

Considering the support of the various areas and, above all, of the interfaces between them, it is obvious that helpful methods and high-quality tools for Service Development (Project & Portfolio Management, Design, Development and Testing) and Service Delivery (IT Service Management) are available and in use.

On the other hand, tools and methods supporting the interfaces between the different areas and to Application Lifecycle Management in general seem to be rather scarce.

At the same time, Application Lifecycle Management promises attractive benefits like:

  • a noticeable increase in developer productivity
  • “best practice” in development and service roll-out
  • a clear focus of developers on business instead of technical requirements
  • largely improved collaboration between development and business area
  • improved time-to-market by repeatable and partly automated processes and generally improved resource planning

The software manufacturers priding oneself on their solutions that are supposed to reduce either project or operating costs are getting a bore. To them, the direct interdependencies between business and development are rarely of central concern. Statements as to the benefit of the solutions usually refer to either of the two aspects, and very often, improvement on one side is combined with a dramatic rise of costs on the other. This is why this topic is often referred to as the general “IT dilemma”.

A relevant issue of “good” software engineering is a comprehensive requirements management, covering diverse influencing parameters. However, there are few cases where with each requirement all depending lifecycle objects are taken into account right from the start. But without this, recognizing competing requirements as what they are is impossible. What is more, hardly ever consideration is given to changes that are being implemented. Thorough IT Planning and Control across all fields of activities including their interfaces also comprises referencing and versioning of the describing, organizational and technical objects and their relation to one another. IT Service, and IT as a whole, is regarded and referred to as a complete system.

The same is often true for business: IT Service Management (ITSM) includes Trouble Tickets without a clear reference to the concerned objects in Application Lifecycle. Information about the newest changes is not passed on to either the present development or the planned projects. This results in duplication, inconsistencies and considerable effort put in subsequent coordination. Any kind of re-use following the change or the newest project release is moving beyond reach.

“Comprehensive” process frameworks and methods such as ITIL, PRINCE2, PMI and COBIT or SOX audit and compliance standards are just as unsuitable to overcome the “IT dilemma”, because they all disregard the interdependencies between the Service Lifecycle objects, meaning between processes, services and all technical objects. Although it is the intent and purpose of all these standards to diminish risks, I doubt if they can half-way reach this target without taking these dependencies into account.

To me, the only solution in sight is introducing a professional method- and tool-supported Application Lifecycle Management.

Sphere: Related Content

No TweetBacks yet. (Be the first to Tweet this post)

2 Responses

  • 1
    Bernie Leadbeater:

    That’s true of PRINCE2 because it is not what it’s for! Projects deliver different types of technical products. PRINCE2 helps to manage progress through the project, and can happily accommodate any extra methodology for dealing with specific product types.

  • 2
    Herman Driessen:

    Hi Dieter,

    Thanks for your blog. I found it by Google alert.
    Every time I see the phrase “Requirements management” I wonder why people are so excited about RM, RM tools and traceability. I know from my defence experience that RM is important, but I see very little excitement about the requirements themselves, that form the start/basis of RM. If these requirements are incomplete or inconsistent, then how will RM help us during the requirements analysis phase?

    So, I would like put emphasis in the requirements themselves, and the analysis of these requirements, before we do any RM. Admitted, there is self-interest too, since I developed a tool Requirements Assistant (see my Website). The tool analyses 1) each requirement as a sentence, 2) each requirement as part of a paragraph, and 3) each requirement as part of the whole set.
    The aim is to assess completeness, consistency, vagueness, ambiguity, etc early in the Lifecycle.
    The tool was recently evaluated by NASA IVV and it is being used on their Orion and Juno programs.

    Have fun!