Contracting out software development; deliver user stories or business requirements?

Question

We are a small company that I am lead developer on, and we have been having on and off meetings with a potential stakeholder for a good opportunity. This stakeholder is helping us directly in getting a proposal together to a group of other stakeholders for software that they have a strong need for. Hopefully if we sell them on our proposal (consisting of very high level features and general deliverables) then they will sponsor the project and it will grow organically from there to users around the country who will see how useful it is.

Problem is that we as a development are terribly bogged down as it is with prior projects, maintenance of existing production systems, and badly needed features on the backlog. As it stands, because this project could be highly lucrative and there are no serious competitors, management wants to act FAST and get the most basic functionality out as quickly as possible, no matter the cost.

This isn't realistic for us without growing our team but that takes too much time. They are thinking about contracting the development work out, but want me to be a business analyst and also have architectural say in the project. When they finish major feature development, they anticipate my team taking responsibility over maintenance so clearly architectural control is important as we want the deliverables to be maintainable.

I am okay with this role, but am unaccustomed to it. In house we typically don't use formalized requirements documents, and instead gather requirements from user stories, use cases, workflows and customer agreements. We are used to formulating user stories but I am afraid that doesn't make sense to deliver user stories to an outside contract company as they will likely have their own project managment who might want to do things their way. I wouldn't want to impose our unfamiliar project managment process on them if they find it alien and it slows them down.

I am thinking that extremely detailed formalized business requirements are in order because we want to be sure that they have the necessary guidelines to create quality software, but I have no idea what kind of effort this will take from myself alone. I am also unsure of when to start. Nothing is official yet, but I have 90% of the information I feel I need from stakeholders. I just don't want to end up with management informing me that the deal was signed, we have to deliver in 6 months and to get him all the requirements documents by the end of the week.

Feeling a little in over my head here, do I formulate user stories or business requirements? Any other helpful suggestions?

Answer 1

Rather than determining how you are going to present your requirements, first focus on finding someone to build the system, preferably within the cost and schedule that is acceptable to your organization. The process should start with the creation of a high level overview that outlines the goals of the project, background and motivations, high level requirements, specifies exactly what is in scope and out of scope, and the required deliverables. At the same time as this is happening, legal would also be involved to determine intellectual property ownership, NDAs, any kind of regulatory compliance needed by the subcontractor, and so on. Both documents would be made available to the potential contractors to provide the information needed to build a proposal that addresses schedule, budget, resources, and even some risks.

At this point, it becomes a negotiation. You might get a series of costs or schedules that are out of line for your expectations, at which point you might need to revisit what you are willing to invest or reduce the size and scope of the project. There might be other questions from potential contractors that need to be answered for them to provide information. There's a back-and-forth period here to iron out a few more of the details that are needed to carry out the project. If you've never been involved in a negotiation, I'd highly recommend the books Getting to Yes: Negotiating Agreement Without Giving In and Getting Past No: Negotiating in Difficult Situations.

Based on your criteria, once you have a selected a contractor, the level of involvement depends on what is negotiated. I've personally seen everything from the contractor being a black box that receives requirements and, on a regular basis, ships the requested artifacts and deliverables out the door to the contractor being a glass box with a customer that is always or routinely on site, actively involved in the development process. And there are lots of shades of gray in the middle, with different levels of involvement between the customer and contractor. Ultimately, that depends on the contract and the agreement between the customer (your organization) and the constractor.

Since you mentioned that your organization is going to receive the product and continue maintenance and development on it, I would spend extra time vetting potential contractors on their development process and quality assurance practices. I'd also try to maximize visibility into their process and product throughout the life of the contract so you can spot potential problems early and take corrective action. So you should work with the contracting company to outline your roles and responsibilities to the project as well as their responsibilities to your organization. However, like I said, it's a negotiation, so you might not get 100% of everything you want.

---

Another option would be to hire temporary, in-house contractors, assuming you have the resources for them to work. They would need some kind of lead (which I would assume would be you), computers, build servers, a meeting or collaboration environment, desk space, and so on. Your organization would also have to spend time interviewing candidates and finding people who will work well together and perhaps within your organization. However, it could also lead to full-time employees in the future.

Under this situation, you can dictate the development process and have great control over how things are done. But you also have the costs such as adding people and infrastructure to deal with. It might or might not be more cost-effective, but it might be something to consider, especially if your company might be looking to expand over the course of the project or at its conclusion - you have a few potential future employees working with you.

Answer 2

As a contractor, here's what I think:

First, get to know your contractor. Talk with him a bit, have him talk with your lead developers. They need to assess his skill level and level of intuition. You can't just assume all contractors can be handed requirements, stories, or whatever you have. You've got to figure out what they can do on their own and what they can't.

Don't give out too much work at once. The contractor is unfamiliar with your company and the work should be checked on a bi-weekly or weekly basis if at all possible to make sure it is going in the correct direction.

If this is a from-scratch project, then:

After the first meeting, ask the contractor to develop a very minimal prototype of what you expect. Give him business requirements and don't tie him down too much. You want to see how good the contractor can do on his own. That way when you give him further instructions, you will not be telling him things he already knows and wasting time. Tailor your instructions to the individual that must execute them.

If the project is an existing project that needs changes:

Explain the project from a business perspective. Send him the project, let him set things up. Give him a day or two with it, and set up a meeting. Ask, explain, communicate, get comfortable, build rapport.

Rapport is going to be far more important than any set of project requirements. At the end of the day, your rapport is what's going to get that contractor to fix the project on short notice, or go the extra mile to make sure it's awesome. A cold set of requirements will not give you that.

Once you've gone through the initial stages, hook your contractor up with a lead developer contact who will be his liaison to the company. If he has a question, he can fire it off to him. They should meet weekly. I find Citrix Go-To Meeting is the best solution for this, screen sharing is a must.

Now, that you have established communications, if you want to implement some agile or just hand out bullet lists of desired features, it doesn't really matter. No methodology or system will ever replace the fundamental things humans need and expect.

We are humans first, developers second.

Caution though, this doesn't mean don't send documentation. You'd better send the best darn documentation and project requirements that you can muster. This guy is brand new, and he has to swim now. Make sure to throw a life preserver.

If you do decide to go Agile, I recommend pivotal tracker.

Answer 3

I am afraid that doesn't make sense to deliver user stories to an outside contract company as they will likely have their own project managment who might want to do things their way

You are the client, and you will be paying them ... tell them what they will get. Also, I don't think it is particularly vital what format the requirements are delivered in, any decent developer should be able to work with either.

Personally, I'd think about getting a couple of individual contractors/freelancers in rather than a large consultancy. You may well end up hiring the very people that the consultancy would have hired, it will just be cheaper and you'll have a closer relationship to the developers.