Category Archives for 2=Planning

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.

picture of a risk owner

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

Continue reading

Risk Management: When All Hell Breaks Loose

What would you do if all hell breaks loose in a critical company project that you are managing? You lose two of your best team members. Your budget is shot. A key stakeholder is breathing down your neck. Behind schedule by four weeks. You haven't slept well in two weeks. And you feel like throwing in the towel.   

Taking on Risky Projects

Some projects are more risky than others. A project sponsor sees an opportunity. It's a stretch and he knows it, but he wants to try anyway. So, the project charter is completed and the top risks are recognized.

The Project Board approves the project. Why? Because there will be tremendous gains if the project is implemented successfully.

And guess what? You've been asked to manage this project. Lucky you.

As you are engaged in the project, you begin to understand just how challenging the project is going to be. How will you approach the uncertainty that lies before you? What can you do to recognize and plan for the events and conditions that may have negative effects on your project objectives?

Continue reading

Five Ways to Reduce Risk Exposure Early

When is risk exposure greatest in a project? In the beginning, in the middle, or at the end of the project? It's actually highest in the beginning. Let's look at how to reduce risk exposure early in your projects.

Why Risk Exposure Is Greatest in the Beginning

So, why is your risk exposure greatest in the beginning? Project managers have the least amount of information. Uncertainty is the greatest. We know very little about the:

  • Goals of the project
  • Deliverables
  • Requirements
  • Budget
  • Constraints
  • Success criteria
  • Availability of resources

Here are five activities that you can undertake to reduce the risk exposure early.

Continue reading

The What, Why, and How of Process Mapping

Operational risk includes people risk, technology risk, external event risk, and process risk. In this article, let's talk about process risk and how to reduce these risks through process mapping.

When employees leave organizations, these entities may loose daily operational knowledge. You know. The people that know how to get things done are now gone. And these organizations often lack process documentation. Furthermore, they fail to cross train other employees adequately.

So, who is impacted? Employees for sure. But most importantly, the customer is adversely impacted. 

Continue reading

The Power of If-Then Risk Statements

IF. Have you thought about the use of this two-letter conjunction in risk management lately? Let's look at how to use the power of If-Then risk statements.

IF is a simple word that can open up new doors to writing clear risk statements. And it can be used to write opportunities as well as threats.

If-Then Risk Statements

Write Opportunity Statements

Opportunities are events and conditions, that if they occur, have a positive impact on your project objectives (e.g., schedule, scope, budget, quality). Here are examples of how you might start these risk statements:

  • If you purchase ten or more computers from the XYZ vendor, 
  • If you add an additional developer to task ABC,
  • If you use quick-drying cement,
Continue reading

How to Perform a SWOT Analysis

If you are looking for a great way to engage your key stakeholders and identify project risks, perform a SWOT Analysis. Project managers or other facilitators can use this powerful tool to identify strengths and weaknesses. Furthermore, strengths may give rise to opportunities and weaknesses may lead to threats. Let's look at how to perform a SWOT Analysis.

SWOT Example

What is SWOT?

S

Strengths. Something that an entity, department, or team is good at doing or that gives it an important capability. A strength may be a skill, expertise, a valuable resource, a competitive capability, or an attribute that provides competitive advantage. 


W

Weaknesses. Something an entity, department, or team lacks or does poorly or a condition that puts it at a disadvantage. 

O

Opportunity. Up-side risks that may cause positive effects to our project objectives. An example would be to exploit a discount savings by purchasing in bulk quantities. 

T

Threats. These down-side risks may cause negative effects to our project objectives. What are your obstacles? What may hinder your ability to achieve your project objectives?

Continue reading

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

Five Things to Start and Five Things to Stop in Requirements Management

According to PMI, "47% of unsuccessful projects fail to meet goals due to poor requirements management." Wow! Requirements are a pretty big deal. Let's look at five things to start and five things to stop in requirements management.

Requirements Notebook

5 Things to Start

  1. Identify and engage appropriate stakeholders. Project managers who work in a matrix environment should seek resource approval from stakeholder's managers early in the project.
  2. Ensure the requested software features will be used. Inquire (politely) why the features are needed. How does the requirement align with the goals of the project? The results of one Standish Group indicated that 45% of product features were never used.
  3. If questionable, ask if a requirement is in the scope of the project. The project manager may wish to capture out-of-scope requirements in a parking lot for future consideration. Check with the Project Management Office (PMO) or other authority on how to handle these requirements.
  4. Analyze requirements using context diagrams, use cases, stories, and other tools and techniques. Project managers or business analysts who use different tools help the stakeholders see things from various perspectives.
  5. When requirements change, be sure to update the requirements under version control. Ideally, the project manager should be able to see the versions of the requirement from the initial version to the current version. Many of the requirement tools today provide this capability.
Continue reading
1 2 3 13