CHANGE CONTROL PROCESS

Scope Management is considered to be the most important project critical success factor. The failure to properly manage scope may result in cost overruns and schedule slippage.

Scope Management begins with a clearly stated, communicated and documented project description set of project objectives and project deliverables. The scope description is included in the Scope Document.

 Managing scope includes a continuous review of project plans and activities as compared to the definition contained within the Scope Document. And when scope changes surface, a process to manage these occurrences must be rigorously followed.

The following outlines a common used change control process:

CHANGE CONTROL IDENTIFICATION & INITIATION

Purpose –  To provide a uniform entry into the change request process and to maintain current records on each change control item.

Roles & Responsibilities –  Any ITS and project team member can identify a change control item. The Project Manager should conduct the initial review of change control item and assign a project resource to complete cost/benefit analysis, then update the Change Control Database.

Process Definition –  The change identification and initiation process begins with the documentation of a potential change on a Change Request form. Specific change control information is provided to the Project Manager for a decision as to whether it is a legitimate change. If it is considered a legitimate change it should move into the impact assessment process. During this process, those requesting the change will be kept informed of the status.

CHANGE IMPACT AND BENEFIT ASSESSMENT

Purpose – To provide a uniform entry into the change request process and to maintain current records on each change control item.

Roles & Responsibilities  – Assigned team members will provide estimates of the effort and benefits. The Project Manager should assess the impact (cost, time, and benefits) of any change in services, and submit the change request for approval to the appropriate management level. Then finally update to the Change Control Database.

Process Definition – The assigned resources will assess the impact on the implementation. The Project Manager will determine if a benefit analysis is needed and make the appropriate assignments. The Project Manager will evaluate the cost/benefit and impact on the schedule and determine who needs to approve the change request. The Project Manager will prepare the appropriate document to be submitted to management for approval.

MANAGEMENT REVIEW/APPROVAL/REJECTION PROCESS

Purpose – To provide a timely and orderly process for obtaining management’s decision on whether a Change Request should or should not be implemented.

Roles and Responsibilities – The Project Manager determines if the change needs to be submitted to management for approval. The change request can be approved at the discretion of the project manager If the change can be accommodated within schedule and budget. If a higher level approval is required the project owner will secure those approvals, whether it is the project sponsor or management committee.

Process Definition – The first step in the process ensures that the information forwarded to management is complete and has the quality required. The project manager will deliver the change request to the project owner for his/her immediate attention. If the change request requires a higher level of approval the project owner will forward the change request to the project sponsor. If approval level is beyond the project sponsor then the project sponsor will bring the request to management committee for approval. The project sponsor will inform the project owner of the decision, who will in turn inform the project manager.

CHANGE IMPLEMENTATION PROCESS

 Purpose – To provide a timely and orderly process for implementing approved Change Requests.

 Roles and Responsibilities – The project manager will schedule changes in the project plan and assigns resources to complete the change request. The project manager then updates appropriate budget cost tracking tools with the changes. The assigned team members will complete the approved changes as scheduled.

Process Definition – The Project Manager ensures that the project management tools are updated and that the changes are completed.

Once again I hopethis sheds some light on the change control process. Comments and feedback are welcomed.

Cheers,

Craig

Purpose

Project status reporting is one element of the project controlling process and project governance.  Its purpose is to ensure that the objectives of the project are being met by monitoring and measuring progress regularly to determine variances from the plan.  When variances are identified, then corrective action can be taken.

 Benefits

There are a number of benefits of regular status reporting.  A few of the more significant benefits are:

•  It provides an opportunity to raise issues or variances from the plan and to take corrective action before a situation gets beyond recovery.  It is possible that a situation cannot be recovered.  However, at a minimum, the situation is identified and it does get reviewed.
• It helps to create accountability for the work being done.  This happens because it makes the work more visible to all of the project stakeholders (i.e. project team members, Project Manager, Project Sponsor, and Senior Management).
• It creates a visible record of the progress of the project.  The Project Manager or Senior Management can review this record should some of the history be needed.

 Status Reporting Cycle

