Six Components of a Procurement Management Plan

/in /by

The Procurement Management Plan is a part of the overall Project Management Plan. The document describes how items will be procured during the project and the approach you will use to managing vendors on the project. Specific areas to describe include:

Procurement process. This section provides a brief overview of the process requirements necessary to manage procurement of the identified needs. This process should include:

  • Initiating a request
  • Development of requirements (technical, timing, quality, constraints)
  • Request approval
  • Purchasing authority
  • Bid / proposal review
  • Contract management responsibility
  • Contract closure requirements
  • Procurement process flowchart

Roles and responsibilities. This section describes the various roles on the project that have some connection to procurement. This section should describe who can request outside resources, who can approve the requests, any secondary approvers, etc.

Identified procurement needs. This section details the material, products or services identified for outside procurement.  Each listed item should include a justification statement explaining why this should be an outside purchase if there is the possibility of inside sourcing (make vs. buy decision).

Timing. This section will describe the timeframe that resources are needed. This will provide a better sense for when the procurement process needs to be started for each item.

Change review and approval process. Describe how changes are made to procurement documents to ensure the changes are valid, understood and approved by the appropriate people.

Vendor processes. Describe the processes that the vendors should use for timesheet approval, invoice processing, contract renegotiation, status reporting, scope change requests, etc.

There may be additional information in the plan as well to ensure the procurement process is understood and managed effectively.

Ten Steps to Manage Issues on Large Projects

/in /by

Issues are more than just common problems. They are problems that meet specific criteria. An issue is a formally-defined problem that willimpede the progress of the project and cannot be totally resolved by the project manager and project team without outside help. The processes used to manage issues can be simpler or more rigorous depending on the size of the project. Use the following process to manage issues on large projects.

    1. Identify the problem and document on the Issues FormSolicit potential issues from any project stakeholders, including the project team, clients, sponsors, etc. The issue can be surfaced through verbal or written means, but it must be formally documented using an Issues Form.
    2. Determine if the problem is really an issueThe project manager determines whether the problem can be resolved or whether it should be classified as an issue.
    3. Enter the issue into the Issues LogIf it is an issue, the project manager enters the issue into the Issues Log.
    4. Determine who needs to be involved in resolving the issueThe project manager determines who needs to be involved in resolving the issue. The sponsor may be involved, or the sponsor may not have the expertise to assist in the resolution process. For instance, the problem may be contractual and require resolution from the Purchasing Department. However, at some point the alternatives will be discussed and a resolution will be made. It is important to understand up-front who needs to be involved in making this final issue resolution.
    5. Assign to team member for analysis and alternativesThe project manager assigns the issue to a project team member for investigation (the project manager could assign it to himself or herself). The team member will investigate options that are available to resolve the issue. For each option, the team member should also estimate the impact to the project in terms of budget, schedule and scope.
    6. Gain agreement on resolutionThe various alternatives and impact on schedule and budget are documented on the Issues Form. The project manager should take the issue, alternatives and project impact to the appropriate stakeholders (from step 6 above) for discussion and resolution. The project manager may want to make a recommendation from among the alternatives as well.
    7. Close the Issues LogThe project manager documents the resolution or course of action on the Issues Log.
    8. Close the Issues FormThe project manager documents the issue resolution on the Issues Form and then closes and files this document.
    9. Add action plan to the scheduleOnce a resolution is agreed upon, the appropriate corrective activities are added to the schedule to ensure the issue is resolved.
    10. Communicate through the Status ReportThe project manager communicates issue status and resolutions to project team members and other appropriate stakeholders through the methods established in the Communication Management Plan, including the project Status Report.

Smaller projects do not need all of these steps. For instance, the issue can be documented directly in the Issues Log without the need for the separate Issues Form.

Schedule Estimating Threshold

/in /by

When you create a schedule you generally don’t know enough to enter all of the detailed activities the first time though. Instead, you identify large chunks of work first, and then break the larger chunks into smaller pieces. These smaller pieces are, in turn, broken down into still smaller and more discrete activities. This technique is referred to as creating a Work Breakdown Structure (WBS).

A question people ask is how small the activities should be before they do not need to be broken down further. This is referred to as your “estimating threshold”. Work can be broken down into smaller activities than the estimating threshold, but normally no work would be left at a higher level. The threshold can be different based on the size of your project and how well the work is understood.

