Category Archives for 4=Control

12 Good Reasons You Are Struggling With Small Projects

"Why am I still having problems with small projects?

This plaintive question is one I'm asked from time to time. I'd like to give a few brief reasons why project managers struggle with small projects.

"Small things have a way of overmastering the great. This small press can destroy a kingdom." —Sonya Levien

Click to Tweet

Pitfalls of Small Projects

1. You think these projects are simple. In general, smaller projects have less risk. However, small projects may have a complex set of variables.

Be sure to analyze the complexity of the project. For example, you may engage your team to draw a context diagram and/or data flow diagrams early in the project. This exercise allows the team to understand the context of the project.

2. You don't have a project charter. Project managers are assigned projects at the last minute with a tight deadline. Rather than discussing the project with stakeholders and documenting the business case, problems, goals, and deliverables, the project manager hits the ground running. Later, stakeholders demand costly changes.

Make it a priority to engage your key stakeholders and develop a project charter. This exercise will provide a good foundation and reduce the changes later in the project. For smaller projects, the project manager should be able to create a charter in short order.

3. You are applying the wrong level of rigor. I see two extremes: First, project managers do not follow any methodology. 

Second, project managers undertake numerous tasks usually performed for large, complex projects.

Keep it simple. Determine the steps you plan to take and develop the planning documents that will provide real value. Execute and stay with the plan.

4. The Project Sponsor is invisible. Many pint-projects have no sponsor at all. The organization may assign a sponsor, but the sponsor has abdicated his or her role to the project manager or someone on the team.

If you don't have a sponsor, solicit a fitting sponsor. Discuss with the sponsor their role and ask for their commitment.

5. Your team has been poorly staffed. These projects often get the leftover resources. Any warm body will do or will it?

For all projects, define the required knowledge and skills. Seek to staff the project team accordingly.

6. You are not performing project risk management. Yes, smaller projects typically have less risk. This does not mean there are zero risks.

Risk management should not take much time, but be sure to integrate risk management in your project activities. Simple qualitative analysis should be sufficient for evaluating the risks.

7. You are not performing change management. A stakeholder asks for a change in the scope. It's not a big change. You say okay.

Users request additional changes over time. The cumulative effect becomes significant.

Decide up front how you will manage, track, and report changes. When is a change order required? Who has to approve it? 

"I can do small things in a great way." —James Freeman Clarke

Click to Tweet

8. You are managing a project no one cares about. Projects may be selected arbitrarily. In some cases, the project does not align with the company’s strategy. The team knows the project is a low priority and give it little attention.

This is a management issue. Management should create a Project Board that reviews project requests for strategic alignment.

9. Your project team is too large. Your project may be small, but it impacts several areas of the company. Everyone feels like they need someone on the team. You have fifteen people on the team when a handful will do.

Create a small core team. Make sure the team represents the primary stakeholder groups. You may wish to create a supplemental team of individuals who may be engaged as needed.

10. You are using the wrong tools. Some project managers spend more time setting up their tools than managing the project.

Keep things simple. For example, rather than using complex scheduling tools, you may use Excel.

11. You are managing too many projects. Project managers may be assigned numerous projects. The project managers may have difficulty prioritizing and juggling the management activities resulting in wasted time.

The person or persons responsible for assigning project managers should be careful to assess each project, estimate the time required by the project manager, and maximize project management resources. Monitor success rates for small projects and make adjustments as needed.

12. You have not identified the important stakeholders. Surely we know who the stakeholders are or do we? We are tempted to skip the stakeholder identification.

Don’t make the common stakeholder mistakes. Small projects can touch a complex set of variables. Neglect in identifying and managing the stakeholders can be costly later in the project.

Review Your Small Projects

Take a few minutes to review your small projects. Do you need to let go of some misconceptions and make some changes? Create some new habits. Don’t allow yourself to slip back into unproductive behaviors.

Let Me Show You How to Determine Project Budget Reserves

After publishing my article entitled Evaluating Risks Using Qualitative Risk Analysis, I received questions on how to determine project budget reserves. Here are my answers.

4 Business People at a Boardroom Table discussing budget reserves

Project Budget Reserves: Questions and Answers

Question #1

After evaluating risks qualitatively, do you set aside some dollars for a contingency reserve?

