Or Why You Should Listen to a PM on the Vendor’s Side
First of all, it’s essential to mention that such a role of a Project Manager (PM) in Agile methodologies doesn’t exist in its classic form. Agile implies that functions, responsibilities, and duties are shared between team members. For other methodologies, a project manager is the one who is responsible for the whole project’s success. For a client, who asked to develop a tailored solution and came to a software development company for outsourcing, a project manager is one of the most important team members on the project. The reason is that throughout the work, they need to interact closely. It is no longer required to control the entire team personally. Also, there is the only one responsible manager who knows absolutely everything that happens with the project. Besides, a person with a PM role has all the necessary knowledge and skills to effectively and efficiently lead the entire team to success. It may become critically important to be responsive and listen to the project manager on the side of the development team. Let’s consider why.
A willingness to control the development process bypassing the project manager’s opinion leads to such adverse effects as:
- project delays
- demotivation of the development team
- violation of contractual obligations
- additional costs for unclaimed functions
- loss of trust
- and much more.
These consequences mainly take place in cases of misconceptions about the role and responsibilities of a project manager in software development. We’d like to make things clear. In the position of a project manager, a person fulfills 4 main functions:
- Planning. Project manager’s planning duties include defining and clarifying project scope, developing a project plan and schedule, assigning tasks.
- Organizing. Setting up the project team’s structure is about organizing. A project manager must determine the optimal number of specialists, their experience, and positions.
- Leading. Project manager’s leading duties include coordinating team to work as a whole, motivating, managing team dynamics, etc.
- Controlling. As for control, last but not least, it includes such activities as checking current project progress, finding schedule deviations and their causes, and developing correcting measures.
Interfering with the PM’s work and the role of a project manager in software project management, a client can create extra load to the whole development team. The intention to get full control may not be the only reason for issues during the work on the project. Below you’ll find examples of situations that periodically happen and can have a significant negative impact on the entire project. A client who wants one’s project to be completed as quickly as possible, efficiently, and without unnecessary, unwanted anxiety should consider this information.
Read Also Project Management Steps that Should Be Taken for Successful Project Launch
Anti-cases. Some Examples of Negative Customer Impact
Some projects run smoothly, and some don’t. To illustrate poor impacts, let’s dive into typical situations to be avoided at software development projects. These anti-cases will partly cover the topic of customer-PM miscommunications and describe the things a client should consider to avoid unrealistic expectations that can harm the project and explain what is expected of a customer. In both cases, since the project managers are at the forefront of the process, any questions that arise will become the subject of their interaction.
Example 1. Direct communication with developers
A client or a representative thinks that a PM isn’t able to convey some valuable comments to the development team. A client requires access to developers to communicate directly.
What is not taken into account is that before a developer will implement, add or remove some functionality, one has to know how it will affect the whole system. Moreover, different people have different levels of communication skills, which may also poorly affect the end result. Frequently, a customer bombards general chats with personal requests, which can make roles and responsibilities too vague. As the communication did not go through a PM, changes to the system may not be reflected in the documentation, as developers do not have such responsibilities.
Example 2. Lack of sticking the timeline predefined
In some cases, a business requires to speed up the development process that was previously scheduled. It may cause more bugs in the final product as there is no time to perform the full range of required tests. This may lead to the result dissatisfaction.
Example 3. Product demo and the product itself are two completely different things
It happens that a client mistakes a product demo for the product itself. Much time is spent on the demo detailing, adding various functionalities, improving the design, and many other things. As a result, the budget is spent, and the product is not ready. The case is more general than specific for customer-to-PM interaction but rather common to ignore it.
Example 4. Absence of access to customer’s systems
Sometimes, a client or a person in charge may not attach importance to such vital things as a deployment environment. How can the lack of deployment environment information or absence of access to client’s systems affect the final result? Сritically. It’s essential that a development team has access to the customer’s systems where the final product can be tested. Even if in the developer’s environment, the product runs perfectly, on the customer’s side bugs may appear. Since they can’t be reproduced by developers, it’ll be hard to fix them, and such a task will require a significant amount of time. Developers will have to work “blindly” to fix the bug, which will increase the cost of the product but won’t guarantee success. Since the number of such bugs can be counted in dozens, this situation invariably ends with tension between the parties and leads to the customer’s dissatisfaction.
Example 5. On-the-go changes with lack of task description and clear mockups
Making any changes to the product needs time. When it’s done on the go, as an experiment, or just for a try, the lack of task description and clear mockups may cause endless alterations. Misunderstanding between a customer and a PM may take place in such cases.
Example 6. Multiple communication channels
It’s not bad to use one-two sources for communication between a customer and a PM. It reduces message retrieval time and structures communication and information storage.
But often tasks are defined via Slack, reports are sent by email, big files are transferred via file sharing, etc. The longer the project, the more difficult it becomes for a PM to find the needed confirmations, agreements, files, etc. Usually, the result is time losses and excessive tension. So the advice is to reduce the number of communication tools and use them as agreed during communication with a PM.
Example 7. Decentralized team (with lack of experience)
It’s a common situation when a client wants to reduce costs by outsourcing the project to specialists with lower rates. The logic may resemble the following: to get a good product I need the best programmers, but it’s not so necessary to overpay for highly professional QA specialists, business analysts, and other specialists. At first sight, this makes sense, but in real life, it causes disappointments.
Let’s take a look at inexperienced QA testers as an example. They may describe the same bugs several times, create bug reports that lack specific information, confuse tasks in bug tracking systems, and cause a lot of harm to those developers who have to deal with their work results. Developers’ rates are higher than QA’s. The more time a developer spends to refine the details, the more expensive is the development process for the client. Thus, there is a risk that inexperienced specialists of the decentralized team will indirectly spend customer’s money, although this will be a hidden process. The problem is that a PM on the vendor’s side won’t have any real chances to affect this situation, as the specialist overseas is not directly subordinate to him. As a result, a customer blames the wrong side for wasting money. Developers and testers inherently have different priorities when it comes to testing, but using new technology such as AI and ML allows for a more data-driven, objective approach to QA.
Conclusion
For a customer, having a PM on a project is an advantage. It means that there’s no need for personal involvement and project control. Also, there is only one responsible person who knows absolutely everything that happens with the project. As a rule, negative scenarios can be avoided by listening to the project manager to whom you entrusted your project. PM is more than anyone else interested in compliance with your agreements and your end result satisfaction. Nevertheless, in cases of an unfavorable scenario, it makes sense to carefully listen to his opinion, since you may not take into account some significant aspects of development. You may also additionally read one more article to learn why projects can take longer than planned or get a free consultation to find answers to all your future project questions.