You can use the following criteria as a guide. For a typical large project (say 5000 effort hours or more) the activities should be no longer than two weeks. Medium and small projects (say 1000 effort hours or less) should have activities no larger than one week. Remember that this threshold is an upper limit. You can break the activities down further if you want.

Assigning work that is smaller than your threshold allows the work to be more manageable. Think about it. When you assign work to a team member you don’t know for sure how he is progressing until the due date (or the completion date if it comes first). (Yes, you can track progress if the work proceeds linearly – like painting a wall. But many of us work in the knowledge business (IT, Sales, Finance) and it is not easy to know exactly how the work is progressing.)

Let’s look at an example. If you assign a team member work that is due in four weeks, you are not going to know for sure whether the work is on time until the four-week deadline. The worker may tell you things are on track, but you don’t really know for sure until the due date. If the work is completed you will know you are on track. If the work is late you will know it then as well. However, four weeks (or longer) is too long to wait to know if the work is on track. A better approach is to break the four-week activity into four one-week activities. Then you will know after the first week if the work is on time or not.

If at all possible you want to try to have schedule work completed within two weeks. If you give someone work that takes four weeks or longer there is just too much time before you really know if things are on-track or not. It is much better for you if you can keep the schedule feedback loop to no more than two weeks.

Manage the Schedule for Small Projects

/in /by

All projects need a schedule. If you have a small project perhaps the schedule is a simple checklist or Excel spreadsheet. As projects get larger they need more formal scheduling templates and tools.

The processes you use to manage a schedule also vary depending on the size of the project. Large projects need a lot of schedule management rigor. Small projects can use a lighter process. The following steps can be used to mage the schedule of a small project.

Review the schedule on a weekly basis.

Identify activities that have been completed during the previous week and update the schedule to show they are finished.

Determine whether there are activities that should be completed, but are not. Work with the individual that is assigned to the work see what is going on. Determine how much additional effort and duration are needed to complete the work and update the schedule accordingly.

Evaluate the remaining work to see if the project will be completed within the original duration. You may find that even though some activities may be completing later than planned, other activities may be completing early and the overall schedule may still be okay.

If your project is trending behind schedule, think of schedule management techniques you can apply to get back on schedule. Raise a schedule risk in your status report if the original deadline appears to be in jeopardy.

Adjust the schedule so that it reflects the remaining work to be completed, and is as accurate as possible.

Since this is a process for a small project, it would be unusual to have major problems with the schedule. The consequences of problems on small projects are generally small as well.

Define the Objectives of Your Project

/in /by

Define the Objectives of Your Project

Objectives are concrete statements that describe the things the project is trying to achieve. They are included in your Project Charter. An objective should be written in a way that it can be evaluated at the conclusion of a project to see whether it was achieved. A well-worded objective will be Specific, Measurable, Attainable / Achievable, Realistic and Time-bound (SMART). (SMART is a technique for wording the objective. An objective does not absolutely have to be SMART to be valid.)

An example of an objective statement might be to “upgrade the customer service telephone system by December 31 to achieve average client wait times of no more than two minutes“.

  • Note that the objective is specific.
  • The objective is measurable in terms of the average client wait times the new phone system is trying to achieve.
  • You can assume that the objective is achievable and realistic.
  • The objective is time-bound, and should be completed by December 31.

Objectives should infer the deliverables of the project. In the prior example, the objective refers to the upgrade of the telephone system. If you cannot determine the deliverables that are created to achieve the objective, the objective may be written at too high a level. On the other hand, if an objective describes the characteristics of the deliverables (such as speed or ability to handle a specific number of users), it is written at too low a level. Characteristics tend to be more requirements statements – not objectives.

If the project is a part of a larger program, the objectives of all the underlying projects should be in alignment with the program objectives.

Objectives are important because they show a consensus of agreement between the project manager and the project sponsor on the main purpose of the project. For example, the specific deliverables of an IT project may or may not make sense to the project sponsor. However, the objectives should be written in a way that they are understandable by all of the project stakeholders.

Objectives are also valuable since they provide alignment to organization goals and strategies. Your organization should not authorize projects that do not tie to goals and strategies

The project objectives should be defined and agreed upon before the project starts. The deliverables of the project are created based on the objectives. A facilitated meeting between all major stakeholders is a good way to create the objectives and gain a consensus on them at the same time.

Three Techniques for Scope Change Management

/in /by

1. Hold Everyone Accountable for Scope 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, your customer may try to go directly to team members for changes.

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. Your customer  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.

