Project Due Date Trap – Video

The project due date trap occurs when the boss will only talk about the project’s due date. They want a commitment to that date without defining what they want the project to deliver.

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

This project due date trap is deadly for a project manager. What draws you into this trap is fear of the boss’ anger. You are certain that your career will be over if you don’t commit to their due date. So you don’t even ask some reasonable questions.  Project Planning Main Page

Experienced project managers have learned how to deal with the executives who set the project due date trap. They have learned that a project manager won’t be fired for refusing to commit to a due date. But a project manager could be fired for failing to hit a due date or budget they have committed to meet The first step is getting the sponsor to clearly define the project scope. The scope includes the major deliverables the project must produce and their acceptance criteria. Without that information, the project manager cannot estimate a realistic due date and commit to it. So the project is doomed.

Project Planning Blunders - Plucking Due Dates Out of the Sky

Project Due Date Don’ts

The wrong way to do project planning is to start by identifying the first task you’re going to do on the project, then the second, then the third and so on. This “to do” list approach is easy because it doesn’t require much thinking. But it has major downfalls. Project managers who use this approach tend to include a lot of good, but unnecessary, requirements. They don’t limit the plan to include only what they must do to deliver the result the boss wants. So they waste lots of time and resources. And since they don’t know exactly what the boss wants, they can’t decide what to do to deliver it. They end up adding things to the project later on that they suddenly discover are vital. This “to do” list approach to project planning gets off to a fast start but ends up with projects that take longer and cost more than they should.

Project Best Practices

Long-term success requires that you learn project management best practices. Those are the skills you need to deliver the project scope on time and within budget. For small projects, a five-step methodology is enough. Here are the steps:
Project Due Date Trap

  1. Project planning – focus on a clear scope and a deliverable-oriented project plan. Create the work breakdown structure by working from the scope statement down to individual team member assignments. Clearly define the deliverables that are required to reach the project’s end result.
  2. Assigning work to the project team – focus on giving them a crystal-clear understanding of what you expect them to produce before they start work. The deliverables must be measurable.
  3. Estimating – focus on how much work it will take to produce each deliverable. It’s always best to have the team member who is going to do the work take part in this estimating process.
  4. Tracking progress against the plan and spotting variances – use project management software and status data from your team members to stay on top of your project. Anticipate problems when they are small and before they impact the entire project.
  5. Designing corrective action and reporting status – design corrective action when you find problems. Clearly report problems and solution options to the project sponsor for their approval.

Learning a simple methodology like this will help you be successful on the vast majority of projects most organizations do.

Get free articles and videos like this every week

 

Stakeholder Analysis

Stakeholder analysis is one of the most important tasks in project management.  Stakeholders are the people who are affected, positively or negatively, by the project.  You must make an effort to the identify the project stakeholders early in the planning process.  Let’s look at an example of a small project and see how to identify the project stakeholders.

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

Stakeholder Analysis Example: Part One

The boss calls you into her office and tells you she is getting complaints from other managers about items out of stock (stock-outs) in the supply room. This situation is wasting people’s time and delaying their work because they can’t get their materials when they need. She goes on to tell you that she wants you to run a project to cut the number of stock-outs in the supply room. She will be the project sponsor. Stakeholder Management Process

You ask some probing questions to quantify the project scope and the acceptance criteria. She states that less than five stock-outs a month would make the project a success.
With the initial scope defined, you tell her the next step is to identify the project’s stakeholders. Then you must do stakeholder analysis. That includes speaking with them to understand their issues with the supply room and their requirements for improving it. The sponsor shakes her head and says, “Let’s not turn this into a never-ending circus by asking other people to give us their to do lists. We’ve got to make a plan and identify how we’re going to deliver the project scope I just set. Let’s keep the planning group small so we can move fast. I don’t want to involve a lot of people who have other ideas we’d have to consider.

You say, “Well if I don’t identify project stakeholders and get their ideas, it may come back to haunt us at the end of the project.”

The sponsor interrupts and says, “We know what we need to do in the supply room. We don’t have to let other people stick their noses into this project.”

You say, “I really think that is a mistake…”

“Then it’s my mistake,” the sponsor said. “I want you to get started making the detailed plan.”

Over the next few days the planning went rapidly and you were able to develop high-level deliverables and a work breakdown structure. You identified procedure deliverables, training deliverables and a new workflow for managing inventory levels. The sponsor approved them all and she assigned people from her department and one from the supply room to serve as your project team and authorized you to start work.

Stakeholder Analysis Example: Part Two

Things went very well for the first week and you and your small team knocked off one deliverable after another. But as you moved into the implementation phase you ran into a couple of problems. FiInfluencing Project Stakeholders

