Have you ever wondered what is the best approach to establish the relationship and the placement of the tasks of the various software disciplines? Have the project managers, developers, and testers been confused because they generally know what CM is but are not clear where CM tasks should occur in a project release lifecycle and how they relate to other disciplines?
When considering the placement of tasks for engineering disciplines such as configuration management (CM), project management (also referred to as project planning and project tracking), requirements management (or requirements engineering), and testing (also referred to as QA or SQA), it can be difficult to understand the big picture of the disciplines and how they inter-relate.
This is where utilizing the concept of release management as a super discipline into an organization may be beneficial. While CM can be considered a discipline, release management can be considered a super glue discipline that holds the other disciplines together and a context discipline that provides a structure within which the engineering disciplines reside.
Introducing release management as a super discipline or structure for the engineering disciplines provides a model for establishing the context for how the disciplines can work together. By providing a context in the form of a lifecycle model, from project initiation thru release/installation, this creates a map of the process for easier understanding of the big picture of the release. Granted, this is at a high-level, but a consistent problem with performing the various engineering discipline tasks is that there is a lack of a high-level model for understanding the context of one task with another and the attributes of each task. For example, CM tends to be thought of as a collection of tasks found within the development phase of a release, but typically lacks a context when it is being utilized earlier in the lifecycle. This tends to lead to CM being viewed as just a tool or just version control task. It would be better for CM tasks like establishing a change control board or problem management function or preparation of a configuration management plan (CMP) to be visible at the beginning of a project. The indication of where tasks should be introduced, gives those on the project team a more clear understanding of where the task occurs and gives project team members an opportunity to participate. Release Management provides the context which (when used effectively) allows CM to be visible in all parts of the lifecycle.
Equally important to establishing the context of tasks are defining the task attributes which include the task name, role, procedure, technology that support the task, and the output of the task. A brief example of this is the task named “check-out code.” The role is the developer; the procedure is the check-out/check-in procedure; the technology is the CM tool; and the output is the checked out code module.
The benefits of the identifying the attributes for each task provide:
· Identification of the technology that support the creation of the release
· Processes needed to manage all aspects of the release
· Roles and responsibilities that improve accountability and reduce confusion
· Identification of expected output
· A common understanding and terminology for the project team of the engineering disciplines across the release lifecycle
By seeing the discipline’s tasks in context with other tasks while also understanding the attributes, dependencies and the connection between the tasks of various disciplines across the project, the lifecycle becomes clearer. Tasks in the early part of a project release include identify requirements, estimate requirements, prioritize requirements by release, and approve requirements. By having these tasks identified in a lifecycle model, those involved in the test discipline who are more commonly involved in the backend of the release lifecycle, can identify where their involvement (aka the role of test) in the requirements phase may be beneficial. In some of the requirements tasks, the test role can ensure that the requirements being identified are actually testable.
Within a release management approach, the disciplines can more clearly work together to focus on the release of deliverables or functionality from requirements to production. Since the focus of release management is on the release and the tasks that support the creation of the release, this approach allows a person or project team to see the overall picture and the placement of the specific task in support of the release.
Once the context and attributes are defined within a lifecycle model, there is clear identification of the technical and tracking components of release management. The technical component includes the technology and environments needed to support a release. For example, this would include design tools, development tools, SCM tool and repository, the test environments, etc. The tracking infrastructure includes the processes and output (aka, project release artifacts) needed to define and move the project that supports the release forward. For example, this would include the requirements for the release, a project plan, various procedures used during the release, roles and responsibilities on the project that is producing the release, etc. An effective way of using this approach is to turn the release management context into a graphical map where the tasks of various disciplines are placed in context to each other and to the overall release lifecycle. Consider several high-level steps for each phase of a release lifecycle and then identify the attributes (step name, the role responsible for the task, the procedure used, the tool used, and the intended output).
From this, divide the high-level tasks into more meaningful low-level tasks. For example, identify and approve requirements (as seen above) would be divided into the following tasks: identify requirements, estimate requirements, prioritize requirements by release, and approve requirements. If an attribute of a task is missing, this is a good method for identifying areas of improvement (if a procedure doesn’t exist, then this can be an improvement activity). This can be an effective way of introducing the disciplines to a project team and their inter-relationships with other disciplines. Also, at the beginning of a project lifecycle, this can be an efficient way of introducing the project team to the roles, tools, procedures, and expected output of a project release.
Ultimately, release management provides an overall roadmap on which different disciplines, and specifically the tasks that support those disciplines, can be placed. The next time you are looking to introduce disciplines as they relate to a release and a project team, consider using the release management approach as a super-discipline to provide the context so that each discipline may be more easily understood and utilized effectively with other disciplines to the overall success of the project release. It will provide an overall picture of the task in relation to a procedure, tool, role, and output; a stronger focus on the release; and a model for the engineering disciplines to easily fit and work together.
