My Kindle book, “Project Management for the Real World”, is now available at
If you like this blog, you will benefit from reading this book.
Welcome!
The Project Management Institute (PMI) encourages its members to advance the profession. One of the ways to do this is by helping others increase their project management skills. The target audiences for this blog are professional PM’s early in their careers as well as those who manage projects but are not PM’s by title or trade. I will be posting every week or so, offering practical tips and tools on the full range of project management topics. I hope you will find this useful and help you advance your career.
Risk Management Deeper Dive Part 1 – Risk Identification
The first step in managing risk is to identify the risks you need to manage. This is the most important step in risk management and something new project managers tend to struggle with. I will present some techniques that have over the years have worked well for me.
- What worries you? – You can ask this question to your project team members and stakeholders. Do this first individually, then in groups. Many do not understand the term “risk” as it applies to projects and may come up with a blank if you ask them about risks. Everyone can relate to the term “worry” and I have found this helpful. You may get answers such as “I don’t have enough resources” or “the timeline is too tight” or “I don’t have enough expertise on my team in this area”. These types of answers are a great start in risk identification.
- The “Pre-Mortem” – We are familiar with doing “lessons learned” and “post-mortems” on projects. Doing a “Pre-Mortem” can help identify risks. You ask the project team and stakeholders “It’s 9 months from now, the project is over and it was a disaster. What are the reasons?”. Your mind works better at identifying risk when looking backwards so this technique can be very effective. You may get responses like “The Sponsor wasn’t involved in decision making” or “We didn’t train the staff on the new tools”. These types of answers are risks that need to be managed. You can also ask the opposite question: “It’s 9 months from now, the project is over and it was wildly successful. Why?”. Responses like “Mary Jones was assigned as the technical lead” or “The Steering Committee made prompt decisions” will help you identify risks and mitigate them.
- Risk Breakdown Structure(RBS) – if you Google this term you will find many examples. An RBS is simply a hierarchy of areas in which risks can occur. You would present each of these areas to the team and brainstorm potential risks for each area. Here is a sample RBS:
- Technical
- Technology
- Complexity of Interfaces
- Performance and Reliability
- Quality
- External
- Vendors
- Regulatory
- Market
- Customer
- Weather
- Environmental
- Government
- Internal
- Dependencies on other projects
- Resources
- Funding
- Requirements
- Resistance to change
- Inexperience
- Schedule
- Equipment
- Quality
- Customer Satisfaction
- Project Management
- Estimates
- Plans
- Controls
- Communications
- Scope
You should state your risks in a consistent manner. A common way to phrase your identified risks are: “If (risk event occurs), then (impact to project in terms of scope, schedule, cost, quality)”
Here is an example: “If the vendor is late delivering Component X, then we may not be able to meet the project milestone for the first build”. Note that I stated “may” not “won’t”. Remember, risks are probabilities, not certainties. If it is a certainty, it is an issue, not a risk.
Note: Much more detail on Risk Management can be found in my Kindle book “Project Management For The Real World”, available at
Happy Labor Day Weekend!
The next post will be published September 14. Stay safe!
Risk Management Deeper Dive – Introduction
When I teach project management principles to non-professional PM’s, I emphasize that the two things you must do to greatly increase your chance of success are (1) create a complete Project Charter, and (2) manage risk. Those two practices, when done well, contribute to the bulk of project success.
In previous topics I discussed Risk Management in two places:
- The Project Charter
- The Project Management Plan
In the Project Charter, only the initially identified high exposure risks are typically listed and you may not yet have fully developed mitigation and contingency plans. In the Project Management Plan, the Risk Management Plan describes the process of risk management but it does not address the specific risks.
In the “Risk Management – Deeper Dive” series of posts, I will present the following topics in detail:
Part 1: Risk Identification
Part 2: Risk Prioritization (probability/impact/exposure)
Part 3: Risk Triggers
Part 4: Risk Mitigation Strategies
Part 5 : Risk Contingency Plans
Part 6: Risk Ownership
Part 7: Risk Monitoring
Managing risk is a key project management best practice. I strongly suggest you make this one of the first areas of mastering project management.
Note: Much more detail on Risk Management can be found in my Kindle book “Project Management For The Real World”, available at
The Five Steps to Successful Project Management
There are no “secrets” to project management success. It’s a combination of education in PM best practices (the Project Management Body of Knowledge, or PMBOK), communication skills, and staying confident, focused and cool under fire. Most successful Project Managers follow these five steps:
Step 1: Know Your Outcomes
In the Project Charter topic, I mentioned the first and most important step in your project is to properly define the business and project outcomes. If you don’t know where you are going, how will you know you have arrived? This is as true for personal projects and goals as it is for business projects.
Step 2: Have a Plan and Take Action
You can speak passionately about your desired outcomes but unless you do something about it they are as worthless as having no outcomes at all. Taking action starts with good planning and the topics on the “Project Management Plan” and the “Project Plan” are excellent places to start. Once you have a plan, you can begin execution.
Step 3: Collect Relevant Information Regarding Progress
It is a rare project that goes exactly according to plan. You need to regularly evaluate whether your outcomes are still achievable and the level of progress towards achieving those outcomes. Having this information leads to the next step …
Step 4: Be Flexible and Change Plans as needed
If your project is not proceeding according to the plan, be prepared to change the plan and do whatever it takes to achieve your desired outcomes. This could mean some combination of the following: changing the order of activities, reassigning resources, changing the scope, crashing the schedule, etc.
The Marines have a motto: “Improvise, Adapt, Overcome”. This is also a good motto for Project Managers.
Step 5: Look and Feel Confident
Your project team will take its cue from you. If you are expressing doubts, look worried and anxious, or show uncertainty, your team will start to feel the same. Using PM best practices and following Steps 1 thru 4 in this post will allow you to proceed with confidence.
Note: Much more detail on successful Project Management can be found in my Kindle book “Project Management For The Real World”, available at
https://www.amazon.com/author/lettera
The Project Schedule Part 7 – Schedule Adjustments
After you have created your initial cut of the schedule, you will often find that this schedule will not meet the target date. Adjusting the schedule and adapting to changing circumstance is where Project Managers earn their money.
Here are some of the actions you can take:
- Focus on the tasks that are on the Critical Path
- Revisit the estimates – do some of the estimates have more safety time built in than is needed? Where can you reduce estimates and not take on more risk?
- Fast-Tracking – look at activities that you have scheduled in sequence due to assumed dependencies. Can you do some of these in parallel or at least have some overlap? For example, you might have “Solution Construction” following “Design” but in reality you can start building some of the solution after some (but not all) of the design is completed. Fast-tracking is a very common practice and you will use this on most large projects.
- Crashing the schedule – this is where you throw additional resources at critical path tasks without regard to efficiency or budget. If meeting the target date is imperative, this is a useful tactic. It is best to plan for this contingency when you are doing your Risk Management Plan in order to have contingency funds in the budget that you can draw on in case the schedule risk is triggered.
- Obtain stronger resources – you can examine the critical path task assignments and look for opportunities where more experienced and knowledgeable resources would allow you to substantially reduce the task estimates.
- Reduce Scope – review the ranked requirements and obtain Sponsor approval to remove or delay requirements that are not essential for the initial go-live date.
- Sacrifice Quality – you can ask the Sponsor for approval to reduce test time for functions that are used rarely or are not business critical.
You are likely to use some or all of the tactics listed above in any project of significant size. It is a critical skill for Project Managers.
Note: Much more detail on creating a Project Schedule can be found in my Kindle book “Project Management For The Real World”, available at
The Project Schedule Part 6 – The Critical Path
With tasks, resource assignments, duration/effort and dependencies defined, your project scheduling software will create a schedule. The path of dependent tasks that in aggregate take the longest amount of time is called “The Critical Path”. This is because if any one of these tasks is completed later than originally scheduled, your project end date will move.
When you are in the “Execution and Monitoring” Phase of your project, regular examination of the state of your critical path tasks is a top priority. It is important to routinely check in with the assigned resources to determine if the “days to completion” is still valid. If you wait until the task is late, it will be too late to do anything about it. Your only choice would be to examine the other tasks on the critical path to see if any task times can be reigned in to make up for the lost time. We will examine techniques you can use for this in the next post.
A technique you can use to make your critical path less volatile is to estimate your individual tasks more aggressively and aggregate the extra time you would have assigned to individual tasks into one “critical path buffer”. If critical path tasks come in early, you can add the time saved to the buffer. If critical path tasks come in late, you subtract time from the buffer. Using this technique, your schedule will not move with any one late task and it will encourage team members to work faster and ignore distractions. Also, the health of the buffer would be the key metric instead of the health of each individual task.
You can measure the health of the critical path buffer with two metrics:
- % of original buffer remaining
- Divide the “% of elapsed project time” into “% of buffer used”. If this is a number less than one you are tracking well. If it is greater than one it is an early warning sign to take action
For example: Your project has used 30% of it’s original buffer but you are only 10 weeks into a 50 week project (only 20% of the project schedule has elapsed), You divide 30%/20% and this equals 1.5 (greater than one) meaning you need to take remedial action.
If your project only used 15% of your original buffer, 15%/20% = 0.75, which is less than one indicating a healthy schedule.
When using this technique, it is very important to regularly update the “days to complete” for each critical path task so you can have confidence in the status of your buffer.
A side benefit of tight task estimates is that it should keep the task owners focused and minimize distractions.
Whatever technique you use, constant monitoring of the health of the critical path is one of the most important tasks for the Project Manager.
Note: Much more detail on creating a Project Schedule can be found in my Kindle book “Project Management For The Real World”, available at
The Project Schedule Part 5 – Dependencies
Now that you have your lowest level scheduled tasks defined and have assigned resources, it is time to define the dependencies between tasks. This is where MS Project really comes in handy as it will create the schedule for you based on task dependencies and resource availability.
There are four types of dependencies:
- Finish to Start – This is the most common and the default in MS Project. The predecessor must finish before the successor can start. For example, “Applying Primer” must finish before “Painting” can start.
- Start to Start – Predecessor must start before the successor can start. For example “Mortgage Application” must start before “Credit Check”.
- Finish to Finish – Predecessor must finish before the successor can finish. This can be true of tasks that run in parallel but both are needed for the subsequent task.
- Start to Finish – Predecessor must start before the Successor can finish. This one is rarely used and frankly should be avoided.
When you initially define the dependencies, take care to only define “true” dependencies. If you have one person assigned to all the tasks you may be tempted to make all of the tasks dependent since the resource must complete one before starting another. Don’t do this. Let MS Project do this via resource leveling. The reason for not doing this is you may get additional resources later so some tasks can run in parallel. If you made them all dependent, the schedule will not show this possibility.
MS Project can now take your tasks, resource assignments, estimates and dependencies and create an initial schedule. I say initial because you often will find with your first cut that the finish date does not occur within the Sponsor’s expected time frame. In the next post I will discuss the concept of the “Critical Path” and what the Project Manager can do to rein in the target date.
Note: Much more detail on creating a Project Schedule can be found in my Kindle book “Project Management For The Real World”, available at
The Project Schedule Part 4 – Resource Assignments and Estimates
Once you have defined your Work Breakdown Structure (WBS) the next step in creating a schedule is to assign resources and estimates to each task (the lowest level items in your WBS). A starting point in assigning resources is to consult the “Roles & Responsibilities” matrix you created as part of the Project Charter. You are looking for the stakeholders that are in the category of “helping you execute your project”.
You may find that some WBS tasks need resources that have not yet been specifically identified as assigned to the project. In this case you will meet with the managers of the areas that have the resource expertise and agree on the assignment. In other cases you may need to contract for professional services. This should have been included in your Project Budget and the Procurement Plan. If not, you will have to use the formal Project Change Management process to alter the budget to include these services.
Microsoft Project allows you to assign resources to a task. You can also assign the percentage of the resource’s time that will be dedicated to the task. In addition, you can assign more than one resource to a given task.
Once you have resources assigned to a task you can attach estimates. You can estimate using “Duration” (the length of time the task will take independent of the resources assigned) or “Effort” (the amount of hours or days a task will take given undivided attention of the resources). Which one you use will depend on the type of project, type of task and organization culture. As a general rule I like to use “Effort” and let MS Project calculate the duration given the resource percent allocation and other tasks assigned to that resource.
When defining estimates, take into account the expertise of the resource(s) assigned to that task. An expert resource may complete a task much faster than a novice. Sometimes estimates are placed on a task prior to the resource assignment to get an idea of how the schedule will look. If you do this, remember to re-estimate once the specific resource is assigned.
There are many techniques to creating estimates. I will not address them all here. The most common are:
- We’ve done this task before so we know how long it takes
- The assigned resource supplies the estimate. Be careful with this one. People tend to be overly optimistic on how much time a task will take.
- A small group of people with expertise in that task are asked to independently estimate the task, then the group discusses the discrepancies and comes to a consensus
- Management may dictate the duration of the task in which case the PM may have to assign resources with more expertise or add resources (if feasible) to meet the deadline.
You can also use a 3-point estimate (optimistic, pessimistic and most likely) and calculate your estimate using PERT (I recommend you Google this term for the details). For a more advanced scheduling technique, you can investigate “Critical Chain and Buffer Management”. This technique that will need organizational buy-in from the top down.
Note: Much more detail on creating a Project Schedule can be found in my Kindle book “Project Management For The Real World”, available at
The Project Schedule Part 3 – Work Breakdown Structure (WBS)
A Work Breakdown Structure (aka WBS) takes high level deliverables and breaks them down into lower-level activities suitable for assigning, managing and scheduling work. Creating a WBS is the first step in creating a schedule.
To build a project schedule, you must first define all of the activities that are part of the schedule. If you have created a Project Charter and a Project Plan, you have rich sources of information with which to define the deliverables and the activities needed to produce them.
The Project Charter contains the Project Objectives, which are products, services or results that the project will produce and will survive after the project is over. These are the ultimate deliverables of the project. The Business Objectives contain “Measures of Success” which may require the project to build measurement tools and processes. The Scope section contains high-level activities which can be broken down to smaller pieces for scheduling.
The Project Plan contains the “hows” of the project and most or all of the key project activities were defined there. As the Project Manager, you will need to decide at what level you will define the activities for scheduling purposes. As I mentioned in an earlier post, I am not a fan of Project Schedules that contain a large amount of activities as you will wind up putting more effort into schedule maintenance than the benefits you derive.
One common way to define the activities (create a WBS) is to start with the project deliverables and work backwards from there, asking the questions “What inputs are needed for this activity?” and “What activity creates each input?”. For example, for the Requirements Document deliverable, you need final approval. To get final approval, you need to conduct a review meeting. To conduct a review meeting, you need to schedule it. To schedule it, you need a draft document. To get a draft document, you need to write it. To write it, you need to schedule and conduct requirements gathering meetings. And so on until you reach the very first activity which either needs no inputs or the inputs have already been created.
If the deliverable is simple enough you can start from first activity and drill forward. Either method should work. For activities that are not yet well understood or defined, you can define high-level placeholders in the schedule and add the activities needed to obtain the required knowledge.
Once you have all of the activities, you will work on assigning the resources to the activities and defining the dependencies between activities. I will cover these topics in the upcoming posts.
Note: Much more detail on creating a Project Schedule can be found in my Kindle book “Project Management For The Real World”, available at
The Project Schedule Part 2 – Schedule Tools
For anything but very small projects, you will need a tool to record and track your schedule. The most common tools used for this are Microsoft Project and Excel. They are not the only ones available but they are the ones I will discuss here.
Microsoft Project is a very robust scheduling tool with many features. You enter tasks and sub-tasks, assign resources (you can do this with varying percentages of availability), identify the effort needed for this task (in days or hours), and link the task to dependent tasks. The software automatically creates a schedule from this information.
Often on the first cut at creating a schedule, the project end date is beyond the desired target date. The sequence of tasks that directly connects to this end date is called the “Critical Path”. It is the longest path of dependent tasks in the project. This path of tasks are your top priority to monitor because slippage in any one of these tasks will increase the length of your project.
You must look for opportunities to bring the target date in line with expectations. You can do things like add more resources, bring in more skilled resources, look for opportunities to do tasks in parallel, and/or start some tasks earlier. Be mindful of budget, risk and quality implications when you use these techniques.
Excel can be used for small and some medium sized projects where you just need a list of key activities and the start and end dates. Unlike MS Project, Excel cannot create the schedule for you. It is used strictly for tracking and communication. It is much more convenient than Project when you don’t need all of the scheduling features.
I advise you not to create a schedule with so many tasks that it eats up your valuable project management time just maintaining the schedule. Create the schedule at a level sufficient enough to track the Critical Path and communicate status to key stakeholders. Keep in mind your Project Plan has all the activity details so there is no need to duplicate all of that information in the schedule.
Note: Much more detail on creating a Project Schedule can be found in my Kindle book “Project Management For The Real World”, available at
