IT project analysis - to conduct or not to conduct?! That is the question!

When you come up with an idea for something to be implemented on the Internet, from a store to a web/mobile application (or maybe something from the world of augmented/virtual reality), you have a certain image of that product in your head. The quintessence of conducting an IT project analysis is to translate that "image" into something that will be unambiguous both for you as the product owner and for the software development company (or interactive agency). Ultimately, everyone involved in the product development process should base their work on a common denominator, which is the project documentation.

Documentation allows us to clearly define the direction in which the IT product will go during the implementation phase. It usually consists of two key elements:

• user stories, which describe all the most important functions of the product in a "layman's" way. User stories allow us to describe the mechanisms governing the application in such a way that everyone (non-technical people, programmers, designers) understands how they work in the same way.
• mockups, which are sketches showing the appearance and behavior of individual product screens, even before they are programmed. They are an excellent complement to user stories, because while the latter allow us to understand the process, mockups are there for everyone to imagine it.

Behind the creation of a detailed and accurate documentation that reflects the nature of an IT project lies a unique benefit for both the product owner and the company executing the project. Documentation eliminates discrepancies in understanding what will be the subject of work and allows for a clear definition of what needs to be done. This results in the fact that when the product implementation stage begins, the final appearance of the application is designed, and then its functions are programmed, everyone knows what they have to do and how to do it.

Anyone who has ever been involved in implementing something online knows how differently individual IT project participants think about the same issues. This applies even to mundane issues, such as the way of logging into the application (for some reason, it may be its key element), which can be implemented according to a certain idea. If I am the product owner and I have a business need for this mechanism to be implemented in a crucial way for me, the analysis stage is a perfect time for my expectation to be expressed and appropriately described by the project team and then implemented.

If there is no room for analysis in the project, we will quickly become hostages to assumptions. These assumptions will quickly reveal one very dangerous phenomenon: everyone involved in the product development process understands its individual functionalities a little differently. And this can lead to some of them having to be rewritten, which in practice means: a waste of time, money, and frayed nerves.

And if you have the unpleasant experience of experiencing the above phenomenon, you will quickly realize that there are no obvious things in IT. That is why at eEngine, when carrying out a project, one of the main principles that guides our work is:

In the IT industry, there are no obvious things.

The analysis stage of an IT project is designed to expose these obvious facts and bring them down to a common denominator. We do this in the interest of the client, but also our own, because the more unconfirmed assumptions in our work, the greater the risk of deviating from the client's business needs. And we want to avoid this because... time, money, and nerves.

In the analysis process, product owners should be involved. It is crucial for them to work as closely as possible with the software development team, of course, as far as it is feasible. The idea is for the creators to feel that they have an impact on how their idea is described by the project team.

Sometimes, it is necessary to involve other entities in the work, such as a lawyer or an external consulting firm. A lot depends on the characteristics of the product we want to create in the end. Nevertheless, the analysis cannot be conducted in such a way that the company conducting it collects as much information as possible and does not verify its accuracy with the assumptions of the creators throughout the entire process.

Questions about obviousness and possibly strong involvement of product owners in the analysis process should allow for checking the sensibility of the adopted assumptions. The analysis is a perfect time to test key mechanisms "on paper" and potentially verify their business logic.

It often happens at this stage that something that sounded great in our heads may prove to be non-functional or unfriendly to the user in practice. Sometimes, discussing a certain issue with the company conducting the analysis is enough, while other times there is a need to describe it using user stories or functional mockups. Regardless of the method, it is a much cheaper and faster way than checking our ideas only after they have been implemented by programmers.

Being assertive and diplomatic in contact with the client is very important because it is never easy to tell the product owner that their idea is impossible to realize or needs to be completely redesigned. Especially when they are convinced of their ideas. Remember that this is precisely why an IT project analysis exists and everything related to it.

Checking assumptions does not only concern what the client proposes. It is also worth considering ideas and suggestions from the company preparing the analysis. Here, I appeal to clients who commission this type of work to be done. It is during the analysis process that you will see how well the potential contractor understands your business and in which direction your project will go. This is why you need to be close to the process of analyzing your idea and turning your "imaginations" into documentation, to be sure of one thing: to what extent does the company serving me understand my needs and expectations?

If you already disagree during the product analysis stage, it is more than likely that things will not improve during implementation. In a situation of constant misunderstandings with the contractor, it is worth considering ending the cooperation already at the analysis stage and looking for another company to implement the product in life. It is possible that this will be a much better solution than continuing a collaboration that shows from the conceptual stage that you communicate on different frequencies.

The tangible result of the analysis will be the development of project documentation. This can take anywhere from a month to three months or even longer in extreme cases. The duration of this stage depends on many factors, such as the complexity of the idea that needs to be described or the speed of the client or company conducting the analysis.

Regardless of the duration of the analysis, its ultimate goal should be to clearly define the requirements, expectations, and needs of the client for their future product. To put it more simply, conducting this stage should allow any IT company to estimate the product and determine the scope of work, cost estimate, and implementation schedule as precisely as possible.

Although preparing project documentation is very helpful in determining its time-consuming nature and scope, it is still worth keeping in mind that we minimize uncertainties and ambiguities, but we can never eliminate them completely. Unfortunately, this is impossible in the IT industry, especially when the product owner wants to be as close to their product during the implementation stage as they were during the analysis. This is a very good approach on their part because an engaged client in the process means that the project team is also more connected to what they are creating.

On the other hand, new ideas will appear during implementation, which the IT company will incorporate into production. This will result in a change in assumptions and modification of some ideas that were developed during the analysis stage. Therefore, it is worth approaching project documentation as the skeleton of the whole, based on which we will create the product. Nevertheless, starting work on your product without analysis and all the benefits it brings is quite a reckless action, especially when we have limited time and budget.

In summary, the analysis stage is crucial in the development of any IT product. If you still need arguments to convince yourself of the importance of conducting this stage for your product, check out one of our vlogs on this topic.

Also, familiarize yourself with Ark's post,which describes the process of creating project documentation for a fairly complex customer relationship management system.