Process & Procedures

It should be clear in the project plan for all stakeholders that a certain project management model will be followed during the implementation process of the project, e.g. waterfall model, agile…This helps setting expectations for the milestones and output of the project in terms of the achievements in milestones, and also help the stakeholders better understand their roles and responsibilities based on the specified process and the procedures to follow while working in the project.

Software Process Standardization

A software development process is concerned primarily with the production aspect of software development, as opposed to the technical aspect. These processes exist primarily for supporting the management of software development, and are generally skewed toward addressing business concerns. Amongst the most common models for process standardization is the Capability Maturity Model (CMMI). CMMI is a process improvement approach that provides organizations with the essential elements of effective processes that ultimately improve their performance. CMMI can be used to guide process improvement across a project, a division, or an entire organization. It helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes. 

CMMI Levels

Maturity Level		Type of Processes
5. Optimizing	Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.	Process Control
4. Managed	Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.	Process Measurement
3. Defined	The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software.	Process Definition
2. Repeatable	Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.	Basic Project Management
1. Initial	The software process is characterized as ad-hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics.	Ad-hoc processes

The benefits you can expect from using CMMI include the following:

• Your organization's activities are explicitly linked to your business objectives
• Your visibility into the organization's activities is increased to help you ensure that your product or service meets the customer's expectations
• You learn from new areas of best practice (e.g., measurement, risk)

Change Control Plan

Change Control is a formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner. It reduces the possibility that unnecessary changes will be introduced to a system without forethought, introducing faults into the system or undoing changes made by other users of software. The goals of a change control procedure usually include minimal disruption to services, reduction in back-out activities, and cost-effective utilization of resources involved in implementing change.

Change control is currently used in a wide variety of products and systems. It is a major aspect of the broader discipline of change management. Typical examples from the computer and network environments are patches to software products, installation of new operating systems, upgrades to network routing tables, or changes to the electrical power systems supporting such infrastructure and off course change in the project’s scope.

Change Reasons

Let's consider some of these reasons:

Change Driver	Comment
The business needs have changed	Business needs are changing ever more rapidly, particularly as competitors explore new business models. All businesses must be willing to change if they are to remain competitive.
The organization has changed	It is surprisingly common to find that the organization undergoes some form of restructuring during the life of a project. This could involve mergers, acquisitions, being taken over, new departments, new business leaders, new products, new accounting structures, new locations etc.
Exploit technology improvements	The available technology improves constantly. All the time your Project Team are trying to exploit the various technology components, each of those components has a large team of people working to create a better version - and thus to make your version obsolete.
The organization’s priorities have changed	Although the scope and objectives of your project remain valid, the organization may decide that there are other business needs that have high priority and should be addressed.
New business partners and channels	Organizations are responding to the rapidly changing marketplace by forming new business partnerships and alliances. New business channels are becoming available through those relationships, e.g. using industry hub portals and intermediaries.
New legislation and regulations	There may be unavoidable external requirements over which you have no control, such as new regulations for data privacy, changed regulatory reporting requirements etc.
Globalization, standards etc.	The organization is making progress in presenting and managing itself as a global entity and, hence, there are new or revised standards for such things as website design, database definitions, corporate knowledge sharing, data warehouses etc.
Effect of other projects and initiatives	Other initiatives within the organization result in revised needs for this project, e.g. there is a new accounting system so the interface from our new system will have to be changed.
We messed up	Or, to put it more discreetly, elements of the project's design and deliverables do not fully meet the defined need and will need to be re-worked.

“A user is somebody who tells you what they want the day you give them what they asked for” - Unknown author

Change Control Process

Certain experts describe change control as a set of six steps:

1. Record/classify: The client initiates change by making a formal request for something to be changed. The change control team then records and categorizes that request. This categorization would include estimates of importance, impact, and complexity.

