How should a project manager handle a request for contracted software to produce twice as many reports as specified in the project's requirements?

Question

I have joined a late-phase software project and there is a great deal of disagreement between my management and the client about work items they are claiming to be outstanding. In short, our business requirements document (BRD) describes three reports that the software needs to produce, but the statement of work (SOW) simply says that the software will support "reporting". Now the client is asking us to create six additional reports and says that it is covered because the SOW says that the software will be used to produce reports.

My PM training has taught me that the BRD definition of a subject will supersede a SOW definition as the purpose of the SOW is to be abstract and the BRD is concrete. However, management at my company are wavering and agreeing that they can see the client's point of view. I think this is gold plating, pure and simple.

Strictly speaking as a project manager, who is technically correct here? Can the SOW's abstractness be used to redefine BRD scope definition or is the BRD and software requirements specification (SRS) considered the definitive word on in/out of scope items?

Answer 1

One of the four values of agile is "Customer Collaboration over Contract Negotiation."

The first thing to ask is "what is best for the customer?". Once you've done that, then you ask "is it covered by the contract?" and only then do you delve into the "do we ask for more $".

Specifically focusing on your issue the first question I'd ask is who was involved in the review and sign off of the BRD? Often I've found that the BRD only had one person from the customer and that person may not have really been the right person.

If the customer is important to your company, I would suggest sticking with the agile value an working with them to make them happy.

Then on any future projects, make sure to get clear definitions of success and acceptance criteria up front. Also make sure the SOW is written in such a way as to reference final requirements are documented somewhere else.

Good luck

Answer 2

TL;DR

At this stage, the project manager's job is to provide a framework for the companies to address scope, and to estimate the budget and resources needed to deliver that scope. That's it! In situations like these, questions of fault (unless of course it's yours) are really outside a project manager's scope of responsibility.

Rather than assign blame, or attempting to shift the burden to the customer, you should:

1. Communicate effectively with your organization (and possibly the client) about the problem.
2. Identify one or more potential solutions to the problem.
3. Recommend a solution to your senior management, who can then work it out with the client.

Each of these action items are discussed in more detail below.

Communicate Effectively About Problems

Acronyms can cause communication problems, but rarely solve them. Most of your post is a confusing mishmash of acronyms, and does a poor job of communicating about the real problem. So, let's fix that first. Your meaningful facts are:

1. [T]he statement of work (SOW) simply says that the software will support "reporting".

2. [O]ur business requirements document (BRD) describes three reports that the software needs to produce.

3. [T]he client is asking us to create six additional reports and says that it is covered because the SOW says that the software will be used to produce reports.

In summary, the statement of work that defines the scope is vague, the business requirements document may or may not have been written in collaboration with the client, and the client is asking that the project cover six reports instead of three.

Analyze the Problem Accurately

Now that we've identified the actual issues, let's see what that really means for your scope and your process.

1. Your company is clearly at fault for the vague scope in the SOW. Your contracting process should be fixed, but in the meantime it kicks responsibility for defining the scope of reporting down the road to some other document or process within the project. This may or may not be your business requirements document.
2. When you say "our" business requirements document, it is terribly unclear who the BRD owner actually is. Were the requirements written by the customer, or solicited from them, and then incorporated into the project by the project leadership? Or did your project team create this document, and perhaps do an incomplete job of capturing the full set of requirements? This matters a lot, because in the first case the client defined a scope that they are now exceeding, while in the second case your organization used a vague SOW followed by an incomplete set of requirements to define the scope. If your project team failed to capture the requirements accurately, that would again be your company's fault.
3. The very existence of the question presupposes that the reporting product isn't easily extensible. If it were, this would be a minor issue that didn't involve a significant budget or cause concern for two separate management teams. So, there's either technical debt, a lack of a robust implementation, or there are complexities about this reporting requirement that were not captured well by the project.
4. This is a question of both project scope (e.g. are the additional reports included in the agreed-upon work?) and liability (e.g. who is at fault for miscommunication, scope creep, or budget overruns). This is a question for senior management (and possibly the lawyers) on both sides to answer, rather than strictly a project management question. To the extent that the project manager should have either identified the vague SOW as a risk, or worked to ensure that the BRD was accurate and complete, there is certainly plenty of blame to go around. However, the real issue is who pays for the additional project costs?

At the end of the day, the first three questions are about assigning blame, and don't really help outside of a courtroom if your contract dispute gets that far. What really matters is how you salvage the project, the customer relationship, and avoid vast cost overruns.

The Pool of Possible Solutions

First of all, forget how you got where you are. Fix that another time. Focus instead on how to collaborate with the customer to find a satisfactory solution that meets:

1. the client's expectations for a working product, and
2. your company's need to fund any additional work.

In no particular order, your project will eventually do one or more of the following:

• Cry "mea culpa" and do the remaining work at no extra charge.
• Use the experience to improve the contracting, budgeting, estimation, and requirements-gathering processes in the future.
• Collect new reporting requirements and add them to the project with an eye towards minimizing any additional costs while still delivering expected customer value.
• Collaborate with the customer to find an equitable solution.
  • Collaborate with the customer to redefine the scope.
  • Collaborate with the customer to renegotiate the budget.
• Sic the contracting principals on each other to hammer out a mutually (un)satisfactory solution.
• Lawyer up, and go to court over who was right.

There may be some variations on a theme that I haven't covered, but in general those are your pool of options. Some are definitely more palatable than others, but it's really up to senior management to pick the set of options, not the project manager.

Recommendations

Personally, I'd recommend the collaborative approach whenever possible. Your goal should be to deliver as much value as possible without eating excessive costs, while the client's goal should be to get working software that meets their needs without expecting free work or souring a relationship they may be counting on for long-term support of the software they're paying your company to write.

In a perfect world, this issue would never have arisen. Since it has, you want to explore the art of compromise so that both parties can walk away content if not happy.

In an agile shop, I'd just treat it as an iterative extension of the work already done. In a waterfall shop, I would:

1. Regather the requirements.
2. Get sign-off by the client and your development team on the new scope to ensure everyone is on the same page.
3. Estimate the effort and cost associated with the new scope.
4. Let the executives of both companies earn their 400:1 pay by hammering out who's going to pay for the additional scope.

At this stage, the project manager's job is to provide a framework for the companies to address scope, and to estimate the budget and resources needed to deliver that scope. That's it! In situations like these, questions of fault (unless of course it's yours) are really outside a project manager's scope of responsibility.

Answer 3

The SOW is contractual. The BRD is a work product. The SOW will likely prevail if this ever ended up in dispute. That said, the BRD is not without weight. If the extra reports are onerous to build and will impact you from a cost perspective, then get the customer to the table and discuss more money. A reasonable customer will negotiate. An unreasonable customer will not. But then lesson learned for your next gig to build more contingency for stuff like this, in your price.

Answer 4

In my experience, the document that will prevail will be the one signed off by both parts.

• If the BRD was very clear about 3 reports but the client wasn't aware of it, it's up to the project to absorb this mistake - and review ASAP the BRD for further gaps
• If the client was aware of the BRD and signed it off, it's a matter of replanning
• If there's no formal document signed off, then it's a matter of getting into an agreement on how to address it (plenty of alternatives extensively mentioned by CodeGnome) - signing off a document, as it seems that collaboration (like the one we expect in Agile environments) isn't strong in this environment.