The Answer:

The short answer is yes. Contingency reserves are for “known risks” identified in risk management. The contingency reserves cover residual risks in the project and account for cost uncertainty such as rework.

Imagine a project budget with no reserves. The project manager is basically saying there will be little to no problems. The project manager expects to deliver every task with no negative impacts to the budget. A wise project manager will identify risks, assess risks, and recognize the potential impacts by adding appropriate reserves to the budget.

Question #2

How do we estimate a contingency reserve?


The Answer:

The Project Management Body of Knowledge (PMBOK) says that contingency reserves may be a percentage of the estimated cost, such as 5% - 10% of the estimated cost.


For example, a project manager may estimate the project cost to be $100,000. Assuming a 10% contingency reserve, the project manager would estimate the contingency reserve to be $10,000 (i.e., $100,000 x 10%). The project manager would add the contingency reserve to the project estimate resulting in a cost baseline of $110,000.

Continue reading

Ask the Right Questions at the Right Time

The success of a project manager largely lies in the individual’s ability to communicate. Some project managers have great oratory skills but don’t ask the right questions at the right time.

Here are some key questions for each of the project management process groups. This is not meant to be a comprehensive list; just some questions to get you thinking. Neither will you need to ask all of these questions for every project.

Keep in mind, the project process groups are seldom sequential, one-time events; they are overlapping activities that occur throughout the project.

Ask the Right Questions at the Right Time

Initiating Process Group

  1. Why are we doing this project?
  2. Is your project sponsor fully engaged and on board?
  3. What is the authority level of the project manager?
  4. What do we wish to accomplish?
  5. What are the products and services we wish to deliver?
  6. What are the budget constraints?
  7. What are the schedule constraints?
  8. What assumptions are being made?
  9. Who will be impacted? Which stakeholders have the greatest interest and power?
  10. Who will comprise the project team?
  11. What are the most significant risks?
  12. How will we know if the project was successful?

The Project Charter

Unfortunately, many people think of the project charter as an administrative hoop they must jump through to get their project approved. Therefore, many charters are written hastily with little thought.


The value of the charter process is engaging stakeholders, discussing the issues, resolving conflicts, and getting agreement as you initiate the project. The stakeholder interest is considered and aligned, resulting in less likelihood of costly changes later in the project.


Read: How to Develop a Project Charter

Continue reading

How to Manage Project Scope

How many times have you experienced scope creep? You know the drill—you elicit and document the requirements. You receive sign off. You continue to see changes to the requirements. Many projects experience 10, 20, 25-percent change in requirements over the life of the project. Let's explore how to manage project scope.

Scope is Not a Mouthwash

You cannot manage what you do not understand. Let's get our arms around the concept of scope. The Project Management Body of Knowledge (PMBOK) defines scope as the sum of the products, services, or results.

When we use the word "scope", it is helpful to specify the type of scope—product scope or project scope. The product scope are the features and functions of the product, service, or result. The project scope is the work to deliver the product, service, or result.

Imagine that you plan to have a painter paint your living room. Here are some product scope questions:

  • Do you want the walls painted?
  • Do you want the trim painted?
  • Do you want the ceiling painted?
  • Do you want a coat of primer applied before the first coat of paint?
paint
  • What color do you want for the walls, trim, and ceiling?
  • What brand and type of paint do you want?
  • Do you want a second coat of paint?

What are the tools and equipment that are needed? What work will be done to deliver the product? Here are some project scope questions:

  • Will someone remove the furniture from the room before the room is painted?
  • Will the painter clean the walls and trim before painting?
  • Will the painter tape the trim before painting the walls?
  • Will the painter use a brush or a paint sprayer?
  • Will someone inspect each step before the painter moves to the next step?

Want more clarification on product and project scope? Read this article from Villanova University.

Manage Your Project Requirements

When it comes to requirements, I wish I could read my user's minds. Unfortunately, collecting requirements is challenging. Project managers should consider engaging an effective business analyst for large projects.

A critical part of projects is defining and managing the project requirements. Requirements are the capabilities or conditions needed in the product, service, or result. They are specifications of what should be developed or implemented.

Like the word scope, it is helpful to use an adjective when talking about requirements. There are different types of requirements. Check with your organization to see if there are standard definitions for different types of requirements.

