Tag Archives: methodology

4 Simple Steps For Tailoring Your Methodology

Posted on
11

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?

The Real Reasons Behind the Methodology Wars

Posted on
2

NOTE: This post is an elaboration of my column in an upcoming issue of PM Network magazine

In my previous post, I laid out 3 Reasons Why Methodology Doesn’t Matter. But the question remains: If it doesn’t matter, why do management experts fuss over those methodologies? Why do we see such heated discussions around the virtues and vices of a given set of policies and procedures?

The wars are rooted in “professional pain”
If you’ve worked on a project where you hated going to work in the morning, where the best of your efforts somehow always led to clunky deliverables, where customers and executives demanded that you squeeze juice from a dead rock….then you’ve experienced “professional pain”. I know; I’ve been there. It’s what motivated me to become a project manager in the first place. After spending 3 years on a death march of a government contract, I vowed never to stand by and let my future projects end up in that kind of misery again. When PM experts label each other as self-serving or ignorant, they miss the emotional source of issue. This is not metaphor or simile; this is about creating the humane working conditions that deliver real business results.

The wars are between Compliance vs. Customization
If the passion in today’s project management debates come from professional pain, then the substance of the debate boils down to whether it is better to run projects with more focus on process compliance or process customization. It goes something like this:

“If only we had more compliant processes…we’d have fewer mistakes…we’d have the predictability needed for planning our risks and resources…we’d know what is expected of us…we’d be more successful.”

or

“If only we had more custom processes…we’d be able to deliver real value instead of wasting time on administrative overhead…we’d be able to own more of our work…we’d be able to adapt to new information…we’d be more successful.”

Don’t pay attention to the arguments of which methodology is better; that’s not what people are usually fighting for. The real passion comes from how much compliance is best versus how much customization is best. This is the debate.

The war rages across all camps
Today’s PM thought leaders have generalized the compliance advocates as “traditionalists” and the customization advocates as “modernists”. However, the methodology wars are not limited to whether you consider yourself a traditionalist or a modernist. Some of the most heated discussions arise in the midst of those camps.

Within the PMI community, the PMBOK is strongly charactarized as the “Guide to Project Management”, allowing for whatever customized approach is needed to deliver a project. However, other project managers remind us that same “Guide” contains an official standard for exactly what goes into risk management or quality assurance. Depending on which PMI person you run into, you’ll get a difference story on whether more compliance or more customization is the way to implement the PMBOK practices.

Within Agile circles, Kanban practitioners decry several practices of the Scrum method as wasteful ceremony, driven by compliance rather than by value. Meanwhile, Scrum is also considered way too loose and easy by the eXtreme Programming community, who advocate compliance to specific engineering practices.

But who’s right? Which of the two is the better focus? Well, that’s another question for another post. For today, it’s enough to know what’s really happening the next time you come a project management flame war on some discussion board: Having suffered professional pain, managers believe strongly that either more compliance or more customization is the path to success, and will defend that belief even against those in their own camp.

Methodology Doesn’t Matter

Posted on
24

NOTE: This post is an elaboration of my column in an upcoming issue of PM Network magazine

Recently, I was reading an online discussion board, where two project managers were arguing whether a particular project management approach could be described as a “methodology”.

Their discussion had 37 entries.

My first reaction was to roll my eyes at the waste of time involved in such a debate. What is so important about whether we use the “methodology” label when referring to the PMBOK, Method/1, Scrum, ITIL, or Prince2? It used to be that we argued over which of these methodologies was the best one to use. Today however, experts will detail for us the finer points of why their product absolutely is NOT a methodology, and must instead be called a “toolkit” or “framework”. Seriously, what’s the big deal? Every project manager should know that how you do your work depends on the the context of that work. So then whether we call our specific approach a “standard”, a “process”, or (gasp!) a”methodology” is irrelevant, right?

However, the more I think a about this religious debate of terminology, the more I see legitimate anxieties. At least some of the time, this is not a debate of “I’m right, you’re wrong”. Rather, there are deep-seeded concerns about the negative impact an organization’s processes and policies have on project teams. The arguments associate “methodology” to a variety of bad management practices. So, if we assume this debate as childish as at first glance, let’s explore some key reasons why methodology doesn’t matter.

