In today’s business landscape, IT projects have become a crucial part of innovation. However, these projects may not always deliver the expected results and can even go very wrong. Kaja Trees, a business and systems analyst with decades of experience in diverse projects, has put together a course titled “Navigating the IT Landscape: A Business Professional’s Guide to IT Procurement and Successful Collaboration.” Here, she reveals common obstacles in IT projects and offers practical strategies to overcome them.

1. Exceeding Budget and Deadline

Problem: IT projects often tend to exceed budgets and timelines. Given that IT projects are not cheap and business outcomes depend on deadlines, this poses a significant problem for businesses.

Solution: Clear communication is the key to successful budget and deadline management. Pay special attention to ensuring a shared understanding in the following areas:

• Define clear project goals and ensure everyone understands them uniformly. It’s crucial to highlight priorities – which goal is more important than others.
• Ensure that the project scope is clear, and any changes are based solely on the project goals. If necessary, abandon less critical project outcomes to achieve more important ones.
• When selecting technologies, ensure that all options, along with sufficient explanations and pros/cons, are presented. The client must understand how to make the best choice based on project goals.
• Use an appropriate project management technique for the project and ensure that decisions are made by the client.
• Regularly evaluate what is working well or not and adjust accordingly.

Exceeding budget and deadline can be acceptable if the result is a product that is worth it. However, these decisions must be made consciously. Ignoring the above can result in no outcome at all – all the work and money have gone to waste.

2. Unusable Results

Problem: Even impeccably executed projects can fail if end users find the system unsuitable, forcing them back to traditional, less efficient methods.

Solution: The system can conflict with end user demands in several ways. Solutions include:

• Functionality must meet users’ needs and qualifications – involve business and systems analysts to ensure the system aligns with user needs.
• System usage should be simple; information and buttons where needed – involve user experience (UX) specialists to ensure an intuitive user interface.
• The system must be fast enough – involve system architects to ensure technological choices meet expected usage intensity.
• The system must deliver what is expected – involve quality assurance engineers (testers) in your team.
• Go straight to the source – involving actual users in the team through user interviews or user testing provides the best insights into what real users need.

Every IT project is teamwork, with each member playing a role. While some individuals may need to fulfill multiple roles, if any aspect is left uncovered, the project may be completed, the system built, but it won’t bring the desired benefits.

The IT world has evolved differently from the traditional business world. It has its project management concepts, specific roles, innovative practices, not to mention technical terms. To successfully carry out IT projects, it’s worthwhile to be aware of the peculiarities of the IT world and consciously consider them.

By enrolling in the “Navigating the IT Landscape” course, you not only acquire essential skills but also gain confidence in successfully managing complex IT projects. In the course, Kaja shares real-world experiences and explains in detail everything a non-IT person needs to know for successful IT collaboration and avoiding the problems that plague many IT projects.

First appeared in Estonian in Geenius DigiPro here: https://digipro.geenius.ee/sisuturundus/mis-saab-it-projektides-valesti-minna-ja-kuidas-seda-valtida/

Get ready, because we are about to debunk the myths surrounding documentation in IT projects! While documentation is essential when building a house, it often gets neglected in the world of technology.

We have invited Kaja Trees to help us explain why documentation is not a burden but a valuable tool on our journey in the IT world. She is an experienced Business and Systems Analyst and has a training called “Optimal Documentation: Enough, Connected, and Up-to-Date” (read more about the course HERE).

1. No one reads documentation anyway

Kaja suggests forgetting about detailed documentation where every nuance is precisely written. Instead think about who needs this information and include only what is necessary.

In your documentation, you should definitely include agreements with clients, tasks, and responsibilities. They help the project manager keep the project moving forward and let the developer know what their area of responsibility is.

When a new team member joins, it’s also beneficial if they can get the necessary information from documentation rather than through oral communication. For example, when a technical team member joins, understanding frameworks, tools, and project workflow is critical.

2. Code is documentation

Kaja states that code is documentation as much as the world is a map!

Yes, code contains a lot of information, but for large systems, understanding it can be as challenging as finding your way from downtown Tallinn to Rome. Code is very detailed, and getting an overview from it can be difficult.

Moreover, code is not understandable to the client and does not describe agreements – if code is documentation, there can’t be any “bugs”! Every change would have to be paid for by the client because, according to this logic, everything in the code is always correct, even if the developer has misunderstood something.

Good documentation helps everyone understand what the software does and navigate the code.

3. Documentation takes too much time

Kaja advises not to spend excessive time on detailed documentation. Think about what information is actually needed and document only that. The time spent creating such documentation is an investment that pays off later, with interest, when it can be used for planning updates and changes.

4. Documentation is always outdated

Kaja explains that documentation doesn’t have to become outdated! In her projects, she has learned to keep it up to date.