2. Use a Change Control Board for Large Projects

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 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.

3. Make Sure the Right Person Approves Scope Changes

A typical problem on a project is that the team does not understand the roles of the sponsor, customer and end users in the area of change management. In general, the project sponsor is the person who is funding the project. The sponsor is usually high up in the organization and not easy to see on a day-to-day basis. 

The people that the project team tends to work with most often are normal customers and end users. End users are the people that use the solution that the project is building.

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. The sponsor (or designee) 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 cannot know if the project impact is acceptable.

Five Steps Before Estimating Work

/in /by

Estimating is hard enough. It is even harder if you are not prepared. Estimating a 20 hour chunk of work is not so hard. Estimating for full projects or large chunks of work can be challenging. Templates can help, but consider the following steps before you begin the estimating process.

Get a clear picture of the work that is being estimated

Many problems with estimation come because the estimator is not really sure what the work entails. You should avoid estimating work that you do not understand. This should not imply that you can know every detail. The estimating contingency is a way to reflect some of this remaining uncertainty.

Determine who should be involved in the estimating process

The project manager may or may not know enough to make the estimates on his or her own. It is usually a good practice to look for estimating help from team members, clients, subject matter experts, etc. This will usually result in the estimates being far more accurate than you would get by yourself.

Determine if there are any estimating constraints

If there are estimating constraints, it is important to know them up-front. For instance, the end-date may be fixed (timeboxed). You should also know if the client expects Six-Sigma level quality in the deliverables, or if the 80/20 rule will apply. It is possible that there may be a fixed budget that cannot be increased. (This would be of interest so that you can reduce the scope of work, if necessary, to meet the fixed budget.) Knowing these constraints will help the estimators make valid assumptions regarding the cost, duration and quality balance.

Determine multiple estimating techniques to utilize if possible

There are a number of techniques that can be used to estimate work. If possible, try to use two or more techniques for the estimate. If the estimates from multiple techniques are close, you will have more confidence in your numbers. If the estimates are far apart, you need to review the numbers to see if you are using similar assumptions. In this case, you can also try to utilize a third (and fourth) estimating technique to see if one initial estimate can be validated and the other rejected.

Document all assumptions

You will never know all the details of a project. Therefore, it is important to document all the assumptions you are making along with the estimate.

Understand the Risk Tolerance Level in Your Organization

/in , /by

All projects have risks and all risks have the potential for negatively impacting the project. You use risk management to determine the risks that are important enough to manage. During the risk identification process, you may encounter many risks that have some likelihood to occur and have a marginal impact to the project. The question to ask is whether the risk has enough impact on the project to worry about (this same question occurs for both qualitative and quantitative approaches). The answer says something about your risk tolerance.

For example, let’s say you identify a risk that is very likely to occur, but has an impact of $100 and one-half day duration. You may choose not to manage it. You cannot list this as an assumption since there is a good chance the risk will occur. However, the impact is small enough that you are willing to absorb the cost if it occurs, rather than deal with managing the risk (which would probably be more costly). Therefore you would choose a risk management strategy of leaving the risk.

In the prior example, the numbers were fairly trivial and the risk was easier to ignore. But, ratchet the impact up a little higher. Let’s say the risk now was $500 and one day duration. What about $100,000 and three months duration? Of course, the answers are all relative based on the size of the project. If your project had a $20,000 budget, a $1,000 risk impact might be worth managing. If your project budget is one million dollars, the risk impact of $1,000 would just be marginal.

When you are performing risk identification, you need to determine your tolerance level for risks. This will help you focus on the risks that are important and above your tolerance level, while ignoring risks where the impact falls below the tolerance level. Risk tolerance is also cultural in your organization. Some organizations are bigger risk-takers and will accept a higher level of risk on projects. They will also tend to have a higher threshold before they chose to manage a risk.

On the other hand, some organizations are more risk-averse. They will tend to accept less risky projects and they will also tend to have a lower threshold to manage risks. For example, let’s say you have a similar project in both organizations. The project managers in these risk-averse organizations will tend to manage risks that a project manager in the other organization might choose to leave.     

The Power of the Aligned Organization

/in /by

When was the last time you rode in a car with wheels that were not properly aligned? Chances are it was a pretty rough ride. The car either pulled in one direction, making it hard work to keep it in your lane, or, it worked against itself as one tire pointed one way and another tire another way.


