One process to rule all projects
“We’re not doing anything fancy here, we’re gonna use our CMS platform, we’re hiring a freelancer to do it and that’s it. Period.”
Once upon a time there was this project. I had overheard about it in water cooler conversations. Something to do with HR, some kind of refurbishment in our careers page. It was supposed to boost our hiring pace.
The opening paragraph were the very first “official” words anyone gave me about it. A few weeks later, that was announced as the most important project we had for the last two months of 2017. And oh, by the way, we had two weeks to deliver it.
This is a convoluted plot, full of twists and revelations. Let me tell you how we learned (in 4 hard lessons) to never again have a project skipping our process.
One: Involve people as early as possible
The first mistake we did was not giving enough attention to this project. We just thought: “It’s just a job listings page, what do we care? Make it a HTML page and we’re good to go. No tech support needed”.
As a company, we failed to ask ourselves the most basic questions. What is our goal with this project? Who are the business stakeholders here? How are they going to operate this? Do they know this is coming? What outcome do we expect? How do we measure success in this project? What’s the impact in our hiring strategy? When do we kick it off? If we don’t need tech, then who’s gonna do it? If we do need tech, what’s their angle on this? Can we actually deliver it in 2 weeks? Who gave this 2 weeks estimate?
Two: Plan all projects the same way
You already know who should implement this project, a freelancer.
Why? For starters, we had pretty important projects running in parallel, and, strange as it sounds, we didn’t have people available to work on the most important project.
Why didn’t we have people available? Since we kept this project under the hood, it didn’t go through our regular planning cycle and hence the people who could work on it were already planned for other projects.
“Oh, relax, how hard could it be to find a freelancer for that? It’s just a simple page on top of our CMS. We’re in Berlin, there are tons of freelancers out there. We have a lot of contacts, in a week or so we should have someone.”
In a week or so we figured out it wasn’t easy at all to find people with experience in our CMS. The ones we found that said they could do the job, didn’t exactly exhale confidence and knowledge.
That’s when we realized we needed to go back to square one. We asked ourselves the questions we missed the first time, chose a tech stack that would not only match what our teams were doing but also make it so much easier to find a freelancer, came up with a very basic, crude and rough outline of what needed to be done and got to the conclusion that 2 weeks weren’t even close to be enough, we needed at least the double.
Three: Measure what you outsource
You have a freelancer that was highly recommended by one of your most senior developers. When you say code coverage should be at least 80% he laughs at you and says he’s gonna pursue at least 95%. Two weeks is all he has available to work on that, but it should be enough. What do you do? Give him a contract that just says “I’ll pay you X euros per hour to do whatever you want, as long as it runs”, right? That’s exactly what we did.
Once again, we rushed things through and didn’t put any kind of obligations in the contract. We didn’t establish any quality metrics. No test coverage, no performance, no cyclomatic complexity, no tool to measure it, nothing. We forgot about rework or minor fixes to misunderstood requirements. Damn, we barely had properly documented requirements.
And of course some of it went wrong. Yes, the solution ran. But the code was much more complex than it needed to be. Things that were agreed upon the kick-off meeting were forgotten. Code coverage? According to our freelancer, he decided to be “smart” about it and only cover the things that mattered — without asking our opinion about what “smart” or “matter” mean, of course.
After two weeks, we ended up paying a lot of money for a solution that did most of the job, but wasn’t quite what we needed.
Four: Plan for delays
It was a very interesting time to be working at Outfittery. A lot of things going on at the same time.
After careers page, we had other projects on the pipeline. Also bound to important business metrics. But we have limited resources, as everyone else. And of course we were counting on people being available at a certain point in time to work on the next high prio project.
But with so many problems to release our careers page, we had to shift people around to make it go live. And you can already guess what happened to the next project: less people to work on it, delay on its planned date, etc.
What have we done about it?
Making mistakes is fine. What you do about it is what really matters.
We don’t water cooler conversations about projects anymore. We just put it through our regular pipeline, have it analyzed and discussed with business stakeholders, someone from Tech involved, eventually do some sketches to have a rough idea of what a project is about and what are the angles to be covered.
Neither we decide on a tech stack before involving Tech. There always are many options to how implement something, we have become more careful in deciding which way to take based on the specifics of the project at hand.
On the other hand, we haven’t tried outsourcing anything else yet. We’re not even sure if we want to do it. But if we ever do it, we should definitely establish how we’re going to measure how well our money was spent.
Oh, by the way
Have you checked out our careers page already? It’s super cool! https://www.outfittery.com/jobs/
