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?

Is there a reason why you need to decide on how you are going to present your requirements to the developing organization now, instead of after you have gone through your organization's contracting process and selected a contractor to build the system?
–
Thomas Owens♦Dec 20 '11 at 12:52

@ThomasOwens This is a good point but I am feeling a lot of pressure and stress on this, and I am that mindset when I am stressed that I get the overwhelming desire to take pre-emptive action or else I will end up biting my nails until they bleed. I need to take charge of this because nobody else will but to be honest I would rather just design software, it is orders of magnitude easier and less stressful for me than meeting with stakeholders and gathering requirements. Somebody has to do it though...
–
maple_shaft♦Dec 20 '11 at 13:13

3 Answers
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.

Thats actually a very good idea! If we needed to grow the team quickly we could easily take contractors on full-time. To present this an option do you have any Pro's about going with Consultancy vs. in-house individual contractors? Now that you mention this it is hard to think of any clear ones.
–
maple_shaft♦Dec 20 '11 at 13:39

@maple_shaft lol. I have always heard bad things, and have also had some bad experiences, with the large consultancies ... very expensive and bad code. If someone is freelancing they really do depend on their skillset/professionality being top notch, and of course the worst that can happen is you get rid of them after a week.
–
NimChimpskyDec 20 '11 at 13:46

It's always a trade-off. With a firm, you might give up some aspects of control, but they supply the people, facilities, and technical resources. With in-house contractors, you might save some money, but also need to furnish them with all of the resources they need and spend time/money training them to use your systems. It comes down to how well you vet the people in both instances and what you're willing to give or take on. Both can be equally viable options, assuming you do your due diligance in both cases.
–
Thomas Owens♦Dec 20 '11 at 13:53

1

@ThomasOwens Maybe in-house contractors are a no-brainer for us then, we have over 6 unutilized, fully equipped and wired cubicles just waiting for us to expand. They were prepared for a project that never came to be but are now sitting unused.
–
maple_shaft♦Dec 20 '11 at 13:59

@ThomasOwens This is inaccurate - some companies specifically do not supply their independent contractors with computers, in order to avoid creating the impression of "disguised employment" when tax inspectors come calling. Instead they bring their own laptops.
–
Robin GreenSep 26 '14 at 19:48

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.

Wow, thanks for the complete answer, it eases my mind a bit. I am not worried about the high level requirements, deliverables and purpose, those are well understood. I am hoping the contractor will use Agile processes and will allow me to interact regularly. Regular sprints for us to test in house would be ideal. I would also like to veto certain design decisions if I feel they are wildly offbase. Management of course will expect a fixed deadline with specific deliverables to be completed at a certain date. I will have to make sure their goals and my goals towards maintainability are mitigated
–
maple_shaft♦Dec 20 '11 at 13:36

1

@maple_shaft By structuring your Request for Proposal properly, you can give strong hints at what type of development process should be utilized to ensure the visibility and interaction that you need. Something important to keep in mind is that it's not always about what someone wants, but why they want it - there are almost always alternatives to meet the needs of involved parties in a way that works well for everyone (that's a key component of Principled Negotiation).
–
Thomas Owens♦Dec 20 '11 at 13:44

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.