First, the project sponsor called you and said, “The purchasing people have their nighties in a knot about how you want to manage the supply inventory. You better get down there and talk with them about what you want to do and get their cooperation.”After spending the next two days meeting with the purchasing people and modifying the entire workflow and procedure you had developed to meet their requirements, you were behind schedule. You knew you would have to hustle to avoid any more slippage in the schedule.stakeholder analysis

Then the human resources trainer finally returned your call. She explained that the training you wanted on the new supply room procedure did not meet corporate standards for training classes and needed to be extensively revised. You explained that the supply room procedure was undergoing modification anyway and the trainer explained that you should have involved her in this process from the beginning.

You stopped the team members who were revising the supply room inventory procedures and told them they would have to wait until the end of the week for a meeting with the human resources department trainer.

Stakeholder Analysis Example: Part Three

To bring an awful week to an end, you met with the project sponsor to submit your status report and explained why the project was at least a week and possibly two weeks late compared to the original plan finish date.

The sponsor asked what the problem was and you said, “We did not identify our project stakeholders in the beginning. That would have let us gather their requirements before we started work. Now we are discovering those requirements and having to redo much of the work we have done over the last two weeks.”

The sponsor’s facial expression went from anger to embarrassment and she said, “Next time we’ll identify the project stakeholders early and do a better stakeholder analysis.”

Learn how to do stakeholder analysis and management in our online project management basics courses. You work privately with a expert project manager. You control the schedule and pace and have as many phone calls and live video conferences as you wish.  Take a look at the courses in your specialty.

[button link=”http://162.144.114.198/~jwkdwgmy/it-project-management/it-project-basics-111/” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/business-project-management/project-management-basics/” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=“yes”]Business[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/construction-project-management/construction-project-basics-121/” style=”info” color=”red” window=”yes” bg_color=“00000000″]Construction[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/healthcare-project-management-2/healthcare-project-basics-131-2/” style=”info” color=”#1e14a8″ window=”yes” bg_color=“00000000″]Healthcare[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/client-project-management/client-project-basics-online-141/” style=”info” color=”red” window=”yes” bg_color=”00000000″]Client Projects[/button]

 

Project Cost Benefit Analysis

A project’s cost benefit analysis is important in any organization, especially in the banking sector. It always comes down to costs and benefits. The perceived value of a project and the prognosis for approval heavily depend on the ability of the project manager and sponsor to show how it benefits the organization. The tool most often used to justify projects is the Cost Benefit Analysis.  Cost Benefit Analysis Main Pagecost benefit analysis

Now a cost benefit analysis or CBA is meant to be an objective tool, using numbers and math to determine the true potential of a project. However, there is an issue with its total objectivity. The three basic components of every CBA are:

  • assumptions
  • a mathematical analysis of the assumptions with inputs like numbers and volumes
  • the time series.

The last two components are objective. But the selection of assumptions is a mainly subjective process and it leaves plenty of room for creativity.

In organizations that rigorously use CBA’s, one of the tricks project managers often use is to include assumptions on benefits that are hard to measure. Examples are intangible benefits, avoided costs, avoided investment, stronger customer loyalty, stronger brand, etc. Although there is nothing wrong with trying your best to justify a project, I believe there is an issue with basing a case on difficult to measure benefits.

These assumptions often produce estimates that are difficult to prove. They look good on paper, but are easily challenged in a board room. Cost Benefit Analysis with fat numbers based on intangible benefits can be deflated and cause the board of directors to distrust the project manager. These assumptions become weak when faced with simple questions like, “Will these numbers be visible in the P&L?” And when you answer with, “No but….,” the executives most probably stop listening.

Some companies do follow-ups after projects are closed to verify the assumed benefits were realized. If a project with bloated numbers is actually approved, the project manager has a tough time proving the existence of the promised benefits.

For a current example, we can look at what is happening in the IT industry where the disconnect between promised and actual results is often large. There are many suppliers that meet with executives and promise huge savings in implementing IT best practices, such as ITIL or COBIT.

The company ITSMF, for example, makes several outrageously unsubstantiated claims in its An Introductory Overview of ITIL [version 2] . *”Over 70% reduction in service downtime, ROI up by over 1000%, Savings of £100 million per annum, New product cycles reduced by 50%.”*

However, looking at it from the other side, we see different results. *”In a survey carried out by Bruton of 400 sites, about half of the 125 organizations which were found to have adopted ITIL made no measured improvement in terms of their service performance…”*

Finally, I do not really trust nor like an “outsmart them”approach when writing a CBA. My advice: be pragmatic and state strong, measurable and clear assumptions in your figures. If the project is strategic but difficult to argue on paper, then build the case on the strategic part and state that the benefits are difficult to quantify. If there is only a 50% chance that the expected benefits will materialize, this fact should be clearly stated. By being truthful, accurate and straightforward, you can build the trust of your executive team and establish yourself as a trustworthy and effective professional.