Back in 2007 we realised that we needed fairly sophisticated and complex technology to run businessbuyguide, a sister brand to G2Guide. With a very small budget and limited time I knew there would be challenges – one option was to hire developers in a lower cost geography. I also knew that the total cost of project delivery through offshore developers was certainly not guaranteed to be lower than onshore.
I knew that cultural differences, different timezones, language usage and general communication norms would be different. Hey, I went to school in 3 countries, I speak 3 languages, I’ve worked professionally in half a dozen countries and managed a team of remote workers covering 12 nationalities. Also, during my 5 years at Gartner I had been exposed to relevant research and had no illusions that going offshore would be some kind of magic bullet.
A For Affordability
We were keen to manage our risks and concluded that we would be more likely to find the most appropriate, affordable and experienced development team in the US. Back then even the exchange rate was firmly in our favour. In fact, after researching dozens of firms, we found a New York based development agency. We had detailed pre-sales discussions and they really seemed to be head and shoulders above their nearest competitor – based on the backgrounds and experience of their development team we knew they would be a good match for our project, despite the timezone difference between the UK and US. We paid a deposit and eagerly awaited the kick-off meeting.
A week later, during that meeting, Harry the project manager (previously a fairly vocal and member of the pre-sales team, with fluent English) seemed like a different person – his English was flawed, he said very little and his US accent seemed to have disappeared. More importantly, this person could not communicate effectively with us. Of course, I knew we had a different person on the conference call.
This US based firm had omitted to tell us that the project would be delivered and managed by their offshore team, based outside the US. After the first few weeks, it became clear that the project manager’s communication style was creating bottlenecks and the account manager became the default go-to person for anything that required a conversation – this created other problems.
Persevere Or Pivot
A month down the line – despite a very clear and detailed specification – we felt we were spending a disproportionate amount of time on communication, with multiple missed delivery dates, a lack of clear updates and no confidence regarding a final completion date, things were going from bad to worse. More than 2 months into what should have been a 2 month build, we knew we knew that the project would fail unless we took drastic action to move things forward. We decided to persevere – we put together a recovery plan to get the project back on track.
Going Agile – First Taste
The recovery plan required a hands on product owner to be available to the development team at all times, across their country timezone. I dropped most of my other responsibilities so that I could work directly with the project manager, nearly full time. My first challenge was to break down all cultural or communications barriers and really get to know the development team and project manager, as people. This really helped to improve communication. Next, I started to use more diagrams and scenarios to collaborate with the development team and project manager and discuss requirements (instead of using the prescriptive approach envisaged by the specification that we had started with). Given the urgency to deliver results, I attended short daily meetings with the developers – my presence at these meetings meant that we could remove any development obstacles and answer questions immediately. Finally, we started to focus the team on discrete sections of work that would make an immediate contribution and and allow us to launch a MVP. Collaboration is the key word here – now we were finally collaborating as a focused and united team.
Our recovery plan started to show early signs of success – later, we would learn that we were applying agile techniques – and we eventually achieved a complete project turnaround. The project was a little late but we got a complete working version of software that met all of our requirements. In fact, to be fair to the development team, we received more features and a better quality product than we had initially specified. After our MVP (minimum viable product) was launched we continued to develop, iterate and refine our offer.
Agile in our DNA
G2Guide matches your project to the most appropriate supplier(s) and provides you with a product manager who makes sure that projects are delivered on time and at an agreed fixed cost.
Agile is at the heart of everything we do.
+44 (0) 203 949 7344