We've been building a CRM for a client. Now that the first major phase has been finished, and a second one agreed upon, the client would like to pick up some of the work, making minor amendments to the database schema and business processes the first phase while we build the second.

I'm undecided whether this is at all practical, but assuming it is, I'd like some pointers on which measures can be taken to make this at all workable. Here's what I've got so far:

  • Until now, the client has mostly seen the project from a user's point of view; clearly, a two-part seminar ought to take place where we introduce him to the inner workings:

    • first, showing the existing database schema and, by way of example, extending it,
    • then, showing some sample code, and writing a new business process for the schema enhancement.
  • The code currently resides in an internal Subversion repository. While we could set up a public one or one on his network (which we can VPN to), I feel a distributed system would work better. I appear to be the only one who feels that way, however, so I could use some good convincing arguments.
  • I'm not sure how to mandate/ensure that code that runs in production is committed. Seems like "x made a critical, undocumented change right before going on vacation; now y's trying to figure out this bug that's been occurring ever since" disasters are inevitable. Ideally, all changes, before deployment, would:

    • be documented in an issue tracking system,
    • occur on a separate testing environment first, and
    • have to pass automated tests.

    Alas, I doubt the discipline for any of those will prevail.

Assume that a plug-in architecture or separate project aren't viable options, because 1) the former doesn't exist, and 2) the latter would prohibit the client from looking at and possibly modifying existing code, an ability I believe he would insist on.

  • 2
    Tell them you need them to play the role of a mushroom. Keep them in the dark and feed them bs.
    – capdragon
    Commented Feb 7, 2012 at 20:08
  • @capdragon I agree, (and so does Mark Whalberg from The Departed)
    – Chani
    Commented Feb 12, 2012 at 16:36
  • 1
    Have you considered the legal aspects of such an arrangement? Who is responsible for maintianing client modified code? Who owns the copyright on the code produced by you and by the client, should you ever want to sell the system or parts of the system to another client?
    – Jaydee
    Commented Feb 14, 2012 at 10:29
  • Yes; the legal aspects are being taken care of. The copyright isn't relevant (or, rather, not an issue specific to this project), as it's customer-specific code, so they own it anyway. Commented Feb 15, 2012 at 17:38

6 Answers 6


This is going to be least favorite answer - but nevertheless here it is!

It is risky (as much as allowing a newbie to drive a brand new car) - but it is not a bad idea.

Understand why they want to do this: it is not that they have spare resources, it is only to make themselves feel under control.

What you need to do is following:

  1. Educate your client - software is more than a code. If they want to participate, let them first review architectural aspects, designs and so on. Raise questions to them and show them the implications of the choices they make a prior.

  2. You should always go back with options about pro/cons on approaches (and document these meetings well) but you should allow them to take on some decision making. At least they will begin to appreciate that they don't know much - or will take ownership on themselves.

  3. You can create separate space - such as branches so that they must be able to code whatever they want - things should be duly tested before commits or merges.

While i know complications might happen, every problem is an opportunity. If all goes well, your client will actually come to more appreciation about internal issues, and will develop a better trust because they know (how) you have done a good job!

PS: To give you an insight - i am from India; and i know great many IT shops where management doesn't really have much clue. They don't usually mind (even feel happy) that client puts additional resources to ensure that project doesn't go in dustbin! This works great for them; they all go with one mindset "Whatever you say sir!". This is not to demean my own countryman - but to show that joint development is not such a bad idea. It is after all, what many management gurus portray is "Prosumer approach" to business problems.


Ouch... You have the right idea but I have seen how messy this can turn out, and both parties suffer considerably. I am maintaining such an application currently.

Find out the real reasons why the client finds it necessary to contribute directly to the project. Is it that they now want the project done faster than you can realistically turn it out? Do they want changes already but are afraid of incurring additional costs from you for making spec changes or requesting additional features? Is there a political struggle in their organization where internal development resources want more control and input in the project or where they are looking for busy work for internal developers? (this last one hits close to home for me)

