Tough Client Management Situation

Question

Ok here's the story:

I manage a team of 3 developers that have been working on, and recently completed, a 1 1/2 year project for one of our largest clients. The project is a web application written in .NET 3.5 MVC 1.0 SQL 2005.

Their requirements for the program were such that we had to build 10 robust completely ajax controls; one of which is a grid control that sorts, pages, add edit delete (modals with custom validation built in), custom security and actions based on user role and workflow state of each row in the grid, csv upload built in to each grid... the list goes on - and that's just the grid control.

The reason I'm giving so much background is to emphasize the complexity of the system.

Upon completion of the project and launch to live the client has begun sending out RFPs (request for proposal) to us and other contractors to do enhancements on this system, yet we're still expected to support it.

So my questions are:

1. Since I am in charge of estimating these new RFPs, how should I account for the fact that there will be other contractors who probably know nothing about MVC, our security model or how important it is that the integrity the custom controls is maintained?

2. What kind of safeguards should we put in place to keep from being blamed for other contractor blunders?

3. What is the best way to maintain source control?

4. Advice for not going insane over what's going on here! :)

<-- EDIT -->

Let me clarify quickly. I am in charge of estimating the RFP's for my company as a "Contractor" - new title for us I guess. In short, I can't impose a competency test on other contractors since I won't be picking who wins the RFP... it could be us, but it might not.

Contractors will not be working from our source control. We will probably be asked to hand over the source code to our clients at some point.

Answer 1

Talk [to this client] !

Your current engagement, and responsibility with regards to maintaining the current application gives you a reason to have direct, informal, contacts with the client, and hence gather insight into why the non exclusive RFPs, and the root reasons for the improvement requests.
You're not seeking special treatment, w/ regard to the RFPs, just trying to understand the context, and maybe dispel some misunderstanding and/or forewarn about potential pitfalls.

Answer 2

This may just be a business-as-usual formality, than again it may not - offhand:

• first, look at your current contract and see if you are obligated to vet competitors; chances are that this is not part of the original scope-of-work agreement.

• second, respond to the RFP as a sole provider; in other words, phrase the RFP such that you will do what they need for such-and-such a cost etc. but only if your company is the sole provider of such services; if other companies are involved, you are not interested in the project due to the potential liabilities, communication complexities, etc. Lay that part on thick. [IMHO it is foolish to have one company develop a complicated custom solution and then bring in a cut-rate competitor to enhance it unless the original system is so well-documented and self-testing that any barrel of code monkeys could do maintenance on it]

• alternately, you can politely inform the client that you'd be happy to provide a time-and-materials service contract for maintenance and enhancement (again as a sole provider) but are not interested in expending time on a competitive bidding process.

Just one opinion; YMMV ;-)

Answer 3

1. Since I am in charge of estimating these new RFPs, how should I account for the fact that there will be other contractors who probably know nothing about MVC, our security model or how important it is that the integrity the custom controls is maintained? You can put together some form of basic competency test to ensure that the new contractors know what they are doing regarding your components. Those that know more about your base technology should rank higher in the stack of RFPs up for consideration.
2. What kind of safeguards should we put in place to keep from being blamed for other contractor blunders? If you have all your code in source control then it is easy to see who did what (try perforce for total configuration management)
3. What is the best way to maintain source control? I have recently be sold on Perforce as you get total view into who did what and when. Way more control than what you get in SVN, Source Safe, etc.
4. Advice for not going insane over what's going on here! :) Document everything regarding the process. Contracts between you, your developers, the company you are working for, etc. Often times documenting what is not being delivered will help you more than documenting what is being delivered in that it creates talking points around things that might otherwise be assumed to be "included" in the project.

Answer 4

Steven Lowe has some good thoughts. It is possible that you can work something out with the client.

Your job isn't to worry about how other contractors will interface with the code you gave your client, your job is to win the new contract if you decide to bid for it.

If you decide to bid, then the following applies:

Critical to the the process is how much of a chance to do you feel you have of winning? Some organizations put out an RFP even when they expect the current provider to win it because they have contracting rules or laws to follow. If this is the case, likely you still have a pretty good chance of winning. If you believe they did this because they were not happy with your team's current work and want a new group, you have a long way to go to win.

First rule of RFPs is to follow the directions exactly. If they say they want three pages don't give them four. In general when bidding (especially government bids), the bids which do not do everything as exactly as specified get thrown out unread.

Next job is to sell your company. Somewhere in the RFP is a section where you describe the experience of the company - make sure to strongly highlight your company's expertise in developing the system, same when you provide bios of the staff if that is required. In the actual proposed solution part of the RFP, you can use your inside knowledge of how the system currently works to show what you would do to enhance it. Etc. If the client has told you they are unhappy with your product as is or with the delivery of the product, try to include verbiage that shows how you will change to address past problems. I wouldn't do that if they have not expressed this to you but only if you feel that your company is unlikely to win for a specific, expressed reason. Then you need to do something to counteract that perception. For instance, if they felt that there wasn't enough testing, explain the new company testing policy and how it will be documented to the client. If they felt that you were unable to meet deadlines, try to develop a more realistic deadline in the proposal and show how you intend to manage the project to keep it on track.

As far as costing, your people won't have to get up-to-speed to understand the code. That means you should be able to show that you can do the enhancements in fewer hours than your competitors. This is a big plus for your side. Find a way to make that point somewhere in the bid.

Now as far as the maintenance and coordination fo code bases if you do not win the enhancements, that is something you need to work out with the client. If the source code is thiers (which it sounds as if it is), then it is up to them to figure out how to manage it between two vendors. Be cooperative, but it isn't your job to solve that problem for them only to provide the code as agreed to in you current contract. Certainly both groups would need to have source control and that should probably be a client-maintained repository that either group can access. Ask for aplan as to how to determine if something is part of the enhancement contract or system maintenance. It's easy at first, but not so easy the week after the first enhancement goes live. Ask them how they intend to get your maintenance people familiar with the enhancements that they will need to support.

How professionally you behave if you lose the enhancements but continue the maintenance might have a lot of bearing on future work. Graciously giving the other team what they need to do their job will serve you better than being pissy about it. And don't be surprised if the other team hires some of your developers away from you if they win. Likely you will need fewer developers if you lose and, it being a small world, again I would let those people go without fighting it unless you have a really strict non-compete clause in their contracts (even then I would tend to let it go in this case if you lost the contract).

Answer 5

other contractors to do enhancements on this system, yet we're still expected to support it.

Speaking as one who is usually in the role of client in these situations, I would expect you to have language in your existing contracts to limit or remove your support obligations if someone else starts working on the code. If you don't, make sure to add it next time.

Other than that, the advice above is all good.