Either as a freelance developer or a small team that already calls itself an agency you’ve probably came across projects that you think are either too big or too challenging to take on.
As with all big projects you know the key lies in chunking it down to manageable bits and pieces but you may well there are simply too many moving parts and areas where you lack the needed expertise.
Or you may simply just be interested or curious on how you could start tackling bigger Web projects and increase your bottom line.
A few years ago I was lucky enough to have been involved in the development of Observador, a digital newspaper in Portugal. At the time me and another developer from my team were part of the team that had been assembled to show WordPress was a viable CMS for this client, and we only had a few weeks to do it.
We were part of a larger team that was composed of developers from other companies, freelancers and the internal newsroom staff. I was far from guessing this experience would affect so much of my life in the coming years. The fact that the project was a significant success meant we now had access to a handful of new opportunities. We saw an increase in leads and sales and ultimately the size and complexity of what clients were now asking us to do increased as well.
We ended up landing the development of ECO.pt, another digital newspaper and working with a team of 12 to deliver an outstanding product to market, soon to receive millions of monthly page views.
We quickly realised we had shifted gears and that we would need to partner up rather than hiring and training because we didn’t have the time nor we wanted to increase our fixed costs/risk too much.
But it was no easy task. Uncertainty was huge. The client was starting from scratch, didn’t had a name, a brand, a product or anything.
We didn’t know how to estimate and price the project nor how/when we could deliver it. But it was in this environment that we faced our fear of tackling such a big project and started asking “what will happen if it goes well” rather than “what may go wrong”.
I mean a lot of things could go wrong of course, e.g. the client not paying us, we not being able to deliver something relevant to the market, biding the project too short, not delivering on-time, etc.
But the reality also meant that if we succeeded this would be another cornerstone project for us and attract even bigger projects. So we decided to go for it and not quitting whatever happened in the end. It was also with that commitment that we derived the rules and the principles of the P.R.O.C.E.S.S. System, a system that helps small teams being able to tackle larger projects without breaking the bank and going on a hiring spree and also competing with the giant software companies that normally win this type of projects.
ECO is a finance economy focused newspaper that raised 1.5M of investment from 15+ investors. When ECO first approached us they had essentially 3 goals: to impact the market with a differentiated product, to create a lasting brand in the journalism space and innovate in terms of Web and mobile.
Our response to such goals was based around Geoffrey A. Moore’s “Escape Velocity” 3 main vectors: Productivity, Neutralisation and Differentiation.
Productivity – Everything that could contribute to the newsroom day to day to run smoothly and fast.
Neutralisation – Doing what our readers already expected from us.
Differentiation – Doing what differentiates us.
So the first thing that happens on a large project is that you start to identify all the big things you (and your team) will have to work on.
For ECO these were mobile native apps, different types of articles, etc.
However when we started thinking more about it we quickly realised that there were a lot more mini-systems, decisions and bolts and pieces that had to be figured out. Instead of trying to figure everything upfront and get overwhelmed we decided to start with the team instead.
Do you know a sky fall can be made by up to 500 or more individual contractors?
Going into ECO we had the following key areas of responsibility:
Web Development, Mobile Development, Architecture, Infrastructure & Devops
Based on that we assembled a team that had multiple roles that fitted into each area. Because we follow Agile we also had a Product Owner and a Scrum Master to help steer the project and interface with the client / protect the team.
Although I was the one assembling the team I didn’t put myself as Product Owner or Scrum Master (normally the roles assumed by how is leading the project) because I knew better equipped people for these roles. It is essential to know your strengths and weaknesses and put the right people in the key positions.
Another point is in partnerships. Our PO was from a partner company. Our lead designer as well and the mobile team and Web had partner developers besides our own. That is in fact the first step that will allow you to tackle bigger projects: making alliances with partners to create a kickass team.
If you’re used to work with partner companies on projects this may not be a challenge but for most teams you will probably need to stretch out of your comfort zone. Here is some advice on finding the right partnerships:
– Look for companies/people where you already have some relationship capital;
– Understand the spirit of partnerships: more than once we had companies that wanted to partner up but weren’t willing to be transparent around who the client was, how much they were thinking in charging or asking us that we sign that we would never feature this work in our portfolio. True partnerships must entail transparency, high communication and trust and also high performance so that everybody wins.
– Don’t rely on legal documents but still make sure to document everything around the expectations and what has been agreed and by when.