The key here is to include updating documentation as part of the natural process at an appropriate point. Software should not be updated without updating the documentation!

5. No One Likes to Write Documentation

Kaja points out that she genuinely enjoys documenting, and in fact, there are many people who enjoy writing documentation.

Choose diverse people for your team and let each person focus on what they enjoy. This is also one of the reasons why it’s good to include an analyst or even multiple analysts in a slightly larger project. Everyone can deal with the part of the work they enjoy.

6. Agile approaches don’t include documentation

Kaja asserts that the Agile Software Development Manifesto created in 2001 stated, “We value … working software over comprehensive documentation!” Over the more than 20 years that followed, this has often been interpreted as “we don’t value documentation.”

It’s forgotten that in the same manifesto, it says: “While there is value in the items on the right, we value the items on the left more.” Of course, the most important thing is that the software works, but good documentation can be a valuable tool in achieving that.

Documentation is not an enemy but a companion that helps the team navigate the complexities of the IT world. Finding the right balance that fits your project and team is crucial.

At Kaja Trees’s training session “Optimal Documentation: Enough, Connected, and Up-to-Date,” you can learn how to naturally write and update documentation to maximize its benefits with minimal effort. This is an opportunity you shouldn’t miss! You can purchase tickets for the training session in English, taking place on November 6 and November 8, 2023, HERE.

First appeared in Geenius DigiPro (in Estonian).

* Disclaimer – All the concepts in this article are written from an Estonian point of view. Some words have different official definitions in English (like Business Analyst, Business Consultant etc.) but in this article they and their meaning have been translated from Estonian.

In Estonian there is only one word for business analysis, “Ärianalüüs” and it is used for both business analysis and business intelligence. This can create a bit of confusion when talking about business analysis in Estonian, because quite a lot of people think you are talking about business intelligence. However, there is a difference between these two. Basically, the goal of business analysis is to map and describe processes and business needs. On the other hand, the goal of business intelligence is to find the numbers that are important for a business and to analyze these numbers. In this article and overall in this blog we will specifically be referring to business analysis.

The confusion between analysis and analytics is one of the reasons why I wanted to write about this topic. The other reason is that during my career, I have not had much chance to see proper business analysis. Something has been done for quite a lot of the cases, but without the understanding of what should have been analysed, in most cases the result is the description of the software system that is wanted. Business analysis however does not mean that the end result has to be software, quite the opposite. It might be concluded that the processes themselves should be changed and no additional IT systems are needed.

What is business analysis?

So, what exactly is business analysis? There is a short description of it in ITBAC blog What is IT and Business Analysis?, but to summarize, business analysis is discovering and mapping the needs for changes in the organization. The article also mentioned that there can be two different roles responsible for it, namely Business Consultant and Business Analyst. A Business Consultant will be mapping the general needs and a Business Analyst will look into the detailed processes connected to each need. Both roles are doing business analysis but on different levels. Business Consultants look at things from an overall point of view while Business Analysts go more into detail.

We will not go into too much detail about what Business Consultants do. In general they sit down with the stakeholders and help put together the overall vision and goals for the company. They describe the internal and external influences, pain points and risk factors. As a result goals and KPIs (Key Performance Indicators) can be decided on, which in turn might be the catalyst for change.

ITBAC focuses mainly on the Business Analyst role and it’s activities. Business Analysts are called in when the need for change has been determined. Their job consists of looking into the connected process and how change should be realized. For example, needs for change can be following:

• Our online store has very low sales, we need to find ways to raise the sales numbers.
• Clients are not happy that our feedback process is slow and they are going to competitors. We need to find ways to improve the process.
• Laws changed and our company is not compliant with them. We need to go over the processes and software systems and describe the places that need changing.

Business Analysts take the problem description, start to investigate it methodically and after documenting the results they can also offer different ways to solve the issue.

There is no definitive process for doing business analysis, in some cases it is necessary to do things that are not needed for other cases. But there are some general things that are necessary most of the time:

• Stakeholder mapping (internal, external etc.)
• Description of the current situation (process diagrams, requirements etc.)
• Proposed solution and expected results (process diagrams, requirements etc.)
• Solution value estimation

It is important to mention that the proposed solution can not be a description of a software system. The result of Business Analysts’ work can be that an online store is needed and that it must be possible to put the products into a virtual shopping cart, but there should be no more details about the software itself. For example the following text is not a very good business analysis result: 

“After opening the online store, the user should see the list of products with pictures. After clicking on the picture product page is shown. On the product page it is possible to click on the shopping cart icon to add the product to the shopping cart.”

