“A concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.”
There typically isn’t a silver bullet to solve all problems. As the saying goes, if all you have is a hammer then everything looks like a nail. It’s important to approach every problem with an open mind so you can choose the best fit tool for the job.
“One of the consequences of centralised governance is the tendency to standardise on single technology platforms. Experience shows that this approach is constricting – not every problem is a nail and not every solution a hammer. We prefer using the right tool for the job and while monolithic applications can take advantage of different languages to a certain extent, it isn’t that common.”
– Martin Fowler, “Microservices“
The project based funding model has been around for a long time and is an important part of the project management discipline. But while the project based funding model certainly has its uses, the dedicated product team model has a number of advantages in the area of product development. One of the main benefits is that it maintains team continuity, which is extremely important to turn knowledge and experience into successful product.
In a post on the Silicon Valley Product Group blog, Marty Cagan argues against the project based funding model for product development and explains the advantages of the dedicated product team model.
There are three fatal problems with the project-based funding model:
- You very likely have no real clue when you propose a project for funding if you should really even be pursuing the project. Even though you might pretend otherwise with a cleverly crafted “business case” the truth is that you probably have no real evidence if your customers are going to like this, and you probably also have no real idea how much it will cost to build (because at the project proposal stage, you don’t even know what “it” is). So you don’t know the revenue and you don’t know the required investment, so of course the ROI estimate is less than meaningful.
- Creating strong products is not a series of projects that come in sporadic bursts of a few months each over several years. Strong products result from getting your concept in front of customers and rapidly and continuously learning and improving. Further, to make this progress, you need not just continuity of investment, but also continuity of the team.
- Very often in good product work we find that our initial ideas are not quite right but if we change direction somewhat, which we call a “pivot,” we can often uncover major new sources of revenue. These are the very sources of revenue that companies depend on for another several years of rapid growth. However, with project-based funding, the consequence is that this sort of pivot is effectively discouraged.
You can find the article on the Silicon Valley Product Group blog here: Project-based Funding
Incidentally, Marty has also written a great book about developing great products that I highly recommend. The book is titled Inspired: How To Create Products Customers Love.
I enjoyed this “trailer” for the Mars Curiosity landing and the demonstration that great achievements can occur through teamwork and ingenuity.
Quality attributes such as performance and scalability are among the attributes determined during architectural definition.
Whether or not a system will be able to exhibit its desired (or required) quality attributes is largely determined by the time the architecture is chosen.
– P. C. Clements and L. M. Northrup, “Software Architecture: An Executive Overview,” Technical Report No. CMU/SEI-96-TR-003, Carnegie Mellon University, Pittsburgh, PA, February, 1996.
I’ve been reading some thoughts on the future of television recently, which I’ve linked to inline below.
It will be interesting to see if we’ll have the ability to pay for television content and sources ala carte (The Unbundling of Media via David Pakman), though I do think we’ll end up eventually using broadcast primarily for live events and the internet for on demand shows and movies (How Netflix is Hurting YouTube via Mark Cuban).
For those who think all content will be eventually distributed over the internet, it may happen sometime in the future but probably not any time soon. It doesn’t seem to be cost effective at this point, as supporting the number of content streams would require major infrastructure build out and the bandwidth is already available via the pre-existing broadcast systems (Think the Internet Will Replace Cable? Read this first via Mark Cuban).
Since I’ve worked with an outsourcing vendor in the past, I’m often asked questions by those who are interested in learning more about outsourcing product development. One of the questions that often comes up is how you can ensure that your effort to outsource product development will be successful. The answer to this is in understanding your goals and the capabilities of the partner to help you meet those goals.
As with any partnership, compatibility is very important. The first step to ensure compatibility is to understand what your short and long term goals are. Is this simply augmenting resources for a short period of time to get a product out the door? Or is this a multi-year relationship with a goal to reduce operating costs? Both? It’s important for you to understand what your goals are, as working with a partner who has conflicting goals is doomed to be a miserable experience.
Once there are agreed upon goals, the next thing you’ll need to do is select the development partner who will help you meet those goals. You want to make sure that the partner is a fit, which can be done by putting together a list of criteria that will help you assess this. By having this criteria, you’ll at least ensure you’re doing your due diligence to find out as much information as possible for the most compatible partner in all aspects of your business.
Here’s a list of selection criteria I’ve used in the past (in no particular order):
- Communication: The partner development team needs to be able to communicate clearly and articulately, through both written and verbal means. Project and other meetings should be during normal work hours (ideally), and you need to have an understanding of the method of communication (teleconference, video conferencing, etc.), frequency, and proficiency in the native language of the development team (how easy will it be to communicate with the core development team?).
- Onshore Alignment: Are they willing to spend time onshore with the team to understand the project and our development? This is key in reducing miscommunication early in the project.
- Infrastructure: The infrastructure of the partner company has to be mature enough and stable to support your development efforts (what is this company’s experience in this area of setup?). This includes internet connectivity, VPN, and telephony services.
- Cultural Differences: There should be some type of awareness of this by the partner company. What are the cultural differences? Is it compatible with your organization or will it negatively impact your projects?
- Software Development Process: This is the maturity level of the software development process (including testing). Is it documented? Is it repeatable? How will development and testing be transitioned back within the onshore team (if needed)? Can they align with your process?
- Individual Contributor Knowledge & Skill Level: Your partner must have the right level of knowledge and experience for the individual contributors. Can you interview their people to make this assessment (Development, QA, and Program Management)? Are they willing to pass a technical challenge to assess this or take on a smaller trial project?
- Staffing Time: What is average time to staff a team when it is needed? You need to know the number of contributors available at any time to be “called up.”
- Performance Issues: How are performance issues handled? Can you turn away individuals who are not performing up to expectations?
- Management of Engagement: How is management of the project (and overall engagement) structured? Is it inline with what your group needs?
- Project Monitoring and Controlling: How will you have “checks and balances” of the offshore Project Manager? What processes are in place for guiding on time/on budget delivery?
- Employee Turnover and Motivation: What is the level of employee turnover (any guarantees against employee loss)? You will probably want to build knowledge within the offshore team, and if team members are constantly changing assignments this will not happen. How are these individuals motivated? Is it inline with your group?
- IP protection: Security for your work. How can you be assured that your development efforts will be secured? What kind of infrastructure security does the partner have (keycard access to only necessary employees, physical separation from other operations, 24 hour security guards)? Security process?
- Business Measurement: What measurement and metrics will be used to ensure alignment with your goals? What is the number and percentage of successful projects on time and budget? How much money is typically saved?
- Resource Costs: What is the cost of resources based on skill and experience level. Is there a rate card?
- Similar Projects Success: What other companies has this vendor delivered for? Are the projects similar in scope and complexity?
- General Engagement/Project Size: How big is the usual engagement? What is the general project size?
By understanding your goals and assessing how a vendor can help you meet those goals, you’ll give yourself the best chance of having a successful partnership in outsourcing your product development.