Find what their true motivations and address them if at all possible. The fact that they even suggest it is a huge warning sign that trouble is coming down the road. Try to alleviate their real concerns before agreeing to such a thing because more than likely what will happen is that they will strongarm control of the project and phase you out, or they will cause massive chaos and a failed project.

EDIT: Unfortunately that ship has sailed for you, but don't despair just yet. There are still things you can do to greatly minimize the pain that will come. No matter what, make absolute sure that their is ONE AND ONLY ONE PROJECT MANAGER and PRODUCT OWNER and that this person is associated with your organization/company. This person must have the ability to plan sprints, include or remove user stories and assign tasks to resources in your company as well as your client's company. Whatever happens, please make sure that development resources at your company do not work seperately from your clients resources and even more importantly DO NOT allow developers in your company to report to their project managers or product owners! They will either take complete advantage of free work not covered by the contract or they will snub you out of your own project. It is a certainty.

  • The first two reasons are likely spot-on, but probably immutable; naturally, there's overhead in collecting change requests, passing them on to us, paying for them, having us do internal testing, then doing some testing of their own. I worry that ship may have already sailed, and thus, I'm more looking for ways to mitigate the problem, hence my question. Commented Feb 7, 2012 at 19:03
  • @SörenKuklau Then I am sorry you have already lost that battle. I am going to edit my answer and provide an alternative.
    – maple_shaft
    Commented Feb 7, 2012 at 19:13
  • I agree, its enough for to client to pay. Actually, charge them extra for any increased participation from their side !
    – Chani
    Commented Feb 12, 2012 at 16:38

From a legal perspective, you're basically asking "What's the best way to ride a donkey blindfolded through a mine field?"

From a programming perspective, I would ask for more information - can what the client is asking for be implemented using some sort of user defined EAV system or with hooks that can be added to the system? Ideally, I'd want to keep the client's code as separate from yours as possible for various reasons.

  • 10
    What's the best way to ride a donkey blindfolded through a mine field? I'd guess the answer is "Drunk!!" Commented Feb 7, 2012 at 18:54
  • 'From a legal perspective, you're basically asking "What's the best way to ride a donkey blindfolded through a mine field?"' The question of responsibility/blame/potential legal issues is an interesting and important one indeed, but not the scope here. Nice metaphor, though. :) As for a plug-in architecture or separate project, see my edit; they aren't realistic prospects. Commented Feb 7, 2012 at 18:56
  • If that is the case, what's wrong with selling the client a source license to the CRM, with a SLA? Commented Feb 7, 2012 at 19:09
  • The client is legally entitled to the code. That's not the issue here; collaboratively working on it is. Commented Feb 7, 2012 at 19:28
  • 1
    If the client is legally entitled to the code, then the best solution is clearly to treat the code as theirs, have them set up version control on their server, and bill any maintenance hourly. Commented Feb 10, 2012 at 21:11

Someone who is usually in the role of the client here chiming in. I honestly wouldn't have this problem because if it got this far you'd be in my source control, using my CI setup and my QA setup to test things. This arrangement can be pretty difficult to setup -- I get lots of pushback from the consultants, especially getting things going. Having process intereferes with billable hours it seems.

I think your perspective is quite honestly a bit skewed. First, keep in mind that it isn't your code base but rather our codebase. Second is that, in most cases, the IT shop on the client side has vastly more motivation to make sure this product works as designed and is easy to maintain, manage and support going forward. Diving back in to fix bugs is not more billable hours to us unlike most consultants. Moreover, building things to be easily configurable and fail in predictable ways are vastly more important when you own the operations side of the coin too. You might just end up with a higher quality project because part of the development staff is not constrained by billable hours.

Insofar as how to make it work, DCVS is definitely the way to go if it can be made to happen. Choosing something neutral (bitbucket, github) can help. Having CI in place is also a godsend here -- harder for things to get out of whack when everyone knows it got out of whack on the last commit. If you can force things to deploy via CI -- something we typically have to force upon vendors -- you can really ensure all changes are committed. Training-wise, have you considered pairing with the client for a few days? That might be a good way to establish the lateral ties you'll need. Overall the best bet is to convince everyone they are on the same team. Because they are on the same team.