Regular status reporting is necessary in order to be effective.  It helps to maintain traction and visibility for the project.  The frequency of reporting is often a function of the duration of a project and its importance to an organization.  For projects with a short duration (i.e. less than six months), it is better to have weekly reporting so that issues are raised and dealt with sooner.  For projects with a longer duration, bi-weekly or monthly reporting may be more suitable or desirable.

 Roles & Responsibilities

 There are various roles and responsibilities in the status reporting process. The following list describes the most common ones:

 Project Manager

• Monitors project progress and report progress regularly, using the Project Status Report form, to the Project Sponsor and Steering Committee/PMO.
• Escalates issues relating to scope, schedule, resources, and budget, when they cannot be resolved.  The first escalation is to the Project Sponsor.  If there is no resolution at that level then the final escalation is to the Steering Committee.
• Escalates proposed significant changes to scope, schedule, resources, and budget.

 Project Sponsor

• Usually the senior manager representing the business area that is receiving the greatest benefit from the project.
• Ensures that Project Status Reports are received and reviewed regularly.
• Addresses issues when they cannot be resolved by the Project Team.

 Project Management Office

• Ensures that Project Status Reports are received regularly.
• Periodically reviews the Project Status Reports and follow up with Project Managers for clarification, as appropriate. 

 Steering Committee

• Should  consist of key stakeholders to he project, the project sponsor, and project owner
• Provides executive level support, guidance, and direction.
• Reviews progress of projects.
• Addresses issues relating to scope, schedule, resources, and budget, when escalated, if not resolvable via project manager or project sponsor.

 Status Report Formats

There are many varying formats that can be used for project status reporting. The contents will depend on the rigor with which you are tracking the project, the frequency of reporting, and whether or not budget tracking is incorporated into the report, and if Earned Value is being reported.

At a minimum the status report should contain the following categories:

• Status Summary – Gives high level summary project state
• Project Progress – Progress made in the last reporting period. Would include key milestones met, key deliverables completed, budget and schedule tacking.
• Planned Progress – Identify any items to be completed during next reporting period.
• Risks/Issues – Any identified risks and issues along with the management plan to deal with specific risks/issues.
• Resources – It is always good to identify the current resourcing level on the project in the status report so that all stakeholders have an appreciation for the work level and resource requirements
• Budget – if required, the report should identify the current project budget to complete, budget used so far, planned budget so far, and explain any variances.
• Schedule – if required, the report should identify the current project schedule to complete, has the work completed so far been done on schedule, and explain any variances.

 Once again, I always enjoy feedback on these topics.

 Cheers

 Craig

Statement of Work (SOW)

A Typical Statement of Work The Statement of Work (SOW) is a section of the contract or an addendum to the contract that describes the services and/or products of the engagement. It is a narrative description of the specific services that a consulting firm or IT group provides to a client for the engagement under the contract. These services may include personnel, project management, software implementation and modification support, training support, documentation support, and deployment support of software applications. Sometimes the project is a process redesign or management consulting engagement, rather than a software application.

The SOW is important because it is the basis for scope change control throughout the project.

When an SOW is produced

A Statement of Work is created during the engagement start-up process. It sets the groundwork for the contract and the subsequent project planning. Confirming or adjusting the SOW is one of the first things you will do as a project manager.

The PM Role in the SOW

The Statement of Work is usually written by the consulting personnel who closed the sale or Business Analysts within the company defining the project for internally staffed projects. Your job, as the Project Manager, is to confirm that the SOW accurately states the commitments of your consulting organization or IT group. In some cases, this will require you to modify the existing SOW to reflect new understandings or changes to the requirements.

Acceptance Criteria for a SOW

Typical standards require that:

1. The SOW is in alignment with the consulting firm’s or IT group’s contract (or Letter of Engagement) and with the client’s expectations.

2. The SOW is complete and describes each of the following:

• Scope & Purpose of Services

• Definitions • Deliverables

• Assumptions • Delivery Acceptance Criteria

• Exclusions

Inputs to an SOW

