In the previous part, we had already discussed about the 3 big parts that consist of Planning, Project Work Plan, and Project Management Procedures. Now, in the 2nd part (last part), we will discuss about how to manage the scope, risk and issue that always occur in every project. Here are the details about the next 3 Big Parts:
4. MANAGING SCOPE
F. Ensure that the sponsor approves scope-change requests.
After the basics of managing schedules, managing scope is the most important activity required to manage a project. Many projects failure are not (majorly) caused by estimating schedule or team skill sets, but by the project team working on major and minor deliverables that were not part of the original project definition or business requirements. Even though you have good scope-management procedures in place, there are still two major areas of scope-change management that must be understood to have a successful project, such as understanding who the customer is and scope creep.
In general, the project sponsor is the person funding the project. For infrastructure projects like an Exchange migration, the sponsor might be the CIO or CFO. Although there is usually only one sponsor, a big project can have many stakeholders, or people who are impacted by the project. Requests for scope changes will most often come from stakeholders – many of whom may be managers in their own right. One manager might want chat services for his or her area. Another might want an exception to the size limits you have placed on mailboxes. It doesn’t matter how important a change is to a stakeholder, they can’t make scope-change decisions, and they can’t give your team the approval to make the change. In proper scope-change management, the sponsor (or a designate people) must give the approval, since they are the only ones who can add funds to cover the changes and understand if the project impact is acceptable.
G. Guard against scope creep.
Most project managers know how to invoke scope-change management procedures if they are asked to add a major new function or a major new deliverable to the project. However, sometimes the project manager doesn’t recognize the small scope changes that get added over time. Scope creep is a term used to define a series of small scope changes that is made to the project without scope-change management procedures being used. With scope creep, a series of small scope changes—none of which appear to affect the project individually—can accumulate and have a significant overall impact on the project. Many projects fail because of scope creep, and the project manager needs to be diligent in guarding against it.
5. MANAGING RISK
H. Identify risks up front.
When the planning work is occurring, the project team should identify all known risks. For each risk, they should also determine the probability that the risk event will occur and the potential impact on the project. Those events, that identified as high-risk, should have specific plans put into place to mitigate them so they do not, in fact, occur. Medium risks should be evaluated to see whether they need to be proactively managed. (Low-level risks may be identified as assumptions. That is, there is potential risk involved, but you are “assuming” that the positive outcome is much more probable) Some risks are inherent in a complex project that affects every person in the company. Other risks may include not having the right level of expertise, unfamiliarity with the technology, and problems integrating smoothly with existing products or equipment.
I. Continue to assess potential risks throughout the project.
Once the project begins, periodically perform an updated risk assessment to determine whether other risks have surfaced that need to be managed.
6. MANAGING ISSUES
J. Resolve issues as quickly as possible.
Issues are big problems. For instance, in an Exchange migration, the Exchange servers you ordered aren’t ready and configured on time. Or perhaps the Windows forest isn’t set up correctly and needs to be redesigned. The project manager should manage open issues diligently to ensure that they are being resolved. If there is no urgency to resolve the issues or if the issues have been active for some time, it may not really be an issue. It may be a potential problem (risk), or it may be an action item that needs to be resolved at some later point. Real issues, by their nature, must be resolved with a sense of urgency.
Source : Tech Republic Article
by Hendra Halim – Head of Project Management Office (Infrastructure Team)
You can follow him on his twitter @takhada