My project is out of control. Pretty harsh statement. In reality, your project has just hit a bumpy part and all the bumps are coming at one time.
Table of Contents
The project schedule is slipping, cost estimate at completion is rising (going beyond the allotted budget), and the team is, let’s just say not enjoying their workday.
Get your favorite beverage, find a quiet place to ponder the situation. Do not overreact, and especially do not jump to conclusions. We must remember that we are only witnessing some portion of the entirety, both in perspective and in time.
Now, what is going on? And why? This is when one must be honest with yourself. As Project Manager, all that has happened and is happening reflects your actions. I know some will say: “but, the team did this; sponsor did that, and the client is overbearing.” All of this may be true, and the bottom line is the PM is accountable for all that happens on their project. This requires doing all that they can to achieve the objective of the project and alerting the management of the enterprise to risk in achieving that objective.
Some of these trials are predictable. A significant responsibility of the project manager will be to anticipate. The project manager is not only responsible for anticipation, the project manager works with the team to discover those things that can go wrong, and prioritize the result, allowing action on the most egregious issues.
Got your beverage. Found a quiet spot. Take a pen and paper, jot down your thoughts on what you observe, or think is happening or has happened. Try to look at the situation as a fly on the wall. As you write don’t judge your statements. You might want to free write or mind map.
• Deliverables are slipping
Deliverables are missing milestone dates by a few days up to a week. Not all but enough deliverables to impact successor and other streams.
• Starting to have more meetings – reviewing the scope
Certain team members request meetings to review what the deliverables are.
• Change Management seems to be under control
There have been very few Change Requests and those received have had very little impact.
• Team members are working well together.
Yes, a few don’t like working with others. And some are slow in asking for help.
• The Project Sponsor has had few questions about the Status Report
Is the Sponsor even reading the Status Report?
After documenting what you observe, find a peer. Someone who you trust and possibly another Project Manager. In the best of situations, we can take these discussions with our team members, if we can keep the focus on the issue at hand. A collective exploration demonstrates transparency with the team and elevates the expectations from them beyond their task delivery.
Create a checklist of issues that you need to address. List what actions you will take.
With the list and any inputs from peers, let’s look for the root cause(s). Root cause takes time and exploration, it requires that we not jump to conclusions. The human mind tends to connect the most recent observable event with the latest outcome post hoc ergo propter hoc (after this, therefore because of this)
An easy tool to use to explore things that can cause our project to fail is the Ishikawa diagram. The graphic below is a version of the template we use for this exploration. This diagram structure has the major bones of the Ishikawa assigned with the knowledge management areas as per the Project Management Institute, Project Management Professional (PMP) certification. The graphic below is an illustration of the Ishikawa diagram, albeit from an older version of the PMBoK (Project Management Body of Knowledge).
To begin, place the failure we witness at the head of the fish (Issue).
Take the items on the list and place them accordingly. Normally the team builds the diagram. If you are like us, you will learn much from this exercise.
Let’s consider the head of the fish diagram if the project is late. What sort of things make this happen? Well, if you have worked on projects for any period at all, you know an ever-changing or uncontrolled scope, can cause a project to be late.
Can quality management problems make our project late? Certainly. Unaccounted for rework can result in a late project. As an aside, this will also add risk to achieving the cost expectations of the project unless it has been accounted for in the estimates, and in our experience, this is seldom the case.
Consider these additional questions:
1. Can communication errors produce a project schedule failure?
a. Am I communicating clearly?
2. Can talent (human resources) failures produce a project schedule failure?
a. Am I managing the talent; right people right places; conflicts?
3. Can errant or undefined quality standards, or poorly defined metrics and metric collection errors, produce schedule failures?
a. Were quality specifications clear? Do we have an environment wherein the team members can articulate what is rather than what management expects to hear?
4. Can unaccounted risk or poor risk management result in schedule failure?
a. Was Risk Identification and logging executed properly?
5. Can errantly estimate of duration cause schedule failure?
a. How did we derive the estimates? Top-down? Bottom-Up?
6. Can procurement (not shown on this Ishikawa graphic by a knowledge management area) error or process malady cause schedule failure?
a. What contract type was selected, contract approval process, supplier selection and many more can produce schedule failure?
If you explore, either by yourself or with a group of people, you will see that there are items under each of these knowledge management areas that can give you a failure in the project schedule. You will likely notice that these are subsystems that interact and can produce a failure symptom that appears to not be associated with a specific knowledge area. Additionally, you will notice that a confluence of certain subsystem failures can produce a visible failure that is not obvious.
Projects, on occasion, do go off the tracks and become frustrating. When that happens, the project manager needs to start self-examining by evaluating the situation and their actions. After looking at what you might have not handled as well as you could have or it should have been, then critique the team. What is happening and how does the project get back on track. The goal is to get the project back under control, even if straighten the past out results in the delivery date slipping.
Document all corrective actions. Use the Change Management process even if you won’t be issuing for additional cost and budget. Also, document in Lessons Learned. Documenting this will help you and others in executing future projects.
This documentation provides a basis for future actions, avoiding what we learned from our past experiences. From experience, a team that burns their metaphorical hand on the same stove is just about as motivating as actually burning your hand on the stove repeatedly.