The same thing can happen in our companies. The ride can be pretty bumpy, not to mention noisy, unless everyone is pointed in the same direction. That’s why it’s important to understand the five benefits of an aligned organization

Benefit #1 – Ensures Everyone Works on the Right Things


The first benefit of an aligned organization is that with a common goal for everyone to strive towards, the right things are worked on. Here’s the trick – you need make sure that everyone clearly understands the goal and the end game. The best way to accomplish this is to clearly communicate the strategy of the company. What are the three to five most important things your company is working on? Once those are communicated and understood, you can then align everyone’s activity to accomplish those initiatives.

Benefit #2 – More is Accomplished


An aligned organization is structured and disciplined. This doesn’t mean the company lacks creativity or is oppressive. Rather, it means that projects not aligned with company strategy are not allowed to infiltrate the company. Alignment allows resources to stay focused on the tasks at hand and not waste time on other distractions.

Benefit #3 – Teamwork Increases


A third benefit of alignment in the organization is increased camaraderie. The ‘us’ versus ‘them’ mentality is nipped in the bud while everyone works toward the same goals together. Departments and groups of people that are not properly aligned have a tendency to look after their own interests. This will still occur in the aligned organization, but there is also more of, “what can I do to help?” Team members in the aligned organization realize that everyone must cross the finish line at the same time in order for the project to be successful.

Benefit #4 – Profitability Rises

 

An aligned company is a company that runs efficiently. Engaged teams that are working on the right things are naturally going to get more done. Getting more done in less time results in increased profitability. There are fewer misunderstandings and mistakes – and rework is few and far between. Alignment helps keep resource costs in check, and reduces expenses, both of which are areas that impact the bottom line.

Benefit #5 – Opportunities Abound

 

People like working with people and companies that have a track record of success. The aligned organization will have plenty of success stories to tell. That credibility allows salespeople to sell more, executives to explore new strategies, and managers to optimize opportunities. It generates more top-line revenue that ultimately trickles down to the bottom line.


A car that is not aligned will still run; however, the ride is rough and it’s not very efficient on gas. Once aligned, the car rides much more smoothly and fuel efficiency increases dramatically. Your company can still run if it’s not aligned, just not very efficiently. Take the time to align your organization and begin realizing the benefits!

The Customer May Not Know Enough to Completely Define the Project

/in /by

Sometimes the project manager places too high an expectation on the amount of foresight and vision that customers and sponsors have. In many cases, the project manager will go to the customer looking for answers to help define the project and the customer will not have all of the information needed. This happens all the time and it does not mean that the customer does not know what they are doing. In many cases, especially for large projects, the customer has a vision of what the end results will be, but cannot yet articulate this vision into concrete objectives, deliverables and scope. 

There are three approaches for when you don’t know very much information on the nature of the project.

Increase Estimating Range Based on Uncertainty

Based on having less than complete information, the  project manager may feel the need to guess on the details. This is not a good solution. It is better to state up-front everything that you know, as well as everything that you do not know. If you are asked to come up with estimated effort, cost and duration, you will need to provide a high and low range based on the uncertainty remaining. On a normal project, for instance, you might estimate the work within +/- 10%. On a project with a lot of uncertainty, the estimating range might be +/- 50%. 

Break the Work into Smaller Projects

Another good alternative is simply to break the work down into a series of smaller projects based on what you know at the time. Even if the final results cannot be clearly defined, there should be some amount of work that is well defined, which will, in turn lead to the information needed for the final solution. You can define a project to cover as far as you can comfortably see today. Then define and plan subsequent projects to cover the remaining work as more details are known.  For instance, you could create a project that gathered business requirements, and then use the results of that project to define a second project to build the final deliverables. 

Uncover the Details as the Project Progresses

If you are not allowed to break the project into smaller pieces, you should at least know enough that you can plan the work for the first 90 days. In this third approach, you plan the short-term work in more detail, and leave the longer term effort more undefined. Each month you should redefine and plan the remaining work. As you uncover more and more information, you can plan the remaining work at a more detailed level. As you uncover more details, you can refine your estimates and work with the sponsor to make sure it is still okay to continue.

This last approach uses an Agile philosophy. Agile projects are generally exploratory. The details of the project are uncovered as the project progresses. (There are many more differences in Agile projects, but this philosophy is one.) In a traditional project management model this would also be known as ‘progressive elaboration’ – which also means more details are uncovered as the project progresses.