To write the SOW you need to draw on a number of resources. You’ll need to refer to all of the following:

• For consulting firms, the sales cycle documents, including the Contract (this may include addendum appendices, or “annexes”) or a Letter of Engagement/Intent. These documents tell you the following:

• The service that your firm/group will provide to the client,

• Fees that will be charged to the client, the basis or assumptions regarding the fees, and the nature of the fee (i.e., fixed or time and expenses)

• The types of resources to be provided, • Assumptions for the engagement, • Client responsibilities (resources, hardware, work environment, etc.)

• Any performance incentives or penalties

• Interview notes from key decision-makers. – It is critical for you to know everything you can about the project from its inception. These notes provide you with information about how key decision-makers view the project and outline any open items or specific exclusions that may not have been specified in the contract.

As stated above, the SOW forms the basis for scope control and change management. So it is extremely important to get this document right and authorized by all parties.

Cheers,

Craig

This week I thought I would stray away form the technical and pure methodical aspects of project management and share a story about life as a consultant road warrior. Those project managers and other IT personnel that work in the consulting business, have many stories of life on the road and the tricks of the trade that go with surviving the long times away from home.

 Several years ago I embarked on my first foray into the consulting life on the road. I was very green to the aspect of being away from home for long periods of time and had not yet become accustomed to hotel life. My first assignment was in Boston where I was assigned to PM a project that had several other colleagues from our consulting firm.

One developer was a seasoned road warrior. He picked me up at the airport and we proceeded to the hotel. As we hopped out of the car in front of the hotel he tossed his keys to the valet parking attendant, who greeted him by name. As we entered the hotel everyone seemed to know this guy personally. The door man, bell hop, the gal on the front desk, and they all seemed to talk to him like they knew him for years. I knew that he had only been at the hotel for three or four weeks. Was he that friendly or were the hotel staff extremely polite?

After settling in to my average hotel room I went to meet my colleague at his room a few floors up, of course at the concierge level. All this was beginning to look suspicious. His room was twice as big as mine with a sitting room and extra big TV. He would not let on as to how he managed to get such a sweet deal.

The next morning I met him in the lobby on our way to the client site. His car had been parked in the VIP section of the lot just outside the door all night. I finally had to make him come clean. He said that after a few years on the road it was clear that having these little perks sure made being away from home for extended periods of time much more bearable. His secret was very simple. We would receive $45 per diem for food when traveling on business. This was more than adequate when you were away for four or five days a week. He would take one day’s per diem each week, put it in an envelope, and give it to a different one of the hotel staff at the end of each week. It did not take long for word to get around between the hotel staff that a nice gratuity would be waiting at the end of the week if he was given a little extra attention. But no one knew who would receive the tip. This was a way for him to get a little preferential treatment at no real cost to him. This is the kind of guy I like to have on my projects, always thinking outside the box.

The life of a road warrior in the consulting business can be long and arduous. Some people learn to adjust and devise ways of coping. Some never get the hang of it. Any perks you can pick up along the way are a bonus.

Cheers,

Craig

Acceptance Criteria for Closing out a Project

When a project is complete, it doesn’t just stop. There is a closeout process. The purpose of the closeout process is to ensure that:

•  All requirements have been met and the client is satisfied – for consultants, hopefully the client can serve as a reference for the future,
• Team members get closure on their performance – by learning the results of team surveys, and
• Your project team is able to leverage what it has learned from this engagement – by documenting learnings and archiving the paperwork.

 Closing out a project correctly entails all of the following:

• Issue a final status report
• Hold a final meeting with client management – In that meeting review all open issues, review business benefits, lessons learned, and change management procedures
• For consultants, you should discuss with your account manager to ensure that the client is able to be used as a reference in the future.
• Assess the potential for future business that is appropriate for your company. On implementation projects, there are frequently Phase II or III opportunities to become involved. As the PM, you are in a good position to know how you can help. You have kept up with change requests that did not get approved for Phase 1 and you know about Model or Preview findings that got postponed because of time, budget or other constraints. You have interacted with SME’s and other client personnel who discuss “wish lists” and business processes that are not supported by current solutions. This is information you should pass to the account manager at project closeout.
• Participate in the Post-Implementation Review Process if one is deemed appropriate and report your findings to your team, client, and management.
• Crate, catalog, and store appropriate hard copy documents as required by the client or your company. This includes confidential and sensitive documents that may have been generated during the project, signature documents such as client sign-off forms for deliverables such as functional specifications, model, testing results, etc. and overall system signoff. Also archive appropriate documents electronically.

