All posts by Kaja Trees

About Kaja Trees

Started work in IT field as Software Developer at 1999, at first in web development and then IT systems, covering also the roles of IT Architect and IT Analyst in several of the projects. 2006 she realized that she is most passionate about making sure the system solves customer’s actual needs, instead of the technical details. This realization resulted in a role change to IT Analyst / Architect. She has moved to cover also Business Analysis since. From 2018, she is offering her services as IT and Business Analyst as a freelancer in her own company Liriel OÜ.

What can go wrong in IT projects and how to avoid it?

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:

Debunking 6 Myths About Documentation in IT Projects

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. Photo: Shutterstock

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).

What should analyst ask from client?

Recently I wrote about characteristics of good analyst. I have to add that nobody is perfect – it is very difficult to find someone with all the listed characteristics. In addition, every analyst has all those traits represented on different level. Every analyst can improve themselves in areas where they aren’t that strong.

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…

Read Full Post…

What is a good (IT-)analyst like?

Hea IT-analüütik kirjutab häid märkmeid
Analyst’s notes. Photo: Kaja Trees

My past and current customers often give me the compliment of asking if I could take on another project. Or maybe I can suggest someone, who would be just as good. But how to evaluate an analyst?

I consider analysis work to be easily learned. When I told my Granny what I do for work, she was surprised that somebody is willing to pay for this! They are, and more than average salary. You just need certain personality traits and learnable skills.

Read Full Post…