Imagine a hypothetical, though standard, situation in which John - the owner of a medium-sized service company - stated that he needs a system for reports in order to be able to better manage his business. For this purpose, he does a simple research to find an IT company that will meet his needs. After a short analysis, he chooses three companies that look professional and have carried out similar projects. He speaks to each of them, briefly informing them about what he needs.
Company A did not ask any more questions and two days later sends its offer, with a very wide scope of the range - say 10,000 to 30,000 $.
A consultant from company B talked to the owner for more than half an hour, asking about the situation in the company, problems he has, business needs, and what he expects from the reporting system. Thanks to more thorough analysis, company B sends the offer for an amount of 15,000 $ the next day.
Company C behaves differently. After the initial task of asking the same questions as a consultant from company B, company C proposes to John, the owner of the company, a pre-implementation analysis service, which would involve an experienced consultant from company C to carry out a workshops at John’s company to find out fully how his company works, what his employees' need and how that data will actually be needed to develop a business, and even whether such a reporting system is needed at all. The cost of this service has been estimated at 5,000 $.
Which offer did John choose? Probably the offer of company B, but having the offer of company A on the table, which started from 10,000, negotiated the discount and ultimately paid 12,000 $.
Has he made a good decision? You could say that yes - after all, company B knew exactly what John needed and prepared an IT system at a really good price.
But was it the best business decision possible?
Perhaps an audit of C company would show that no reporting system is needed because it would be enough to buy a higher package of currently used software. Company C wouldn’t sell a software, but would help the customer save costs and gain loyalty. Or maybe the audit would show that the unused potential lies elsewhere in the company?
This John will not know, because he did not take into account C's offer for various reasons - he could not compare their offer with the others (and he was used to making decisions based on price and first impression), he did not want to "throw away" 5,000 for an audit that would show what he already knows (or rather what he thinks he knows), and consultancy would delay the whole project, and time is money.
What is the moral of this story? Do not be like John;)
And quite seriously - often we do not know what we do not know, and often what we think we know is not really that. Therefore, it is worth using the experience of experts in areas where we don’t have full knowledge.
And that’s what this blogpost is about.
How does the estimation of software development price look like?
Before we go any further, let's stop for a moment and think about how pricing of IT services is currently being created.
Mostly an IT company (whether it's a software house or an interactive agency) receives a brief from the client, in which the client's needs are included (sometimes also the current context and reasons for dealing with this topic). Then, the business developer (once a salesman) asks the customer for details and the necessary information to make a pricing
After obtaining all the information, the business department together with IT develops a preliminary valuation, based on information from the client, but also its assumptions and guesses, overstating the time to perform specific tasks to obtain a buffer both is terms of time and money. Often such pricing is multivariant, with optional modules / tasks, and if the company is less transparent, the most common valuation is given in the range from to-to.
This style of cooperation, despite the fact that agile software development techniques have been popularized for almost 20 years, is still dominant in cooperation between business and IT. However, if an IT consultant convinces the client that it is worth creating software agile - then the final cost can not be fully predicted, because the scope of IT work is determined on an ongoing basis.
In this situation, the pre-implementation analysis, which will result in a preliminary specification, very specific written needs and goals of the client, as well as business processes, terminology and expert knowledge - will be necessary for the project to be estimated, and would have a better chance of success (which we understand as meeting customer needs, meeting its business goals, budgeting and scheduling).
But if in the previous situation - when the client does not have time to cooperate with an IT company - he just wants to receive a website, platform or mobile application - such analysis would not give the customer a benefit?
Contact us now to receive non-binding advice on the implementation of IT projects :
Why the valuation of IT projects looks like this?
Before we answer this question, let's think about why the valuations created by IT companies look the way they look?
The main reasons are three:
- Sales people working in software houses do not read the minds of customers - rarely the client is able to convey all the important information and needs in one brief or by phone or even at a meeting.
- Clients are not IT specialists (mostly), but they are entrepreneurs, employees of marketing and production departments - so they often focus on solutions and not on their needs and challenges.
- Estimating even a few-month project is a very difficult art, with a great number of unknowns and variables - so the more data and knowledge, the less unknown.
These three reasons are the origin of the most important problem that affects IT projects. This is CHANGE.
Heraklitus from Ephesus already said: "The only constant thing in life is change." There is no more true opinion about IT projects than this sentence.
It’s because of unconscious customer's needs, focusing on solutions, not needs and high complexity of software development - which cause that during the project (or its end) the client will be aware of subsequent IT needs (resulting from his business needs). In our work, we meet these and many more issues very often. And this, unfortunately, raises serious problems in cooperation.
To illustrate this, let's go back to history with John. John, as we remember, chose the company B, which became interested in its needs and provided a specific amount for the reporting system. Everything goes smoothly, and in the middle of the project John realized that one of the reports that the new system will generate, he already has in his current system. At the same time, he realized that he could have another one in return. Therefore, he contacts company B and presents his wish:
John: "I would like to abandon the report X, but have a report Y instead".
Company B: "Unfortunately, it's not possible. We've already done an X report. "
John: "But I do not need an X report because I already have it on my computer. I want a Y report. "
Company B: "Mr. John, even if we did not report X, the Y report is 3 times more complicated, which would mean that you will have to pay 10 man-hours to do it"
John: "10 hours more? After all, it's just a bit more complicated report. You can definitely do it faster"
The discussion continues, most likely it will end with the fact that the X report will not see the light of day in the new system, and for the Y report the company B will get 5 man-hours, writing down the costs incurred in preparing the X report.
Of course, this is an exaggerated situation, but unfortunately, it often takes place - with each type of customer, and with any type of IT company. Therefore, Agile and Scrum techniques are so effective, but they require a lot of commitment and trust.
Are both sides happy with the situation? Definitely not. John had to negotiate heavily, he didn’t want to pay for something that he had for a long time (and which he was not aware of), and the IT company incurred another margin reduction in order to maintain relations with the client.
Many of the problems that will appear in the project could be avoided by doing pre-implementation analysis and advisory work at the beginning of the project. Probably not all, but a significant part, thanks to which the cooperation between both parties would be much better, as well as the final effect would better fulfill the client's business goals.
How should the ideal estimate of IT project costs look like?
Now I would like to describe a real story - with one of our clients, which is one of the three leaders in the Polish industry on the market of workwear leasing.
Jakub, the logistics director, spoke to us because he needed IT solutions to improve the work of drivers (de facto, company representatives) and the customer service office. Our client had ideas in his head, what will be useful for his company, but he knew that he needed a partner and IT advisor.
Instead of letting us know that he needs the X application and the Y system, he explained what problems he has and whether we can help him solve them. This is exactly one of the things we do - we not only create dedicated IT solutions for business, but also help our clients to achieve their business goals.
And even though at the first meeting we knew what Jakub's company needs - we knew that we needed to carry out a professional analysis of the company's business situation by auditing processes, learning the needs, challenges and goals of all those affected by this change.
So instead of immediately presenting the offer and trying to close the "deal", we recommended an IT audit, which not only confirms Jakub and our assumptions, but also gives the necessary knowledge, what can be done, how to do it, what are the limitations.
One of such discoveries was that by a relatively low cost we could create clothing scanning program, which will have a much clearer interface, which will result in fewer mistakes in sorting clothing, which will translate into fewer mistakes for customers, which in turn will translate for a better reputation of the company.
The end result was not only confirmation of assumptions what will be needed, but also mapping the company's processes (in the analyzed area), future possible improvements, a list of restrictions, as well as specification and a specific offer.
Such cooperation is possible only when we treat an IT company as a partner, a specialist in their field, and not only a supplier who will do what we think we need. This is the same principle as when hiring people in your company - we should hire specialists to do their job the best they can, and not telling them what to do.
Wondering where to start implementing the IT project? Contact us now!
Benefits of conducting IT pre-implementation analysis
Once we know that it is worth carrying out in-depth pre-implementation analysis in complex situations, let us consider what specific benefits we can achieve.
The main benefit is the realisation of costs. The fewer uncertainties for software house, the more accurate the valuation (by more accurate I mean better reflecting the expected final state). Therefore, we will be able to better determine the costs, without large price and time buffers.
Additionally, it is worth being aware that the later a change occurs during the life of the project that changes the requirements or scope of work, the greater the cost of servicing it. This is the most important task of pre-implementation analysis - to minimize the number of changes during working on the project.
Visualization of rising costs of changes in the project depending on the stage of project involvement.
Another huge profit from pre-implementation analysis is meeting expectations. Thanks to the analysis, everyone will be more aware of the real needs of the client. And the final effect should meet the client's goals.
Another potential benefit is the reduction of project time. If we know what exactly is to be done and we have knowledge about the company - we are able to better define the schedule and set up smaller reserve buffers.
The result of the analysis is also a better understanding of both companies and teams. As part of the cooperation, both parties get to know each other, see how they cooperate, which is a big advantage before starting the actual work on the IT system. In addition, from the beginning, we gain customer involvement in the work on the project, instead of the frequent expectation that the IT company will do everything.
Another advantage for the client from the pre-implementation analysis of IT is that a lot of questions will be asked, which he himself has not answered for a long time. This is one of the advantages of consulting - that you will answer questions you do not ask yourself, broaden your horizons or remind yourself of important things that you forgot about in everyday routine.
The end result of the analysis is specification (depending on the needs of the UX mock-up), but also a set of requirements, analysis of limitations and risks, proposition of changes in the company's processes, as well as an offer containing the required budget and schedule.
Where does the reluctance to conduct IT pre-implementation analysis come from?
If we know the benefits of pre-implementation analysis, let us consider the disadvantages.
One of the main arguments we hear is its duration, and thus the impact of the analysis as an additional activity on the delay of starting work. The truth is that the time of pre-implementation analysis is much shorter (and cheaper) than unforeseen changes on the project resulting from the lack of previous analysis.
A more serious argument is, of course, an additional cost. Here it should be stressed that the pre-implementation analysis is not a cost but an investment and an opportunity to reduce the project's target costs.
And since we are at the competition, it is not possible to mention the need of business owners to compare the offers of many software providers. Such an approach is of course correct, but recalling John’s story from the beginning of the article - we send requests for valuation of something that is not fully specified and we are not sure if we need it in this form.
Wouldn’t it be better firstly to conduct a pre-implementation analysis - know exactly what we need, have a specific specification, make an analysis of risks and constraints and only then have other IT companies asked to submit an offer? In our opinion, it would be much better for all parties..
Another issue is the fact that pre-implementation analyzes have been used so far before the implementation of ERP systems, which may affect the perception of them as expensive and long-lasting solutions. However, depending on the complexity of the project, it may take from 1 to 4 weeks (unless we talk about ERP solutions - then it is a longer time - closer to 3 months).
I will now quote another story with our customer-to-be. We have been invited to a very fast-growing temporary work agency to talk about creating a dedicated system for their needs, because now all data is kept in a small ERP system and in many Excel files.
The company has been working with an experienced consultant for a month, who wrote all the company's processes (for the first time in the company's history) and based on them the first conclusions were drawn, what the company needs to continue to develop, but also how to increase quality and efficiency.
Our approach in such a situation assumes carrying out an in-depth pre-implementation analysis, in this case an audit of mapped processes, interviews with representatives of each group of employees, analysis of currently used tools (Excel) and how they are used in everyday work. And only then would we be able to prepare a specific offer, containing the initial specification of works, the assumed schedule and we would propose an iterative approach, i.e. software development in equal time stages (so-called sprints - e.g. 2 weeks), focusing on the current company's priority.
This approach would not only increase the chances of successful computerization of the company, but also quick financial results thanks to the implementation of subsequent improvements.
Unfortunately, our would-be customer immediately expected a specific offer (which was impossible to prepare after one and a half hour's meeting), and also from the beginning expressed distrust towards IT companies. With this approach, it was not possible to partner and have a win-win cooperation for both parties.
On the day that this article is created, 4 months have passed since that meeting and so far no cooperation with any software house has been started, which must be treated as wasted time that could be used to increase the company's competitiveness and accelerate its development. There is no doubt that someday IT solutions will appear in this company, but probably already when the huge boom in this industry will end.
What does the pre-implementation IT analysis look like?
We already know the benefits of pre-implementation analysis. We also know why, wrongly, not everyone is deciding on it. So let's look at how exactly it looks.
The first step should usually be a detailed audit of the company, so that the consultant can get to know the exact nature of the environment, processes taking place in the company, how does the work and communication of employees look like. With less complex topics, this step can be significantly shortened, but it's worth doing.
The second step should be a workshop with the main people in the client's company who will be affected by the change (not only decision-makers, but also people who will implement the new solution and people who will be users of the new system). It can take the form of Q & A (questions and answers), a common analysis of requirements, risks and limitations, or an Event Storming session.
As Event Storming is a very interesting but also an advanced method of designing requirements, events, limitations in the existing business context, it deserves a separate entry. In short, it involves work of several people who support the entire process in the company, whose task is to list all possible events that happen in this process. Then all these events are grouped together and we attempt to put them into a logical whole, adding restrictions, triggers, and requirements for having the right resources. Having such a diagram, from which nothing can be taken away - we are able to design a business model and reflect in the code all business rules regarding this process. Event Storming is a basic tool of the DDD (Domain-Driven Development) methodology.
If we do not do an Event Storming session, the result of the audit should be mapping the process(whether in BPMN or similar notation). Based on the collected data and diagrams, the consultant then develops the initial specification of the solution, and if the user interface plays a large role in the system, UX models are also designed (simple interface drawings, illustrating the idea and intention of users, without emphasizing graphics or aesthetics).
After a joint analysis of the developed specification and UX mock-ups with the client, the software house is ready to prepare an offer containing a much more accurate estimation of costs and schedule, understanding the challenges, needs and threats for the client.
This is also the time when the pre-implementation analysis ends and the client can decide to cooperate with the software house preparing the entire analysis (if the cooperation was good) or use all materials as a basis for doing research on the market (instead of a traditional brief).
It often happens that IT companies provide 50% (or 100%) discounts for conducting pre-implementation analysis, if the customer decides to implement a project with them.
Let's summarize once again what the company ultimately obtains when it decides to carry out the pre-implementation analysis:
- identification and description of business processes affected by the problem / challenge / need from the point of view of an independent consultant,
- recommendation regarding the scope of functional implementation of IT solutions,
- establishing with the client its business goals and expected benefits that are possible to achieve with IT tools,
- relatively accurate schedule,
- accurately written costs,
- description of technical needs (eg server parameters, additional software, etc.)
And we have it all before the proper programming and graphic work begins. With larger projects it is difficult to imagine the start of a project without such a thorough analysis.
Will it be possible to fasten the project without analysis?
Exactly. Can a large project work without such analysis? Of course, yes, but the risk of misunderstandings, changes in requirements, creating unnecessary modules is then much higher. Should it not be the responsibility of professionals to minimize the risk?
Pre-implementation analysis becomes standard for more complex projects. With simpler projects, a well-done job of an adviser and an expert on the part of an IT company can be enough to know the client's needs, but this will never replace a professionally performed audit and analysis.
It may also work if the company has extensive experience in running IT projects, has a learning culture and improves its practices every time. Then they can do most of the consulting work themselves and can provide the IT company with exact requirements and limitations.
Unfortunately, most customers do not have such competences. And if they did not chose the pre-implementation analysis, then is it possible to complain that the IT company did not complete the project on time or did the costs go beyond the budget? A lot depends on what work the IT company did, but the software development is so heavily burdened with many variables / unknowns that minimizing each of these difficulties will always have a positive effect on the final result.
Also, to sum up: the chance, of course, is that everything will succeed without analysis, but why not increase your chances of success?
Szans, które są liczone w pieniądzach?