Almost all prescribed remedies to scope creep relate to change management after the business requirements for a project have been set.
Project managers (PMs) are trained to try to police increases in the cost and time
required for the project that don’t
create any clear benefit for the business
.

I italicized that last phrase
because, ultimately, business value is the final litmus test on whether a scope
change is creep or just crazy-smart Agile management. Growing a project can
actually make sense, so long as there is a payoff. Evaluating the business impact
of features and projects is the first, the best, and often the only guard
against scope creep, “gold plating,” and other ways to waste the
company’s money.

That’s why you need to make sure
the business analyst is among your closest allies on the project team.

In my last post, I suggested that
the PM office require anyone who requests a scope change to include a quick business rationale, including mapping to established business goals, on the
change management form before you log it and begin the formal approval
process. That is going to create, or at least shift up, work for the business
analyst.

But as a PM, you need to get even
more greedy. You need to ensure that you have a direct channel to the business
analyst during development of the business requirements, even in the early
stages. The most wasteful “gold plated” features on a project are often
injected at those early stages, and as the PM, you need to have a direct line
to push back even before the business requirements get to formal review.

Case in point: Back in the early days of TechRepublic,
probably about four years in, the management team (of which I was a member) decided
to implement an industrial-grade Content Management System (CMS) for our growing website.
We did an initial business analysis to determine needs, and then we bid out to
several vendors for what ended up as a substantial six-figure contract. (This
was before the days when WordPress and other site-in-a-box technologies had
matured to be useful backends, at least, for almost any online publishing
venture. These things used to cost a ton of money.)

The project ultimately ended up with myself (as a sort of
hybrid business analyst / line-of-business manager) and our project manager
making trips to Cambridge, Mass., and spending several sleepless nights trying
to hash out the most highly customized requirement of the project: the ability
to parse Microsoft Word binary large object files (BLOBs!) in and out of the
CMS’s structured DB schema.

The company decided on the “need” to do this because editors
relied heavily on Word’s commenting and track changes features for versioning
with authors, and web-form based editors simply did not (and really, still do
not) support that function. So, we paid to code out a translator, coupled with
a structured Word template, that retained comments and the like as it pushed
and pulled content in and out of the DB as an article moved throughout its
workflow prior to publishing.

This was to handle less than 20 articles each day.

In hindsight, I can say: “It’s called copy and paste,
dude.”

Truth be told, as a business analyst, I did not push back on
the VPs and others in the organization on that requirement, because it was on
“my side” of the fence, as it were. It made sense to me; as an editor
by training, I could see the benefit of the feature. However, I had almost no
visibility of the cost, and so I did not credibly evaluate the actual benefit.
So the BLOB parser went in the business requirement, and as the project took shape, stakeholders
began to view it not as a nice-to-have but as a key value proposition. By the
time we reached formal review, it was etched in stone.

Initial, active feedback from the PM would have been
invaluable in making what should have been a pretty obvious decision toward
streamlining.

Clearly, this situation can’t be laid at the feet of the PM,
and it can’t technically be described as scope creep — the business got what
it asked for. But the PM did catch some heat on the backend of the project that
could have been avoided (at least, I’d like to think so) with a little peer-to-peer
communication.

You just count on the VPs to focus on these kinds of
details. Until they are looking for somebody to blame for what went wrong.