2. Assess: The impact assessor or assessors then make their risk analysis typically by answering a set of questions concerning risk, both to the business and to the process, and follow this by making a judgment on who should carry out the change. If the change requires more than one type of assessment, the head of the change control team will consolidate these. Everyone with a stake in the change then must meet to determine whether there is a business or technical justification for the change. The change is then sent to the delivery team for planning. The decision whether to accept or reject a change would be based on a number of rules. The fundamental logic should be:

• Is the change unavoidable (e.g. legislative changes, mergers, etc.)?
• or Does the change increase the overall benefit to the organization (taking into account any impact on the costs, benefits, timescales and risks)?
• and Is the Project Team able to make such a change?
• and Is the change best done now, or would it be more beneficial to defer it until the current work is complete?

3. Plan: Management will assign the change to a specific delivery team, usually one with the specific role of carrying out this particular type of change. The team's first job is to plan the change in detail as well as construct a regression plan in case the change needs to be backed out.

4. Build/test: If all stakeholders agree with the plan, the delivery team will build the solution, which will then be tested. They will then seek approval and request a time and date to carry out the implementation phase.

5. Implement: All stakeholders must agree to a time, date and cost of implementation. Following implementation, it is usual to carry out a post-implementation review which would take place at another stakeholder meeting.

6. Close/gain acceptance: When the client agrees that the change was implemented correctly, the change can be closed.

An efficient Scope & Change Control process should be defined. There are needs to be a balance between flexibility and control. If the process is too onerous, either valuable changes will be lost or the participants will ignore the rules - leading to uncontrolled scope and configuration. If the process is too easy, then many changes may be applied with insufficient thought given to their merits and consequences.

It is common to define various responsibilities and authority levels so that routine changes can be dealt with efficiently but significant changes receive due management attention. Where a proposed change affects the scope of the project it should be seen as a business decision requiring approval from the business owners of the project (e.g. Project Sponsor, senior leadership, Steering Committee). Where scope is not affected, it may be agreed that the Project Manager has the power to approve the change within certain authority limits. In some projects, Change Control Boards are defined and convened to consider and approve change requests on a regular basis, say every two to four weeks. Different panels might be appropriate for handling different types of change request. For example, a technical panel might look at technology issues, departmental leaders might look at the business processes, and the HR managers might examine organizational issues. Above a certain level of impact, the request would normally be referred to the overall Steering Committee.

Tip: Change is inevitable. During a project there will be many good reasons why things need to change. There will also be a few bad reasons - bad, but unavoidable.

The basis of decision for Change Requests should be agreed as part of the Project Definition work. It should define how the Project Manager is allowed to exercise the power to approve minor changes, and should provide guidance for the decisions of the Change Control Board(s) and Steering Committee.

Particular considerations occur where the change impacts the relationship with an external sub-contractor. Each time the work content increases the contractor might reasonably demand further time, resources and fees. If the change is due to the contractor's own fault, then, arguably, there should be no allowance made.

The Change Control process will involve a combination of procedures, responsibilities and systems. The key to success is to have a well-controlled but efficient process. Define and agree:

• on what basis changes should be approved,
• who does what,
• the membership of the Change Control Board(s),
• the detailed procedures, forms, etc.,
• protocols for levels of authority, e.g. what types of change can be approved without reference to the project's business owners,
• linkage to other management procedures, e.g. the issue management process, configuration management,
• which tools will be used to support and manage the process,
• how to communicate and promote the process and its importance to all participants.

“Change is the only constant in life!” - Unknown author

Configuration Management Plan

Configuration Management is the task of tracking and controlling changes in the software. Configuration management practices include revision control and the establishment of baselines.

Configuration Management concerns itself with answering the question "Somebody did something, how can one reproduce it?" Often the problem involves not reproducing "it" identically, but with controlled, incremental changes. Answering the question thus becomes a matter of comparing different results and of analyzing their differences. Traditional configuration management typically focused on controlled creation of relatively simple products.