In part one of this series, we proposed two situations that are occurring in this tough economy:
- Startups with experienced founders and a strong product idea for a new software application but limited funds and time to build a team.
- ISVs with existing software products who are faced with dwindling sales, lowered product development budgets and increased pressure to roll out new versions and extensions for their product line.
We posed outsourced product development (OPD) as one possible solution, but also exposed a few of significant risks involved. So what issues do you have to consider when judging OPD vendors?
According to the CTO forum – one of the biggest concerns is intellectual property (IP) security. The second is that when engaging an “end-to-end” consultancy that also provides software development, product development may not be a core practice within their services.
I would say there should be several other concerns that are generally only exposed by actually going down the OPD road. IP security and practice development are certainly important. Covering those questions first, what would an experienced product manager would also consider before engaging an OPD vendor? -
- Is IP security sufficiently covered in both national laws and treaties? Is it covered in the standard contractual language found in the vendor’s agreements? Do the vendor’s internal development practices reflect the difference between “best practices” – common base elements in code development and outright code copying between customer projects?
- Is the vendor really aware of product development disciplines, aware of best practices as they are applied to software products, and able to work collaboratively with the in-house team? More than that – in the current economy – can the vendor approach the project collaboratively using Agile techniques so that results can be seen early and judged before the project goes too far off track? This applies across the entire product development cycle. Agile techniques provide early prototyping, clear identification of in-house “product owners” and validation of concepts at points where they can be assessed against the product requirements and roadmap.
- Is the vendor’s team stable, experienced and available? Can you interview proposed team members? Are their language skills and understanding of your business culture up to your standards? Many times proposals are sent with a pile of “representative resumes” which may or may not actually represent the team offered when the contract is signed. Can you specify a dedicated team that will be available for on-going work, enhancements, bug fixes, and maintenance? Switching team members in mid-stream is sometimes more difficult to hand with remote teams than it is with in-house.
- What is their QA and release system? If the vendor is handling several projects – test and release may be a very busy asset in the company that is quite separate from development. Understanding the differences between various types of business models (licensed, downloadable, on-demand, etc) and the impact of releases on each time is critical. How are bugs handled? How transparent are their results? How complete is their testing cycle?
- Is collaboration a core value within the team? Does the vendor have the tools, practices and procedures in place to provide the platform necessary for good collaboration?
- How will collaboration actually play out? Typically, offshore that are several time zones away teams will say, “we are working while you are sleeping” which indicates a 24 hour working cycle. But how is collaboration between the remote team and the in-house team really taking place? If it is limited to emails and voice mails the messages can easily end up in a frustrating cycle of cross communication. Many offshore vendors will provide a project manager with overlapping hours for both the in-house team and the remote team. This can still lead to a “telephone game” syndrome where the remote team is never completely “in the loop.” Bringing the remote team or project manager on site for a period of time can be difficult and costly if they are several time zones away, which lowers the value of an outsourced solution. Consideration of a national or nearshore provider should be part of the list to evaluate the approaches to this issue. In full disclosure, Scio is a nearshore provider to the Western hemisphere, but is important consideration none the less. Throwing critical product development work “over the wall” is difficult process to manage well regardless so any improvements that can be made are worth evaluating.
- And in line with evaluation – does the vendor offer a range of engagement options that allow you to both look at your needs in discrete sections and evaluate the team, the approach and deliverables in a way that you can avoid bitting off more than you can chew? If the first response back from a vendor is an end-to-end proposal – are there ways to do shorter, tighter engagements that will allow you to see how the team works and judge if it is a good match? Well-defined, short engagements that will still give you useful deliverables a good way to “move the ball ahead,” avoid risk and get a feeling for what you are getting into.
- Is the development environment open and flexible? If you want your developers to work “side-by-side” with the remote team, can they work and share a common environment and code base? Even if you are not a developer by trade, is the work assignment system open and clear so you can understand what is currently in work and what is in the queue?
- How well versed is the vendor team in the technologies you need to employ? Can they offer a range of approaches with clear value cases for each? If your project involves collaboration with your in-house team, it is critical that the technologies and environments used leverage your teams knowledge base. A good prospect will be clear about their domain and will place boundaries around what is in their sphere and will take more time to work with. Limited experience may not always be a disqualifying factor if the team is aware of their limitations and can take appropriate measures to remediate, but simply indicating “we can do anything” can be dangerous.
- How much attention will your project get from your OPD vendor? If your project requires a team of five or ten, will it be considered a priority with a vendor that has more than 1,000 staff members? Feeling comfortable with the level of interaction you’re going to have with your vendor has a lot to do with how important your project is to them in the “big scheme of things.” If typical team sizes range increments of 10′s or 100′s you have to be concerned about how dedicated your team will actually be.
So – with that insight, is OPD for everyone? No. Does it have any more or less risk than other outsourcing? No. If you understand the risks, you can deal with them by both planning projects properly and selecting the right partner. And in the end, that is the point. An OPD vendor needs to be a team you feel comfortable approaching as a partner. There are many companies today that have only a handful of direct staff members who do quite well with an end-to-end OPD team. They concentrate on their market, sales, customer satisfaction and the leadership of their product development teams – regardless of where they are. They have learned to work fully with product development “in the cloud.”
Useful? Copy, paste and Tweet It!
OPD – Product Development “In the Cloud” http://bit.ly/32P3
Recent Comments