Solving Problems, Not Solutions - How Time and Materials Pricing Model Motivates Your Vendor
The topic of the time & materials pricing model is becoming a frequent topic in business conversations. Especially between software development vendors and their clients. If you are the later, you are wondering whether going with the time and materials model is worth the risk. A cooperation that does not clearly specify the final development price may indeed sound like an uncertain investment.
Yet, if the outcome of your project is a so-called “painkiller” product that will solve some real life problems, then, in my opinion, taking the risk is something to consider.
Why?
FIXED OR FLEXIBLE? CHOOSE WISELY
The time & materials model goes well with projects where the key goal is to create a software product (like eg. SaaS). It also works when building an internal management system for your company.
For products and internal systems, the goal is effective problem solving. At Accesto, we often suggest using the solutions that already exist on the market and are proved to work well and more importantly, are continuously being developed and improved. For example, using Mailchimp (an email marketing platform) that we proposed to our client instead of creating a new complex mailing system. Or integrating Kibana (the analytics and visualization platform) for reports and graphs generation from usage of client’s API. In both cases, making use of already proven solutions saved thousands of dollars.
Of course, there are projects where the key to success is following the specs as long as it doesn’t mean reinventing the wheel. When creating a software product, your goal is to find the best solution for a real problem, and make sure people will want to use it.
It doesn’t matter if you are creating a software product for users outside of your company or an internal system. In both cases, the fixed price model can cause some constraints.
In some situations, the fixed price is a quite a natural choice. The time and materials model may not be the perfect fit for various IT projects. If there is a precise specification that the developers need to follow, the fixed price model is the perfect solution. Let it be an implementation of a documented standard like the LTE standard in the telecom branch. Or a legal regulation that needs to be strictly followed which defines the implementation. Having a precise scope allows for the fixed price model to be implemented.
NOT BETTER THAN SPECIFIED
However, the fixed price model is a two-way street. A fixed price implies a fixed project scope. No vendor will agree to a precise price without having a precise scope of specification. It needs to define all product or system features, like functionality or technical aspects.
Listing all the problems and letting the vendor find the solution for an agreed price doesn't work. Such an approach could result in getting the cheapest solution and you or your customers will get the short end of the stick by not having a quality product.
Usually, the vendor will simply not agree to these conditions. To agree on the fixed price, he will ask for the specifications of particular solutions to your list of problems.
The process of creating the specifications itself consumes lots of time and money. And, of course, creating them does not guarantee the success.
Fixing the scope at the beginning of the project means making decisions at the moment when you have the least amount of knowledge about the whole project. Most of us make bad assumptions at the beginning of new projects. In this industry, testing and getting feedback is what makes a project successful.
This is precisely why you don't want to block yourself from being able to adjust to the market. Working on a fixed price budget doesn’t allow for fast adjustments. When there is a need to make them you need extra investments of money and time.
Ending up with a product that doesn’t meet the expectations and needs of its end users is not your end goal.
MOTIVATED TO CREATE A SOLUTION, NOT TO SOLVE A PROBLEM
Practice shows that even when one identifies a specific problem, they may not know the best possible way of addressing it. This can be challenging from both a business and technical perspective. And when you limit the vendor to the fixed price and scope, they may not want to come forward with other options outside of the specified scope.
Focusing on a precise solution narrows the vendor's view and literally kills his creative process. You end up with having a dev team focused on finding a solution instead of solving problems.
By fixing the price and the specification we show the vendor a final reward and a clear path leading to it. And that leaves them little or no room for creativity.
Daniel H. Pink in his book - Drive: The Surprising Truth About What Motivates Us illustrates this case well. Pink gives a set of examples of how familiarity with final reward and a well-known process of accomplishing the tasks kills the motivation to think outside of the box and find innovative ways of addressing problems.
According to Pink, a predefined process of work can indeed have a positive influence on effectiveness. However, it's true only in case of repeatable, reproductive tasks. So if your goal is to implement some standard, then this approach is right up your alley. But if you want to create a new, distinctive and customized product creativity is much needed.
GOOD IDEA? KEEP IT TO YOURSELF!
When the vendor is tied up with a fixed contract his goal is to accomplish the specified tasks for a specified amount. New ideas may come as obstacles on the path to this goal. Therefore, the fixed price model may actually cause the dev team and the vendor to keep the good ideas away from you. Each new idea usually causes a change in the project scope that affects the whole project and causes delays. And this is something that no vendor likes in fixed price driven projects.
As it often happens, changes in the scope don't imply an increase in project's budget. It means that one feature has to replace another. When the scope changes, the additional specification is needed and this is all accompanied by constant negotiations. All that consumes time and money. In this case, the more changes that are made results in bigger overhead. Being innovative simply does not pay off for the vendor. Hence, they continue to focus on the specified solution, not the problem itself.
VENDOR AS A PARTNER
I am far from making general statements. The fact that a fixed price contract may de-motivate the software development company from finding and suggesting better solutions does not imply that they will not do it. But if you decide on this type of contract, you should be aware of this potential negative impact. In such a case, the chances that your vendor will become your digital partner will decrease. By a partner, I mean someone who will fulfill their work duties but will also tell you where you might be wrong and suggest better ways of approaching problems. An honest partner will do this for you, even if it means less financial reward for them.
In his TED talk, designer Alastair Parvin told a story of an architect who was asked to re-plan an old Victorian school. The problem was that the narrow school corridors got congested between classes. He could have started his re-planning work, but instead of focusing on the particular solution of reshaping the corridors, which would cost several million pounds, he focused on the problem itself.
Looking at the problem from a wider angle, he suggested a much simpler and cheaper solution. Instead of having one school bell for all the pupils, he would place several smaller bells that would go off in different places at different times. This solved the congestion problem by distributing the traffic through the corridors. And it cost significantly less than the reconstruction of an antique building.
Similar cases happen in IT projects. Actually, there are a lot of similarities between IT and the design/construction industries. Acting as a product owner for our customers in Accesto for over 6 years, I have been working on many projects in which the final solution that was implemented was quite different from the original idea. Still, it solved the same problem.
One example is when we received an order for a design of an ERP system that among other features included a complex notification system. The goal was to constantly inform all employees within the company about the ongoing work of other co-workers. Surely, we could have designed that, no problem! But questioning the reason of the notifications I had discovered that customer’s real need was having the possibility to work together on a common set of documents without overriding each other's work. The notification system was to help them by informing them who was working on which document at the time.
Now, the solution that we proposed may surprise you. Instead of designing the notification module from scratch, we suggested a Google Docs integration. This completely solved the problem and provided full transparency in regards to the changes others were creating in common documents.
This example shows how a project's cost and, how sometimes, the whole project itself can be influenced by switching from the mindless implementation initial assumptions to focusing on finding the right solution for real problems. That is what I call “solving the problems, not the solutions” approach.
DOES YOUR VENDOR CHALLENGE YOU?
A good dev team is not one that will blindly follow your vision but one that will challenge it. Your vendor should question your assumptions and make you think. Maybe instead of creating a content management system (CMS), they will simply use existing tools and invest saved time for refining more important features.
In this case, the time & materials model will leave their hands untied and they will be more motivated for such simplifications. If you are interested in this topic read our previous blog post and sign up for our newsletter.
