- You are here:
- Home »
- Blog »
- 2=Planning
Category Archives for 4=Control
The Relationship Between Project Risk Management and Project Management
Project management is "the application of knowledge, skills, tools, and techniques to project activities to meet the project objectives" (PMBOK®—6th Edition). So, how does project risk management fit in the world of project management?
Hand in Glove Relationship
Project risk management fits in project management like a hand in glove. Project managers can use it to achieve their project objectives and goals. How?
Good risk management always starts with clear project objectives and goals. That is to say, project managers who manage risks without project objectives as the basis are simply playing games. There is an appearance of risk management but these individuals are simply going through the motions.
Good risk management always starts with clear project objectives and goals. —Harry Hall
Want Better Results in Software Projects? Try 3 Simple Questions
Project managers crave successful software projects. They dream of crossing the finish line with a win. Project managers want to help their company and advance their career. Let's look at three powerful questions to help you identify lessons learned.
Unfortunately, some project managers fall into a rut and fail to make progress. These individuals do the same things from one project to another project and expect a different result. They take the wrong actions, pursue the wrong things and operate under wrong assumptions.
"Insanity is doing the same thing over and over and expecting different results." —Albert Einstein
10 Habits of Highly Effective Project Managers
Just because you've been a project manager since the days of "Gilligan's Island" is no guarantee that you are an effective project manager.
As a matter of fact, you may be still trying to get off your island. Even the Skipper and the Professor can't seem to help...encouraging...huh?
So, how can we produce intended or desired results in our projects? Here are 10 tips. Forming habits requires time and effort, but let's decide first which of these would be most helpful.
10 Habits of Effective Project Managers
Define what you mean by risk
The term "risk" means different things to different people. Some individuals think risks are negative events (i.e., threats); others include positive events (i.e., opportunities). Whether you are starting a project or a program, be clear about what you mean by the term risk.
Define and use a risk management plan
Many project managers and project teams approach their projects with no idea of how they plan to identify risks, assess risks, define risk response plans, implement response plans, or monitor risks. Don't make this mistake. Define a risk management plan and reach agreement with your team as to the approach and the amount of rigor you plan to use.
What are Project Assumptions?
There may be inherent risks when we make project assumptions. We assume certain things to be true when in fact, they may not be. Consequently, we fail to challenge assumptions and continue planning and executing based on false notions. This can be costly.
An Example of Wrong Assumptions
So, how does this happen? In her book—Thinking in Bets—author Annie Duke shares an illustration:
Suppose someone says, "I flipped a coin and it landed heads four times in a row. How likely is that to occur?" It feels like that should be a pretty easy question to answer. Once we do the math on the probability of heads on four consecutive 50-50 flips, we can determine that would happen 6.25% of the time (.50 x .50 x .50 x.50).
The problem is that we came to this answer without knowing anything about the coin or the person flipping it. Is it a two-sided coin or three-sided coin or four? If it is two-sided, is it a two-headed coin? Is the flipper a magician who is capable of influencing how the coin lands?
In our projects, we may be guilty of this type of thinking. We may assume the world is flat when indeed, it is not. Assumption analysis can help us discover the facts or supporting information when identifying project risks and later when evaluating risks.
What Everybody Ought To Know About Project Risk Owners
So, what are project risk owners and how should project managers identify and assign them? Let's talk.
Imagine that you are the project manager of a two-year, multi-million dollar project. During the execution of your project, you take a beach vacation.
One of your team members calls upset that a major risk has occurred. You cooly reply, "No problem." You text the risk owner and discover that the risk response plan is being executed and everything is fine.
Is this scenario possible? One thing is for sure. If we don't identify and recruit risk owners, this will never happen. Your project will be at greater risk.
Risk Owner
What is a Project Risk Owner?
The PMBOK 6th Edition says a risk owner is "the person responsible for monitoring the risks and for selecting and implementing an appropriate risk response strategy." Furthermore, these individuals may aid in evaluating their risks in performing qualitative risk analysis and the quantitative risk analysis.
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 some reasons why project managers struggle to manage small projects.
Pitfalls of Small Projects
1. You think these endeavors are simple. In general, smaller endeavors have less risk. However, these may have a complex set of variables.
Be sure to analyze the complexity. For example, you may engage your team to develop a context diagram and/or data flow diagrams early. This exercise allows the team to understand the context of the project.
2. You don’t have a charter. Individuals are assigned projects at the last minute with a tight deadline. Rather than discussing the undertaking 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. For smaller endeavors, one should be able to create a charter in short order.
3. You are applying the wrong level of rigor. I see two extremes: First, managers do not follow any methodology. Second, managers perform unneeded tasks.
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-sized-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. Often, these undertakings are assigned leftover resources. Any warm body will do or will it?
For all endeavors, define the required knowledge and skills. Seek to staff the team accordingly.
6. Poor risk management. Yes, smaller ventures 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 upfront how you will manage, track, and report changes. When is a change order required? Who has to approve it?
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 venture is a low priority and give it little attention.
This is a management issue. Management should create a Project Board that reviews requests for strategic alignment.
9. Your 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. One may spend more time setting up their tools than managing the effort.
Keep things simple. For example, rather than using complex scheduling tools, you may use Excel.
11. You are managing too many projects. An individual may have a heavier load than they can manage. These managers may have difficulty prioritizing and juggling all the activities resulting in wasted time.
The resource manager should be careful to assess each project, estimate the time required for each project manager. Monitor success rates for these endeavors 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.
How About You?
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.
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.
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
- Why are we doing this project?
- Is your project sponsor fully engaged and on board?
- What is the authority level of the project manager?
- What do we wish to accomplish?
- What are the products and services we wish to deliver?
- What are the budget constraints?
- What are the schedule constraints?
- What assumptions are being made?
- Who will be impacted? Which stakeholders have the greatest interest and power?
- Who will comprise the project team?
- What are the most significant risks?
- 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.
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?
- 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
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?
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!
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.
