Cottage PM Example – Managing for Change

I got the first issue of my renewed subscription to Inc. Magazine this week (November 2009, see inc.com). One of the first articles I read had a good Cottage PM scenario as the opening story. The article is “Slow Growth = Slow Death?” and is mostly about growth questions and strategies. It’s an insightful read on that topic. But the opening story should be pretty familiar to those of you who work projects without formal PM practices.

The article is nicely written; I recommend that you read it. Here’s the story I’m referencing, though:

One of our best programmers just came into my office. . . . Implementing the new prices on our website going to take too long, he told me. . . . Changing the prices for new customers is easy, he explained. The hard part is building a slick new area on our website where existing customers can go to convert to the new pricing. “What if we don’t have a slick website?” I asked. “Anybody who wanted to convert would have to call in, and we’d have to do it manually,” he said. “Could you get that part done on time? With the manual conversion?” He said he could. Which means we’re going to do a half-baked job of implementing these new prices. We have to, this time, because we’re committed to a date. (Reference link.)

There’s a lot to conclude and consider about project management in that short scene. I’m sure that for many of you, this is not an unfamiliar scene. What can we observe and how can we make this go well?

Some Assumptions and Next Steps

Making assumptions on a short story who’se point was not PM analysis, I note the following:

There was apparently no PM involved. The story gives no insight into how the project was scoped, defined, controlled, or managed. I’m presuming something existed between the organization leader and the programmer, but perhaps not.
Notice the trade-off in what PM types call the triple constraint, the constant balance between Time, Cost, and Scope. In this case, Time (launch date) was firm, so Scope had to change (change in deliverables and quality of deliverables).

What needs to happen next? What’s the fallout from this decision? If you were PM-ing this project, you ought to readily see the following considerations:

Who needs to know the change in deliverable? Are others doing work that needs to be called off now?
It’s not just that we’re not doing the new interface; we’re replacing that deliverable with a new deliverable: the manual process. Who’s going to define that, frame it, design it, test it, train it? Is there new cost associated to that?
Are we still going to want to build the new web interface later? If so, will it be a new project, or a new phase of this project? Is it subject to other prioritization decisions / processes?

Planning for Change

These kinds of changes are not uncommon. When you plan your project, you need to plan to re-plan. It’s going to happen. Sometimes it happens big, sometimes it’s just small adjustments, but change is, well, a constant.

If you were the PM on this, whether formally the “PM” or simply the functional manager who owns it — that’s how it often happens in Cottage PM environments, as you well know — how could you manage this well? How could you structure the project to anticipate such change and to be able to manage that change quickly and well?

In his recent package, WBS Coach, Josh Nankivel (Twitter: @PMStudent) makes the case that you can probably do this best by using a Work Breakdown Structure (WBS). You don’t have to be a formal PM or a certified PMP to be able to use a WBS effectively.

A WBS captures the full set of deliverables — the work — for the project. If it’s part of the project, it’s on the WBS. If it’s not on the WBS, it’s not part of the project and you don’t pay attention to it. Then, if your programmer says the deadline prohibits delivery of a key deliverable, you can quickly see the impact of that change, and the impact of introducing a new deliverable in its place. You can communicate that change to the project team and stakeholders easily using a WBS.

You might simply stop there, just having the WBS. Already, that would be really helpful and would give you more control of and visibility to your project. You could also go further and tie that WBS to schedules and cost structures. This provides “traceability,” making it much simpler and much more reliable to quantify and manage the impact of change.

I highly recommend that you learn how to use a simple WBS on all your projects. Whether or not you bear the title of PM, if you’re leading projects, you need this tool. Need to know more about the WBS? Check out Josh’s “WBS Coach” package. It’s a quick 4-hour self-study. Choose to read the PDF (like me) or to listen to the MP3 files during your commute. Watch Josh demo some common approaches and tools to building a WBS. Pick your preferred medium and start using it immediately.

Don’t be thrown by project change. Plan for it and know how to manage it.