methodology-doesnt-matter

Reason 1: According to English, anything intentionally organized is a “methodology”.
A common objection to the M-word is that it explicitly means we have to do all of the steps all of the time. However, a quick review of the definition reveals that’s not the case
The Oxford English Dictionary defines a methodology as “a system of methods used in a particular field”. It further defines a system as “a set of things working together as a mechanism or interconnecting network”. So if we put those together, we find:

A Methodology is a set of things working together as a mechanism or interconnecting network, which is used in a particular field.

It would be hard to argue that the PMBOK or Scrum do not qualify as a set of methods that work well together in an intentional fashion. Even the Agile Manifesto, which is a document of values and principles, advocates specific methods like regular reflection and face-to-face conversation. There’s nothing in the definition that mentions rules, let alone saying you have to follow all the rules, or that you’re less of a person if you don’t follow all the rules. Indeed, even the experiential and emergent Montessori approach to primary school is called a methodology. According to English, christening your management practices as a methodology says almost nothing about what those practices are.

Reason #2: Methodologies themselves tell us NOT to follow all the rules.
If the primary anxiety is that methodologies require us to manage-by-the-book, we do well to actually read the book:

  • The PMBOK references process tailoring 14 times.
  • The Agile Manifesto values individuals and interactions of a team that tunes and adjusts its behavior throughout the project.
  • The Unified Process describes the relative emphasis of skill sets at different phases.
  • ISO 9001, Section 8 explains the goal of formalizing business operations is facilitating continual improvement (read tailoring) of those processes.

…and these are just the examples I have on hand. I would challenge you to find a process methodology that explicitly states you have to follow all the rules, all the time, now and forever.

Reason #3 No methodology asserts it is always better than another
The examples I’ve given above lay out a set of practices that accomplish a specific goal within a specific context. The PMBOK is a set of practices for managing projects, whereas ISO 9001 is focused business operations. The Agile manifesto was crafted for the knowledge work of software, but Six Sigma was designed manufacturing. None of them explicitly state they are better than any other.

It’s worth noting that even though these methods don’t assert superiority over each other, people do. Process Champion X can preach all he wants that his method is better than the others, but that doesn’t change the fact that his method doesn’t say so. People do like to be right, over and above others, but that’s a different blog post.

Summary and a Question
So, now that we see that methodologies pose no danger in and of themselves, where does the impassioned debate stem from? I’ll explore that in my next post. But for now, what are your thoughts? Have you seen a formalized approach to work that contradicts the observations above? Have you found a methodology that DOES mandate following all the rules is a better approach than any other?

PMI Hosts Agile Breakfast

Posted on
Reply

This morning at the National Press Building, the Washington DC chapter of PMI hosted a talk entitled “Agile or PMBOK? You can have both”. The presenter was David Sides from ESI, who has been using Agile at his client engagements for a while, and shared his observations light-hearted fashion (more on that in moment).

The event was sold out, with more than 100 DC-area professionals coming to check out the talk. When David asked how many were using Agile, only 2 raised their hands (including me). When he asked how many were looking into / thinking about using it, a full 40% raised their hands. Clearly, this was a topic that had significant draw.

pm-in-the-am

So with that backdrop, Dave went about debunking some Agile myths, and making some interesting points. Here are the highlights:

  • “There’s no such thing as pure methodology” – His point here is that all Agile projects have a dose of reality tempering the ideal process. Indeed, even waterfall projects use iterative/incremental process to knock out bugs during a test cycle.
  • “Will Agile get you working software faster? Yes. Will Agile get your product to market faster? Maybe.” Getting to market depends on more than just working software. Packaging, marketing, sales prep, training, need to be considered.
  • J.E.D. = Just Enough Documentation

    • <li >”Too often we don’t have enough SMEs. Instead we get SMRs (subject matter rookies)”

  • “How many of us have been on ‘stereo concalls’…where half the participants are in the cubes next to us?”
  • “Some cultures never change.” Even those that do need a “constant iterative change process to get where we can use Agile”.
  • Move away from “Earned Value” to “Achieved Value”

