Project Management

Many scope management processes work well at the project manager level, but get compromised by team members. If the project manager is diligent in enforcing the scope change rules, the client may try to go directly to team members for changes. For instance, when an agreed-upon report is delivered for review, the client may request a second report to provide more clarity. The team member may agree to the work (showing 'client focus'). The result is that the activity takes too long or resources that could have been applied to other high priority work get absorbed working in an area that is out of scope.

The bottom line is that everyone needs to be held accountable for the scope management process. Team members must understand the process and why it is important. The client must also understand the process and its importance. Don't consider these procedures to be only of interest to the project manager and the sponsor. Make sure the procedures are communicated to the entire team.

When clients request scope changes directly from team members, bring this to the attention of the client manager or the sponsor. When team members make commitments for work that is out of scope, deal with it promptly. The first time it happens it may be considered a training matter. The next time it might be a performance problem.

The Change Control Board

Sometimes on very large projects, the project sponsor does not feel comfortable making the scope change decisions alone. This may especially be the case if the effect of the change will impact other organizations. It may also be the case that multiple organizations are participating in, or contributing to, the project funding, and want to have some say in evaluating scope change requests. For these cases, a group of people might be needed to handle the scope change approval.

A common name for this group is a Change Control Board. If a Board exists, it may be more cumbersome to work through. However, the general scope change management process does not need to change dramatically. For instance, there is still a document for the initial the scope change request. The project team needs to determine the impact and cost to the project. The Board must consider the impact, the value to the project, the timing, etc., and then make a determination as to whether the request is accepted.

The Scope Change Procedures must be somewhat more sophisticated to account for the Board. For instance, you need to clarify who is on the Board, how often they will meet, how they will be notified in emergencies, how they will reach decisions (consensus, majority, unanimous, etc.), how incremental work will be paid for, etc.

Only the Sponsor Can Approve Changes – Not Users and Client Managers

A typical problem on a project is that the team does not understand the roles of the sponsor, client and end users. In general, the project sponsor is the person who is funding the project. If the client were embodied in one person, it would be the project sponsor. The sponsor is usually high up in the organization and not easy to see on a day-to-day basis. In most cases, the sponsor designates someone in his or her organization to make most decisions on a daily basis.

The people that the project team tends to work with most often are end users. End users are the people that use the solution that the project is building. The end users are the ones that will generally make requests for changes to deliverables. It doesn't matter how important a change is to an end user, the end users cannot make scope change decisions and they cannot give your team the approval to make a scope change. In proper scope change management, the sponsor must give the approval. The end users can request scope changes, but they cannot approve them. The end user cannot allocate additional funding to cover the changes and they cannot know if the project impact is acceptable. If the change is important enough to the Sponsor, he or she will approve it, along with the appropriate budget and duration changes. If the change is not important enough, it will not be approved. However, it will be the Sponsor making the decision, not the project manager, client manager, project team or end users.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Weekly Anagram

Let's have some fun! See if you can unravel this anagram. (Anagrams are a word or phrase formed by reordering the letters of another word or phrase, such as satin to stain.)

Activities that have to be performed sequentially or within a predetermined time of each other

TAD ICE TIE VISIT: _ _ _ _ | _ _ _ _ _ _ _ _ _ _

Last Week's Anagram.

A condition where there is no excess time between activities

ART ELF ZOO: ZERO FLOAT

Wideman Glossary Term of the Week - Capability

• The ability to perform effectively, efficiently and with the necessary skills.

• Having the needed attributes to perform or accomplish.

• The power to produce an effect, or perform as expected.

Labels: Scope Management Process

Five Strategies for Risk Response

Once risks have been identified, there are a number of options that the project manager should consider for responses.

• Leave it. In this approach, the project manager looks at the risk and decides to do nothing. This can happen for a couple reasons.

1. The project manager may feel that the risk should be managed, but that the negative impact of the risk is not worth the cost and effort required to manage the risk. In this case you would rather deal with the costs of the risk occurring that the cost of trying to manage the risk.

2. There may not be any reasonable and practical activities available to manage the risk. This is different from the prior reason where the cost was more than the benefit. In this case, there is no practical way to manage the risk, even if the risk has been identified as high. For instance, it is possible that there is a risk of your sponsor leaving and a new sponsor canceling the project. In fact, you may know that the sponsor is up for a promotion and that this scenario has some possibility of occurring. However, you may not be in a position to do much about it as long as the current sponsor is in place, and you may just need to leave it and see how events play out.

• Monitor the risk. In this case, the project manager does not proactively manage the risk, but monitors it to see whether it is more or less likely to occur as time goes on. If it looks more likely to occur, the team must formulate a different response at a later time. This approach can work for serious risks that are not likely to occur. Rather than put a plan in place immediately, the project manager creates a plan only if it looks likely that the risk will occur. The advantage is that scarce resources are expended only on those risks that are likely to occur. The disadvantage is that the delay in addressing the risk might make it less likely that the risk can be successfully managed in the future.

This is also a good approach if you have identified a risk that should be managed, but the risk event is far off in the future. For instance, if your risk event is nine months in the future, it may not make sense to spend resources to manage the risk at this time. A better approach might be to monitor the risk on a monthly basis. It is possible that over time the risk will go away because of other circumstances. However, if it does not go away, the team will still need to manage the risk in the coming months.

