The delivery date is going to slip because we have learned about new requirements.
Projects are always late and over budget. We shouldn't worry.
We can't predict our final costs because the requirements are changing.
The estimate is in line with management expectations.
Our schedule is good because we used a project-scheduling tool.
We can always add people to meet the deadline.
We are behind schedule because the customer can't make up their minds.
We can cut our testing time to make the delivery date.
Good people make up for bad processes.
Our process is good because it is repeatable.
If they quit we can quickly hire someone to take their place.
We don't involve the people doing the work in estimating because that will increase costs. Besides, they will just inflate/pad their estimates.
Using a Tool is not a Risk.
The sooner we begin coding the more successful we will be.
We will save more by reusing code, not architecture.
We will worry about the cost of maintenance later. There is no time now.
If it doesn't work we will fix it when we have time.
We don't need to document because we put comments in our code.
Technical people don't like to write documentation and we shouldn't insist that they do. Besides, they are terrible writers.
You can't blame the Project Manager. How were they supposed to know?
All of the problems we have been having our
Trust me; we will deliver everything you want on time and at or under budget.
I think you get the idea. As Project Managers, we were hired to tell the truth and include the good, the bad, and the ugly in our status reports. Sugar coating project issues and problems for management will only get us in trouble later. Don't make excuses. Use status reports, e-mail, voice mail, and most importantly face-to-face meetings to relay project status. Don't be afraid to deliver bad news. Just make sure when you present management with issues and problems with your project you have a plan to get it back on track.
Be Responsible, take Ownership, and most importantly, be Trustworthy.