Why is that description bad, if we leave out the wording and how superficial it is? Because the person who wrote it does not have a lot of knowledge about the technical side of online stores nor best design options. This might be how they are used to shopping online and so that is what they describe. There might be lots of better options available, for example most of the stores have the option to add products into the shopping cart in the product list, without the need of an additional page and click.

To summarize, Business Analysts start their activities when the need for change has been identified and they will describe the stakeholders, processes and whatever other things that are necessary for that specific situation. When the current situation has been described in enough detail, then it is possible to decide on what the requirements for the new solution are, how it should work, and what is the expected value for the company. With this information it is possible for the IT Business Analyst to start designing the needed software, if it is necessary of course.

Why is business analysis needed?

Why is business analysis needed? A simple way to find the answer is to ask yourself, do you want to use or be involved in a software system development process where the stakeholders are not known and the requirements have not been described or decided on? If business analysis has not been done beforehand (at least to reasonable extent, I am not talking about the long business analysis process as described in Waterfall methodology) then the most common result is that during the development process new stakeholders and requirements are found and the scope, duration and cost of the project will change. In the worst case the project will be cancelled and there is no result at all after a sizable expenditure of money and time.

Another important reason for business analysis is to find how much value will be provided as the result of the change. Will it affect the internal processes and save money and time for the company? Will it raise the customer satisfaction and sales? If those things are not known then it is possible that money and time will be used on an unnecessary solution, and after completion it will not be used. The reasons for not using the software might be different, but doing business analysis and evaluating the value of the change will help to avoid quite a few of them.

Life has shown that during the development process, new things are always discovered, no matter how well you prepare beforehand. What is important is, how many of those unexpected things will you find? No matter what methodology is used, all the new things that need to be added will cost time, money or other functionalities. If business analysis is done before the development, then it will lessen the amount of changes that need to be done during development, and as such will save money and time. Overall, it will result in a better, more comprehensive solution.

In my own opinion, my biggest weakness is asking questions. Often I didn’t know what to ask even when it was clear that I don’t understand anything. Still, you need to start somewhere…

In the world of autistic people, I found the book The Essential 5. This book says that autistic children have it easier, if you always answer 5 questions: “why?”, “who?”, “where?”, “when?” and “how?”. I have started to use those same questions to find out everything necessary in IT-projects.

Why?

If you don’t know answer to “why?”, there is no point in going to next questions.

Why is this project started? What goals does this project need to reach? What KPIs need to be improved with this? Why are these KPIs important?

Simon Sinek has written a book “Start with why”. I agree with the title without reading the book itself. This is the most important question, the easiest to ask – and most underutilized. From “why?” you can set priorities and lead to more suitable functionality. IT system is waste of everyone’s time and money, if it doesn’t correspond to that question.

“Why?” gives the goal to the whole project and puts it in the context of the surrounding world. This is the clear basis for making decisions by all parties. The opposite question of “why not?” is also important. As an example, it is not necessary to implement already existing functionality or currently less important requirement. It limits the scope and helps make sure it is ready in time.

Answer to “Why?” often doesn’t is not documented. I have not found any good techniques to make sure it is always added there. “Why?” should be part of vision, RFQ or project contract. As this is compiled by customer, it doesn’t have a standard structure. During business analysis, different techniques are used to examine the background (SWOT, MOST, PESTLE, business plan etc), but the goal is only a small part of it. “5 Whys” technique helps discover the deeper reasons, but in my experience, it is used rarely and only in the beginning.

If “Why?” is missing then:

• Work is mechanical and error prone for all roles – developers, testers, implementers;
• Later, when system is repaired or improved, they may contradict the objectives;
• Nobody knows whether described functionality is actually needed or an analyst’s nice-to-have idea.

Agile software development methodology solves the problem by bringing customer and developer behind the same table. Still, in this case “Why?” is only in their memory. After a few iterations, it is difficult to remember why the solution was created the way it was. Something important for the customer may be lost in further developments, and will need to be restored.

“Why?” also needs to be asked as sub-question of all of the following questions:

• “Why they are interested in the project?”
• „Why exactly this way?“
• „Why at that time or with that regularity?“
• „Why there?“

Who?

Who orders the project? Who will be using the system? Who is interested in this system for some other reason?

“Who?” is often the starting point of project because, as they say – the one who pays, orders the music. Customer’s “why” is the most important for the project and it is customer, whose goals are primary from project’s standpoint. Analyst still needs to view solution from viewpoint of all parties. Stakeholder analysis is used to find all parties, and you can use different techniques to do that.

“Who?” says to the analyst, whom they need to talk to, or whose interests they need to find from other channels.

There are also common answers to this question. First, the customer and different roles who will be using the system. Analyst will be spending most of the time with them or considering from their point of view. Additionally, there are roles that tend to get overlooked:

• Legal requirements (if customer cannot bring these up);
• Competitor’s interest (that we want to contradict);
• Accountant/management reporting needs;
• and needs of technical system administrators.