When you Close Out a Project

On some projects closeout occurs during the final week the PM is on-site at the client location. If the team is responsible for interim support for a period of time, closeout would occur after this period. In either situation, transitional meetings are conducted and final action items are completed. The PM should confirm with his/her account manager and project sponsors that required closeout actions have been performed.

Your Role in Closing Out a Project

The Project Manager should own the responsibility for closing out the project. As Project Manager, you are responsible to:

• Finalize the project closeout paperwork. This typically means applying final updates to closeout the project plan and issuing a final project status report, but other documents may need to be prepared. Open or pending items such as questions on invoices or client concerns must be documented and reported to the proper company and/or client management.
• Complete the electronic archiving of final engagement-specific documents. This includes migrating appropriate documents to any company or client LAN directory.
• Package appropriate paper documents for archiving in the regional office. Gather together all hard copy project documents such as client signature documents or other documents that are confidential in nature or may not have been created in electronic format and create a packing list itemizing the documents either by category or individually.

Remember, the project close out and lesssons learned is a crucial part of communications with the client, project team members, and an important opportunity to improve on future projects.

Cheers,

Craig

Providing Performance Feedback

Some tasks are behind schedule, some resources are reporting lower than expected productivity, you are hearing about performance issues from the project team members. How would you as PM handle it, what would you do?

It is safe to say that within most companies a major function of the Project Manager is to identify and remove roadblocks so that people who have the “R” (Responsible according to the RACI Chart) to do the work can do the work. Sometimes that requires us to look at our own performance.

 Providing both positive and negative feedback on the performance of your individual resources on assignment is an aspect of Human Resource Management, one of the critical PM disciplines. It is an important part of leading and developing your team.

 When you need to Provide Feedback on Performance

 Feedback is very important. Not only is the PM responsible for communicating progress to project sponsors and consulting management, but you are also responsible for informing the team and individual team members of the progress at regular intervals throughout the project. A PM must devote significant time to providing clear direction to team members, understanding their status and difficulties, and keeping them informed regarding the project and their role in it. This is most effective when good working relationships are maintained and the PM interacts routinely with each team member to review their efforts and personally confer on issues or challenges associated with progress. This is sometimes referred to as MBWA or “Management by Walking Around”.

In addition to providing ad hoc feedback to team members, the PM is usually also responsible for providing team members with formal evaluations of their performance on a periodic basis. These periodic evaluations provide feedback on the performance expected of the resource for their particular role on the project and for their title/level of consultant. The PM provides information about performance expectations, strengths, developmental opportunities, and ratings on specific competencies related to the resource’s role on the project. This documented feedback recognizes good performance and helps individuals identify areas where improvement is required.

Your Role in Providing Performance Feedback

 Once the project has been staffed, it is primarily your management of your resources that determines whether or not you are a success at the end of the project. The PM is the coach of the team and must:

•  Lead and motivate team members to achieve maximum contributions
•  Monitor the productivity of project team members through the effective use of productivity measurement tools
•  Identify any performance issues
•  Work with your resource management team to rectify the situation through mentoring, coaching, or other approved management processes.
•  Participate in the periodic evaluation process to perform accurate evaluations of resource performance.

Teams typically go through a universal process as they develop within the project life cycle. They go from Forming to Storming to Norming, to Performing. If the leader can successfully diagnose what stage the team is in, the leader can help the team from getting stuck in the past by providing what is needed. At each stage, teams need something very specific from their leader.

