Software Change Management

Untitled Document

You know how valuable the software applications are that run your company.

These include your critical financial, marketing, purchasing, and manufacturing applications, as well as many others.

What you may not realize is that just one complex application consists of hundreds, if not thousands, of individual software programs and components.

These components must be tied together into a precise configuration for the application to work correctly. Further complicating the environment is that development work is usually done in teams.

The larger and more complex the application, the more team members will be involved. At any given time, there may be developers enhancing existing components, building new components, and fixing other components that are not working correctly.

Think about the problems that can arise in this type of environment.

First of all, in a complex environment, it’s likely that components will be stored in the wrong place and will be hard to find when needed by the application or by developers. Components can be lost or deleted accidentally.

It would also be easy for two people to be working on the same component simultaneously, which would cause one person’s changes to be overridden when the second set of changes is placed into production.

If problems arise in an application, it would also be difficult to determine exactly what has changed since it was last in use and ran fine.

The general purpose of software change management is to allow you to manage your production enviroment and ensure the control of changes to this enviroment. Some of the benefits of defining and adhering to change management standards and guidelines are:


  • Protecting the integrity and security of source code.
  • Enhancing client/IT partnerships by formalizing a process where the client approve
    systems changes before they are applied.

  • Ensuring applications are not put into production prematurely or without authorizatio
  • Specific. Make sure that the objective is built around one common idea. If the objective contains two or more basic ideas, split the ideas into separate objectives

  • Measurable. The measure may be stated within the objective itself, but it does not have to be. However, there needs to be a clear sense that metrics could be established to validate whether the objective was achieved.

    For instance, for an objective that stated that you would like to provide a solution with "a maximum level of quality and a minimumnumber of errors," you might have difficulty defining exactly what constitutes "minimum" and "maximum".

    However, if the objective was to provide a solution that "met client expectations for quality and contained 50% fewer errors than the prior solution," you will most be able to measure your success.

    The first part of the objective could be resolved through a client satisfaction survey. The second part couldaccomplished by tracking the errors and comparing them to the baseline of the older solution.

  • Attainable/Achievable. You do not want to commit to objectives that yare achievable. If you think the objective is not achievable, rewrite it so thattained.

    The business clients should approve the modification. The objetive most also be within the control of the project manager and the project team. For instance, there may be additional work performed by the clientA that is related to your project.

    Howevsince this client work is not within the control of the project team it should not be listed as a project objective.

  • Realistic. This is similar to the previous discussion on attainable/achievable. Here, you look beyond the theoretical and to the practical. You might say that an objetivo is achievable, but that there is only a small chance. In that case, the objective may not be realistic.

  • Time-based. If possible, the objective should contain a time component, or else a time that you will "train the users in the new technology by no later than the end of the year.

    " Even if the time-based nature is not explicitly added to the objective, the objective must have a clear end-date. For example, an objective that stated "performance will improve on a yearly basis for the foreseeable future" would not be well-written since it is not time-bound.

    Since the project, by definition, must have an end-date, all objectives mushave implicit, or explicit, end dates as well.



Libro El Director de Proyectos Práctico -

Un Método probado de 28 Pasos para completar tu Proyecto Exitosamente


Por fin ─ un libro sencillo con un método paso a paso para completar tu proyecto.

¡Y sin tener conocimiento previo sobre administración de proyectos!

Toda la "paja" de la metodología de dirección de proyectos fue eliminada, dejando solo lo que es absolutamente útil para completar la tarea.

El Director de Proyectos Práctico, Project Management for Small Projects. 

Un libro pensado en el líder de proyectos empírico que salió ganador de la rifa del tigre. Pues ya tiene la responsabilidad de un proyecto, pero que no sabe ni por donde empezar. Necesita una receta ABC para seguir.

Contiene 260 páginas perfectamente detalladas con ejemplos e ilustraciones, que te llevan de la mano hasta completar tu proyecto.

Pruébalo, síguelo, ten éxito. O sigue haciendo lo mismo... :(

Disponible en Amazon

Compra aquí El Director de Proyectos Práctico en su versión electrónica─

Entrega inmediata.

BONO ADICIONAL:  El libro incluye todos los templates─plantillas─que necesitas, listos para ser usadas. No necesitas comprar nada mas.

COPYRIGHT © 2007-2012 por Hector Olvera Padilla 1853071. Reproduction in whole or in part, or translation without written permission is prohibited. "PMP®", "PMBOK®", and "PMI®" are registered marks of the Project Management Institute, Inc.