Author: Muralitharan Ramalingam

Ways to Manage The Fear of Scope Creep

Written by Muralitharan Ramalingam on November 20, 2017. Posted in Articles. 5 Comments on Ways to Manage The Fear of Scope Creep

This paper is designed to provide a framework on ways to manage the fear of scope creep in a project.

Introduction

Scope Creep, as the term sounds tends to give the “creeps” to the project manager if it is to happen in a project. It is treated as a threat to any given project as it will cause the “project triangle” which consists of cost, schedule and scope to be affected and which will also indirectly affect the quality and profitability of a project.

What is Scope Creep

Scope creep is defined as an additional workload or changes from the originally agreed project scope and normally happens when the project scope tends to give way for ad-hoc processes to happen during the mid-way of the project without anyone noticing. This will eventually lead to extra stress to the resource and timeline of the project. On some projects there are scope changes every week, or even several times a week.

Different types of Scope Creeps

There are several types of scope creep that can happen in a given project and below are a few keys issues:

Changing the original requirements
New requirements being added and removing existing requirements
Change in technology
Changing and adding of new stakeholder

1. Changing The Original Requirements

A major reason for change in the original requirements is due to a poorly defined or ignored requirement development process. This happens when a client doesn’t know what they want until they see the GUI Interface. Another reason for the change is due to some key stakeholders was left out at the beginning of the project and when joining mid-way of the project, they tend to put their requirement or change the existing requirements.

2. New Requirements Being Added and Removing Existing Requirements

Stakeholder’s expectations change over time if not managed properly. This will lead to requirements being added or remove from time to time. If we are not going to set the mindset of the stakeholders on what to expect from the original requirements, other people could be influencing them and changing their expectations.

3. Change in Technology

Another reason for scope creep is the rapid technology updates and improvement. With this rapid change, every project stakeholder wants to be up to date with latest technology. If a project is in a long development time, a change in technology (hardware/ software) tend to happened which directly will affect the project triangle.

4. Changing and Adding of New Stakeholders

Not all stakeholders will be joining in the beginning of a requirement process. Some even might be replaced or leave mid-way of the discussion. This will bring different views of understanding of certain requirements which will directly impact the scope of the project.

We can’t conclude that all the changes above comes from the customer only rather, scope creep is often a sign of poor initial requirement analysis of needs or simply misunderstanding on the part of the client.

Ways to Manage Scope Creep

There are several ways which a project manager can deal with scope creep:

1. Use the prioritization technique rather than numbering technique.

Example of a prioritization technique that can be used is MoSCoW technique.

This technique is a “know how” for most project managers out there. Always remember that the prioritization is from the client perspective. The definition of MoSCoW theory is as below:

Advertisement
[widget id=”custom_html-68″]

Must Have – this requirement is critical and must be included to achieve project success. Project Managers also need to be aware that not including at least one Must Have requirement will be considered a failure of the project.
Should Have – this is a high priority requirement but not critical to be developed but it is considered important and of high value to users.
Could Have – this requirement is nice to have but not a critical for a project success. This kind of requirements will be normally removed first from the scope if the project timeline’s are at risk.
Won’t Have – this requirement doesn’t need to be implemented for now but may be included in future development stages. This kind of requirements normally does not affect the project success.

The below diagram illustrates the MosCow Prioritization Technique:

2. Have a strong Change Control Process such as:

Any new changes must go through a change request form (CR) and analyzed properly on the impact the change will have on the wider side of the project.
Do not entertain any ad-hoc changes from the customer without going through the proper channel of authority
Not all changes can be accepted. Some would need to be rejected or amended depending on the required priority
All changes that have been accepted need to be added as addendum to the original project scope documentation

3. Scope of Work should be clearly defined in the early stage or even better before the project initiation.

Have regular workshop before the project kick- off to finalize all requirements. Once this is done, this will reduce the “leg room” for a change to happen and causing a scope creep.

4. Stop using “Gold Plating” technique in any project as it is a bad practice.

What it means that any team members of a project would go an extra mile just to please the customer by adding some features which are not originally in the agreed scope. If the customer turns down the feature, all the efforts of the team member will be futile. It is a waste of resource and time.

Conclusion

