Andrew Meyer blogged about a short hand method of cutting to the chase when it comes to finding excuses. He and his readers compiled a list of numbered excuses so that people can refer to them by their number instead of going through the inefficient process of voicing them manually.
I think this is great! How about using it in combination with a spinning wheel, or one of those dice with a ridiculous amount of sides? The possibilities are endless! We could even get the team involved by picking someone out of a hat to have the honor of rolling the die or spinning the wheel in a team meeting to determine which excuses we will use. Talk about teamwork!
I really like number 12, “The Development, Testing, QA, Production environments aren’t the same, the sysadmins are looking at it, they should be done…“ A related one that is very popular: “We are working on that with xxxx….we should have more information by the end of the [day, week].” -Next week’s meeting: “We are working on that with xxxx….we should have more information by the end of the [day, week].”
This point consists of two elements as I see it. (1) Walk the talk, and (2) hold systems accountable.
Walk the Talk
Slogans are phony. The word slogan has a connotation of something that is not real. It sounds like an advertisement, and not something you can really trust in. In a project management organization, it is much better to have published guidelines and a vision that defines your philosophy and practice. Train your project managers and teams on the methodology. Then, let them execute within that framework, and put a system in place so that the practitioners can revise the process and make it better.
Additionally, if you say you are going to deliver the product by a specified date, budget, and quality, then do it. Consistently. Estimating a launch and then consistently missing the deadline is a sure way to make upper management believe you are full of it. Sometimes this goes with Point #9; the project manager points the finger at the stakeholders and says “well, it wouldn’t be so late if they wouldn’t have changed their requirements.” It’s your job to fully understand the requirements early on, so step up to that responsibility and stop the finger pointing. If you took the effort to better understand what they wanted, perhaps you could have provided more reasonable estimates. No excuses.
Hold Systems Accountable
If you do not have a common and well-defined company methodology for project management, you must be expecting every project manager to be perfect. The lessons learned from other projects and project managers must be transmitted through osmosis or psychically, I suppose. That project manager “should have known” how to do proper risk planning. If you lecture the project managers, they should automatically be motivate to do a better job right? After all, it was their fault for not being omnipotent in the first place, right?
A better approach might be to have a set of guidelines, tools, and techniques within well defined processes so that a project manager does not have to also be a mind reader. If projects are constantly failing at your organization, it is not because you have a set of lousy project managers (more than likely), it’s because you have no system in place to manage projects.