He also had fun doing his Letterman routine: 10 stupid Agile tricks (e.g. “We in IT know what is best”). David did a good job, and he’ll be reprising the talk as a webinar tomorrow: http://request.esi-intl.com/forms/EV09JUN11FM-PM-AgileWebinar

At the end of the talk, he took questions from the crowd:

  • But what about regression testing?
  • But what about fixed-price?
  • But what about Agile teams that need a full iteration to finish testing?
  • But what about matrixed teams? My organization would never give dedicated staff

What suprised me about this event, was not that Agile newcomers were asking the same questions. Instead, my eyes were opened to the uncharted ocean of opportunity that exists in the market. So many projects are struggling with the same issues. So many PMs are tasked with the impossible. Agile offers a management approach that can solve those problems, but people are not getting the message.

This is why I volunteer with PMI’s Agile Community of Practice. The market needs a place for dyed-in-the-wool PMs to go for their first exposure to Agile PM. A place where people can have these basic questions can be answered, and then get directed to a local user group and local training. This kind of resource could the beginning of a journey of growth and expertise that could transform our workplace from a dungeon to a dynamo.

PMBOK/Agile @ APLN Maryland

Posted on
1

I am giving a talk on PMBOK vs. Agile at the APLN Maryland chapter meeting later this month. Details are below:

Date & Time: Tuesday, 24 February 2009, 5:45pm

Title: PMBOK vs. Agile: Sifting Reality From Myth
Description: With the increased success of Agile processes and the growth of PMI, project teams are faced with a choice: Use PMI’s collected body of project management practices or use Agile. We are told that PMI practioners mandate a waterfall command-and-control approach, and that Agile is the process-free alternative. But a quick look side-by-side comparison reveals a much more complex situation. What do we make of facilitative servant-minded PMPs? Could Agilists gain value from PMI materials? What is the official position of PMI towards Agile?

Locale: Columbia, MD
Presenter: Jesse Fewell
Details and Registration here: http://www.gbspin.org/upcoming.html

Project Metrics for the Homeless

Posted on
Reply

To help strengthen our culture of client service, Excella Consulting has partnered with Homestretch, a local non-profit that provides homeless transition services.

A few weeks ago, we were visiting Homestretch headquarters, planning our community service activity for the Martin Luther King holiday. During the meeting, one of us asked a staffer the simple question: On average, how long does an unit stay empty. The staffer replied: “I’m not sure. We don’t keep track of that. What we care about is how many units are available at any given time”.

I was awe-struck.

Homestretch is a non-profit. They have to run on a shoe-string budget, use limited staff, and serve a clientele that ranges from refugees to layoffs to domestic violence victims. Also consider that half of their units are rented from other owners, to where they generate an negative property revenue each month. Yet, they completely ignore the convention metric of resource idle time. From this brief dialog, I learned a few lessons:

  • Measure Your Mission – When a project, or an organization knows it’s mission, you can find that one measurement that tells you how well you’re doing. In the case of Homestretch, it’s how many otherwise homeless families are we housing right now, and how many more could we help right now.
  • Train The Measurement – Did I mention the staffer wasn’t an office worker? His name is Saul, and he’s a maintenance supervisor. The fact that everyone on the staff knew what numbers mattered most is a hint to why Homestretch is so successful.
  • Capacity Matters More – When looking for that measurement, consider that Capacity matters more than Idle time. Rather than fussing over how much work you’re not doing, focus on how much work you are doing. It sounds like the same, but the subtley is huge. While idle time tells you if resources are busy on anything at all, capacity tells you how much business value you are generating. Indeed, if capacity goes too far in one direction, you end up learning the same thing you would be trying to find measuring idle time.

    On MLK day, we turned over 4 housing units, and moved the life skills training facility to a larger space. Certainly, the event was a success, but I can tell exactly how much of a success it was in Homestretch’s own terminology: 4 new families off the street.