To avoid all the unnecessary implication caused by scope creep, it is advisable to well manage a project scope from the start to avoid any unauthorized changes happening to the original scope. Implementing scope management processes which include a change control process will ensure all changes are properly raised and documented. This will help ensure the project is delivered on time and within budget, with no unwanted surprises.

Tips to Manage a Complex Multi-Vendor Project Successfully

Written by Muralitharan Ramalingam on September 27, 2017. Posted in Articles. 3 Comments on Tips to Manage a Complex Multi-Vendor Project Successfully

It is quite common in projects that the selected vendors are unable to keep up with the expectations that were committed during the tendering process.

This can be partly due to unavoidable cultural, processes and language differences between the vendors. The vendors often have their own perception on what they signed up for during the negotiation process. Some of the vendors tend to deliver their portion of the project milestones or deliverables late and below the customers’ expectations. Furthermore, during the project tenure, there will be an increase in cost, delay in schedule, and poor quality of deliverables. The vendors failed to understand the actual requirements set by the customer and on top of that, the complexity of the project due to multi-vendor and dependency concept.

The impact of these differences in terms of understanding and perception of the project deliverables can be reduced to a minimal level if both the customer and vendors stays vigilant. This paper recommends some of the key practices that can be used effectively to establish and manage vendor relationship successfully from the beginning to the end of the project. Some of the key areas that a project management team needs to adhere to while working with multi-vendor projects are as below:

Communication
Roles and Responsibility Assignment Matrix
Performance Reports
Issue and Risk Management
Change Management

1. Communication

The main concern on any given project, be it a simple or a complex multi-vendor environment, communication is key and needs to be given the utmost priority. Most projects fail due to the lack of effective communication between customer and vendors. For example, a vendor sends an email stating issues to another vendor or customer and waits for a reply even though the person who can provide the solution may be sitting in a few cubicles away on the same floor of the same building. It’s always advisable and recommended to speak or confront the person directly to solve the issue first, followed by an email later to capture the issues discussed and the outcome of the discussion.

Another good practice would be for the project management team and the vendors to hold regular meetings on the project so that inputs can be obtained and every key team member is on the same page with regards to the project deliverables.

2. Roles and Responsibility Assignment Matrix

Roles and responsibility matrix needs to be available so that the customer and vendor are clear about their roles and responsibilities and hence to avoid any dispute during the project tenure. This can be done through the issuance of a “Responsibility Assignment Matrix” (RAM) prior to commencing work on the project. It should be noted that issuing a RAM without following it through during the project will cause a project to fail terribly. Hence, constant monitoring to ensure that the vendors “walk the talk” after the project is being awarded is required. Another main reason why the roles and responsibilities assignment matrix should be clearly defined in the early stages of the project is to avoid stakeholders from “jumping the gun” during decision making without understanding their level of authority.

3. Performance Reports

It’s advisable for all vendors to submit their performance reports to the project management team or customers on a regular basis. The report should contain information such as progress update, issues encountered together with proposed solutions, improvements, risks along with mitigation plans and other related matters that would need the attention of the customer. The report should be submitted on a weekly basis so that everyone is aware on the progress and also to be able to detect any issues earlier if there is one.

4. Issues and Risk Management

Issues and risks are the two most unwanted terms in any project management. However, this can never be avoided. In fact, it is best to spend more time in this area to ensure the project deliverables are met timely and with high quality. The repercussion of not managing these two are very heavy, this can even bring down a project to a disastrous level if not managed properly. We all know that in a multi-vendor environment project, there are very high probability of issues raised and if they are not managed well, it will cause the project to fail.

A centralized system to log in issues need to be in place such as an issue register, and a dedicated team needs to be assigned to monitor it on a daily basis if possible. The team will be responsible to manage and review the issues raised, be able to assess the severity of the issues and identify if the issues have an impact on other parts of the project deliverables. This is because even though an issue tracker is in place, in most cases, issues logged are left unattended since there are no dedicated team is appointed or responsible to manage and review the issues. Currently what happens is that, once vendors log in to register the issue list, no action will be taken till the owner of the problem queries the status. If the issues are not managed well and resolved we face the risk of the issue becoming critical and to make it worse it becomes a showstopper for the project.

