Okay, the title is a bit of a false advertising. I’m not revealing the top five rules – I’m actually looking for help in defining rules #3-5. Any input is appreciated – care to weigh in with an opinion?
I’ve had a number of discussions, with some of the best project managers I know, as we discuss ways to simplify methodologies and streamline our delivery process. Many organizations are trying to train their next generation of project managers, and all seem to run into the same basic problem. You can hand someone the PMBOK, teach them how to use MS Project, and send them off to PMI certification classes – but that doesn’t guarantee an effective project manager. The toughest thing to train is the “soft skills” – how to get things done through other people without being able to tell them what to do.
Through these discussions, we’ve tried to come up with the Five Fundamental Rules of Project Management. Methodologies, documentation styles, collaboration tools & design frameworks come and go, but in the end – these are the critical things that you must focus on to be an effective PM:
- Manage Expectations: This is Rule Number One, and I typically get agreement on this pretty quickly. It encompasses communication (early and often) plus clarity of requirements. I once had a VP/GM tell me to never be afraid of delivering bad news as long as you give people plenty of time to react. Budget overruns and missed dates can be managed – but it’s a lot easier to manage things with two months warning. Never wait until the day before a go-live to drop the bomb!
- Watch the Critical Path: A cynical way of saying this is stay off the critical path; the best project managers are adept at identifying what truly is the Next Most Important Thing to Work On, and focusing their effort to make sure these items don’t delay the project. A laser focus is not quite what you’re looking for – you need to be able to anticipate what’s next on the critical path, and what other things are close.
Now, here’s where the conversation decomposes – I can get clarity on 1-2, but there are any number of candidates for the next three of this Top Five …
- Manage Scope: Software development as well was system implementation projects often suffer from the creeping feature creature – deadly enemy of all delivery dates
- Calendar Time vs. Effort Time: Project estimators and schedulers often need to clearly define the difference. MS Project demurely offers the Duration column, and all too often your estimators will ask “how much time do you need”, and get answers from developers, documentors, testers, and domain experts all trying to make sure they won’t come in “late”
- Project “checkpoints” and Go/No Go Reviews: A mechanical means of managing expectations watching critical path and managing scope. If done correctly, this also allows a project to make significant course corrections, and even get canceled. If it made good business sense to start a project, it’s reasonable to think that when conditions change, it can make good business sense to stop a project. Scheduled checkpoints are built-in escape hatches.
- The Iron Triangle: Better? Faster? Cheaper? Pick two.
- Definition of Success: Projects, by definition, end. Many projects suffer from a lack of clarity around when the project ends and when the operational system begins.
- Executive Sponsorship: This will only work if the bosses jam it down their throats … I mean, make it a priority
- Business Process Ownership: This will only work if the people involved in the process take an active part in Design and Test
- Get Out of the Way: Project managers need to understand when to be managers, and when not to be do-ers. Too often, folks with technical skills are promoted to a PM role without enough training, and when the project gets tight on time, will grab the wheel and try to get it all done themselves. This works in small organizations or smaller projects, but it just doesn’t scale.
I’m sure I am missing a few, and I definitely have more than five here. Anyone care to weigh in on my “course syllabus for PM 101”?