Let’s do a deep dive into the table below. Let’s assume you are a CEO or manager of a company (it could be a TelCo, a large bank, or a small company) and you want to build a new product. You hire a development company to do this work for you and you sign a contract with this company. This is how most companies do since in-house teams are considered expensive to maintain. A lot of foreign companies use this approach as well. Accenture is a 178 billion $ company and its core business is to build products for other companies. So, what type of contract should you use if you want Accenture or a similar outsourced company to build a product for you? Fixed, open, partially fixed? What should be fixed? Let’s look at the table:
This type of setup is used to reduce the risk. By fixing the price, scope & time of product development you know exactly what you will get, for what price, and time. The company building the product for you is also sure that they will get a certain profit for their time. Most companies, advertising agencies, and especially government work with this type of contract. You know what you get and for what price.
But is it true that you reduce the risk? Let’s look into this. Several problems arise from fixing price, scope, and time.
First, if we are building something innovative (at least for the company) we don’t know exactly how much time it will take – we have not done it before. If we set a deadline, it probably means the team will not deliver on time. Usually, that’s exactly the case because a deadline is not an extra employee and it’s also not the knowledge that can help to finish work faster. We use it, because we assume that without it the team will not try its best to deliver the project and will postpone it. But is that the best way to make sure the team is productive?
There are actually significant downsides to having a deadline. It increases the chance that the team will reduce the quality to make it in time. Or maybe they will boost the price and deadline of the contract to include a safety margin – extra time if things go wrong (and they most likely will), but it’s a margin you as a business owner have to pay for and you have no idea how big the margin is because the contractor says there is none. So, fixing the time can actually create harm to the business.
Do we gain some risk reduction or other benefits from fixing the scope? Yes, we know exactly what we will get by the end of the deadline so that’s some comfort to the CEO, but are we sure that’s the right product for the right market? Is our research on customer needs precise enough to predict what a new and unique product should look like? And do our customers themselves know if our product will solve their problems before trying the product? Will we be able to reach more of the same customers with the same needs?
Even if that’s the case, are we sure we will be able to build this product as fast as we thought? If we experience delays (which most companies do since we don’t know how much time innovation will take) the scope that we are building, might not give the business value we want anymore. If that’s the case we should change the scope, but we can’t - it’s fixed in the contract.
As you see the complex and changing environment we deal with in business and product development means it’s difficult to predict exactly what we should be building in a long term and we should be able to change the scope of the product. That means by trying to reduce the risk and fixing the scope we actually create more risk - we might be building a product without market fit.
What about the price? Can we at least fix that to ensure some protection so that we don’t overspend our budget? As we know, the team will probably delay the work and will not manage it in time – it’s the nature of innovation. If they are forced to meet the time deadline, they could increase their speed as a team and work overtime. But why should they if they are paid the same fixed price for the project? They have no motivation to increase their speed and capabilities to deliver on time, but to avoid penalties and deliver on time they are very likely to reduce the quality. So again, by fixing the price we think we are protecting our business from the risk of not knowing the final price, but we are actually creating a risk of reduced quality or over-exaggerated safety margins included in the price.
This is one of the reasons why the Waterfall approach which relays on a pre-planned scope, price, and time statistically gets ~1.6x worse results than the Agile methodology. Fixing price, time, and scope delays learning and therefore produces worse outcomes. However, this is the most common type of contract used in outsourced product development. Why? Well, most of the outsourced development is done by companies that have enough money to be inefficient. Additionally, for a lot of corporate CEO’s and managers the idea, that you cannot know how much time building something will take, is something difficult to grasp. The job of most managers is to produce results within a certain time and control the execution of work. By fixing the scope, price, and time you get some level of control. However, too much control does not provide enough space for innovation, learning, and discovery of market needs – which leads to mistakes and more cost.
To better understand this concept, let’s give the fixed scope approach some chance. Would opening price help?
Now by being more flexible about the price of the project or in other words the overall cost, we essentially pay more to the team, so that they actually can deliver on time. We still set a time deadline, and the team tries its best, but we see they are not going to make it (because it’s innovation). We are willing to pay the team more to produce more speed if necessary and still manage the scope in time.
Where does this extra speed come from? We pay the contractor more, to get extra people on the team or they work overtime. In any case, they are monetarily incentivized to produce results faster and deliver on time. In real life, it’s unlikely that a company would want to pay for this extra speed of the team. However, if the contractor is doing more work due to the nature of innovation and you don’t pay for it, they will cut corners in quality or hide the safety margin included in the price.
But even if we do pay the team more so they finish the work in time, we still get the same scope. And we still cannot be sure if that’s the product the market needs. It still creates more risk than it solves, but we are now paying more for it. So this approach is also not desirable, but let’s give the idea of fixing the scope one more try.
Now we are essentially giving the team more time to build the product in good quality, but we are not paying for it, since the costs are fixed. Sounds tempting. If it takes more time for the team to finish the work, they do the extra time for free. We just want a good quality product for a certain price.
This is actually better for the contractor than a fixed time, price and scope contract as they at least don’t have to worry about the deadline and penalties. They will produce a better product this way without stressing about rushing things too much. It’s unlikely that a serious contractor would work this way since more time on the scope means more expenses for them, but you might use this approach with, for example, a carpenter. He takes his time to make sure the table he builds is of good quality and you have to wait, but you still pay the same.
In this case, we have still fixed the scope of the product that we will build. It works if you are producing a table that is hardly an innovation, but any innovation would still be subject to change according to market feedback. So what’s the point of the quality of a product if the product is not the right one for the market we can reach?
It’s clear that by fixing the scope in any field of innovation, we are essentially decreasing our capacity to learn and adapt and that’s expensive. However, fixing the scope is still the most common approach in Latvian companies and it’s a huge problem for international companies as well. Companies might have fixed budgets, set roadmaps and management chains that require fixed scope and control. This is something Large Scale Agile deals with.
So now that we understand the scope should be open, let’s see if opening up the scope creates more risk for the company.
This means we are open to changing our product according to user feedback and we can start talking about Agile. But of course, the CEO or the manager might want some control, right? So, let’s control the costs by fixing the price we pay and setting a deadline.
Since the scope can be changed, you are not building the same stuff you planned before. You are instead learning about the user’s needs and adapting. Learning takes time and you might not get it right with the first release of the product. It might seem that you are building less physical stuff in the same timeframe, but actually, you’re just building less of the stuff you don’t need. You are increasing the value of your product in eyes of the customer, but the product might have fewer features built. This can happen, but another likely scenario is that you learn from the first feature you have built, adapt the scope and the second feature you build is even more useful, and so on. So when the deadline comes you have built something else compared to the initial plan, but it’s totally useful and doesn’t feel like less of a product.
There are no important drawbacks to this approach. It works. The CEO or manager just has to understand that by the deadline he might see less physical stuff actually built than he might have hoped for, but it will be the stuff that the customer needs. The manager or CEO at this point must extend the budget and give a new deadline to the team to produce more of the product customer needs. Or they will see that none of the features they have tried works and that’s also important to know as fast as possible.
By the way, most of the venture funding works this way. You give 1M EUR to a company and see how much they can build in 1 year. They produce a product and learn the market needs during this time. If the product brings results, the VC can give more money and time to the company to build more of this product.
If you would fix the product in the contract, you would still spend 1M EUR on it, but you would realize that the market does not need it only after the 1M EUR is already spent. And since you have not changed the product during the development, you don’t even have the information on what changes would improve the situation. This is what corporations encounter when running innovation projects with Waterfall.
So, opening the scope and fixing the deadline and price (or cost) works, as long as you are ready to extend the budget and time after seeing positive results being created.
So, should we fix the price or time at all? Let’s try the next option.
In this case, you will be paying the team more to get more done by a certain deadline. It’s similar to the approach we reviewed before (2), but now the product can change. It might be useful if you need to get certain business results by a specific date. This can be a deadline for a conference or a similar one-time opportunity to show your product. If you see that you are not getting the results you need in time, you can increase the budget. The team will likely use the extra money to increase its size (for example, from 5 people to 7) or 2 teams will work on this to make more stuff at the same time. Maybe they will work overtime. It’s their choice, as long as you get the results.
Since the scope is open, the team will collect feedback on what they are building and learn from it and you will probably get the market fit, or at least some proof of it. So, essentially, by paying more to the team you will get more speed from the team and the market fit will come faster - just in time for your big conference, right?
It might be right and in a lot of cases, it works. It might also be the case that the team produces the product faster than you can collect feedback about it. Depending on the platform, it takes approximately 45 days for digital advertising to train its machine learning which is also a way of collecting feedback about marketing campaigns. It takes at least 1 week after the app update, for a significant portion of users to update the latest version and you need even more time to draw conclusions and do measurements. In these cases, more speed might not be beneficial and could even cause the development of useless features.
It also might be the case that adding more people to the team doesn’t increase the speed as the new members are catching up and need to be trained. More people also mean more complexity in work organization and that takes time to solve. So, the approach of paying more to get results by a certain deadline can work to some extent, but it’s also not so straightforward, can be risky and only one thing is certain – you will pay more.
So what’s left…
This last approach may sound crazy, right? The team will change the product, work as long as it takes to build it and we will pay for all of it. For many companies, this is where they bail out from Agile and feel that everyone will just be lazy and scam them. As you know from the first 2 lectures, the reason for this is a lack of training and understanding of how Agile works – a.k.a. Cargo Cult. Solid Agile implementation, of course, is not that simple and solves these issues. So, let’s unpack it.
By now, one thing is clear - we need to open the scope to learn from the feedback of customers.
Does it harm to avoid setting a deadline for the work to be completed? We think we might lose the speed of the team but remember - we have to pay for the extra speed, so let’s assume we only want to pay for the full-time work of one team. Do we need a deadline to make sure they are doing their best at work?
How about we just allow the team to work at their organic pace and monitor the results – every day without a deadline? We’ll know if they go in the wrong direction, and we can adjust their course. As long as they are producing value and we get valuable customer feedback, the product will get better, and business results will improve. So, is the deadline really needed to achieve that?
But isn’t this daily monitoring of the team control? Not really. You don’t tell the team what they should do or how they should work – they are free to choose that themselves. You monitor if they need help and if their work is organized. You provide them training on how to be the most productive and if they have a well-functioning Agile setup, most likely they won’t even need your help. It’s called transparency. It creates trust in the team’s ability to be creative and deliver, and it’s the job of Scrum Master and Agile frameworks like Scrum, Kanban and Large Scale Agile to make sure the team has this transparency and work organization in place. Also, you should not hire lazy people as their lack of work culture will quickly be exposed in Agile environment.
So, if we don’t need a deadline, maybe we can fix the price and keep the scope and deadline open? Probably not. That would mean that the people will learn about market needs, improve, and deliver a better product, and spend time on it, but you will pay them the same no matter how much effort it took. Since the scope is open, probably, no one would agree to this or you would pay a gigantic safety margin to make sure everyone gets paid, even if it takes a long time to find the market fit.
So overall, does opening the scope, price and time create risks for the company? The realistic answer is yes, it does. An open scope and therefore costs and time are certainly unpredictable circumstances. Any business itself is a risk. But as with all risks, you must manage the risk of innovation and uncertainty – and you can do that by implementing Agile frameworks like Scrum and Kanban, using software tools like JIRA, and so on. The risk of building the wrong product or spending too much money on it, is probably much higher.
However, keep in mind, that if you use open price, scope, and time setup, you will need transparency and trust with your team and that’s something that’s easier to be achieved with an in-house team that works in your office. It can be done with an outsourcing company like Accenture, but it’s just more difficult. Often placing the people of an outsourced company in your office or virtual office can help with that.
If you are working with an outsourced team, there is a contract type you should use – it’s a time and material contract. It means you pay for the time the team spends without fixing the scope, project price (cost), or time. You agree on a certain hourly fee and work collaboratively with the team on the product you build. Instead of setting the scope, you decide how much time they will spend and when changes should be made to the product. Your contractor counts the time spent and charges you per hour. If you lose the trust in the team, you can stop working with the contractor and find another one.
This is the most common type of contract used by outsourced teams that work with Agile. And by that, I mean the teams that actually do work with Agile. It’s very likely that a company will have a fixed contract with an outsourced team, and they will only think they do Agile because they use some elements from the Scrum framework. That’s cargo cult.
I hope this gives you a deeper understanding of these concepts. You can learn more about Agile frameworks in the 5 week Click With Agile course, but remember, even if a company executes all the rules in Scrum or Kanban framework, it can gain some efficiency and it will likely gain some transparency. However, if the company will make a mistake in these fundamentals of fixing the scope, price and time, it can easily stop the company from being Agile and the company will lose the productivity increase associated with this method of work.
