beteo ALM Experts Blog

Category: Best Practice

  • Three Phases for Project Leadership Success

    The article Efficient and Targeted Project Execution describes how on time and on budget execution and successful completion of complex projects can be realized. It requires clearly defined leadership process covering all people involved supported by software-based leadership systems.

    Basically, the process of managing and driving project execution has three stages

    • Leadership Initiation
    • Leadership execution management
    • Leadership Closing

    Drei Phasen im Führungsprozess

    Fig.: The three stages of the leadership process

    1. Leadership Initiation

    The execution of every project should be marked by a clearly defined initiation. Setting up the process on an intelligent, elaborate and accurately described base concept can save a considerable amount of time and money.

    Initiation provides the project framework and defines the project guidelines, giving the project the actual go-ahead. A successful project start is crucial to the whole course of the project. Initiation particularly includes an exact definition and approval of the project. If the project scope including the individual goals is precisely and consistently defined, initiation is the valuable foundation enabling targeted work all daily leadership activities.

    2. Project Leadership – Project Execution Management

    The main phase is the actual phase where the project execution is managed. To ensure a highly efficient, proactive, and targeted leadership, it is recommended to base the leadership process on a standardized approach, a repetitive leadership process of measuring, evaluating, defining measures based on software-based project leadership system. Using both, leadership process and leadership system, has proven to significantly add to the chances of project success.

    3. Leadership Closing

    Every project must end with a closing phase. A deliberately scheduled closing resulting in an approved closing report avoids subsequent interventions. Apart from the closing report, the closing phase includes the acceptance by the client (e.g. customer, management), documented «Lessons Learned» and results that can be reused in next releases of the project or by other projects.

    A proper closing phase is an important and highly beneficial activity in the organization’s Lifecycle Management process and discipline.

    About the author:
    Robert Sutz is CEO of TimeWinner AG , Wallisellen, Switzerland.  TimeWinner AG develops and markets the Internet-based Leadership $ystem TimeWinner.

  • Is Tool-Supported Test Management Profitable?

    Every software project targets at providing high-quality software within the frame of a cost and time schedule. tool-based IT test management usually accompanies the whole software development process and partly adds to reaching this goal. This includes tasks like requirements management, test planning, test design, test execution, test evaluation as well as a superordinate defects management.

    Practical experience
    However, erratic and unsystemantic testing is general practice in many enterprises. A variety of manual steps, redundancies and inconsistent documentations are the order of the day, resulting in additional costs. On the other hand, high benefit could be achieved by use of a tool-based test management. Introducing the necessary test management tools, along with the suitable methods and processes, improves both the testing process and the software quality. The  benefit  provided for both the test organization and the IT projects can be summarized as follows:

    Testing gets

    • standardized (tool instead of free-text in Word/Excel), more systematic, more reliable,
    • less time-consuming, easier to execute,
    • verifiable (content and coverage), more effective and comprehensive,
    • traceable,
    • reusable, trainable,
    • it can be automated
    • and planned.

    Using test management methods and tools facilitates error recovery and consistently reduces error occurrence. Time and costs for testing and support are enormously reduced as well. This results in a reduction of total costs, higher quality, transpareny, improved system requirements and completion on schedule, if not ahead of schedule. Operation will be less error-prone with reduced breakdown frequency, leading to highest-possible customer satisfaction.

    The benefit is evident. The earlier an error is detected, the easier its recovery. But often, there is no time for testing, the project is behind schedule and people are under time pressure. Testing is considered a necessary evil. But tool-based test management is more than just a cost factor. If used in the right way, test management is a value-adding process.

    Potential return of tool-based test management
    Potential improvements are not easy to quantify. However, experience from successful implementations of the test management tool HP Quality Center has shown that real improvement is possible:

    • Improved product quality leading to
      • Less delay caused by bad product quality
      • Avoiding frequent emergency implementations during production
      • Higher customer satisfaction by meeting expected delivery requirements
      • Cost savings by less re-working and reduced support costs
    • Improved testing process leading to
      • Lower costs per test cycle by standardization and reuse
      • Standardization of planning, documentation and execution of tests
      • Less time and cost effort for preparation thanks to reuse of requirements, testing data and test cases
      • Fast test execution by automated regression testing
    • Improved use of test resources leading to
      • Savings by centralized use of HP Quality Center (hardware, software, support, services)
      • Automated test coverage management avoids the need for retesting or performing unneeded testing
    • Improved project delivery leading to
      • More predictable and optimizated delivery schedule
      • Test automation, less time needed for execution, reduced use of resources
      • Optimized use of project resources, e.g. by higher performance, better prioritization
      • Test resources are earlier made available to new projects (by on schedule delivery)
      • Comparable results allowing to continously improve test processes

    The aspects of potential benefit listed above can be used as a basis for profit calculation. By applying a scoping approach to the project, the relevant data and facts can be derived from above general potential advantages and applied to the particular environment, and the actual return can be calculated.

    Summary
    Test management is necessary and clearly improves the quality of software projects. The advantages of tool-based test management are evident. However, it is not always easy to quantify and clearly define the benefit. Often, a budget for testing projects is approved only after some unpleasant incident has happened. This can be avoided, though.

    Successful implementations of the test management tool HP Quality Center have shown that practical improvements can definitely be realized and the de facto profit can be calculated in advance. The general aspects of potential value can easily be transferred to the particular environment by applying project scoping. Data and facts gained then form the basis of a specific profit calculation. Tool-supported test management does not only pay off, but the benefit can also be quantified.

  • OC Oerlikon – How SAP Roll-in Projects can Fail

    On Friday, October 26, 2007, inside-it.ch reported that OC Oerlikon will stop its super SAP project. The new approach is said to provide a „more intelligent, more flexible and cheaper solution that integrates all ERP systems of the business units using a central SAP consolidation tool“.

    This seems to simplify things, but why is it that SAP roll-in projects fail one after another? As a solution architect and interested oberserver of such projects, I dare to give some simple explanations:
    The originally pragmatic plan to technically avoid a number of varying ERP environments is in most cases not the primary goal. Often, the roll-in project is targeting to implement an operation with identical processes all across the enterprise and to benefit from best practices. Extremely challenging goals!

    Unfortunately, the project’s target organization and processes for the overall company often end up being insufficiently adjusted to SAP. In addition, the organizational and cultural complexity of such a original technical project requires that all quality assuring measures are clearly defined and strictly adhered to right from the beginning. Very often in such initiatives this is done much later, if at all.

    Of course, these are not the only things to be observed in order to ensure success of a SAP R/3 roll-in project or any other super project. But to begin with, every project manager is well advised to be alert to the stumbling blocks in SAP roll-in projects as described above.

  • Project Roadmap: Quick Wins with Iterations

    My blog Scoping – A Guarantee for Success through Harmonized Expectations describes how to identify factors that are most relevant to the success of the project:

    • Expectations of all key roles are defined and synchronized from the start
    • The technical system architecture is designed
    • The functional requirements are defined
    • An implementation roadmap comprising project contents, required organizations and project procedure is set up

    Harmonized Expectations and Step-by-Step Implementation Targeted at Partial Success
    Experience has shown that defining and synchronizing expectations is of great importance. With regard to expectations, the project scope plays a major role. Unfortunately, project team members as well as clients often fail to define the project precisely enough, including a variety of options and features into the project. Limited time and budget available for a maximum content are part of everyday business. Teams are getting unfocussed and bogged down in details loosing sight oft the project target. The project clients get impatient, failures mute motivation, and the original business cases are questioned.

    It is well known that projects promise to be successful only if sub-goals are defined ensuring step-by-step success and continuously producing a visible benefit. This is particularly true for long-lasting projects. The main issue here is to focus on the most important and prioritized requirements and functions and adhere to their consistent implementation.

    Implementation Roadmap and Iterations
    One oft he main issues of the scoping phase is to generate a practice-oriented implementation roadmap. This includes clearly defined targeted project objects, a time schedule, and the organization implied. Experience has shown that dividing the project into several iterations with clearly defined targeted objects leads to business quick wins and to a successful completion of the project. To follow this strategy, the most relevant requirements and core functions are identified and implemented in iterations.

    The main goal is to provide constant benefit for the project client and the users as soon as possible. Quick wins are achieved by first implementing those functions which are most suitable to ensure the highest possible benefit. In further iterations, more functions are added to those successfully implied to finally integrate the solution step by step into further processes, methods, systems and organizations. At the same time, a consistent project management und project marketing support the roadmap implementation. Management, client, and users know at any time which functions are available to them, and when.

    Iterations Optimized by Quick Wins
    Dividing projects into several iterations provides decisive advantages. They vary depending on context and task, but in most cases, the following advantages are ensured:

    • System with core functionality which rather soon works efficiently
    • Systematic knowledge transfer to users and business by targeted training at the right time.
    • Quick benefit as a basis and guideline for further procedure
    • Early integration of business organization and building up support services
    • Optimistic attitude towards the project by successfully completing iterations and meeting the expectations
    • Flexibility in structuring the functional requirements and a manageable basis for Scope Change Management
    • Organziational changes are implemented step by step and associated with achieving success
    • Short feedback loops, „lessons learned“, can be implemented in the next iteration

    The Challenge of Implementing Iterations
    Very frequently, a rigid project procedure is set forth by large enterprises. In addition to document templates, this includes specified and standardized rules of phase acceptance. The project passes through several phases, comprising preliminary studies, rough and detailed concept, realization, implementation, and operation. A new phase can only be started, after the preceding phase has been completed. This approach is often contrary to the basic idea and the immense benefit achieved by an iterative procedure.

    It is true that dividing the project into several iterations results in quick wins. But if all iterations, i.e. new functions, are repeatedly forced to pass through all project phases from the preliminary studies to operation,  this necessarily implies disprofit by loss of time and additional effort. The great benefit is given away!

    It is quite important to find common solutions in collaboration with the responsible persons, for example, from the project management office (PMO) or from quality control. Experience has shown that it is recommendable to have the most prominent mile stones approved „officially“, whereas the individual iterations can be approved by project members and application of quality assurance measures. A step-by-step extension of this approach to include scoping and phase acceptance which is attuned to an iterative concept would be useful.

    beteo Iterations

    Summary
    The benefit of an iterative approach is enormously high. In the context of standardized and rigid project implementation, this can be quite a challenge. However, addressing it at an early stage, iterations can easily be integrated into the existing environment. In a further step, this concept can be extended to include scoping and phase acceptance particularly attuned to iterations.

    After harmonizing the expectations of all key roles and prioritizing the requirements, all functions should be divided into individual iterations according to their importance. This allows you to focus on the core features and the highest possible benefit. Systems are available to users at an early stage, providing efficiently working core functionality. There is a fast and well-structured knowledge transfer leaving more time for the organization to implement changes. Quickly and successfully completed iterations result in a sense of achievement and promote an affirmative attitude  towards the project.

    In addition, the iterative approach allows you to carry out faster feedback loops and more flexibility in planning further iterations. This ensures quick wins and step-by-step success of the project.

  • Project Scoping – Aligning Expectations

    Projects often fail to be successful due to diverging, badly aligned expectations
    Dozens of statistics seem to suggest that there are dozens of reasons why projects fail to be successful. However, a great deal of them are attributable to vaguely defined objectives, problems related to technical architecture and a lack of management support. These causes, in turn, are in most cases due to either too optimistic or diverging expectations of the parties involved. Very often, projects are initiated without having identified and documented expectations as well as requirements on the part of all expert and management key roles.

    Scoping: Efficient approach to defining project content
    This is where scoping comes into play. This approach is extremely helpful when it comes to describing the functional requirements, defining project content and an adequate proceeding, and designing the technical architecture. The scoping phase targets at mapping the relevant context, ideas, requirements and prerequisites of all parties involved in the project in a well-structured way, reaching an agreement upon the project scope and establishing the project guidelines. Fixing an order of priority and laying down a clear structure makes the demanded objects transparent, well-defined, and synchronises the expectations of all persons involved. Experience has shown that syntonized expectations are one of the most important factors to ensure the success of a project.

    Scoping Ansatz

    Scoping phase in practice
    Several steps are necessary to reach these goals. Most of them must be executed in close collaboration with the client. This includes:

    • Defining a common objective and selecting relevant persons for workshops and interviews
    • Informing or training the project team members in order to create a common basis
    • Recording of business-related and functional requirements, needs and ideas during workshops and interviews
    • Understanding the technical requirements and challenges, the system landscape, and the necessary integrations
    • Prioritization with regard to quick wins and a high payback
    • Attending to a common understanding and identifying the points where the project gains momentum
    • Elaborating a detailed implementation roadmap, including time management and organizational planning, split up in iterations optimized by quick wins
    • Presentation of the results to the management

    Implementation Roadmap
    One of the most significant results from the scoping phase is the roadmap for implementation. The roadmap includes not only project content and proceeding, but also a time schedule and organizational planning, and provides a basis for the project. It is recommended to split up the project scope into several implementation iterations in favor of a clearly structured step-by-step planning and in order to immediately provide maximum benefit to the project client.

    Core factor of success
    Principally, scoping should be a closely integrated part of the project methodology. If, for example, there are no interviews, this will cause lead to a sign of alarm at the quality gate. If necessary, this item must be re-worked – or there is a clear decision not to do so.
    Experience has shown that the choice of persons involved in the scoping phase is of great importance. The key roles might vary depending on the task and the context, but it is indispensable to involve the client, the top management, the users, and the experts as regards content and technical issues. As soon as the participants are selected, the core factor of success are their availability as well as competent scheduling. We also recommend to have two persons hold the interviews in order not to loose sight of important aspects and to ensure complete documentation.

    Summary
    Scoping is a good way of fine-tuning project ideas and analyze the approaches to solution finding. Preferably, the scoping phase is an integral part of the typical procedure of all projects. As all information is collected by relevant key roles, the required data can be accessed, translated into requirements, and given a defined level of priority. From this, the concrete implementation roadmap is derived. Thus, the project idea is clearly defined, and the project scope is fixed with consideration of processes, organization, systems, including required system integrations, and other dependent processes. All persons involved in the project have a common interest in and are focused on the same issues. Their expectations are synchronized. The momentum gained by this common basis is the most significant stimulus for all to make the project a success story.

  • Software Archeology – how to Successfully Change SAP Releases

    16th century. The eyes of an archeologist are scanning a field. He is asking himself where he should start digging. In his life, he still has a few years left. Which area would, from his experience, hold a chance for him to make a discovery? Then he notices a tree. For growing, it would need nutrients, so underneath there might be something. This is what he knows from experience.

    When he starts digging, he hits on a small house of a rather poor family. Disappointed, he gives up.
    200 years later, a larger excavation project is started. The settlement is found to be the most important source of information about ancient times.

    SAP
    Those who know me are acquainted with my writing style exposing my affinity to exaggerate. Let´s take a typical SAP project, a release upgrade, for example. Doesn´t differ that much from the story of the unlucky archeologist, I think. In the beginning, you often know little about a system. Everything seems to be underground. You are asking yourself how to address the release change, and on the basis of which information you might dare a prognosis. What will happen during the project? If you are lucky, the consultant experts have a fair knowledge of the system and the processes implemented on them. If not, the project will almost typically go beyond its scope on the two axes expenditure of time and budget planning. As some of the most important project phases, such as testing and training of the end user, are neglected in favour of the implementation phase, you will be faced with a quality problem. This, in turn, will have an impact on the third axis, the user acceptance.

    The way out
    Typical SAP projects, such as upgrades, are planned according to the waterfall principle. But one important step of this method is massively neglected: The requirements analysis, also known as gap analysis – in other words, the question, „How did SAP influence OUR particular standard?” If you want to comprehensively answer this simple question with reference to a SAP landscape, the only solution to the “problem” of such massive analysis is its automation.

    How can you access best quality and complete information in the shortest possible time?
    There are quite a number of vendors who offer analysis tools, from SAP Consulting via RBE up to IntelliCorp. Each of these tools focuses on a particular aspect and therefore has its individual potency.

    IntelliCorp´s Assessor Template for SAP Upgrades addresses the problem on a rather broad basis. The tool offers a variety of fully automated analysis workflows. Within a few days, three on average, it provides a wide range of material for use in the context of a detailed planning of the upgrade project. As a side-effect, the result provides a basis for the implementation team to operate on. Its high degree of flexibility makes it a tool which is suitable for all SAP applications, including commercial solutions, integration of third-party software or own namespaces in workbench.

    About the author: Fritz Mosonyi is senior consultant and division manager for SAP tools at beteo partner SPP Wien.

  • SAP Change Impact Management – PHW Business School and beteo study

    In collaboration with the PHW Business School, Zurich, Switzerland we are conducting  a study in the IT Change Impact Management area.

    We are analyzing a specific challenges of international corporations using SAP as their corporate software globally and specifically the challenges of their IT development organization because of impacts given by system consolidaton centralization efforts.

    Fundamentally we will focus on the following issues:
    – what benefits were and are to expect from these consolidation projects?
    – What are the (intermediate)  results?
    – What new challenges are there for further developments in the centralized SAP system and development world?

    The goal of the research is to analyze trends, identify possible sources of trouble and generate possible solutions for the new challenges.

    In order to accomplish this, we will conduct expert interviews with selected contacts in person and/or on the phone. The results will be available to all interview partners. We want to actively increase the interaction between client, partners and experts in this study.

    Interested? Leave a comment in the blog or get in touch with us, studie@beteo.ch.

  • Configuration Management for SAP Customizing?

    A comprehensive configuration management is the most important basis of SAP Change and Transport Management. For ABAP code, this is accepted as general practice and supported by suitable tools. But how about configuration management for SAP customizing?

    From our experience, the major part of changes transported across a SAP system landscape are customizing changes. Not surprisingly, the persons responsible for change and transport management often keep struggling with problems after roll-outs for lack of consistently applied configuration management for_these objects. A consistent change and distribution of customizing requires stringent configuration management.
    Crucial to a cross-enterprise use and protection of SAP templates is that central and local objects are well documented, comprising all versions of their lifecycle up to the newest version.

    Comprehensive SAP configuration management all across the SAP landscape is meant to ensure overall integrity of the objects involved in SAP development, including ABAP as well as non-ABAP objects:

    • The use of well-defined standardized naming conventions clearly reveals to which organizations, areas and projects the objects belong.
    • All changes to objects, including individual customizing settings, are documented. At any time, it is obvious who is – and at which times – the owner of settings, who is entitled to make and has made changes and for which reason. This allows the changes to be tracked afterwards, which is an equivalent to versioning.
    • The documentation also includes the information as to who and what and who depends from a defined customizing setting. This is an integral factor of reasonable impact management.

    In the context of each change to the SAP landscape systems, it must be made sure that the rules listed above for practicing a comprehensive SAP configuration management are observed. This, again, requires a strict organization of the change und transport management. Naming conventions for transport objects and transports must be established, transport packages must be grouped according to their content, organizational and technical processes must be clearly defined and adhered to.

    Some projects are highly dependent on a consistent comprehensive SAP configuration management. Without this, very often the challenges to enterprise SAP organizations can hardly be mastered, especially in the context of mergers and acquisitions, strategic outsourcing projects, insourcing, and regional or global consolidations of systems. This is also true for customizing changes. However, a solid foundation as outlined above allows such projects to planned and implemented with reasonable effort and fair success. Also customizing changes of several systems can be consolidated without a negative impact.

    In addition, a comprehensive SAP configuration management allows you to permanently record the data related to transports, to the transported objects and to the result of the transport, and to evaluate them. This is comparable to using suitable analyzing tools, such as the one offered by Prospero, which have been designed to disclose the causes of problems in SAP logistic processes, or even to give a prognosis concerning their results. The same is achieved by using SAP change management data for the transport of SAP changes. In any case, SAP change and transport management has still plenty of room for improvement in complex SAP landscapes.

    Summary
    Applying a wide-ranging SAP configuration management has turned out to be the most effective method to ensure a consistent and efficient SAP change and transport management and a consistent customizing across the SAP system landscape.

    Unfortunately, the opportunity for global enterprises using large SAP systems to improve the quality and to save costs by investing in SAP change and transport management is very often not seized, because it is thought to be technically complex. But if the challenge is taken up it soon shows that the problems are more political or company-related than of a technical nature.

  • Proof of Concept – Less Risk for System Implementations

    Scoping for defined requirements and harmonized expectations
    The scoping approach allows you to define requirements, expectations and project scopes when systems, methods and processes are implemented. This results in aligned expectations, a well-designed system architecture, defined requirements as well as a structured implementation roadmap. If the roadmap is implemented in several iterations, quick wins are achieved in addition to a direct benefit to the project client and the users.

    Technically complex problems as a challenge
    If system implementations are planned in technically complex environments, in addition to the purely technical requirements that have to be met, the following questions should be addressed:

    • Is a clean system installation possible?
    • Can the solution be integrated into the existing system landscape?
    • Which is the best way to coordinate the installation and integration with the IT organization
    • Are all used technologies compatible?
    • Which interfaces are affected, and in which way?
    • Can the described functions really be implemented?
    • How does the system behave with regard to usability?
    • Will the system be accepted by the users?
    • Which are the actual costs to be faced?
    • Which technical capabilities and roles are required for the implementation?
    • Can the planned benefit really be achieved?
    • How about the capabilities of partners, manufacturers and providers, and what characterizes collaboration with them?

    The above questions are only part of the criteria which are relevant to success. To answer them, further activities are necessary. Very often, there is a great deal of uncertainty about the technical and organizational feasability of the project as well as about the time and costs involved.

    Proof of concept: minimization of risk in decision-making process
    In the context of system implementations, proof of concept (POC) equals a technical feasability study. POC can be used as a part of scoping to check for technical and organizational feasability of projects. Prior to execution, the criteria relevant to success and the subsequent steps must be clearly defined in order to ensure maximum benefit. For working out a POC, it is recommendable to implement a mock-up or a prototype comprising the core functionality. This allows to test the functions, define them accurately and involve the users in the planned project at an early stage. Proof of concept reveals which requirements can be met in which way and which functionality demand workarounds or additional solutions. Thus, time and cost expenditure for installation and integration into the existing system landscape can later be well estimated and planned in agreement with the responsible IT organization.

    Pilot pojects as a performance indicator
    Experience has shown that working with pilot projects significantly adds to success. The prototype is used in productive systems on a limited scale. There are various alternatives to proceed:

    • limited user group
    • limited functionality
    • limited process scope
    • limited and/or isolated system environment

    Working with a pilot project allows you to rather accurately pre-estimate if the system in action meets all requirements, covers the planned functionality and proves to provide the expected benefit.

    Summary

    Proof of concept allows you to find out if the implementation of a system can be technically realized, and to evaluate the capabilities of manufacturers, partners and providers as well as the quality of collaboration with them. In addition, the expected time and cost expenditure for installation and integration into the existing system landscape are made calculable and can be planned in accordance with the responsible IT organization. Prior to execution, the criteria relevant to success and the subsequent steps must be defined.

    It is recommended to create a prototype which includes the core functionality, i.e. those functions from which the greatest benefit is derived. This allows the users to be involved at an early stage of the project; as a positive result, user-friendliness and acceptance by users can be evaluated and taken into account. If the prototype is tested in the context of a pilot project with either a limited user group, limited functionality, limited process scope, or on a separate system, this will result in a realistic view of the potential of benefit. Proof of concept is used to work out facts and foundations in order to minimize the risk of making inappropriate decisions in the process of system deployment.

  • Lifecycle Management – no Pain, no Gain!

    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.

Powered by