Seems like this is a much a management issue as it is a technical issue. I've dealt with situations like this in both consulting and software firms. From an overall "How much value will the customer get out of the software?" and "How much effort will I need to maintain it post-production?" this is actually a good situation for you. Many clients insist on their people being involved. It will take a lot of work though.

Beginning with the end in mind, you will need is a good Statement of Work. This will list what you're on the hook for, and what they're on the hook for. A Roles and Responsibilities matrix is a less legalistic document that describes who owns each item, who is involved, and who just needs to be informed. Both of these assume that you have a well defined Work Breakdown Structure that list at a low level (low enough to estimate) what each task is.

In terms of creation, it's usually the reverse order: Scope (which you clearly already have) -> WBS (which you may have) -> Roles and Responsibilities matrix -> SOW.

Once you have the ownership clearly defined, it's time to manage the code and environments. I am fairly agnostic on code management tools. What I will say is that it's vital to do a code review for everything done by someone outside the core team. If the tool you're using flags this, all the better. You want to avoid someone clamping something on that goes against key architectural decisions previously made. The 4 eyes concept (2 additional eyes reviewing everything) is the single most important tactical decision you can make.

Environments are also painful to manage. Usually I've experienced situations where "We do our work on our environment, when we're done it goes to yours" and both the vendor and client struggle through. Your situation sounds more complex. I'd advise to try and find a way for them to work in your environment until the project is finished. If you can find a way to train the client in managing their environments (don't assume they're good at this) then all the better.

A couple other caveats...

  1. Don't assume the client has the same productivity as your team. (You'll get upwards surprises on domain knowledge, downward surprises on speed specific to your software.)

  2. Don't assume the client knows your methodology.

  3. Don't assume the client shares your team's workethic. (I've seen both upwards and downwards surprises.)

  4. Spend lots of time training and co-locating.

  5. Every hour spend teaching the client to troubleshoot will save many days in the future.

  6. Do utilize the client to work through their internal organization for you, and find experts in content and domain questions.

  7. Do utilize the client to sell train their organization.

  8. By default involving clients in your development process will force you to think like a professional services firm. David Maister wrote the best book on the topic. Even if only 20% is relevant to you, it's worth reading.

Despite all these caveats, including clients in your teams can do wonders to bringing you closer to your buyers. These clients are the ones most likely to be future references. Good luck in making the best of this situation!

  • 1
    I agree, but as for as one of the technical concerns, each organization having their own repository and toolchain is fine, but if that is the route you go with, declaring a 'master' source is crucial: either yours, theirs, or a seperately maintained 'shared master.' Without a 'master' the ability to integrate and piecewise revert will be, not might be, problematic, as OP suspects. A single 'master' repository would simplify mapping tests and defects back to a single source version, instead of having a double mapping first to the master version, and then to each independant, 'local' copy.
    – JustinC
    Commented Feb 15, 2012 at 22:30
  • 1
    There might be political or economic reasons why either side is hesitant to give up control or grant access, but if the goal is to work together, simultaneously, neither side will be effective without first negotiating control. Eg. who is in charge of and caretaker of the master, how are disputes about the master resolved, and how will you transition control from the master back to the client (if you as the contracting firm maintain and control the master).
    – JustinC
    Commented Feb 15, 2012 at 22:39
  • @JustinC - I hear you. One of my projects has half am FTE just keeping two defect repositories in synch.
    – MathAttack
    Commented Feb 16, 2012 at 3:49

Your client should definitely be given a walk-through of how everything is set up, it should have been a requirement for sign off on the first phase. You should push back on allowing your client to edit anything directly, he should fill out a change request that is entered into your issue tracking system and prioritized with the rest of the work. It will be up to you and your client to decide which requests are out of the scope of the contract. How this happens should be designed in some sort of change management workflow/document, if one doesn't exist I highly suggest you create one and get your client to agree that this is the process through which he can change things, and get this in writing. Otherwise there isn't much you can do other than pray nothing goes wrong.

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.