There’s 5 distinct phases of any software project:
Your ability to navigate all of these successfully will determine the level of success of your overall project.
Also known as the Pre-Procurement or “Bid” phase, this is when you’re looking for a developer (individual or team) to work on your project.
In order to identify the right candidate for your project, you should start with the following questions:
- How long have they been in business? (If a company) How much work experience do they have? (if an individual)
- What tangible success stories do they have of products brought to market or other relevant work?
- Can the business/individual deliver the needed continuum of services, ranging from developing high-level requirements to working on the individual components to developing a complete product and transitioning it to production?
- Does the business/individual have a proven track record of delivering items similar to what will be required in this scope?
- If a business: Will senior staff be assigned to the project? If not, why not?
- Who specifically will be responsible for the success of your project?
- Does the business/individual have a defined, proven process for project management and customer communication?
- Does the business/individual have dedicated test personnel and defined test processes?
- If a business: Is the engineering team sufficiently deep that you are not relying on key individuals?
- Is the business/individual experienced with and knowledgeable in your software and/or hardware technologies?
You really need to do your homework at this phase to ensure that whomever you are working with, whether it is a team or an individual, is successful and reputable enough to be in business with.
In order to do that, you will need to ask for references. You will need to check them, thoroughly. Part of that process will be to check out their tangible goods – if they don’t have any to show you, then find out the reason for that, and make a determination on how to move forward.
It is a good idea to create a screening test (in addition to all of this) – an App Challenge that will test an applicant or team’s ability to use the frameworks available.
And most of all, if you find you are not able to evaluate the team properly, find someone you trust who is.
Once you have settled on who will be undertaking your project, you’re still not in the clear to start development.
Here is the contract phase, which is arguably the most important part of the entire process as far as getting things done.
Your contract will define how you and the developer work together for the course of the project – how things are to be done, what you can expect from them, and what they can expect from you. If this is not done properly, you can end up back at square one.
A clearly defined contract should contain:
- Product Scope
- Product Roadmap
- Payment Arrangements
- Project Handover
- Ownership Rights
- Dispute Resolution
This section is a a very detailed description of what you want developed. If you haven’t got this, you shouldn’t be at this point.
It should contain, at minimum:
A short, bulleted list of key features your project must have in order to be considered an MVP.
A list of optional features that would further differentiate your project from others. These should be listed in order of your priority, but the developer has discretion to work with you to determine which of these are feasible to include in the agreed upon timeline/budget.
Examples of any similar projects that you like with the descriptions of what you like about them so that the developer can better understand your style.
This is, in essence the timeline in which a project must be completed. It should be agreed upon and set into the contract or the contract may be deemed unenforceable (which can end up to be quite costly for the company who wants development done.)
How do you propose to pay for the work? Is there a fixed cost, or are you paying for Time & Material? If Time and Material, costs may skyrocket the longer a project goes on, as you’ll receive larger and larger bills. With Fixed-Cost, you need to be entirely sure what you’re getting for your cost.
Additionally, are you paying upfront, in milestones, or via escrow?
And how will they receive payment?
This all needs to be written down and agreed to before the first payment is made.
Once you have clearly defined what “deliverable” is you are receiving, you need to know how you will receive it. Are there physical goods that need to be transferred? Is there training involved? Will there be documentation or a product manual? When/how will transfer take place? Define what you are getting when the project is complete so there will be no questions.
Along those lines, determine who holds the copyright/patents and any other applicable rights to your product. You may restrict or specify any third-party or open-source materials to be used, as well as create something like ownership of any new processes that the development team developed as a result of working on your project remain with them while the resulting project itself is yours.
Stuff happens. Companies stop paying their contractors, and even the best contractors randomly disappear. Some developers put in things called kill-switches to their software to hold code hostage to protect themselves –
Put it in the contract that they can’t do that, and also add in arbitration agreements that will protect *both* of you.
This is pretty Standard – you want a non-disclosure agreement because someone outside your company is working on your proprietary stuff.
Now you’re at the development stage and everything’s awesome! You have found an amazing team and a great, binding contract that set out everything ahead of time – except you still have no idea what is going on.
Here’s where a lot of people get into trouble:
If you aren’t a technical project manager, or someone who understands software development, you will have trouble managing this type of project. Even the best laid out project needs someone to keep on top of it from your side.
Developers will ask questions. You need to answer them (or have someone who does.)
You need to make decisions when they ask, and also realize that as the project’s “boss”, what you say has a lot of weight. If you tell them something, they’ll scramble to change everything they’ve been doing so that they can develop feature you mentioned as an offhanded comment.
Make sure you have someone as a cushion between you and your developers who knows how to run a project and keep everything on track, or expect it to go wildly off course and way over budget.
Here is the first really fun part of the whole process – Usability Testing! Once you have a first version and you get to try out your initial design and share it with others, you will have some fun come up with new ways to improve upon it in ways you never considered before.
Also, you’ll find bugs. Lots of them.
Squashing them is kinda fun – no, really 🙂
It is not at all uncommon to see contracts written with up to 25% of their time spent on QA/Revisions, because this is really a huge part of it.
You’re done. After all that work its kind of anticlimactic to just have a handover and release your project into the world.
Usually, you immediately start working on the next thing. Only now, you have someone trusted to work with, so you can skip straight to part 2.
Originally Posted: https://www.quora.com/What-are-best-practices-for-successfully-contracting-out-software-engineering-work-How-do-you-communicate-requirements-assess-if-theyre-good-manage-the-relationship-and-so-on
Originally Posted On: 2016-03-07