SOWs: The challenge of executing on stakeholder requirements

As I watch IM/IT projects evolve, I see a trend that is very concerning – losing the stakeholder’s vision in the process of implementing the solution.

Stakeholders have real business concerns: increasing sales, lowering costs and improving competitive position. By the time a project moves to the execution phase, these are not always obvious.

When I interview executives and confirm their C-level business requirements, it seems pretty simple. There is a problem statement, usually enough of a pain point that they are thinking of a reasonable budget, and they are in the process of scoping level of effort and timelines. The challenges seem basic in that a few investments in processes and technologies should have substantial impact(s).

But somewhere along the way, all this changes …

Business analysts come in to document the requirements, which usually results in a distillation of the original problem. There is more granular detail, but the overall business objective can become estranged from the business requirements document. Inevitably, the purchasing department picks up the process and reduces it to an RFP/RFI.

Companies respond to the RFP and a services vendor is selected. By now the vision has strayed considerably. The winner of the RFP carefully generates a Statement of Work (SOW). Sure it wants to deliver value, but it has to manage its own risks and ensure a fair profit.

A few months have passed by now and the stakeholder’s requirements have shifted slightly as well. If everyone is lucky, the SOW that the project manager occasionally refers to still represents the stakeholder’s requirements. Both organizations take the project plan as gospel and hand it to their respective project managers to deploy.

By the time the project kicks off, there are two sets of requirements and no opportunity to tweak them to keep the deliverables in lock step with the evolving needs.

The solution

Get a project executive, a title that may conjure concerns about more overhead, when it should instill confidence. I often step in to fill this critical role and in many cases I do not bill for it. I find myself six months later standing in front of the same C-level manager and injecting a new project milestone that is not on anyone’s plan.

I insist on a few short meetings and, throughout the project, on bringing the CMO or CFO down to the shop to see what the developers have created. I also ensure that the team is there to meet the “boss” and get direct feedback.

The results are always interesting; initially there is some level of concern among the client team and our people about such high-level visits. But these senior management people are usually thrilled to briefly step in and provide advice on tweaks and directions. Not surprisingly, the outcome is that everyone relaxes, motivation levels go up, and risks go down.

These stakeholder progress reviews have several benefits:

Ongoing project investment is kept on track with business needs for maximum ROI;

Should a change order be required, everyone understands why developers have a higher understanding of the requirements and can provided added value;

Motivation for the entire team on both sides, who feel a higher level of investment and commitment to the project.