Project management from the middle
How Did We Get Into This?
Many people begin their project management careers by getting involved in projects that are already underway. Many experienced, and sometimes inexperienced, project managers are called in to replace retiring/promoted/transferred managers, sometimes replacing managers when a project is in trouble. Occasionally, a project that seems to be running smoothly needs major overhaul when a replacement manager is assigned.
Where Are We?
It is reasonable to assume that decisions have been made, commitments given, schedules negotiated, resources defined, objectives established, funds appropriated, and so on., all before the new project manager enters the picture. However, understanding the current state is often difficult for the new project team member. In a real-time environment, the current state changes as the member is getting oriented. The longer it takes to get up to date, the more difficult it is, and the longer it takes for the new member to begin to contribute.
Let’s Get Started!
It is, therefore, important to shorten the time required for the new member to become a contributing member by reducing the time required to understand the current state. This approach assists in clarifying the information that must be gathered in order to understand the current state of the project. Only then can a contribution be made to advance the objectives for which the project was initiated.
What Can We Do?
We provide some first steps to solving common project problems.
Why Are You in This Job?
“A good manager left and I’m inheriting a well-run project.’
“An OK manager left. There are some existing problems that I have to clean up to get this project back on track.’
“The old manager was removed because this project is in trouble. I have to clean up a mess.”
“I’m here to preside over a funeral.”
“The project is just about over and I’m here to close it out.”
‘This project is doomed. Nobody wants it to succeed. It’s going to be cancelled and everyone knows it but me.”
Yes. But Why You?
“I’m uniquely qualified for this job.”
“I was the only one available.”
“I’m not sure. There are others available who seem more appropriate.”
“It will be good training for me.”
“I need the experience.”
“I’m the sacrificial lamb.”
What Phase Is Your Project In?
Definition: Formal recognition of the beginning of a project.
Definition: Creating and maintaining a workable plan to accomplish the purpose of the project.
Definition: Carrying out the plan.
Definition: Monitoring progress and taking corrective action when necessary.
Definition: Bringing project and paperwork to 100% completion, and entering the history in a database.
Appendix A (p. X of this paper) shows a list of the activities you should be seeing in each phase of the project. By identifying what activities are currently taking place in the project you will be able to determine the project phase. In the worst case, work is being performed before the requirements are determined.
How Much Authority Do You Really Have?
Strong: “I have total authority over the resources assigned to my project.”
Moderate: “I have referral authority only.”
Weak: “I have no authority over the resources necessary to complete my project.”
Assessing the Current State
Before You Start
Determine the level of your authority over:
Find out where the money comes from. Who is the funding source, sponsor? Who cares about this project? How much organizational influence do they have? You want to know this because you’ll probably have only referent authority. The more authority they have, the more you’ll have.
Review the Project Plan
Next, review the project plan:
- Project objectives
- Scope statement
- Scope change control
- Work breakdown structure (WBS)
- Project team
- Responsibility matrix
Who is responsible for what?
- Agreements (written and unwritten)
Tracking and Monitoring
Next, perform tracking and monitoring.
- Gantt charts
- PERT and the critical path
- Resource-driven schedules
You need to know where your project stands with respect to measurable factors. You are being tasked with meeting criteria that someone else has agreed to. Until you do a complete assessment, you don’t know if it’s even possible to meet the requirements within schedule and budget. Metrics to help assess this are:
- Earned value
- Cost performance index
- Schedule performance index
- Cost to complete
Typical Problems: Project Plan
What Project Plan?
If you’re asking this, you’re in trouble already.
Incomplete, Missing, or Wrong Project Plan
Team member identification
The Triple Constraints
Which is Most Important?
Customer Needs and Expectations
Needs are usually outlined in the specifications, whereas expectations are usually not even mentioned.
Where do you think the problems show up? You can meet the specifications and have a disappointed customer!
If the acceptance criteria are not defined properly you won’t know how the customer is going to decide if your deliverables are acceptable.
- Not defined adequately
- Different interpretations of the scope
- Lack of scope change control
- Scope changes
Sometimes it’s not clear whether we are on schedule or not. Some things are late, some are ahead, and some are indeterminate.
Was the schedule realistic to begin with?
Can you identify the cause(s) of schedule delays?
Can they be fixed so that they are not causing more delays?
Is the problem caused by a low priority for your project?
Is it related to budget deficiencies?
Is it a resource issue?
First, you should determine the type of cost problem.
Over Budget for the Work Performed?
Work not performed to schedule, but scheduled costs incurred:
- Are you being charged for people/materials being used on another effort?
- Are poor estimates used?
- Are there technical problems? Work being done but results not achieved?
Work performed to schedule, but over cost
- Added resources were needed to maintain schedule
- Something was left out of the budget
- Costs have increased since project initiation
- Cost phasing incorrect (this is not really a cost problem, but it is a budget problem)
The biggest cost problem of all, however is…scope creep!
Whenever a problem causes a missed target, whether it be a schedule milestone, a cost variance, or a performance criterion, a get-well plan should be created and implemented.
The purpose of the get-well plan is to put the project back on track, so that future milestones, costs, and performance are consistent with the overall schedule, budget, and scope.
Assemble the team members involved and together figure out what will be required to put the project back where it should be. If money or effort need to be rephased in order to accomplish this, negotiate with whomever has the authority to implement the change.
Rephasing is much preferable to added costs, reduced functionality, or extended schedule.
Project Plan Get-Well Plans
You must repair the faults in the project plan! The temptation to implement a get-well plan without fixing the original plan will be very strong.
Whatever they are---vague scope statement, missing WBS, lack of change control, inadequate communications plan, and so on---they must be fixed. If not, you will find yourself solving the same problems over and over again.
Fix the project plan.
Quality Get-Well Plans
To fix poor scope definition, first renegotiate scope with customer/sponsor. If you cannot get the customer to identify the deliverables expected more clearly, along with their acceptance criteria, then write it yourself and get buy-off from the customer.
Unstated expectations will cause no end of trouble. Find out what the customer envisions as the result of the project. Get his or her picture of the results. What does it look like, feel like, sound like? If you can’t get this from the customer, create it yourself and try to get customer buy-off on your vision. Show the customer sketches, photos, screens, and similar projects. What you want to know is what will make the customer say, “Yes! That’s exactly what I had in mind.”
If you are delivering something that meets the specs in your mind but not in the customer’s, you must find out what the acceptance criteria are.
This deserves a section of its own. Not only do problems with scope indicate a problem with quality, scope problems indicate schedule and cost problems, as well.
Scope Get-Well Plans
Problems with scope indicate that you don’t really know what the customer wants. Plans were based on what the customer said that he or she wanted, but specs were left out, or expectations weren’t defined, or the customer changed his or her mind. Sometimes you can even tell that the customer has just read a book or magazine article that has had undue influence on him or her.
Whatever the reason, you must nail down the scope of the project. If the customer has been giving input about changes to team members, and they have accepted them, make sure that the customer understands that all changes are to go through you. Make sure your team members know this, too.
If you are the performing organization, and you don’t handle changes to scope well, you will come in with an unacceptable product that is late and over budget.
If you have contractors performing work for you, the contractor will probably handle changes just fine. Contractors make their living on scope changes.
The Three Rules of Costing Scope Changes
If you do more work, it costs more money.
If you do less work, it costs more money.
If you do the same work, it costs more money.
The response to every change should consist of a proposal (technically, a change order) that indicates the impact on performance, schedule, and cost. If the customer still wants the change, they know what the price will be.
Any change to work already correctly completed is automatically a scope change.
Your change control procedure should include all team members or functions that are affected by the proposed change. Often called the change control board, this group looks at every change in terms of its impact on performance, schedule, and cost, and then makes recommendations or decisions about the implementation of changes. This is a formal process, the output of which is a change control report. This is an official part of the history of any project.
Schedule Get-Well Plans
Can’t Tell if You Are on Schedule?
If you can’t tell whether you are on schedule, it’s usually because different activities are in different stages of completion. Look at each activity that should already be completed according to the schedule. If any of these are not complete, get an explanation of what is holding them up. Sometimes it’s because the wrong sequencing was used in planning. If that’s the case, re-plan. Project plans are living documents. They should not be ignored once the project is underway. You should expect that things will not go according to plan. If they did, we wouldn’t need project managers. We could get by with project planners.
Often tasks get behind schedule because estimating was bad. Re-evaluate the tasks that are behind, and any future tasks based on the same kind of estimating.
Sometimes tasks are behind schedule because no one paid any attention to them. The performers let them slip because they could, and someone else was probably breathing down their necks for their project. Pay attention. Let people know you will be on top of your project. Then be on top of it.
Sometimes tasks are behind schedule because the customer didn’t provide information when it was needed, or review submitted work in a timely manner. This should be handled in the schedule by designating input milestones and review schedules.
What Can You Do About Late Projects?
First, let’s look at some ways you can fix schedule problems.
The Fast Track
The fast track is an overlapping technique. As an example, if you are finishing an interior, the dry wall has to be taped and buttered before you can paint it. But not all of the dry wall has to be done before you can start painting. Depending on the size of the building, perhaps only 20% of it has to be done. You can then move the painting schedule up to begin when the dry wall is 20% finished.
If your project is being held up by something you can’t fix, maybe a work-around would be possible. Sit down with your team to see if you can work around a bottleneck to keep things moving. When the bottleneck is cleared you can integrate the old tasks with the new schedule.
Sometimes adding resources to a task in the form of employees or contractors can get you back on schedule. Remember that the purpose of a get-well plan is to get you back on the original milestone schedule. Warning: this approach will usually cost you money!
If you can’t keep the original schedule, consider a phased implementation. This means that you still deliver the bulk of the deliverables on time, then phase in some of the functionality on an extended schedule. This is often done in IS projects. It is sometimes the case that the customer will not be using all of the deliverables immediately. This approach is usually far better than reducing scope.
Reduce Scope or Deliver Late
If you can’t get buy-in on a phased implementation, you are left with being late or reducing scope. You may know the customer’s preference for these choices, but you are going to have to bite the bullet and get the customer to choose between them.
If you have to be late or reduce scope, then the earlier that the customer knows it, the better. We often try to keep the bad news from customers hoping that something else will go wrong in the customer’s plans and provide us with some relief. This is not a good policy. The short explanation is simple. The way you deal with customers sets the standard by which your team members deal with you.
Cost Get-Well Plans
Work Not Performed to Schedule, but Scheduled Costs Incurred
Time and/or materials have been charged to your project but the work was not done. With the budget analyst in tow, sit down with the performing organization that charged your project and get the charges reversed.
This is a bad one. However the estimates were performed, they were wrong. What else has been underestimated? Try to determine this and reestimate. Buy-in may be difficult to receive.
Are the right people working on this? Can you get some outside expertise to solve the problem? Can you get the customer to approve a change that will make the technical problem moot?
Work Performed to Schedule, but Over Cost
Perhaps added resources were needed to maintain schedule. Someone solved one problem, only to create another. Can you reduce costs in another part of the budget, or use your management reserve?
Maybe something was left out of the budget. The lowest bidder was the one who, when the contract award was announced, said, “Oh, (bleep) what did I leave out?” This problem can be minor or very serious. If it’s minor, handle it yourself. If it’s major, you may have to call in the cavalry (i.e., your boss or the customer).
Perhaps costs have increased since project initiation. Long-term (multiyear) projects should have a cost escalator built in to account for inflation. If yours do not, or if an unforeseen condition causes a price increase, you can try to pass it on to the customer. Sometimes the customer just won’t have the money to give you. Then you are stuck with having to reduce scope or eat the difference.
Sometimes it may be that cost phasing was incorrect. Cost estimating was off according to the calendar, but not the total budget. Your costs are being incurred sooner than the budget allocations. This may not be a problem if you can simply explain the variance and that it will balance out in future periods. However, it could be a problem if the money is not available until the time periods for which the expenditures were scheduled. In this case, your project may not be in trouble, but you are. How fast can you tap dance? If the problem is caused by being ahead of schedule, can you slow it down?
Tracking and Monitoring
For Gantt charts, Pert/CPM, earned value, organizational reporting assets, see the Metrics section below.
You must have an agreement with your team about progress reports and timesheets. Both should be submitted weekly. Progress reports should include an estimate of the percentage of completion of tasks in progress.
It is good to have a form for this, and any form you can agree on is fine.
One more hint. You won’t be able to do this with everyone, but wherever you can, it will save you a lot of time and worry. Get an agreement with whichever team members you can trust, to let you know the first time they have a thought that a milestone will be missed. They should also let you know what they are going to do about it, but they shouldn’t wait to figure that out to let you know about the potential slip. If they want you to do anything to help, they should let you know that, too. Warning: If you hang them when they tell you about a problem, they will never tell you about a problem again. Neither will anyone else.
The measurements by which we evaluate our progress are called metrics. The most common ones are listed here.
People tend to think that this is complex subject matter, but it is actually quite simple. For our purposes, the value of a task is what we said (in the budget) that it would cost to complete it. The earned value is determined by how much of the task we have completed. For example, if we have a task whose value we said is $10,000, and we have completed 50% of it, the earned value is $5,000.
The Cost Performance Index (© Project Management Institute)
The cost performance index (CPI) is determined by comparing the budgeted costs with the actual costs. In the example above, the value that has been earned is $5,000. If your actual cost is $5,000, you are right on the money. If, however, you have spent $7,500, you are way over your cost expectation. The CPI is determined by dividing the earned value (EV) by the actual cost (AC) CPI = EV/AC. In the example here, the CPI is 0.67, indicating that you are overexpended. A CPI of 1.0 says you are right on budget. Less than 1.0 means you are over budget. Be careful! Until a task is complete, you are dealing with estimates of completion. If those estimates are not accurate, neither will your calculations be accurate.
The Schedule Performance Index (© Project Management Institute)
The schedule performance index (SPI) is similar to the CPI, but uses different measures to compute results. The SPI also uses dollar figures, but it is a measure of work completed, not money spent. To compute the SPI, divide the earned value (EV) by the planned value (PV). So, SPI = EV/PV. For example, in this time period, you have scheduled to do $20,000 worth of work. The work you have actually done was estimated at $10,000 earned value. The SPI is 0.5. This is not good. You are behind schedule. A SPI greater than 1.0 indicates that you are ahead of schedule. 1.0 exactly means that you are right on schedule. The same caution applies here to work completion figures based on estimates.
Project Problem Solving
Project problem solving is no different than problem solving in any other management environment. Since, however, it seems to be an uncommon skill, we will present here an approach to getting problems solved in your projects.
The Needs to Be Met
Most problem-solving processes begin with some version of defining the problem. This one does, too---with one difference. In our process, we are very specific about what constitutes a problem definition. In most cases, when people attempt to define a problem they identify various solutions and call one or more of them the problem. If you are dealing with a performance problem and identify it, for example, as a training or supervision or budget problem, you are defining the problem in terms of solutions. A performance problem should be identified in terms of the desired performance. Or, in other words, it should be identified in terms of the needs to be met.
If you do this step well, almost any process that you use to arrive at a solution will work. If you do not do this step well, it won’t matter what you do next, you will be solving the wrong problem.
A process for arriving at a solution will be presented here, but keep in mind that this is not the critical issue. Because 90% of problem-solving time is spent in defining the problem, defining the problem is the critical issue. As you review the steps in the process, bear in mind that this is a reiterative process. You will complete a step, move on, and then find yourself back at a previous step. This is not an indication of the process not working. This is how the process works.
The Six-Step Problem-Solving Process
Step 1: Define the problem in terms of the needs to be met.
Step 2: Generate solutions. Brainstorming is a useful tool. Come up with as many solutions as you can. Be very careful to allow no judgments during the brainstorming session. Judgments, good or bad, will short-circuit the creative process.
Step 3: Evaluate solutions. Use the needs identified in Step 1 as the criteria for evaluation. Ask yourself, will the solution meet the needs? If so, can it be implemented?
Step 4: Choose one or more as tentative solutions. These tentative solutions should be considered merely as something to try out to see if it works. Don’t get too attached to your solutions at this point. If you do, and they don’t work, you will try to force them instead of discarding them and trying something else.
Step 5: Plan and implement. Figure out who has to do what, by when, in order to make this solution a reality. Also, set a date to review your results.
Step 6: Review your results. Has the original problem been solved? Has a new problem been created? Consider, for example, the scenario in which resources are added to a task to stay on schedule? In this case, a schedule problem has been traded for a cost problem. Remember, the chief source of problems is solutions---and that sometimes the new problem will be worse than the old one.
Activities in the Initiating Phase
- Project charter preparation
- Project manager assigned
- Budget negotiation (sometimes)
- Negotiated project outcomes
- Project metrics
- Approvals/agreements signed
- Commitment to proceed
Activities in the Planning Phase
- Scope definition
- Scope verification with acceptance criteria
- Scope change control
- Quality planning
- Communication plan
- Work breakdown structure definition
- Dependencies determined
- Activity effort and duration estimated
- Project team organization and identification
- Resource planning
- Schedule development
- Risk analysis and mitigation planning
- Procurement planning
- Cost estimating
- Budget approval
- Manpower determined
- Major milestones identified
- Major milestones scheduled
- Project plan completion
Activities in the Executing Phase
- Information distribution and collection
- Team development
- Quality assurance
- Solicitation publication
- Contractor selection
- Contract oversight
- Contract administration
- Functional work according to plan
- Change implementation
Activities in the Controlling Phase
- Performance reporting
- Change control
- Schedule monitoring and control
- Progress reporting
- Cost Monitoring and Control
- Financial reporting
- Quality monitoring and control
- Risk response and mitigation
Activities in the Closing Phase
- Contract close-outs
- Administrative close-out
- Conduct lessons-learned session
- History entered into data base
©2008, Gary Somma
Originally published as a part of 2008 PMI global Congress Proceedings – Denver, Colorado, USA