Do you know that feeling of exhaustion – it’s Friday evening, all possible deadlines are blown, the team are so tired they can’t take any more, the client is mad, the product has bugs and there seems to be no end to the fixes reported? 🔥
After several months of fighting, frustration begins to mix with hatred. The client becomes the enemy, while the team don’t want to make any further changes and become entrenched in defensive positions…
Usually, in a situation like this, the client points the finger at the incompetence of the programmers, while the programmers accuse the client of not knowing what he wants. I venture to say, however, that the problem lies in our lack of understanding of the needs and a lack of business analysis in the project.
The world is speeding up 💨
There have been more innovations in the last 10 years than in the past 100 years. The human mind is designed to adapt, to acclimate. We don’t think on a day-to-day basis about how there will be even more innovations in the next 10 years. We have to get ready for this.
The projects we work on are getting bigger, there is more and more information, and implementations must be faster and just as error-free. After all, someone’s finances or even life often depend on the quality of the software. In this context, it’s even more essential to understand the problem on a human level, and not just accurately reproduce the specifications.
At the beginning of the computer age, one programmer alone was able to build a program that changed the lives of millions and solved key problems. Today we need highly complex systems, and there are more requirements, so software is developed by entire teams – often rather large teams.
You can find more on this topic in the PMI report Tomorrow’s Teams Today (2020).
Start with why 👉
This is why it’s so important to build up understanding at the very beginning, to get as much information as possible, and try to get to the heart of the project – e.g. by answering questions using Simon Sinek’s golden circle model:
1️⃣ Why is this project important? Why with us? Why now? What is our goal? What are the values driving this?
2️⃣ How should we implement this project? What methodology should we use?
3️⃣ What exactly will be created as a result of these actions? What will be the outcome of the work? What technologies should we use? What are the next steps needed?
The reason why this approach is effective was best explained by the creator of this concept in his excellent lecture Start with Why.
An opportunity to build understanding 🏗
During the needs assessment, we should check whether we understand the task in the same way as the client. It’s extremely frustrating to discover at the end of the project that the client actually wanted something different or imagined the result differently. We work on design documents which we discuss with the client and gather feedback. These can be images, specifications, descriptions, graphs, etc. Although not always – the more the better – each of these elements is an opportunity to contrast our vision of the product with the client’s vision.
Sometimes the analysis itself is the end product. It may become apparent that the client doesn’t need an advanced solution or that they need more time to precisely determine their business needs: either the client or the market isn’t ready.
Nevertheless, the client becomes an integral part of the project team. Throughout the process, time should also be set aside for the client’s feedback, for their work, in every project, regardless of the methodology. We can call it a hybrid model – it doesn’t matter what we call it, as long as the client is engaged.
Including the client or a person from the client’s team in the project ensures that they have a better understanding of our decisions and the difficulties that arise in the course of the project, and that they help solve them. The client becomes an ally, rather than a source of further problems.
Who should be involved in this process? 👩💻🧑💻
1️⃣ Client – the first key role. This can mean a group of people. It seems obvious, but it’s easy to forget this and to work on solutions without the client. It’s essential to consult the client and get their confirmation of the assumptions and ideas that emerge.
2️⃣ Project manager – the second key role; they will help you plan and synchronise all activities. The project manager often acts as a moderator in discussions and an intermediary in transmitting and gathering information.
3️⃣ UX designer – will help assess the needs, translate them into visual language, conduct research and connect all the dots into one coherent picture.
4️⃣ Business analyst – will help assess the needs and translate them into the language of IT systems, draft a clear and unambiguous specification.
5️⃣ Developer, devops – a technical role, helps by consulting on planned solutions, ensuring they are realistic – i.e. that our ideas can actually be implemented.
What problems does business analysis enable us to avoid? 🧐
Misunderstanding of the task
Incorrect guidelines, a change of guidelines in the middle of the work
Time wasted working on unclear guidelines
Doing work that will never be used
Loss of trust
Not addressing the expectations of the market/users
The trap of the obvious and connecting the dots 🚨
Let’s start with a certain generalisation: all people working in software development are intelligent, educated, usually multilingual people with experience in similar projects. If you give such a person at least an outline of your idea, they will be able to use their experience to fill in the missing dots and combine it all into a coherent picture.
However, this doesn’t mean that it will be consistent with the client’s vision; hence this quality becomes both a blessing and a curse. Therefore, we have two ways to proceed – either we describe the entire system very thoroughly at once, or we approach the implementation iteratively and work on the description of subsequent, smaller parts of the project.
For more details on how the first approach significantly reduces the chance of a project’s success, I recommend reading the report by Gartner: IT Projects Need Less Complexity, Not More Governance.
Also, there is a certain contradictory force at work here. When solving a specific problem – e.g. calculating the order total with a discount and shipping costs in the basket – the developer must take a deep dive into the actual method of implementation (models, database, technology, security, etc.), which makes them automatically lose sight of the big picture. Usually only for a while, but it is very difficult to return to objectivity and distance; moreover, there is usually no time for this during the work.
As a result, if the developer later has to fill in some information gaps (something that the client didn’t articulate, something that wasn’t in the specification) it will be very difficult for them to get the necessary perspective and connect the two closest dots – instead of the two that seem to fit together. This is another reason why you should spend time on needs assessment and business analysis.
Incorrect guidelines 👉
Software development is the process of producing something new. Each project is a unique creation. Even if we model it on something that already works, there will still be some distinguishing feature. In a situation like this, it’s hard to expect the client to know exactly what to do and how to do it. The client knows what goal they want to achieve (and that’s in the best case scenario). The job of the software house is to work with them to determine the method and tools needed to achieve the goal. Without the analysis stage, it’s very easy to confuse the end with the means – and that’s how the guidelines will be created.
For example: the client knows that they want to sell their product on the international market. So, they come to the software house and say they need a WooCommerce store (they heard that this is what everyone does) in 3 language versions and with a Yoast plugin (because it supposedly makes the website magically meet the “SEO” requirement). If the software house simply completes this task, it will theoretically have achieved the client’s goal – to have WooCommerce.
Unfortunately, it won’t bring the client closer to their sales target. The job of business analysis is sometimes to take a step back and get to the underlying need, then consider the possible ways to get there. Maybe we just need to list the product on eBay and launch a simple, free landing page? From the client’s perspective, it’s better to pay for a few days of workshops and analysis to discover such an answer than to spend several months on the implementation of a store that won’t sell.
Loss of trust
Again, there is a certain contradiction here. Why would a software house suggest a solution to the client that it would receive no profit from? If you want a one-time sale, of course, such an action doesn’t make sense. If you approach each client seriously and as a partner, then you want to identify the best ways to achieve success. If your client is successful, they will be well aware of who helped them get there. This way, we build a relationship based on trust that will bear fruit in future.
If the client receives something other than what they ordered – the contractor will be to blame. It’s the contractor’s job to understand and exceed the client’s goal. The client should be pleasantly surprised, not have their time wasted on implementing something that is unnecessary or even counterproductive. Blindly carrying out each client request will result in a loss of trust and, at best, will be the beginning of the end of the partnership. For me, this is one of the basic arguments for spending time on analysing and assessing the client’s needs.
Unclear guidelines
We can’t always expect the client to be able to create guidelines meeting the requirements of a clear specification or technical documentation. At the beginning, the specification is usually 1-2 pages of initial thoughts or an idea described in one email. Leaving the client to come up with an exact description of the solution may lead to a situation where, by becoming more and more focused on their own idea and writing out elaborate solutions, the client loses perspective. Then it becomes difficult to make any modifications to their ideas and you have to make programming compromises.
If we work out a solution together, the client has the opportunity right away to contrast their ideas with what is technically possible. On the other hand, the developer gets the challenge of making the technology meet the client’s expectations. Only by combining these two points of view can a product be created that works well and meets the client’s requirements at the same time.
Different ways of seeing the world
We can’t get away from the fact that each of us sees reality differently. We have different ways of describing the same phenomena, creating different maps in our consciousness. In a situation where we have to reconcile, for example, a client from the creative industry and a developer who spends most of their time around Java programmers? It could be a recipe for disaster.
The client doesn’t understand our jargon, doesn’t understand why something simple is a change, not a minor adjustment, etc; meanwhile, we don’t recognise the reality the client is describing – we try to translate their words into the tools we know, but in the end it turns out not to be it. Our brains work differently. We have differences in language, culture, age, industry, experience, and more.
For this very reason, skilful dialogue, striving to understand what the client really means – a needs assessment – is the key to the success of the implementation. I recommend reading Thomas Erikson’s book, Surrounded by Idiots. It gives a picture of the striking differences in communication that exist among different people, and how these differences manifest themselves.
A change of guidelines in the middle of the work
This is the scourge of most IT projects. Sometimes, after seeing the first results of the work, the client realises that it is not exactly what they had imagined. Sometimes it isn’t even because they saw something in particular, but just that some time has passed, the idea has settled in their mind and it requires some changes – just small, minimal ones. Something that is a cosmetic change for the client, from the programmer’s point of view, may invalidate weeks of work.
Even if we agree that we can change the project’s objectives midway through – we all want to be agile – if such changes are too frequent or too large, the product created will be inconsistent. There will be unnecessary, broken features left in the code and the project will be far more complex, which will affect the failure rate, increase the price, etc. It’s best to avoid this if we can.
This doesn’t mean that the project has to be atomic (indivisible). It means that firstly, we need to establish a very firm understanding of the big picture. Make sure that the whole team knows what the ultimate goal is and can tailor solutions to best achieve it. Secondly, we should keep iterations as short as possible, then make slight course corrections on an ongoing basis. This approach actually welcomes changes to the process because, in practice, the goal can also change. After completing iterations, it’s worth verifying whether the goal is still the same (or changing/adjusting it).
Work in the bin
Another danger is that during the long period of work on the first version, our idea or technology may become outdated. If we’re implementing a start-up or a new service, but someone else does it faster – we lose the advantage of being first in the market. If it’s a tool that improves our work – we spend longer working in an ineffective way. If we’re simply refreshing our website – we potentially lose clients who don’t trust us because the website doesn’t inspire confidence. In short, time is of the essence: the faster the better.
Say we’ve spent 3 years building our perfect start-up and we’re finally ready for take-off. By this time, the client is probably not so passionate about their own idea anymore, the enthusiasm has faded, the world has moved on. At best, you just have to rewrite part of the product; at worst, several years of work start to die slowly before finally ending up in the bin.
There is always the risk that part of the work will have to be thrown in the bin, but the faster we verify our ideas, the less of our work and time will be wasted.
What does the market think?
Another aspect of the needs assessment is that we create a space to check whether a given idea or product is suited to the market. We check the so-called market-fit. This is especially important for new products and start-ups.
Such an analysis enables us to work together to develop an MVP: a first version of the project which, with the least possible expenditure, will allow us to check the project hypothesis and quickly adapt to market feedback. And if the product does not find a market –we can, relatively quickly and inexpensively, pull back and redirect our energy elsewhere.
Why should the client pay for it?
Isn’t this something the contractor needs, rather than the client? This is an understandable concern. However, it results from a narrow perspective of looking at the project. The time devoted to pre-implementation analysis really allows money to be saved at the next stages of implementation. It can also stop the completion of some projects altogether.
With decent materials – specifications and mock-ups – the designer has less work to do. With a well-prepared and thought-out graphic design and system, the programmers have less work to do. They can just go straight to what they do best. They don’t have to get caught up in questions like “what did the author mean by this?”, come back with questions, then wait, creating downtime. The analysis means that the estimate for the design and production stages can be more realistic and with a smaller margin.
Of course, this doesn’t mean that errors are completely eliminated; however, it allows us to reduce them to a minimum. As a result, the whole team is not so averse to changes in the process, which opens the way for controlled, beneficial and well-thought-out changes during implementation. The entire project is then created in an incremental, agile way – and this is what both we and the client want.
In a nutshell
Needs assessment is a stage of preparation that allows us to understand the real need, the true goal of the client. Business analysis is a continuous process and allows us to build a real relationship and communication: we create the mutual trust that is essential to our work.
Of course, a well-conducted needs assessment and a continually conducted business analysis don’t protect us against random events that may disrupt our plans for the project. However, they significantly reduce the risk of the project going wrong and increase the repeatability of the results. System development is planned for years in advance, while at the same time, the first – completely functional – version is available much faster. We can also verify our ideas faster.
Even though usually both the contractor and the client would like to start the project as soon as possible. Even though, at that moment, starting work on the project ASAP often seems to be an absolute necessity (after all, deadlines are looming and there’s still so much to do). It’s worth stopping to find out first what the goal is and how we can achieve it, to prepare materials and a plan, so that later we can calmly watch the next stages of the project unfold.
Comments