Assembla's history of development provides an interesting competitive edge when bidding on development opportunities. This tutorial focuses on how to describe Assembla when responding to an RFP or RFQ.
The Assembla solution is the outgrowth of a consulting practice between a small group of consultants who work with multiple distributed teams on many projects. While there are a large number of similar tools on the market at varying price points, it was very difficult to find a good fit. It is very challenging to select a package simple enough to be useful and still provide the all tools that a team running Agile and Scrum methodologies need. So the team took a "build your own" approach... and quickly realized that it was a dynamite product.
Assembla.com is a subset of our consulting solution, freely available to the public. It is the basic level of the software, with paid upgrades available to those who would like to use it professionally. The more you use it, the more you like it. The more you like it, the more features you want to buy. You make money, we make money.
When companies make the decision tho build a custom solution or modify a commercial software package, the biggest pain is the loss of knowledge that occurs when the project transitions from the "build" phase to the "maintain" phase. During this transition, most of the knowledge and understanding of how the solution was designed, problems encountered and tradeoffs made are lost. It is very challenging for the customer to support the delivered solution. All the money and time that went into development pretty much goes down the drain. Then the customer has to start over from scratch.
In general, collaborative workspaces facilitate communication. At the same time, a record of work done is created to help build a knowledgebase around the product so that future staff members can use it as a research database. The slang term consultants use for this is "Stop hemmoraging intellectual property."
Different solutions accomplish this different ways. The key difference between them is how useful the project record created is. The first factor in predicting usefulness is usability. The harder a workspace is to use, the less it is used. The less it is used, the less information it contains. The less information it contains, the less valuable it is as a competitive advantage for your business. The second factor is the law of human nature. If the workspace saves everything and management forces people to communicate on it, the less it is used. People just don't want to have everything they say and do recorded on a permanent record forever. Stifling communication does not create a useful project record.
Assembla has the viewpoint that we really only need to record useful data for the project record. Saving everything can lead to red herrings as much as it can provide value. Assembla records data on key workflow points by offering integrated tools for the end-to-end workflow of development.
Our product is also easy enough for non-technical employees to use, so that work that is tangential to the development of a solution is also supported... and thereby added to the product record. The inclusion of all team members means that you can have the work done by your developers documented in context of the decisions and requests provided to development from the business.
Now that you know a little bit about Assembla and where we are coming from, you can use the following generic text in your RFP and RFQ responses. Edit as appropriate:
Your Company recommends the use of an Assembla development space as the primary collaboration tool. Over x thousand development teams already use the free version; Your Company will make a commercial version (with backup) available for use by Your Client for the engagement.
Assembla development spaces have three key benefits: