What is the best way to allow a client to contribute to a project?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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!

Answer 6

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.