In the last few posts, I’ve been elaborating on an upcoming column I wrote for PM Network magazine. In those posts, we discovered that methodology doesn’t matter, but that doesn’t stop us from engaging in the methodology wars. In particular, the methodology war is about whether process compliance or process customization is more important for tailoring your work to the job at hand. It’s been an active conversation, with alternate posts offered up by Bob Tarne, Glen Allen, Pawel Brodzinski, Andrew Sparks, and Tathagat Varma.
Certainly, the debate between compliance-to-methodology vs. customizing-methodology is interesting. But I want to take a detour to a more fundamental question about exactly process tailoring is in the first place. Project Management experts have told us that to be effective, you have to tailor your organization’s processes for the specific context and constraints of a specific project. But they never told us HOW to do that. Exactly HOW am I supposed to know what parts are fixed, and which parts can be altered or pitched? Since no one ever gave me a good answer, I offer the following framework:
Step 1: Start With What Is Easiest.
Usually that means you start with what you have. If your organization has been using an internal procedure standard for years, then it makes sense to use that standard as a baseline for how to get work done. On the other hand, if youâ€™ve just launched a new division or a new startup, it will be easiest to choose from a more industry-wide process standard. Doing so will give you access to more training and coaching options to get your staff setup. Whatever you do, donâ€™t be dramatic. If you start with something that simply doesnâ€™t fit your culture, youâ€™ll find a lot of resistance to all the ideas, even the good ones.
Step 2: Delivery Early, Deliver Often.
The entire point of a project is to execute a strategic objective. Whatever execution framework you choose (PMBOK, Scrum, RUP, etc), you have to be able to deliver to your customer…frequently. One of your greatest risk mitigation strategies is to use your process standard to deliver completed work as soon as possible, rather than all at once. Once a work package is delivered, you no longer need to manage the project risk associated with that work package. Furthermore, your sponsors will be satisfied at having preliminary or intermediate results as a track record towards the final result. The best project management metric out there is delivered results.
Step 3: Inspect and Adapt.
How many organizations hold a lessons-learned meeting only after the project is completed? Why? Shouldnâ€™t we be learning lessons about how to be more effective, while the project is actually underway? What if half of your communications team caught the flu in the middle of a project, the same time your subject matter expert suffered a death in the family? Did your methodology have a flowchart for that? It may tell you to crash the schedule or reallocate staff, but the project team will know better than the methodology whether doing so will impact higher priority items. A good project manager will schedule recurring project reviews, where he or she can foster a relentless commitment to process improvement. How can our process be more effective? How can we tailor it to deliver more business value earlier in the project timeline?
Step 4: Go Back To Step 2.
Once you’ve implemented a few tweaks here and there, you’ll be tempted to think that you’re finished with tailoring. However, management is never finished. The secret to a becoming a high-performing team is to be obsessed on delivering more quality, more product, more services, more often, but in a regulated fashion. Don’t burn out, but don’t get complacent. Once you’ve improved a few of your processes and procedures, go back and re-evaluate your deliverables. Then, perform another lessons-learned to become even more effective. Get into the Jim Collins’ flywheel principle, where you get better and better, gradually, consistently.
Granted, all of this is easier said than done. In the last several months, I have been working for one project sponsor that has deep anxiety over changes in the project plan, especially as the final delivery date comes closer. Sheâ€™s made very significant commitments to her stakeholders, and thus, to her, change represents risk. She doesnâ€™t want to hear that everyone failed to comply with the project process, nor will it comfort her to hear that change is just fine. My role as a project manager is to explain that we merely started with the process standard, and that success is based on how well we adapt.
So what do you think? Does this make sense as a project tailoring framework? Have you formalized your tailoring approach in a different way?