How We Improved Project Predictability by 102% in 9 Months. You Can Fix Your Company, Too - Pt. 1
According to this report by Small Business Trends, more than 50% of small businesses fail in their first 4 years. The leading reason? Incompetence, which basically means failure at applying good internal processes in business. So, what can you do to turn the odds in your favour?
Whether you’re a small business owner or a member of a corporate team, it should all start with this question: have you ever checked how predictable your core business processes are?
We did ask ourselves that question and we weren’t pleased with the result. We were wasting time, money and losing market opportunities as we struggled to deal with project crises. But we fixed this. We’ve managed to increase the predictability of our core processes by 102% in 9 months. We left no stone unturned - we introduced Agile methodologies, used psychology, built our own tools to calculate project KPIs automatically and we even implemented the Fibonacci sequence in our business decisions. Guess what? Our metric it’s still growing.
Yet, it wasn’t easy. We had to figure out how to do it without wasting time and resources. We had to deal with some initial resistance within the team. All in all, the effort we put into increasing our business predictability was absolutely worth it.
In our predictability trilogy, we will show you the process we implemented, the steps that got us there, the tools we use on a daily basis, the goals we set for ourselves, and the next steps we will be taking. We’ll share our story, our thought process, and some advice on how to go through a similar journey at your company.
Predictability in business means being able to correctly estimate how long it will take to complete a project and how risky it is. In the world of software development, this is crucial information for clients as well as software development agencies.
Why predictability is crucial for agencies
- It allows you to plan costs and revenue and thus become a valuable partner for other business entities
- Fewer problems for key stakeholders lead to increased customer happiness and trust
- Predictability is the essence of successful software development processes
- You can make your processes more efficient and have more control over your budget
- You’ll be able to make use of data you already have, so there’ll be less waste in your processes
- It’ll help you get ahead of your competition
Why predictability is crucial for clients
- Clients can develop a precise plan of their business and marketing strategy in advance of the product launch
- Key stakeholders can prepare for the costs of development and won’t be surprised by the sudden need for extra budgeting
- Meeting clients’ expectations helps you build mutual trust, which positively impacts your relationships with the clients
What to expect from this article series
In the first part of the series, we cover the background of this story. We also share our process for introducing a major change to the team, managing employee expectations and resistance, and effective education within a company.
Part 2 covers working with data (lot of business nuts and bolts there), while Part 3 includes our guide for improving predictability and the possible next steps.
As you know, we managed to improve the predictability of our processes by 102% in a short time. Marek Talarczyk, our COO, the co-author of this article and the mastermind behind the process of increasing our predictability, started working at Netguru in May 2016. In January 2017, improving the company and its processes became one of his main focuses. Read on to learn how we accomplished so much so quickly, and why need to to do it.
The Background - Why We Were Obsessed with Predictability
This chart shows the demand for our services over several months, using the number of various services (such as Ruby on Rails development or product design) as they appeared in business opportunities each month. As you can see, we’re observing stable growth, which is no accident. Our increasing predictability has had a direct impact on customer satisfaction, which led to more referrals. These, in turn, have brought about 50% of our new contracts.
We had always known that we wanted to be more predictable, but we had never measured just how predictable we were – we didn’t have the necessary tools, processes, and metrics in place. We used some rough estimates based on experience and intuition. We analysed projects post-factum – after finishing a milestone or AAR (after-action review).
The Netguru Team - Bird’s Eye View
Netguru’s Project Management team consists of a number of talented PMs, all of whom are responsible for several client projects at a time. The structure of the Quality Assurance team is similar – they are a group of QA specialists, and each one of them gets assigned to projects. The Talent team makes sure that the right people get assigned to the right projects.
Other production teams, such as the Technology team or the Project Design team, are somewhat separate. This doesn’t mean we can work in silos. What we need to do is cooperate very closely to achieve success and avoid excessive risk.
Team Feedback - Initial Resistance
From the start, the team were very receptive to Marek’s ideas for improving predictability. We have a very ambitious team that wants to keep improving what we do and how we do it. We recruit this type of people on purpose. Thanks to our iterative Agile work and our good track record, people trust and believe in their leaders at the company.
The first batch of changes – estimations and methodology – was the easiest because the course of action was clear and understandable, and we were sure the changes would help in a quantifiable way. We couldn’t prove the changes would help until we put them into practice and saw tangible results of working with data.
There was some resistance, of course. People dislike change and the difficulty of switching from one toolset to another didn’t exactly help. As soon as Marek introduced his ideas to the PM and QA teams, the very first reaction of every team member was to protect their interests. They asked him: “once we learn to work with data and we have the KPIs, will our performance be measured according to those KPIs?”
A purely natural human reaction. But that’s not what the changes were about at all. We didn’t want to stress people out. The ultimate goal was to predict how our projects will go, not judge anyone based on what we learn. People are naturally afraid that they’ll get in trouble for not meeting expectations. The only way to help the team understand our true intentions was to talk to them - one by one - and let them know we wanted to be better at solving our problems. The efficiency in solving project problems is the only thing with which we measure our team’s performance. Clearly, then, data and KPIs are our friends, and not a danger.
The resistance was also felt on the tool level. We had been working with Salesforce for a long time, but when Marek came to Netguru, no one was using it effectively, because the team hadn’t been shown what the value of the tool was. Eventually, we convinced the team that it was worth it to spend the time and input data into Salesforce. We built a few very useful and PM-friendly features in Salesforce. This way, we debunked the two basic myths: that inputting data into Salesforce benefitted no one, and that it was only useful to our Business Development team. nce the team understood what they were doing and experienced Salesforce’s beneficial impact on their work, they were much more willing to join our cause.
Education - How to Approach Your Team with Changes
In the beginning, we took a soft approach: we began educating the team and encouraged them to be proactive: to raise an issue at the early signs of any apparent dysfunction. The key was to react before the alarms started blaring.
Yet, it wasn’t easy. PMs engaged in one project are not involved deeply in other projects, so it’s difficult for them to judge how other projects are doing. To deal with that, we introduced the Agile review, in which a more experienced PM would “go into” each project and look for possible issues. We expected that introducing the Agile review would be a quick win. We were right, at least in the beginning. The early results were very promising, and the process was embraced by the team. However right now we’re struggling with the natural difficulties caused by introducing such a process. Implementing it has also taken more time than we expected.
Other examples of internal education include: case studies, workshops, and AARs. We try to break out of our silos (of each individual project) and learn from the mistakes of others. We’re redistributing knowledge within the company.
Part 1 Conclusions
In this first episode of our three-part article series, we talked about how important it is to properly predict your business processes and shared our experiences and advice on introducing a major change to your company. Part 2 covers working with data and measuring progress efficiently, while Part 3 is our guide for improving predictability in your company.