Similar to issues, risk need to be managed properly as well. A risk is defined as an event that may or may not occur. It is advisable for the customer or the project management team to have a risk management team to review and manage the risk by conducting a fortnightly or monthly Risk Review meeting. This would be beneficial as it allows no gaps to be left out.

Project Managers should emphasize adopting the Risk Management Plan. The risk management plan is a set of five steps which are recommended by Prince2 to help manage the risks. They are Identify, Assess, Plan, Implement and Communicate. The first 4 steps are sequential, while Communicate will always be done from the beginning to let stakeholders know what is going on and to get continual feedback during this process. The key “to-do” for each step is stated below:

Identify the risks (threats & opportunities) that could affect the Project objectives
Assess the risks in terms of their probability and impact on the project objectives
Plan steps to help reduce or avoid the threat, or this could also be to plan to maximize the opportunity if the risk happens.
Implement the planned steps

Advertisement
[widget id=”custom_html-68″]

The following diagram illustrates the steps involved in the risk management plan:

The risk management plan will help project managers to understand the following:

Probability of risks and opportunities in terms of how likely they are to occur
Impact of each risk and opportunities in terms of project objectives
Proximity of each risk and opportunities with regard to when they might materialize
How the impact the risks and opportunities may change over the life of the project

Below are some of the issues/risks that typically may happen in a multi-vendor environment projects with the proposed mitigation plans:

Issues/Risk	Resolution/Mitigation
Vendors do not work as a team to complete the project successfully, this will lead more to a “blaming-game”	Roles and responsibility assignment matrix (RAM) of each key team member of different vendors are clearly defined. Hold regular “war room” session to trash out all issues and also to be on the same “boat” of the project progress
Teams of the vendor who are not transparent tends to create a wrong perception to the client This happens when the said vendor has the higher authority then the others. (ex : PMO reporting to customer or board of directors)	Need to make sure the status report from the team is not adjusted or changed by their respective PMO when reporting to customers as not all vendors will be present during a said meeting Each vendor should hold a regular review on the project with the presence of the PMO but chaired by the customer top management.
Handover process of a project or a particular deliverable are not clearly defined	Clearly defined the handover process such as : Have regular meeting with the new team Make sure the project information is up to date Involve the new team in all communication at early stage Prepare a project handover checklist

5. Change Management

Change Management is another critical part of a project. Customer or the project management team needs to check the proposed change and determine what effect the change will have on the project as a whole before allowing the change request to be implemented. Effective change management processes are needed to ensure all levels from the vendor or customer organization are updated on the changes so it doesn’t affect the project delivery. There are several changes that can happen during the execution of the project and should be dealt differently depending on the category such as:

Changes in Scope of Work
Management team should be able to differentiate between critical work packages that need to be tightly controlled, and non-critical work packages at a project level whereas at the multi-project level, top management has to differentiate between prioritized and non-prioritized projects, giving top priority to critical work packages belonging to prioritized projects. This will ensure that the projects with the highest priority will be delivered on time.
Changes in Project Schedule
A project schedule needs to be followed rigidly once it has been determined. Sadly, it never happens as there will be changes required, so the most important thing is to make sure the change are managed and tracked correctly. The big problem is uncontrolled change, where a change in any of the critical success factors affects the other factors, which will then affect project deliverables, thus affecting stakeholder satisfaction. Any time a change occurs, the project manager needs to recognize the change, evaluate the impact of the change, communicate the change to the members of the project team and the stakeholders and make the appropriate adjustments if the change is accepted and endorsed by the Change Control Board (CCB).
Changes in Project Cost
Changes in project cost is directly involved with change in project scope and schedule. Project managers should estimate the cost impact of the change request in terms of materials, equipment and supplies as well as changes to existing contracts and the cost of the people assigned to the task.

Conclusions

Managing a multiple-vendor project can be very challenging and chaotic, given the complexity of the project and managing the vendors. Prior to starting a project, it’s always advisable to clearly define the process, procedures and roles of each key team members of the vendors in the early stages of the project to avoid any conflict of interest or miscommunications. A clearly defined vendor management process chaired by the project management team or the customer would be a great implementation. A good project management plan needs to be in place prior to starting the project and also good governance should be demonstrated by the project management team throughout the project to avoid any “unwanted” incidents to happen.