The discovered needs are usually contradictory, but analyst needs to find suitable solution for the customer.

Where?

Where does future user currently do needed activities? What is customer’s and users’ vision about where they could do these in the future? Where is information needed by stakeholders?

“Where?” tells you first about the architecture of future solution. For example, what views are needed, how the data is stored, which systems are involved – and which are not.

On the other hand, “where?” talks about devices used by future users. Maybe the user is a technician, who uses a mobile phone with small screen while on the site? Maybe they didn’t have some devices before and it is needed to procure them within the project? Maybe it is required for all future users to use specific operation system? Maybe it is reasonable to continue using existing solutions – partially, for transition or as replacement of some development.

Different aspects of “where?” are described in (nonfunctional) requirements, architecture and deployment views. It is also mentioned on process diagrams, user stories and use cases.

When?

When does a process start? What is the order of different processes, what is the frequency? When does user need to see any information? When do the process results need to be ready?

“When?” helps to decide whether to automate a process or make it manually accessible. Often used processes and information may need to be made more easily accessible or highlighted. It may be necessary to optimize time-critical processes.

“When?” gives mostly information about what the solution can be like. This information is described in requirements, processes and use cases.

How?

How do future users currently do those activities? What is the customer’s and users’ vision for how to do that in the future? How would it be most convenient/efficient/correct way to reach to the result? How can we provide best solution to customer within given time and budget constraints?

“How?” question is dealt with during most project meetings and hours spent alone by analyst. It helps you understand all details that you can’t find with previous more generic questions. It is also used to understand how processes work in system to be built or around it.

When focusing on “How?” there is risk to forget “Why?”. For example, you create system exactly the same way as current process that is based on paper or Excel use. There is no added value from process optimization in such system.

“How?” is mostly described in process diagrams, use cases or user stories. In my experience, the best way is process diagrams with descriptive remarks, because these don’t need specialized IT knowledge to read. Depending on the project, it still might be better to create user stories or use cases instead.

Conclusion

Maybe you wonder, why there is no “what?” question in this list? It wasn’t there in given framework – and whether through luck or some other reason, it is not needed. Analyst is answering this question with their work. Some customers do give quite detailed vision about what the future should be. Still, even in this case, it must be analyzed whether it really is the best possible solution. Using the analyst’s experience and analysis process, usually the final solution will be somewhat different. Too detailed vision given by customer may even draw out analysis process and make it more complicated; especially if analyst forgets to ask “Why?” because of it.

Those questions are clearly not exhaustive. You can go into more details in everything, and based on project, you may need to ask some very specific questions. Still, this framework helps cover biggest areas during IT project analysis. They help me start the discussion, if it is difficult for some reason, and keep the most important thing in focus.

Why would you use this framework – or not? Do you have some simple frameworks that help in analysis process? Add them below as comments or in our Facebook or LinkedIn group!

Best way to understand the analysis roles is to go through the process of project.

Simplified project process

A project starts when the Client has created a vision for a business model or change in the organization. They define the model for change with the help from Business Consultant. Their goal is to verify that the change is worth pursuing. The main results from this process are definition of vision, budget and deadline.

If the project is worth pursuing, they find a Project Manager to control its execution. He/she will include other roles to the project, as necessary – Business and IT Analysts among others.

Next, Business Analyst defines the business organization and processes based on the vision. They might need workshops with people involved to find all needs. Business Analyst might also discover ways to improve the model of the vision, which they will relay to Client. Often they discover changes needed in existing IT-systems or need for new ones. In this case, they will involve IT Analyst.

IT Analyst defines the details of IT-systems and their interactions. They use business processes and workshops with people involved to understand the needs. They might discover ways to streamline the business processes using the IT-systems. In this case they will work with Business Analyst to improve them.

IT Analyst includes IT Architect to define the structure of the IT systems. This includes components of the systems as well as interactions between systems. They consider non-functional specifics like performance and security to find the solution. IT Analyst then defines how the processes use this structure.

The designed solution is then:

• realized by the Developer
• tested by Quality Assurance engineer (or Tester)
• approved by all the above roles for implementation
• and implemented through both technical and other activities;
• results interpreted by Client, who may start next project for any improvements.

Differences

Above description looks like the dreaded waterfall model, but this doesn’t need to be the case. One person can be in all these roles, as is often the case in smaller projects or with agile methodologies. Yet, in bigger projects the roles may be even more specific:

• User Interface Analyst
• Database Analyst
• Integrations Analyst
• etc.

It is easier to understand the roles and responsibilities when broken down like this. We will be using the roles on this page as defined in this simplified process. The IT and Business Analysis Club focuses on the roles of Business Analyst and IT Analyst.