As a web development company, we are developing highly customized and complex websites based on a popular open source platform (Joomla). I see that 4 of our clients have an overlapping problem, so I have an idea to solve this problem for them. I have pitched the idea to get 40h of work funded by each of them for this project and had generally quite positive responses.

My question here centers around how to manage scope for the development, as these clients are used to get (and pay for) exactly what they want.

The current idea is to make a very detailed plan for half of the available funding and reserve the half to make 4 very specific customizations to the project for each client. Obviously the exact needs could be researched much more deeply as well, to split the funds 60%/40% etc.

Is this a reasonable idea to manage scope? What is the most correct way to manage this scope?

3 Answers 3


Interesting idea, but I can't see it working. Controlling multiple stakeholders froma single organization is a challenge already. Multiplying that by four seems like you are closing in on the impossible.

Instead, your company should make this an investment project. You fund this to get an 80% solution, then sell it to each with additional work to close the gaps and make it company specific. I think you would increase the odds of completing it and might make more money out of it, and you will almost certainly save each customer as a customer for future business.


From jdog:

The current idea is to make a very detailed plan for half of the available funding and reserve the half to make 4 very specific customizations to the project for each client. Obviously the exact needs could be researched much more deeply as well, to split the funds 60%/40% etc.

You're allocating the funds in an appropriate manner, splitting the initial cost for both clients at 50/50 and splitting the remaining customizations at 50/50. This is a great place to start negotiations. Depending on requirements overlap, this may change.

From WikiBooks PMBOK Scope Management:

Scope refers to a project’s boundaries: it determines what work will be completed during the project lifecycle. This includes identifying the work that won’t be included in the current round of product/service development.

If you're going to ask two of your clients to split the cost of a portion of the project, you're going to need to know exactly what requirements both will agree on and exactly what requirements will be paid for and worked on separately. You must clearly define those scope boundaries; disagreements in agreed-upon requirements, changing requirements, and scope creep that heads in completely different directions is a huge risk to the combined projects.

As you're aware, your job in managing scope is going to be a lot tougher than if you're dealing with only a single client.

First, you need to make it clear to both clients that the items that they agree to split cannot be changed without revisiting the entire scope.

If, theoretically, 50% of the work is split for the same requirements and 50% of the work is directed towards differing requirements, and client A decides to change a requirement from the shared category, then does that mean that Client B then picks up the costs of the abandoned requirement, or do you hold Client A to that cost?

You'll need to get an agreement up front as to how to handle these scope changes to determine who pays for them. Despite the clients being used to getting what they want, you'll need to clearly define the scope and hold them to that. In the Project Charter, pay special attention to details such as Project Manager authority in changing the scope and clearly define the budget for both sets of requirements.

Communication and negotiation skills are a “must-have” as well. Project managers need to educate stakeholders about the project impacts of some requirements. Adding complexity to a project may require more staff, time, and/or money. It may also have an impact on project quality. Some aspects of the project may be unfeasible – stakeholders need to know this so they can adjust their vision or prepare for future challenges.

Moreover, you may discuss with the clients to gauge their tolerance for cutting features, if necessary. If Client A absolutely requires that you expose an API to allow them to integrate one of their databases, and they're not willing to pay more, then come up with a plan for what features are lowest priority from the non-shared 50% category to make up for the differences in time or cost.

Ultimately, it's up to you to ensure that the scope is realistic and that you can meet the needs of each client, and this will involve some negotiating on your part as well as drawing from your past experiences as to what is and isn't doable.

Lastly, if these clients are known for changing requirements or pushing for changes that add scope creep, you may want to consider both of these as separate projects. The costs will be higher for both of the the clients, and some work may be duplicated, but it may be easier to guarantee that both clients get exactly what they want as the risks will be lessened and more transparent.


I'll take a slightly different approach than the others - Really what you have are two projects. I would split the scope into two projects and then deal with the clients separately based on that split.

Project 1: As I read it - you have 4 clients, each with a problem (4 problems). But they're the same problem, so you only have one problem to fix. You could in fact solve the one problem, then charge each individually for the fix (sort of what David suggested).

But you don't want to do that, so what do you do?

Tell them you'll fix the one common, base problem for all of them and they can split the costs. Sounds like you've already done that on they're on board. That's the first part of the scope - fixing the one part that's common to all of them. This is the Fixed Scope. You know what it will take, and what has to be done for all 4, and you include only those changes that apply to all 4.

Project 2: Then the second part of the scope - individual customization. The first, common part of the problem has been fixed, and they've shared the cost equally (at a huge discount were they to do it separately). That was one cost. Now the group project is over, and you deal with each separately on their individual customization, with each paying for what they want.

At this point they can ask for whatever they want and you can deliver as they're paying for it, and it doesn't affect your other clients. And no matter what they ask for, it's still cheaper than if you had handled the clients individually and charged them each for the fix.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.