•  In the Forming stage – They need a clear vision, a picture of what success looks like.
•  In the Storming stage – Let conflict rise to the surface, then clarify roles and support.
•  In the Norming stage – Team members need feedback on whether their ideas and strategies for how to achieve goals are working or not.
•  In the Performing stage – The leader needs to recognize and reinforce success through positive feedback.

The framework above can help you to see how important feedback is to the success of your team, especially in the later stages. When it comes to building a coherent working team timely and accurate performance feedback is essential. Remember to apply the following tips on performance feedback on your next project team:

•  Performance issues are dealt with as soon as they are recognized and before they can negatively impact the project. 
•  The feedback states clearly:
  •  What needs to be improved
  •  Why it needs to be improved
  •  How much and by when it needs to be improved (the “how” part of improving performance should be left up to the resource to the extent possible)

Cheers,

 Craig

When you need to do Time Estimates

The Project Plan: Tasks & Time Estimates

After you have completed the WBS and each deliverable has been broken down to the appropriate level, i.e., the level where the task can be completed within 40 hours or less, you are ready for the next steps in developing the project plan. (Please note, 40 hours or less is based upon best practice by PMBOK where hard deliverable tasks are kept to no longer than 1 week in duration.)

 The next step is to assign time estimates to each of the tasks.

After you have assigned time estimates, the next step is to put the tasks in logical sequence. Task dependencies will determine the sequence of some activities. The sequence of tasks is very dynamic. You must re-evaluate the sequence of tasks throughout the life of the project.

 You are now ready to:

• Assign Human Resources – Consider the skill sets needed to perform the tasks.
• Build a Project Schedule – Your will base your schedule on: when the project starts, how long each tasks takes, how many tasks are assigned to a resource, and the priority you assign each of those tasks. To do this

The time estimates are part of developing the project plan. They are started as early as possible in the planning process, often before the project manager has been assigned to the project. They should be completed as soon as possible after the WBS has been broken down into the lowest level. Completion and ongoing revision is the responsibility of the project manager.

 The Project Manager’s Role in Time Estimates

As Project Manager, you are responsible for refining any existing project time estimates, for assigning specific time estimates to each task in the fully decomposed WBS, and for revising and updating time estimates in the plan as the project progresses.

 How estimates are typically done

Task estimates are developed in 3 ways:

1. Historical Information – some companies maintain project task plan templates containing pre-defined tasks for the specific product(s) being installed. The tasks are pre-estimated, based on experience from other implementations. Another source of estimates for tasks is previously used project plans.  Many project tasks, especially implementation project tasks, are repeatable and it is helpful to review how other project managers have estimated the tasks. (It is important to archive  your completed project plan in a common knowledgebase as part of your project closeout process. These estimates should be refined after specific resources (individuals) are assigned to perform the tasks.
2.  For work units specific to the current project (e.g., an interface or a report), the PM can solicit estimates from an colleague or expert who has performed similar work in the past.
   If extensive work units are to be estimated (e.g., after a complex model is completed), the PM may request a technical resource to be assigned to the project specifically to perform the estimates.
   Other sources of Expert Judgement
   Individual project team members are also a good source of knowledge. They will often remember actuals from previous projects.
   Use Caution
   Be cautious of technical estimates made by functional resources or functional estimates made by technical resources. Both tend to undervalue the effort required by the other.
3. Approved Estimating Algorithms – Spreadsheets containing formulas and estimating determinates may be available for estimating specific work units.
   Use Caution
   Before you use an estimating algorithm, make sure it is approved by the client sponsor or the PMO. An algorithm that fails to take the right factors into consideration can create big problems for your project.

Effort- vs. Duration-based Estimates

Most estimates are effort-based (i.e., the total effort or resource hours required to complete the task with no elapsed time factored into the estimate), but sometimes a duration-based approach is acceptable. For example, the time required to acquire workstation PCs is typically based on the vendor’s lead-time which is duration, rather than the number of resources applied to the task of PC acquisition. Therefore the acquisition task is duration (or elapsed time) based.

 Revising Estimates

You will need to revisit the initial time estimates once specific resources are acquired. Any estimates you use should be influenced by the capabilities of the individual assigned. The estimates found in the templates may assume an average skill and experience level, but the actual resource assigned may be a highly skilled resource with extensive experience. Such a resource will be capable of completing the work unit much quicker than the basic estimate. Conversely, an inexperienced, junior resource will require more time to complete the work. You should confer with the assigned resources to ensure that the estimates are as accurate as possible and to ensure that the resources can commit to estimates and will accept responsibility for completing the work within the estimated timeframe.
You may also have to make adjustments because of differences in the client situation.  As an example, maybe the current client has 5 resources available for analysis, while the typical client has only 1 resource. Pre-existing estimates are based on typical clients, so you would need to revise the estimate upward.

 Reconciling Estimates for New Project Managers

If you don’t have the subject matter expertise to reconcile a difference between the time estimate in a template or previous project plan and the one provided by the human resource assigned, what should you do?

• Use the estimates provided by the assigned resource unless the resource makes adjustments to pre-existing estimates that seem unreasonable. 
• If you sense that the adjustment might be out of line, use another source to confirm the resource’s estimate.  Possibilities include:
  • Looking back at previously used plans
  • Using one of the approved algorithms in conjunction with a historical estimate
  • Asking the PMO or a Project Manager with the subject matter expertise you lack is a good reality check.

 Skill in Estimating

As you become more skilled as a Project Manager, you will be able to refine estimates with greater confidence. The more experience you obtain with actuals vs estimates, the better your own judgment will become. Most implementation tasks are repeated project after project, so as you update your project plans, you will become more knowledgeable about how long tasks actually take.

Estimates Should Change Throughout the Project

Estimates can and should be changed as the project progresses and the team gains more knowledge about the work to be done. Completing significant tasks can provide information that invalidates early estimates for subsequent related tasks. For example, completing the functional design for an interface can indicate that too much time has been allocated for the development of the interface.

 General Acceptance requirements for Time Estimating

In summary, all time estimates should be based on the following criteria:

• primarily be effort based (as opposed to duration based)
• expressed in hours (not days)
• based upon historical information, expert judgment, an approved algorithm, or a combination of all three
• be agreed to by the resource assigned
• take into consideration unique circumstances of the client and non-standard requirements specified in the SOW and Contract.

 Happy estimating,

  Craig

Educating Clients & Managing Expectation

You have completed the Charter and given it to the client. Despite all your good planning efforts, the client responds by identifying some internal expectations that are in clear contradiction to what is in the charter. What will you do?

Educating Clients & Managing Client Expectations

The key to being successful is managing the client’s expectations from the beginning to the end of the project. That is easy to say, but it is not always easy to do. We all pride ourselves on having excellent relationships with our clients. Sometimes, however, we are so concerned with customer satisfaction that we are tempted to agree to things the client asks for that are not really within the scope of the project. When that moment comes, we have to step back, assess the impact on all resources, and educate the client about what is and what is not within scope, and then negotiate a solution. If we silently accept small changes in scope in the beginning, we are not only failing to manage scope, we are also stepping onto a slippery slope. It will be much harder to recover later on. Remember: A successful relationship entails the mutual satisfaction of needs. A relationship is not successful if one party benefits at the expense of the other.

When you need to Manage Expectations and Educate your Client

As we said, you’ll need to manage client expectations throughout the project, beginning with the Statement of Work. Whenever you assess that the client’s expectations are different from project team’s, the education process must begin.

Your Role in Managing Expectations and Educating Clients

 As Project Manager, you’ll be responsible to:

•   Set expectations about Scope in the SOW and Scope Definition Statement
•   Clearly define roles and responsibilities
•   Monitor those roles to make sure they are being fulfilled
•   Educate clients about the project methodology being followed
•  Educate clients about change control and procedures

Acceptance criteria for Educating Clients

When it comes to relationship building with customers it is important to realize that all people have three kinds of needs:

•  Social Needs
•  Security Needs
•  Results Needs

At any one time, one kind of need may be more important than the others. When people feel that one (or more) of their needs are not going to be met, barriers to relationship arise. Those barriers include:

•  Defensiveness
•  Tension
•  Self-interest

 When those barriers arise, we need to be able to listen, ask questions, and build bridges across those barriers. The three bridges are:

•  Trust
•  Empathy
•  Understanding

 The above is true for your client and your team members alike. The next time you sense a barrier rising, move to build a bridge. It doesn’t work to ignore the problem and hope it will go away, to stonewall, or to become aggressive and try to beat down the resistance you are encountering. Only when you understand the client’s need can you start building a foundation of trust and understanding. Once you have a sturdy foundation, continue building the mutually beneficial relationship by educating the client and re-setting expectations appropriately.

A sign of proficiency is when you can say “no” to the client when you need to (to enforce the rigors of the project management methodology being followed) in a way that doesn’t “beat up” on the client, but actually improves the relationship because the needs of both parties are being addressed. Remember that developing these skills takes time. If you sense that your skills need improvement, seek out a colleague or mentor who will work with you to help you improve and give you real-time feedback.

Cheers,

Craig

How to Get Your Project Back on Track

 Your last project status highlighted several issues that the PROJECT MANAGER must address. Although the overall project progress is acceptable at this point, the technical work is lagging behind and there are strong indicators that this situation will continue unless some proactive changes are made now. Ten of the fourteen technical tasks scheduled to start within the first two weeks of the project did not get started. This was due to one group not finishing tasks so that another group could commence. You have resources scheduled to go on vacation in the coming weeks and the client has reported that system performance is unacceptable. What will you do as Project Manager?

An important aspect of project control is determining whether schedule variations require corrective action. The Project Manager must conduct a risk assessment of slipping tasks and make some decisions about how to change the plan to meet the target for implementation. This may mean identifying workarounds or rethinking priorities and assignments to accelerate the overall schedule. These decisions are part of the on-going requirement for the Project Manager to control the project. To do this, the Project Manager must know the exact status of tasks and Identify impediments to progress. Appropriate actions may include:

• Reprioritizing tasks and changing task assignments to optimize the project schedule.
• Procuring additional resources to keep the project on schedule.
• Identifying performance issues and rectifying the situation through mentoring, coaching or other approved management processes.
• Identifying and recommending reductions in scope
• Initiating the change control process

When you need to get your Project Back on Track

As Project Manager, you must initiate action to get your project back on track soon as:

• you determine that it is off-track, or
• you discover that there is a strong likelihood of schedule slippage downstream.

As the scenario above has illustrated, the progress of one project group can obscure the lack of progress in others. This emphasizes the need to analyze and understand the plan at the task level and to track productivity and contribution at the individual resource level. This process is not specific to one phase, but is continuous throughout the project and involves ongoing planning and scheduling as well as controlling.

The Project Manager’s Role in Getting the Project Back on Track

When you detect a problem with the project you are responsible to:

• Identify workload balancing changes that could be made to the plan to bring it back into alignment (e.g., reassignment of tasks or reprioritizing tasks).
• Determine what resource changes to recommend (e.g., adding more or different client resources, employing 3rd party vendor when appropriate, bringing on more contract resources, etc.).
• Prioritize your recommendations and escalate them for higher level decisions when appropriate (when it will affect cost, timeline or functionality). When you need to escalate, use the Change Control process specified in the project charter.

Getting the project back on track always falls to the responsibility of the Project Manager. A quick check list you can follow should consist of the following:

• Identify when the project is going off track before irrecoverable time is lost.
• Assess the potential impact if the situation is not corrected (do an impact analysis).
• Identify possible changes to the plan that would bring the project back into alignment.
• If the changes require additional budget, resources, or changes to the timeline or deliverables, initiate change control.
• Obtain necessary approvals and implement the changes.
• Update the project operating plan with the changes.

 

 Cheers,

Craig

Do You Follow a Regimented Issue Management Process?

An issue is an unresolved decision or situation that will significantly impact the project.

Every project manager is confronted with issues during the course of an engagement. All issues must be evaluated and resolved to ensure that risks to project success are identified and mitigated effectively.

The identification of an issue and its preliminary analysis are sub-processes included in the risk identification process (The four basic processes within the Risk Management discipline are risk identification, risk quantification, risk response development and risk response control).

As issues surface they must be documented and evaluated to determine if they fall into one of three basic classifications: (1) an issue subject to change control, (2) an issue requiring some administrative action on the part of the service provider or client or (3) an issue that has the potential to become a tangible risk factor to the project. The issue classification step should assign the issue to one of these three categories and start the process to resolve or mitigate the issue. More details on each class follow:

(1) If the issue has a specific remedy that is defined in the terms and conditions of the contract under change control (e.g., a resource cannot find time to complete his assigned tasks and requests that a contract resource be assigned to help with interface development), then the standard change control process is executed.

(2) Another group of issues includes questions that are raised by the client or other project stakeholders that need additional research or discussion to satisfy the inquiry. The eventual answer may move the issue into the change control process or the risk management process, or it may simply be closed once the answer has been supplied. Every issue that is documented or vigorously pursued by the client is a potential risk to project and business success and must be resolved. The resolution should be documented and published to mitigate exposure to write-offs and post-delivery disputes that may result in litigation.

(3) The last category includes those issues that present potential risk to the project’s success.

When you need to Manage Project Issues

Issues can be identified at any time, during project planning, scheduling or controlling. They need to be managed (controlled) as soon as they arise. An issue can become a risk at any time.

Acceptance Criteria for Issue Management at AG Consulting

There are 4 aspects to Issue Management:

Issue Identification & Tracking – Identifying outstanding questions, decisions and other problems before they adversely affect the project. Establishing and tracking a plan for getting them resolved.

Issue Analysis – Understanding the issue sufficiently to consider future consequences of action plans made to resolve it.

Issue Control – Carrying out actions to ensure issues are resolved in a timely and effective manner. Prioritizing and orchestrating the issue resolution process.

Issue Communication – Communicating issues and their resolution to the right level of the organization to get them resolved, or to prevent them from escalating into risks.

The Project Manager’s Role in Scope Definition

Like Risk Management, Issues Management is a collaborative endeavor. Everyone is responsible for identifying issues. However, the Project Manager is responsible to:

Set up an issues tracking system. You will need to make a choice as to how you want to keep track of issues. Many organizations have their own process to follow.

Assess whether the questions or situations raised by other team members are truly issues, i.e, that the question or situation cannot be answered or corrected in time to prevent an impact on the project progress or budget.

If so, update your issues tracking system so that the issue is on record.

Initiate a resolution by determining the issue priority and assigning an owner with responsibility for identifying several alternative resolutions and recommendations. Assign target dates for reporting periodic status on the resolution.

Escalate the issue, if necessary. Some issues cannot be resolved within the project team. The project manager is responsible for presenting such an issue to those who need to know and for making sure that an action plan is created.

Select a resolution from the alternatives presented to you, or assemble the appropriate decision makers and present the alternatives together with recommendations

Notify those who need to know how the issue is going to be resolved.

Determine if the resolution involves a change request. If so, implement the Change Control Process.

Track the resolution progress n the Issue Tracking System and communicate the results.

As with Risk Management, although the ultimate responsibility for Issue management lies with the Project Manager, this is a collaborative endeavor. Team members are responsible for identifying issues and for escalating issues to you, the Project Manager, if they cannot resolve them at their level. It is your responsibility as Project Manager to encourage your team to identify issues throughout the engagement. Experience has shown that the people closest to the work usually know best how to resolve issues. Therefore, it is also your job to encourage each team to be responsible for resolving as many issues as possible at the local level. At the same time, it is important to escalate those issues which should be escalated as soon as possible.

If Issues are not resolved, there can be negative consequences for the Project Manager. The consequences include the following:

• Inability to deliver to contract timelines, cost, and schedule
• Poor or unacceptable functional design
• Poor reference from the client
• Post implementation disputes

Having a well documented issue management process is crucial to communicating and enforcing that process across your team. If your organization does not have one, be sure to create one for your project.

Cheers,

Craig