Skip to Content

Did you encounter this situation yourself? The project is over. The money has been spent.
The planned project-time has been needed. Surprisingly not every requirement was delivered.

How could this happen?

Imagine a waterfall-based project methodology. The phases of this approach have been described by several authors. Let me use here for simplification reasons the unified waterfall model and 1st of all list the phases:

  • Requirements
  • Design
  • Implementation
  • Verification
  • Maintenance.

All of these phases to my opinion are used in ALM (= application lifecycle management) approaches.

My kind of ALM approach starts with the implementation phase handling requirements, blueprint, design, implementation & test, project management and open issues. By using every capable method of verification to set the project live you will enable your customer to handle IT service management for the software delivered by the project. By taking monitoring and operations control center capabilities into account (maintenance) there is a good chance that your software can be run. A mature software will be handled then by change management. If in the monitoring and run phase an error occured this incident could be handled because of references you inserted into the software in the implementation phase.

The possibilities of structuring your project by using methods of an ALM approach ensure that your project gets into maintenance in a “in time” and “in budget” manner.

But how do you start to avoid errors and manage successful software projects by using an

First of all answer all of these questions for your company and consider the bold marked methods:

  • What means Application Lifecycle Management in my company?
    -> interviews.
  • What is done actively to avoid known errors in the “organizational change process”?
    -> early and frequent information to ensure your management’s buy-in before you start.
  • Do I have an overview about all requirements of my project?
    -> solution readiness matrix.
  • How do I ensure, that at the end of my project the enduser gets everything delivered
    what the business process expert did require by me? -> completeness checks.
  • Am I able to report the progress of my project beginning in blueprint, covering the development and ending in the delivery phase? -> solution readiness dashboard.
  • Is my delivered project ready for maintenance and ready to run?
    -> checklists for application management team.
  • How do I handle changes?
    -> structure the information of changes by using the 7R of change management.
    Remark: There is a good practice derived from ITIL called “the 7R of change management”. This information should be known and entered already in the requirements process.

How described in blogs about Change Request Management with the SAP Solution Manager every project step is adressable (revision-proofable) and is traceable by a bi-directional traceability from the source of a requirement to the goal of a successful software implementation. Make the work of your maintenance team much easier by entering the project requirements following the 7R
(Raise, Reason, Return, Risks, Resources, Responsible, Relationships). If an incident occured, all the information to trace back to the requirement is available in the source code and in the linked transaction types.

Providing this information is a good starting point for the mentioned methods.

Using an ITIL-certified ALM-Suite (like SAP Solution Manager) additionally ensures that the most common errors in the “organizational change” of huge system change requests could by handled by transparency and a single source of truth. This means that every stakeholder looks at the same data.

What you can do to go a few steps further, by applying ALM-techniques:

  1. Reduce the complexity of a project by early prototypes and by using a bi-directional traceability-matrix.
  2. Make manager dashboards available for requirements, user-stories, testing results, development-IDs or backlog IDs.
  3. Test fearlessly. Report errors.
  4. Settle a trustful relation to every stakeholder early in your project.
    As an example you could design the processes and user interfaces together with the business requestors and lead them by iterative or agile project methods. This ensures early future oriented change needs.
  5. Do an appropriate positive marketing for your project.

Everything mentioned here could be ensured by using SAP Solution Manager. My good practice is to use the newest version Solman 7.2.  End of 2017 the general maintenance for Solman 7.1 ends, so don’t hesitate. Start now your upgrade project or start in a greenfield project approach with SAP Solution Manager version 7.2. Optionally install the Focused-Build add-on described here:

Further Information for ALM: (German blog):


To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply