According to different surveys, from 19% to 75% of IT software projects fail. There are many reasons, but the most pressing one is the lack of proper communication between clients and vendors.  

Today, we’re talking to Daria Nechyporenko – DICEUS Project Manager. She has more than eight years of professional experience in development and project management. In this interview, Daria compares successful and unsuccessful IT projects, reveals failure reasons, and shows how clients can boost project success chances. The core idea is to understand own business processes and be open to communication with the development team.  

Guaranteed software project success with a free 30-minute strategy session!

Get started
Daria Nechyporenko, Diceus Project Manager

About project management 

Q: Hello, Daria. Let’s clarify it in the beginning – who is a Project Manager, and what’s his/her role in the IT software projects?  

A: Project Manager is a connecting link between the project strategy and the individuals involved. Typically, we spend 70% of time in communication with teams, clients, stakeholders. A good PM should timely provide a client with the appropriate state on the development progress, its risks and issues, timeline, resolve conflicts and other aspects of the development process. Appropriate means that the client can clearly understand it despite his technical or non-technical background. Project Manager should bring the biggest client’s values to the team in order to show that everyone makes a great contribution to one’s dream. 

We manage people, tasks, risks, money, and efforts in order to keep everything balanced and matching the project goals. 

Q: Sounds cool! As you know a lot about people who start their IT projects, can you tell more about them? Who are the customers, generally? 

A: Overall, our client is a business without in-house IT capabilities. Thus, they cooperate with software outsourcing service providers to mitigate risks, automate processes, get software products, etc. As for people we work with, they have low to middle tech experience but strong financial goals. Most often, they realize their business goals, want to cut costs, improve transparency, or optimize processes.  

About success and failures 

Q: Daria, how to understand that the project is successful, and the client is satisfied? 

A: Earlier, the understanding of success was based on the project management triangle purely. This concept includes project scope, time, and costs between which PMs and other parties can agree on. However, today, the triangle isn’t the dogma anymore. These parameters still matter a lot, but they aren’t exclusive. For instance, we can fulfill many change requests related to new requirements, extra offers, scope modifications, budget issues. As a result, we bring our client the expected values. 

Thus, even moving beyond the limits of the triangle, it’s possible to get a happy and satisfied client. If we solved his/her issues, delivered what’s required, the project is successful. Apart from this, let’s mind emotions and experience. I recommend the formula: Emotions = Result – Expectations. The outcome will be positive, all partners will be happy if initial expectations were lower than the results delivered. And vice versa. 

Project success formula - results, expectations

Q: We know that many IT projects fail. What are the main reasons for this, what do you think as a Project Manager? 

A: Rephrasing the classic, I’d say that all successful projects are alike; each failed project is unsuccessful in its own way. The reasons are different. To start with, each project begins with the analysis stage that defines the mentioned triangle: scope, time, costs. Here, we identify the client’s needs and propose the best solutions.  

And here’s the first reason for potential failure: wrong analysis or estimation. Proceeding to development without a clear understanding or with unnecessary risks is extremely dangerous. This understanding also includes client and vendor limitations in budget, time, technologies, skills.  

Partially, the previous problem intersects with the issue of poor requirements preparation. On the one hand, clients may provide incomplete or inadequate requirements. Vendors may fail to complete quality requirements gathering. As a result, change management worsens, stakeholders lack control and make wrong decisions.  

The next reason is insufficient work with risks. If we don’t spot risks, don’t describe them, and don’t have proper risk management, the chances of success will decrease. Types of risks are diverse, they relate to the team, stakeholders, costs, scope, procurement, third-party services, and so on.  

The third failure reason is miscommunication between stakeholders. Let’s say, key customers just initiate the start and check the results. Simultaneously, other employees handle work communication. Thus, the risks are green-shifted, control is weak.  

In total, there are two types of problems: 

  1. Initial. These issues emerge in the very beginning. Mainly, they include misunderstandings and poor business analysis. Further, they lead to extra risks.  
  2. Ongoing. These problems appear during the project, at any stage. Here, we have poor communication, lack of focus on core features.  
Project success - classic quote

Q: It seems that project succesdepends on many factors. Are there the most essential rules to follow to guarantee good results? 

A: Based on my experience, all projects are unique. That’s why universal factors simply don’t exist. Here’s a quick comparison. In terms of complexity, clients often think that software development is similar to getting a new car. They say that if you want to get a cool BMW, you just purchase it from a dealer and can use it immediately. However, software development is completely different. In this case, you don’t buy a ready-made BMW but ask to design a brand-new vehicle that hasn’t existed before at all. It’s important to understand that development from scratch is always unique. 

If you choose critical rules that affect nearly all projects, I’d focus on these:  

  • Sufficient communication during all stages. 
  • Detailed planning and understanding of client goals. 
  • Timely risk identification and mitigation. 
  • Attention to budget.  
  • Adequate expectations.  

Q: And how does the vendor help the client? Are there any extra values apart from software development? 

A: We, as the vendors, always love working on projects that seem potentially successful. As we dive so deep, we know the smallest details that play for and against the project goal. That’s why we guarantee delivery on time, on budget, and on scope. Our teams deliver professional BA through the careful gathering of functional and non-functional requirements. And our clients get full control over their projects, budgets, resources, changes, and schedules.  