I typically use the following terms. Notice the cascading levels of requirements. We begin with high-level requirements and progressively elaborate the requirements into greater detail.

  • Business requirements - the high-level business goals of the project (e.g., Increase customer retention by 5% by the end of the year).
  • User requirements - a task of a user group (e.g., Quote an insurance policy).
  • Systems requirements - the detailed specifications of the features and conditions needed in the system (e.g., The system shall invoice customers at month-end).

WBS: Define Your Scope

How do you eat an elephant? One bite at time. We all know the saying. Project managers can use this principle for any size project. Use the Work Breakdown Structure (WBS) to break your projects into bite-sized pieces.

The WBS is a hierarchical decomposition of the work to be performed in order to meet the project goals and create the deliverables. The lowest levels of the WBS are the work products and deliverables used for scheduling, estimating, monitoring, and controlling the project. Learn how to build a WBS.

“Any goal can be achieved if you break it down into enough small parts.” -Brian Tracy

Click to Tweet

Use Prototypes to Analyze Requirements

Do not make the mistake of waiting until the end of a project to unveil the product, service, or result to your stakeholders. Periodically show the prototypes or deliverables to the customer(s) and the sponsor. When the deliverables are mature, seek formal acceptance. These steps can greatly reduce the risk of rework.

Monitor and Control Project Scope

Project managers should meet with their teams on a regular basis to compare the work completed to the project scope baseline (the defined deliverables, assumptions, and constraints). If there is variance, determine whether corrective or preventive action is required.

Manage the Changes

Many project managers think their job is ensure that no changes occur. Make no mistake about it—change happens. Expect it!

Our job as project managers is not to stop all the changes but to ensure the necessary changes occur in an organized and agreed-upon manner. Don't get me—project managers should not just add anything that is requested. Requested changes should support and align with the overall goals of the project.

Take changes through a change control process. Analyze and report the impact to the project sponsor. Seek approval when necessary before proceeding.

Your Turn

Project managers face a multitude of scope risks. Be diligent up front in your project to develop a scope management plan. Seek to understand your user's needs. Engage appropriate stakeholders on an ongoing basis. Regularly compare your work against your plan and make needed corrections.

Are You Making These 8 Stakeholder Mistakes?

Have you ever had someone torpedo your project? Did this individual have a motive to undermine your efforts? Or, did you make some stakeholder mistakes that gave rise to this event?

Either way, it's hindering your progress. Things are not going as planned. What can we do to manage stakeholder risks better?

stakeholder mistakes

A Stakeholder Story

I once observed a  junior project manager who was knighted to manage a project with a fixed regulatory deadline. Software changes were needed. The project sponsor told the project manager that it was critical that the project be delivered on time. No exceptions!

sword

Knighted Project Manager 

The project manager formed a project team. Within days, the project team started making programming changes. The team worked evenings and weekends.

Continue reading

3 Ways Your Team Makes Your Project More Risky

This is a guest article by Elizabeth Harrin from GirlsGuideToPM.com.

Much of the time, risk management at the beginning of a project looks like getting the team in a room to review the whole project and work out what might be coming that could affect how the project proceeds.

The project manager writes up the discussion in the risk register along with what the team is going to do to avoid or amplify (in the case of positive risk) the risks. As the project progresses, more risks are identified, dutifully added and managed.

Team Risks

Risks Caused by Team Members

What’s happening here is that we’re looking at the work and impacts on the work. This approach to risk management is very task driven. We ask questions like:

  • What might prevent us from hitting that milestone on time?
  • What might mean we need to ask for a budget increase during this phase?
  • What quality problems might we come across that would give the client an issue?
  • Who might be a difficult stakeholder on the project?

These are all valid questions. But they miss one crucial area that massively affects everything on the project every day. Us. The project team.

Our skills, ability to work together as a team, or lack thereof, present the biggest chance of success for the project and also the biggest risk.

Here are some examples of how the people on your team make your project inherently more risky.

Continue reading

8 Powerful Ways to Manage Project Quality

Why is project quality often neglected? Well, it's hard to manage things we don't understand. And quality seems to be an esoteric concept to many people. Therefore, let's define quality and discuss some practical ways to manage project quality.

Project team focused on quality