• Avoid the risk. Avoiding the risk means that the condition that is causing the problem is eliminated. One example is that if you find that a part of the project has high risk associated with it, that whole part of the project is eliminated. The risks associated with a particular vendor, for instance, might be avoided if another vendor is used instead. This is a very effective way to eliminate risks but obviously can be used only in certain unique circumstances. In another example, you may have a project risk associated with implementing a solution in multiple locations. Once the risk is identified, the sponsor may change the scope of the project to only implement in one location. In this way, the risk of implementing at multiple locations has been avoided.

• Move the risk. In some instances, the responsibility for managing a risk can be removed from the project by assigning the risk to another entity or third party. For instance, outsourcing a function to a third party might eliminate that risk for the project team. The third party might have particular expertise that allows them to do the work without the risk. Even if the risk is still present, it now is up to another party to resolve.

Another example of moving the risk is buying insurance. In a simple example, you may have a very fragile and valuable piece of equipment that needs to be shipped to your project team. There is some risk that the material will be damaged. You might move the financial risk by purchasing insurance on the shipment. Of course, if the shipment is damaged, you may still lose time waiting for a replacement part to be shipped. However, you no longer have the financial risk. In exchange for an insurance premium payment, the insurer now has the financial risk.

• Mitigate the risk. In most cases, this is the approach to take. Mitigating the risk means that you put in place a set of proactive steps to ensure that the risk does not occur, or that the impact of the risk event in minimized. Both are valid mitigation strategies. (For the purposes of the Project Management Process, it is generally assumed that Risk Management Plans are put in place to mitigate the risk.)

Weekly Anagram

Let's have some fun! See if you can unravel this anagram. (Anagrams are a word or phrase formed by reordering the letters of another word or phrase, such as satin to stain.)

Conditional logic. Alternative paths in a probabilistic network. Breakdown Structure

BRACING CHIN LOG: _ _ _ _ _ _ _ _ _ | _ _ _ _ _

Last Week's Anagram.

A record of jobs to do or to check that others have done, commitments from the author or others, important events, decisions and discussion, and kept by the project manager and any team members.

ALLOY DIG: DAILY LOG

Wideman Glossary Term of the Week - Graph

• In Quality Management, a visual comparison of variables that yield data in numerical facts. Examples include trend graphs, histograms, control charts, frequency distributions arid, scatter diagrams.

• In Time Management, the display or drawing that shows the relationship between activities. Pictorial representation of relative variables.

Labels: avoid the risk, manage the risk, mitigate the risk, monitor the risk, move the risk

The Document Life Cycle

It is important for the project manager to recognize the stages that a document must go through from creation to completion. This knowledge allows the project manager to understand the overall status of a document at any given time and helps ensure adequate time is allocated for the completion of the document. For instance, when a team member says they can complete a document in two weeks, are they saying that the document will be ready to circulate in two weeks or that the document will be completed and totally approved in two weeks? Not all documents need to go through all the stages of document creation and approval. However, depending on the document, one or more of the steps will be required.

Some of the review steps defined here would also be considered part of a quality control process for the documents.

Like all completed (production) deliverables there may be subsequent updates or enhancements that may require their own mini-document life cycle as well.

Transition Documents to the Right Area After the Project

After the project has completed, some of the documents may be archived, while others need to be maintained indefinitely. For instance, project Status Reports can be archived (or purged) when the project has completed, since they are time-sensitive and have limited value after the project is completed. On the other hand, you should save a User’s Manual after the project is completed. These saved documents can continue to be updated in the document repository if the repository is something that is utilized by the entire organization. Otherwise these long-term documents will need to be moved to the document repository used by the support team.

Some companies maintain a central repository of major project deliverables that can be leveraged for reuse. For instance, the Business Requirements document that was created for your project may be able to be leveraged by another project that is looking into a similar business area. The Testing Strategy your project defined may be able to be reused by another project with similar testing needs. After your project has ended, the project manager and librarian should determine the information that can be leveraged on future projects if the organization has a repository where the documents can be saved.

Weekly Anagram

Let's have some fun! See if you can unravel this anagram. (Anagrams are a word or phrase formed by reordering the letters of another word or phrase, such as satin to stain.)

Time-phased project funding usually displayed in spreadsheet or graphical format.

DIFFER LOG UNPIN: _ _ _ _ _ _ _ | _ _ _ _ _ _ _

Last Week's Anagram.

Conditional logic. Alternative paths in a probabilistic network. Breakdown Structure

BRACING CHIN LOG: BRANCHING LOGIC

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Wideman Glossary Term of the Week - Network

• Graphical representation of activities or nodes and the dependencies between them.

• The logical order of tasks that defines the sequence of work in a project. Networks are usually drawn from left to right, with lines drawn between to indicate the precedence between tasks. Arrow heads are often placed on the lines to indicate the direction of the flow through time.

• A logic flow diagram consisting of the activities and events which must be accomplished to reach project objectives, which show their planned sequence, interrelationships, and constraints.

Labels: Document life cycle