Mainly, it’s possible thanks to the Customer Portal – dedicated platform for clients who can oversight projects through it. It establishes full transparency, creates a single source of truth, provides C-level reporting and communication.  

About communication and miscommunication 

Q: You mentioned communication between clients and vendors as one of the core success factors. As a PM, you should know a lot about it. How is the process organized? 

A: The first step is to identify key stakeholders at the client’s side and their areas of responsibility. Further, we should understand their availability for regular communication, as well as the preferred methods: phone calls, emails, etc. The next task is to answer how and when we contact, what we discuss, which things we share.  

As a PM, I think that it’s vital to notify the client about the development state, issues, risks, factors that affect the performance. As well, it seems that a combination of personal communication and visual materials works the best. We use reports, call minutes with main notes, etc. Finally, it’s important to respect formal channels such as email as they’re tailored for business agreements. 

Project communication rules, steps

Q: Is communication always smooth and fine? Which problems may appear?  

A: Not at all. There are a few significant problems that make cooperation more complicated. For example, exhaustive communication drains a lot of resources. Here are the most common types and issues: 

  • Irrelevant off-topic discussions: to deal with them, I use agendas and set time limits. 
  • Micromanagement: clients want to control everything, for this, we offer detailed metrics. 
  • Avoidance of responsibility: we use the RACI matrix with close-ended questions. 
  • Too many communication channels: it’s important to agree on the channels beforehand.  
  • Several stakeholders from the client side: so, we have to contact a lot of persons, and to deal with conflicting requests and to help to find the base ground. 

Q: What are the potential consequences of misunderstandings between clients and vendors? 

A: Ultimately, the vendor’s goal is to make clients satisfied, fulfill the requirements, and to help them reach their main project goals. If a customer has specific expectations but can’t share them with partners, they can’t meet them. As a result, the initial scope changes, new costs arise, the vendor spends more time making new and new changes. The team loses its motivation, decreases productivity. Eventually, the project may fail, and the client will end up angry, dissatisfied.  

Problems with deadlines are the most common. Other parts of the PM triangle fail, too. Projects often exceed initial budgets and scopes due to different expectations: we plan to set smooth communication, but various misunderstandings appear and affect the entire project. 

Q: But it’s still possible to reach success, even with these changes? 

A: Yes, sure. Modern understanding of the project management triangle provides for more flexible boundaries. As long as we meet the core criteria, we can consider the project successful.  

Q: We’re building software products. Is it important for clients to be tech-savvy? And is it simpler to work on projects with people who know a lot about development? 

A: We don’t expect our clients to be tech-savvy. It’s pleasant and convenient when we can be on the same page, explain tech nuances quickly. But lack of tech knowledge isn’t the reason for worse communication. Business Analyst is a key person who is responsible for translating business requirements to the technical ones. 

The majority of clients know something about tech aspects. Let’s also look at two not as common but illustrative cases. There may be projects with tech-savvy clients and ones with completely non-tech clients. Both scenarios have their difficulties and potential issues: 

  • Working with a non-tech business owner, it’s difficult to explain why some basic things are essential. I often see that people think that we do redundant work: analysis, testing, multiple environments, etc. We spend much time convincing such partners in the importance of all software development stages, and, basically, helping them to make things done on time and budget, not overcharging them on continuous change management 
  • With a tech professional, it’s like a tailor who comes to another tailor and wants to get a new suit. He has own opinion, vision on development, and other processes. While both the client’s and the vendor’s approaches are viable, we need to agree on a single one. As a PM, I know that in this case, endless disputes may arise, affecting the scope. 

Q: So, if tech knowledge isn’t the most impactful factor, then what is it?  

A: One thing that matters the most here is the understanding of business processes. Let’s imagine two scenarios again.  

Two approaches to communication

Alice comes with a clear request – she wants to automate in-house reporting to free up her CFO from manual work, boost processes, optimize expenses. We analyze reporting tasks and propose solutions like machine-based calculations and quicker data processing. Alice appreciates this approach and gets what she actually needs. 

And Bob comes with another request – to optimize his website’s performance and make it better selling. This desire is pretty vague. There are no goals or desired values, so we can’t come with the best technological solution. Of course, we will try to help Bob by launching the business analysis phase to measure the current state, collect all data asking him about the desired target and measurable state. But issues are much more likely here.  

As you see, these cases don’t involve tech and non-tech leaders, they rely on business knowledge, and expectations.  

Q: Well, but what if the client knows the goals but can’t understand tech and dev things? Is the project doomed in this case? 

A: No, it’s totally okay. Business people don’t have to understand development processes or describe their wishes in the tech language. As I’ve mentioned, for this, we have Business Analysts. Put simply, they translate non-tech requirements into ones understandable for developers. And Project Manager, who translates back delivery progress, risk and issues into the language that can be understood by clients. 

The golden advice for business owners 

Q: Daria, thank you for this interview. In conclusion, do you have one or more ultimate tips for DICEUS clients? What should they do to guarantee the project’s success?  

A: I’d say that it’s all about trust. Obviously, it can’t be built immediately, but it depends on mutual respect, the cooperation of both parties: developers and clients. As well, it’s essential for all sides to have a clear vision of the client’s business goals and measurement of success. Combining trust and this understanding, a business owner can specify his or her requirements, and we can suggest the best development ways.  

Guaranteed software project success with a free 30-minute strategy session!

Get started