Project team focused on quality

Quality Management Tips

1. Make quality management pragmatic. Many people do not invest appropriate effort towards quality because they do not understand it. The Project Management Institute defines quality as “conformance to requirements and fitness of use.” According to this definition, quality comes through clearly defining and meeting the requirements of the users and stakeholders.

Continue reading

6 Tools and Techniques for Controlling Risks

Changes in project risks are inevitable. As a project progresses, the probability and impact of current risks change, new risks emerge, and residual risks may increase or decrease. What tools and techniques can project managers use for controlling risks and getting the results they are looking for?

Tool box with tools

Allow me to introduce you to two project managers—Tom and Susan. Tom started his project with a risk identification exercise with several stakeholders resulting in a list of 77 risks. He entered these risks into an Excel spreadsheet and stored the file in his project repository (and never looked at it again).

Susan, on the other hand, facilitated an early risk identification workshop. She periodically met with her team to review current risks and used additional techniques to identify new risks. In these risk review sessions, the team discussed the effectiveness of the risk responses and the risk management processes.

Which team do you think had the greatest chance of meeting their project objectives? Yes, Susan’s team wins the day, hands down.

Let’s look at six tools and techniques recommended in the Project Management Body of Knowledge (PMBOK) 5th Edition for controlling risks. 

PMBOK 6th Edition

The PMBOK 6th Edition changed the process name of "Control Risks" to "Monitor Risks."


"Monitor Risks is the process of monitoring the implementation of agreed-upon risk response plans, tracking identified risks, identifying and analyzing new risks, and evaluating risk process effectiveness throughout the project."


Read my articles: 

Risk Control Tools and Techniques

1. Risk reassessment

Risk reassessments involve the following activities:

  • Identifying new risks
  • Evaluating current risks
  • Evaluating the risk management processes
  • Closing risks 

2. Risk audit

Project teams may have defined risk responses. The question is—“Are the responses effective?” Project managers facilitate risk audits to examine the effectiveness of the risk responses and to determine whether changes are required. The team also examines the processes to identify, evaluate, respond to, and control risks.

3. Variance and trend analysis

As with many control processes, we now look for variances between the schedule and cost baselines and the actual results. When we the variances are increasing, there is increased uncertainty and risk. Watch the trends and respond before the situation gets out of hand.

4. Technical performance measurement

Imagine that you are working on a software development project and that the functional requirements have been developed. You’ve planned to deliver functions at a point in time—at the end of the fourth sprint, at the end of phase 1, or a milestone. The technical performance measurement is a measurement of the technical accomplishments.

5. Reserve analysis

During the cost planning, the contingency and management reserves are added to the project budget as needed. As risks occur, the reserves may decrease. Depending on how your organization handles reserves and your risk management plan, project managers may request more reserves when inadequate.

6. Meetings

Project managers should be deliberate risk managers. Engage your team members and appropriate stakeholders in meetings to facilitate the risk management processes. For these meetings, be sure to:

  • Distribute an agenda with a clearly stated purpose
  • Invite the appropriate team members and stakeholders
  • Use appropriate tools and techniques
  • Distribute meeting minutes containing decisions, action items, issues, and risks 

Finish the Drill

Don’t be like Tom who started his risk management with a bang and quickly fizzled. The best project managers identify, evaluate, and respond to risks. And they regularly perform the control activities to keep the project healthy.

Hey, before you go, keep in mind—you can't control risks until you first identify risks. Click here to discover 7 ways to identify project risks.

Evaluating Risks Using Qualitative Risk Analysis

Have you ever endured a project meeting where you spent hours evaluating risks? Afterward, team members walked down the hall saying, “What a waste of time! Now I can get back to the real work.” Today, let’s discuss the use of qualitative risk analysis to get you back on track.

What causes this frustration? First, the evaluation process may not fit the project – too complex for simple projects or deficient for large, complex projects. Second, the process may not fit the maturity level of the project team. Third, team members view the process as burdensome with little value.

Business people in a meeting analyzing content

Qualitative Risk Analysis

What is Risk Evaluation?

