From this article, you will learn about what Founders and Software Houses can do to plan IT project development well. We will concentrate on how Founders can prepare to deal with the uneasy challenge of precise project estimation. If you haven’t read the previous part of our IT project evaluation cycle – don’t forget to read part 1.
Introduction: what causes the difference between the planned and actual cost of software development?
In the first part of our article, we tried to explain what the pricing process looks like and what Founders can do to help software houses prepare more accurate price offers. In this second part, we shall look closer at what causes this difference. Is it possible at all that buying custom made software products could be contracted at a fixed rate, with no surprises regarding the final bill, or is it just wishful thinking?
Even with rigorous project development steps and thorough research and analysis, can we guarantee that your project will be prepared exactly as planned? Let’s see.
Good context is…good. Read the 1 part of this article to improve your estimation process better.
Is it possible for a software house to estimate the costs of certain elements at a repeated, fixed rate?
Perhaps you would have preferred a more decisive reply, but the truth is that the answer is not a simple yes or no. It will be easier to make a precise time estimation if we already have experience with a certain solution. Why? Because we already know what kind of problems we struggled with previously and have learned how to avoid repeating them. This experience allows us to safely claim that we are familiar with a certain element of the pricing offer.
However, please remember that it is a completely different story in the case of building a complete and complex application. There are so many changeables in the process, so many unknown aspects, that it is difficult to say at the starting point in which direction development will go. When you add the dynamics of user tests and the influence of all stakeholders involved in the project, you will see that these are elements outside of the control of any Software House. These variables can often slow down development and influence production costs.
Summing up, as Adam Trojańczyk, Head of Development at Inwedo would say – it depends 😉 In any case, let’s take a closer look at what exactly can be influenced in IT project development.
Five changeables that influence product development – from a Software House’s perspective
Adam breaks down the variables into a few most common elements:
How much time can we devote to a particular project, but also:
- how much time do we have till the product’s premiere
- what will be the speed of implementation
- how important is market validation
“Companies are often under great pressure to introduce change and innovation, therefore their time frame is very tight”, Adam says.
Even if at the start of a project we have a comfortable budget, it may so happen that it shall shrink in time due to unforeseen circumstances. To be fair, the opposite too may happen.
What is a good idea to do in case of the first scenario? A tip from Adam: “Try to develop a project so it can be quickly validated, may bring profit and save money from the first day of your product premiere, hence bringing money to your budget”.
Quality depends on people, time, and money and also can be a variable in the project. It has a great influence on the future success or failure of our business. If you are planning to create an application that affects many processes in your company, do not take shortcuts or save on the project’s quality.
#4 Experience & people
These elements are closely intertwined. We recommend diversifying the skills of your team members and making sure that you have people on board with the necessary experience. Otherwise, there is a risk that an idea with great potential may turn into a black swan project, or in other words, a project that is in danger. Where there are much rotation amongst team members and/or leaders there is discontinuity which creates the space for many things going wrong.
Technologies and frameworks constantly evolve and literally change from day to day. They give us unlimited possibilities to develop software, but as Adam advises: “you need to make a careful and well thought through decision about the technology you will choose for your project. Make sure that the application will follow the latest library versions so that it will be supported”.
These are factors on the side of the Software House. How about Investors and Founders, what can they do to help?
Five changeables that influence product development – Founder & Investor side
“From my experience, what is the most common cause that influences product development (therefore pricing too) is feedback and changing the project’s requirements and goals. I will risk a statement that at the beginning of the software development process customers want to copy 1:1 the physical process that takes place in their company and repeat it in their application”.
Paulina Mączyńska, Head of Clients at Inwedo
Changing goals and expectations in software development
With time, during the concept phase or sometimes even later, when the tool itself is beginning to emerge, a customer might come to the conclusion that perhaps it would be worth changing and improving certain processes. At that point, they see the potential of changing the way they operate through the application that we create together.
When designing software solutions, our main goal is to make everyday work easier through process automation, elimination of human mistakes, and speeding up processes within companies.
Thinking about how we can do this is a tedious process that starts with the beginning of our first meeting with the customer and continues through application development, even up till the phase of providing support. The ongoing urge to improve processes and make a life for final users more friendly results in a series of further consequences: it changes priorities and backlogs therefore affecting the initial cost estimations of software development. Of course, it is also important to distinguish which changes bring actual benefits and which are only “nice-to-have” additions that may be implemented sometime in the future.
We can divide feedback into external (coming from users and investors) and internal (from departments and team members).
“We often receive feedback coming from users and investors or from internal departments after the application has been implemented or when it is consulted during development. In the case of user feedback, which often comes in large quantities and is both positive and constructive, putting the right priorities on planned actions and referring them to the earlier project roadmap or criteria of success is absolutely crucial”.
Agatha Solnica, Key Account Manager at Inwedo
Why? Because it might turn out that the changes resulting from feedback are important, but not all even should be implemented immediately. If there are changes which we all agree are important, we can amend the scope of work, and what goes with it also the initial time & budget estimations.
So what can we do to avoid this time-consuming and costly stage? “I would highly recommend letting users test your application as soon as possible, at the MVP stage. Thanks to this we will avoid a situation, when we have been working on a product for 9 months that does not meet consumer needs” – advises Agatha.
In other cases, we may develop an application with one department for the internal use of another department in the same company, and then we have feedback from end-users but within the company. The rule however is the same – they are also final users of the application, so their feedback may also influence the direction of development.
Again it is important to include a representative of the group of final users into the development process from the very beginning. We often do so by engaging stakeholders/representatives of various departments as early as discovery workshops. We can then have insight into real user needs and the risk of major changes after implementation will be much lower.
These changeables influence the price and are the reason why there is a gap between price estimation and the actual costs of software development. For Founders, managers, and everyone who is responsible for the project, it is very important to be aware of this fact before making a decision to start developing a software product. But this does not mean we can’t do anything about it.
Five things you can do to minimize the gap between price estimation and actual costs
What can you do for the pricing to be more realistic and present the Founder with more precise budget scenarios for the upcoming months? Give investors a sense of security and predictability?
At Inwedo we have a few ideas.
#1 Workshops & roadmaps
One of the elements we have introduced in our software development process are workshops prepared according to an Inwedo formula. This is a perfect moment to prioritize activities, prepare a roadmap, and specify the scope of the project, both in the short and long-term.
A roadmap is a very important document as it allows the team and the customer to keep watch over the process, which minimizes change and provides a sense of security. The further down the roadmap, the less precise the project scope will be as there is much in the project that can change through time. But when we have a defined roadmap together with criteria of success and smaller goals we plan to achieve on our way, both the customer and the development team can track progress and see whether work is heading in the right direction.
Remember to update your roadmap on a regular basis, whenever there are changes in the project. At Inwedo the Project Owner together with the customer will always introduce all changes into the roadmap.
#2 Minimum Viable Product [MVP]*
It is a good idea to define the scope of an MVP in the project, a minimum version of your product that will allow you to achieve your first goals, collect feedback, and verify assumptions. How does an MVP translate into better cost prediction and saving money?
- Quicker → It is part of the whole project and usually it takes 2-3 months to develop a beta version that can be shared with first users for tests.
- More precise → since it is a part of the whole project, it can be better defined and more accurately estimated. Later, during workshops, we can concentrate on the shape of functionalities only from the MVP scope, which allows us to describe and estimate with greater precision.
- More effective use of budget → because and MVP product can be quickly validated by users, we can make necessary changes to our project and concentrate on areas which will bring the most value or have the greatest priority
#3 Project kickoff
A project kick-off is an important element of the software development process which we go through together with our customers. What elements of the project kickoff help stay within the predicted budget frame of a software development process?
- Confirming with the customer the project roadmap and next few sprints → because when we have set time and budget frames, during kickoff we make sure the whole team is familiar with them and that our plan is feasible. If not, we will search for solutions.
- Agreeing on reporting routines → so that both the Project Owner as well as customer will be up-to-date with the hour burndown and can take adequate steps
GOOD TO KNOW:
What is also important from the customer’s perspective is that we determine how much time they can devote to our sprints, so we can better plan co-operation. We also explain exactly what will happen during the next two sprints as well as remind the rules of communication and reporting. Together we agree upon the dates of important meetings and what documents will be needed. Everything we agreed upon during the kickoff meeting, including links to documents and contact information, will be sent to the customer in the form of a PDF post kickoff summary.
#4 Offboarding, or else sewing seeds for the future
Whenever co-operation is more complex and lengthy we go through an offboarding process with our customers. Thanks to this systematic approach it is easier for the customer to understand how to embark on their project now that our work is done. It also gives a better understanding of future projects, to some extent it can be seen as an investment. At this point, we ask ourselves questions like:
- What have we learned?
- Was everything measured as planned?
- What are the results?
Answering these questions and checking at the end again the success criteria, we can see whether they were formulated well in the beginning. If they weren’t, we have the chance to rethink certain criteria and improve for future projects.
#5 Project specifications and assumptions
In practice, this means building a product in small steps, quick verification with the target user groups, and collecting feedback. According to this report from MCKinsey “On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. Software projects run the highest risk of cost and schedule overruns”.
We can follow Adam’s advice to avoid such a situation:
- define clear goals;
- do not succumb to pressure and confirm unrealistic or risky deadlines;
- divide the project into smaller parts, which can be evaluated;
- maintain strict control over your project, at every stage;
- leave some percentage of time and budget to unforeseen circumstances.
Agata adds to this list:
- to keep control of the costs, we can agree with the customer on a cap and agree on priorities within a given scope and have regular reporting routines (daily hours tracking/weekly reporting)
- to make sure the project will be of high value we agree on business goals, which we are to deliver with every sprint and report progress on their delivery.
Maybe we can never or rarely have perfect price estimations, but surely we can strive to improve. In fact, excellence has to do with the process, not exactly with the goal (although it’s a paradox). Last words of advice:
- measure the gap over consecutive projects and see if decreases
- put gap minimization as criteria for your project’s success
- educate your team on good practices to minimize the gap
- inform customers about your practice; this may give you leverage on the market.
The more accurate, predictable, and precise the price estimation, the happier the customer will be. And that is what we wish everyone!