The business analyst: The project manager's best ally

Ken Hardin shares a tale from his days as a TechRepublic manager that illustrates why PMs need a direct channel to the business analyst.

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.