One wise man once said: “a smart person thinks first and then does it.” This is a critical sentence that describes why IT projects often fail and why it is important to think through and plan before starting to do something. Or how a Lithuanian saying goes: measure 9 times and cut on the 10th.
IT projects are like construction sites – you can’t put on a roof before you have the walls. It is important to prepare well! The better your planning and preparations prior to the project, the better your construction process will go – with less stress and more probability that you and your client will be happy with the collaboration.
There are a lot of books written, a lot of methodologies created about how to manage and prepare for IT projects. Sometimes the books work, but unfortunately not always. The more clients I am working with and the more projects I am starting, I have noticed that you can’t be stuck with one methodology and blindly follow all the steps. You have to assess every client separately and realize what methods and theories to use and what methods will not work in a specific situation.
In this article, I won’t be writing about textbook theories (even though I have nothing against it). Rather, I will share practical tips about crucial things you need to discuss with your client before starting to realize a project so that it doesn’t ‘go south.’
- Project success
- Risks in IT projects
- Time needed for preparation
We will start with the basic components of every project, one of them being the product – what we want to create.
Often our vision and the client’s vision about the outcomes of the final product can differ a lot. In construction to ensure that everyone understands what will be built, visualizations and drawings are made. This makes it clear both for you and for the client how the building will look. The same goes for IT projects – making prototypes and design drafts help to clarify and visualize the end product. When you actually see the draft of the end product, it is easier for both parties to agree since everyone is on the same page.
Additionally, it is important for both sides to communicate about the goal of the project. When you know the goal, it becomes easier to decide which tools to use to reach that goal, and how the end product will look like. Imagine that you are a builder and your client asks for “a building with a roof so that it doesn’t leak inside.” So, you build a two-story house and later find out that all that was needed was just a garage for the car.
Therefore, knowing the goal of the project helps define which tools to use to reach that goal. There is one key thing to remember: sometimes your vision and the client’s vision about what tools to use can differ greatly! So before agreeing on further project details, both parties have to agree on what tools will be used to reach the set goal. The tools used will set the price and time needed to execute the project.
Very often, especially in bigger projects, it is easier to discuss the project goal with the client than agree on what has to be in the project to achieve the desired goal. The client thinks that he needs this and that, and that function, and then the other, and can’t decide on the third one at all. Sometimes he even needs to discuss the details with other departments and the decision-making process becomes extremely long. At first, it seems great because you are discussing all the details and later will get to work but then… you realize that the time is passing by and no progress is being made. At this stage, at least for us, expertise helps out a lot. What do I mean? Well, if the client hires you to work on the project, he trusts you and sees experts in you and your team. If that’s not the case, then I don’t understand why your company was chosen. As experts, we can always advise about functions not being important at the beginning and right now we should focus on x y z to reach the goal.
When we know what building we want to build, we can divide the construction process into pieces. In IT projects that would be dividing the whole work scope into sprints. Why is this important? This allows us to set clear terms about when and what will be done. Thus, it allows us to assess if we are reaching the set milestones and goals. Also it will help to communicate with the client. Our client has to clearly understand when and what is being done – in what sprints we are working and when are the end of the sprints. When everything is discussed, there will be no cases that you will be blamed for not delivering x. Moreover, the client won’t have any unreasonable claims because he will see all the details about each sprint.
When we know the details about the tasks and the terms of the project, we can estimate the costs of the project. Of course, dividing the whole project into smaller pieces and a clear description of each sprint will help to agree on payment terms. For example, when the 1st sprint is finished – we have done a and b activities, we show the work to the client and get the payment.
When talking about money with the client, it is crucial to not only decide on the price of the activities you will do but also to clearly define agreement and payment terms.
This aspect is extremely important, especially in bigger projects. We have even talked about this topic before (link to article). Both parties have to clearly understand who the responsible people are, both on the IT company side and on the client-side. The client has to know with whom he will communicate and to whom he can ask the questions related to money, technical details of the project etc. The IT company has to certainly understand who to ask and from who to expect an answer on the client’s side.
“What will you see as a successfully delivered project?” This will be one of your essential questions that you can ask your client before starting the project. This cornerstone question will help you understand how your client thinks. It is a question that the client has to think through and answer to himself as well.
Of course, the agile methodology will tell that we work in sprints so we will be able to see that the client does not imagine the project the agreed way. Yes, if in the client’s head a successful project has x functions, then maybe you will have to adjust. But what if the client thinks that a successful project is one that helps him attract more customers? Maybe in this case the marketing part is as important as the IT part. Maybe even the marketing is more important. Now you might think – what does IT have to do with marketing? We are building a product that others are promoting. So yes, in principle, you are right, but the goal is not to be right but to effectively communicate and collaborate to reach the common goal. If before the start of the project, you are able to discuss and agree on all criteria of the project with the client, you will better understand the expectations and will be able to provide better solutions. Lastly, the probability of creating a product that is technically impeccable but does not perform its purpose. You will not only save monetary resources but will also avoid unwanted stress and tension.
Risks in IT projects
Most projects have some sort of risk. That is why it is important to identify the potential dangers and prepare solutions beforehand. For example, we see that the company we will be working with is very big. One danger in this case may be that you will not receive answers to your questions in a timely manner. To avoid such a situation, we have to very clearly communicate with the client about the importance of receiving information on time, because it is crucial to the project’s tasks and progress. If the client does not understand this, he might think that you are not doing certain tasks. The client may not understand that function B cannot be created before creating function A, and to do that you need answers. If you identify this risk on time and communicate the creation process to the client, you are more likely to have answers on time and avoid stress and conflict. It will just be much easier to explain why the process has stopped.
In the preparation phase of each project, communication is a key component. The more people involved in the project understand the details about the tasks and timeline, the better they will be able to tackle challenges along the way. This is specifically important when the project is created by an external IT company, rather than an inside team.
When talking about communication, it is necessary to decide which channels will be used. It can be a simple Skype chat, where both parties can ask arising questions. It can be a Microsoft Teams group created for the project. The essence is that both sides have to discuss this topic and agree on a channel. To add on, very often in projects written communication is not enough, sometimes the questions that arise can be answered more effectively during a call. It is very important to agree on this with the client. Inform that there may be such a need, and even better to arrange a time in advance, e.g. once a week when you call and talk live with the client.
The time needed for preparation
You had to create the project YESTERDAY. Probably a familiar situation. Or the project has to be ready for mass use in 3 months. This wish is understandable: the sooner we release the project, the earlier we can start earning money. We will bypass our competitors before they have something similar. However, from the observations, often this wish passes with reality. There is no visualization about what we will build, we just have a vision that we still need to convert into numbers, letters and pictures. From our practice, preparation work usually is directly proportional to the size of the project and the company with whom you are working. Regularly, it takes around 30-50% of the whole designated project time. For example, if it is a 6-month project, then the preparation for real work can take up to 2-3 months. It can look like a lot of time but don’t forget that a lot of internal nuances have to be resolved by the client. Furthermore, it is way better to dedicate 2-3 months to preparations rather than creating the project for more than 12 months, and in the worst case – not even finishing it, because the initial agreed process was built incorrectly. A successful project – is a consequence of careful planning.
There is also another way – start fast without discussing all the questions, however, in this case, you have to prepare for situations where someone will have to pay for that. Maybe it will be the IT company, that will have to rewrite a part of the project’s functionality because it does not work right. Maybe it will be the client, who will have to pay for that. Potentially, more than once.
All the above-mentioned points could have their own long articles. I could provide details about what communication tools to use, how to identify risks etc. However, the goal of this article is not to overload you with technical information, but to make you think and analyze critical points, that can help you avoid a lot of unwanted situations in your next project.
Good luck with the preparations and more successful projects!
You may also be interested in reading: