Project Management is an operational exercise and requires a very practical approach. When considering the adoption of a methodology into your practice you should never accept methodology in it’s pure form. It should be up a lump of play-do that you can form and kneed into a shape that benefits your practice, not hinders that.
Acceptance of any pure form carte blanche is lazy at best and destructive at worst. Taking the best the methodology has to offer and adapting it to your practice is recommended. This is coming a newly minted PMP too- even before I have a chance to get jaded about the whole PMI methodology. However, I had over 6 years of experience as a PM before I even picked up the PMBOK guide, so I was walking in with context of experience.
The PMI methodology is extremely document heavy. You can write risk registers, communications plans, and set up change control boards all day and night while valuable time is burning through your timeline, and you suddenly wake up on the angry end of an SVI that’s north of 1.5, and a client demanding to know what happened. “Er- let me check the lessons learned document.”
Agile methodology is obsessed with tasks and sprints. It also puts a heavy level of control on your dev team. It posts up tasks and allows them to decide what tasks or stories to claim. In my experience you have to assign the tasks based on specialization and availability. Resourcing is a fairly delicate art. Tossing it over to the team and saying “Here! You assholes deal with it!” is not something I’m prepared to do. Additionally, the notion of sprints is that the team will gain inertia and start cranking through sprints with greater and greater levels of productivity. I’m skeptical on how that will magically happen. Additionally, consider this scenario.
You’ve decomposed all your tasks into stories and have decided to make sprints 10 mandays (i.e: 2 weeks- that’s fortnight to you fancypantses out there), and you associate all high priority stories to sprint 1, you discover based on your best estimation it will take 12 days. D’ho! So you take out the leasts prioritized story and move it to sprint 2- but that story is estimated at 3 days. That means Sprint 1 is 9 days, and Sprint 2 will be 13, and that will be exceptionally bad.
Waterfall methodology leaves no room for rolling wave planning or progressive elaboration. It requires crystalized articulation of all requirements at inception, and while that’s great in theory, it doesn’t totally reflect real life. In real life, the client says the most dangerous words she can say at least once during a project. That phrase invariably starts with “Wouldn’t it be cool if…” Now if you’re smart, talented and lucky, you can either 1) Accommodate them by planning to allow for progressive elaboration with timeline and budget, so when they do say that you can say “No problem!” and get to BA-ing it. Or 2) You can sell them on a Phase 2 with a new timeline, and a new budget and treat it as a new and separate project entirely and hope they have the budget to accommodate it and the patience to wait for it to be delivered or 3) Change Request- which is basically like option 2, but within the current phase. Depending on the nature of the change, it could potentially preclude inclusion (due to hard logic (that’s necessary sequences of tasks)) and telling a client they have to wait for Phase 2 can potentially incite the rancor of the client.
This has been a fairly negative blog, to be sure. I have been outlining the shortcomings of these methodologies, but there are elements in them I appreciate and use regularly. Your practice should be based on best practice elements and the influence of standard methodologies can only make it stronger. Yes, Project Management is based on operations, but I’ve been in companies where the lack of methodology wasn’t just shocking, it was crippling to the timeline and budgets.
Read up on methodologies, use elements that work for you.