Risk evaluation is the process to determine the significance of each risk. There are two ways to evaluate risks:

  1. Qualitative Risk Analysis. Qualitative analysis such as rating probability and impact should always be performed. This allows you to quickly prioritize and rank your risks.
  2. Quantitative Risk Analysis. Quantitative analysis is not always performed. This analysis requires more time but provides more data to aid in making decisions. (We will cover quantitative evaluations in another post.)

Watch this YouTube Video: Qualitative and Quantitative Risk Analysis: What’s the Difference?

Watch this YouTube Video: Two Simple Methods to Analyze Project Risks Qualitatively

Why Evaluate/Prioritize Project Risks?

You cannot respond to all risks, neither should you. Prioritization is a way to deal with competing demands. This aids in determining where you will spend your limited time and effort.

We evaluate in order:

  •  To have the greatest impact. Eighty percent of the impact will come from twenty percent of the risks. What are the vital few things that we should do that will have the greatest impact on minimizing threats and maximizing opportunities?
  •  To respond wisely and appropriately. The goal of evaluating risks is to discriminate between one risk and another. This aids us in determining the amount of effort to invest in developing response plans.
  •  To assign resources suitably. Assign your most skilled, knowledgeable resources to the projects with the greatest risk.
Continue reading

How to Build and Use a Risk Register

picture of a risk register and watchProject managers constantly think about risks, both threats and opportunities. What if the requirements are late? What if the testing environment becomes unstable? How can we exploit the design skills of our developers? Let’s consider a simple but powerful tool to capture and manage your risks—the Risk Register.

What to Include in a Risk Register

The Risk Register is simply a list of risk-related information including but not limited to:

  • Risk Description. Consider using this syntax: Cause -> Risk -> Impact. For example: “Because Information Technology is updating the testing software, the testing team may experience an unstable test environment resulting in adverse impacts to the schedule.”
  • Risk Owner. Each risk should be owned by one person and that person should have the knowledge and skills to plan and execute risk responses.
  • Triggers. Triggers indicate when a risk is about to occur or that the risk has occurred.
  • Category. Assigning categories to your risks allows you to filter, group, analyze, and respond to your risks by category. Standard project categories include schedule, cost, and quality.
  • Probability Risk Rating. Probability is the likelihood of the risk occurring. Consider using a scale of 1 to 10, 10 being the highest.
  • Impact Risk Rating. Impact, also referred to as severity or consequence, is the amount of impact on the project. Consider using a scale of 1 to 10, 10 being the highest.
  • Risk Score. The risk score is calculated by multiplying probability x impact. If the probability is 8 and the impact is 5, the risk score is 40.
  • Risk Response Strategies. Strategies for threats include: accept the risk, avoid the risk, mitigate the risk, or transfer the risk. Strategies for opportunities include: accept the risk, exploit the risk, enhance the risk, or share the risk.
  • Risk Response Plan or Contingency Plan. The risk owner should determine the appropriate response(s) which may be executed immediately or once a trigger is hit. For example, a risk owner may take immediate actions to mitigate a threat. Contingency plans are plans that are executed if the risk occurs.
  • Fallback Plans. For some risks, you may wish to define a Fallback Plan. The plan outlines what would be done in the event that the Contingency Plan fails.
  • Residual Risks. The risk owner may reduce a risk by 70%. The remaining 30% risk is the residual risk. Note the residual risk and determine if additional response planning is required.
  • Trends. Note if each risk is increasing, decreasing, or is stable.

Other Risk Register Tips

The Risk Register may be created in a spreadsheet, database, risk management tool, SharePoint, or a project management information system. Make sure that the Risk Register is visible and easy to access by your project team members.

The risk management processes include: 1) plan risk management, 2) identify risks, 3) evaluate/assess risks, 4) plan risk responses, 5) implement risk responses, and 6) monitor risks.

The initial risk information is entered when identifying risks in the planning process. For example, project managers may capture initial risks while developing the communications plan or the project schedule. The initial risk information may include the risks, causes, triggers, categories, potential risk owners, and potential risk responses.

As you evaluate your risk in the planning process, you should assign risk ratings for probability and impact and calculate the risk scores.

Next, validate risk owners and have risk owners complete response plans.

Lastly, review and update your risks during your team meetings. Add emerging risks. Other reasons for updating the risk register include change requests, project re-planning, or project recovery.

Other Resources:
Risk Register Template

1 2 3 8