Written for Silicon Prairie News (http://www.siliconprairienews.com/2013/12/10-steps-to-getting-the-most-out-of-external-development)
For more than two years, I’ve consulted with more than 35 different organizations around the country on various software projects. These organizations have had very different development needs. Some of them were just an idea a solo entrepreneur was trying hard to get off the ground without any funding at all, while others were for Fortune 500 companies with a lot of experience working with outside developers and agencies.
Through my participation in these projects, I’ve learned a lot about how to effectively manage a development project when you’re contracting to a developer or a development team that’s not internal, and more importantly, how not to manage such a relationship.
Here’s what I’ve learned:
1. Have a clear idea of what you want
The first step before engaging with any developer or development agency is to develop a clear idea in your mind about the product or service you’re trying to develop. It’s important to be able to present a very quick summary of what you’re working on, yet at the same time being prepared to delve into the nitty-gritty of any individual section.
2. Think through special/edge cases
Solutions to whatever problem you’re solving are not usually a straight line. Have you walked through all possible scenarios and figured out how the system will react? Have you thought about invalid situations, when the user provides incorrect input or misses a step?
3. Develop a comprehensive requirements document
This is an important step a lot of people seem to ignore. Being able to articulate your concept and present it in written form is not only essential to the developer(s), but also helpful to understand your own product as well. This can be in one or more of many forms: user stories, “system shalls,” wireframes, etc.
In any event, it’s very important to ensure this document covers the purpose and scope of your product or service, identifies the user demographics, elaborately presents functional and non-functional requirements, and identifies all assumptions and constraints. An ideal requirements document also includes a proposed timeline with appropriate milestones, a testing plan and anything else you might think is helpful for the team to be aware of.
This is the single-most valuable resource for your development team, internal or external.
It’s also essential to remember this is continuously a work in progress, and will be revised as additional information becomes available. It’s not a big deal to change it as long as proper procedures are followed, but the earlier the changes happen, the better and cheaper it is.
4. Research several companies
Identify their strengths and weaknesses. Ask about their core areas of expertise and request to see work samples. Learn about how they approach software development. Are they fans of a particular software-development process methodology? Have they used their recommended process on previous projects? What were some of the biggest challenges? Figure out what kind of software consulting firm they are.
5. Know your expectations and learn about theirs
￼Before signing a contract with a company, state your expectations about the project precisely. What is your criteria for a successful project? How much wiggle room is there with the timeline? How often do you expect status reports? Who will be your point of contact? How soon can you expect a response to an e-mail sent to this point of contact? Do you expect them to comment the code in a certain manner or maintain a development log documenting technical decisions?
It’s also important that you ask what their expectations are from you. Do they expect you to be at bi-weekly scrum meetings? What kind of deliverables are required out of you to keep a smooth flow going? Are they developing a throw-away prototype for an MVP in an effort to get it done quick, or is this going into the final product?
6. Define the scope of each phase of the project well
It’s important to have the scope of each phase of the overall project defined precisely, and this is often dictated by other factors. What would the stakeholders (potential/existing customers) most want to see earliest? Sometimes the marketing plan dictates this to some extent as well. Also, sometimes two or more different entities work on a project. Maybe there’s a creative/digital agency developing the user experience and a back-end development firm working on the business logic. In such instances, it’s important for the client to identify in precise terms the scope of each of those sub-modules of the project.
7. For existing projects, make sure the team knows all the assumptions made by the previous developer(s)
Although starting a project from scratch is every developers’ dream, that’s often not the case. In such instances, it’s important for the new development team to be aware of the technical assumptions made by the previous team(s). This reduces ramp-up time for the new team and greatly diminishes the risks associated with the project.
8. Find a technical mentor not associated with the development company
If you’re not very technical yourself, it’s very advantageous for you to have a technical mentor you can bounce ideas off of. Sometimes, when the development team presents you with a few technical options that will achieve your desired goal, it’s a good idea to sit down with your mentor and discuss these so you have a different and perhaps more educated perspective guiding your decision.
9. R&D is more expensive than engineering
If your product or service requires original research and development, it’s going to take longer than an engineering solution that relies on existing research. R&D involves multiple cycles of hypothesis and exploration; design, development and testing; implementation and improvisation; and dealing with a lot more uncertainty.
10. Notify of changes to the requirements, scope or timeline immediately
From a developers perspective, it’s always better to know immediately of any changes to the project sooner rather than later. The sooner a change is identified, the cost to deal with the change can be remarkably minimized.