What was the scope of their involvement?
Our in-house team started the initial work on the web part of the project, and we brought Mercury Development onboard a year later. They initiated the Android, iOS, and desktop work.
The productivity of our engagement with them was reliant on the nature of the consultant team and the capacities of the in-house team. We offer fairly high-level visions and good product management; however, we did not have sophisticated wireframe design capabilities or requirements-gathering and documentation. Mercury has a relatively comprehensive set of skills that can be added in a modular fashion to our own capacity. This made it possible for us to have high-level discussions and explore details, and then the Mercury team fleshed out the remainder of what we needed in more precise terms. When we needed more details from an analysis point of view and wanted to capture additional requirements, they were able to do so. When we provided that information, Mercury Development simply captured and implemented it. We fit together well.
In the middle of the project, we developed an adaptation to a particular deployment in India. In this case, we had a disconnected user base, as opposed to our situation in the US, where people generally are connected to the internet all the time. This meant that we had to design our caching of information in a way that was synchronous and could support an offline situation. That required a thorough analysis of complex synchronization situations, including the ability to create folders and take photos offline, add metadata to them, and synchronize all of this information with the cloud once a connection was present.
We organized our teams by a couple of verticals and horizontals, with a team for each platform, centered on a single language and set of characteristics. These included iOS, Android, Windows desktop, and Mac OS teams, with core engineers who provided the actual implementations for the feature sets (some cross-platform, and some not). Layered on top of this, we had some horizontal groups such as business analysis, which was not platform-specific. For example, some features required analysis specifically in the context of Android versus iOS. The native contacts infrastructure on iOS is fundamentally different than on Android, so, even though the business analysis involves some sort of integration with contacts, the platform-specific integration requires its own analysis based on the platform’s capabilities. In general, an engineering team was in charge of the implementation with several cross-platform layers, including design, analysis, product management, and quality assurance.
At most, we had approximately 30 people from the Mercury group and amongst those 5 teams. Over 3 years, we had the advantage of changing the team sizes, allowing us to balance resources as our business requirements changed. We could add brand-new teams and adjust the velocity of feature production.
In the US, our market was predominantly iOS, as 60% of our customer base used this version of the app. However, in India, the market was 99% Android, which prompted us to build resources according to our business definition.
How did you come to work with Mercury Development?
They were engaged with the company before I joined. I re-engaged them after viewing their previous work. For our first cloud project, there were no other vendors when we made the initial selection, but I did perform a vendor review, using other companies on the market for comparison. I was open about this with Mercury, in terms of ensuring that they offered the highest value and were market-tested.
For our next project, I conducted a 3-vendor comparison prior to selecting or recommending Mercury. This included SOWs [statements of work] and RFPs [requests for proposals] with 2 other stellar vendors.
The vendor-selection process was fairly standard. Certain parts take time and involve some risk. In the current RFP, a point in Mercury’s favor was familiarity. This is an intangible benefit which makes a difference when differentiating between independent contributors. It allows increased efficiency and communication within the team. This is important not only for the engineering groups, but also for the different horizontals such as product management, business analysis, and design.
How much have you invested with Mercury Development?
This is not something I can disclose. There was some fluctuation.
What is the status of this engagement?
We started working with Mercury Development in August 2013. The first version of the mobile application launched within 3 months. From that point, we continuously deployed new features on a 2-week sprint cycle.
Our current project has been running for 2 months, and we have a team size of 7 people. It’s a much smaller-sized project, and I anticipate that it might go on for another 4–5 months.