Defect analysis and project manager

Defect analysis and project manager

Defects and bugs are in every project. And the project manager is at the center of events. However, too many defects can cause chaos in the project and create serious trouble for project managers.

The most common causes of defects are usually misunderstood scope, change of scope and the category of poorly described requirements is most affected. If we look globally at the big picture, these three most affected causes of defects found may be due to the poor work of all teams and all stakeholders as a whole. Reference: “Defects analysis in Project Management and development”, (BVOP.org) https://bvop.org/learn/pmdefectsanalysis/ On the other hand, the role of the project manager is at the core of these three categories. This is because the reason for a misunderstood scope can be due to several reasons. For example, the lack of sufficient competence on the part of the project manager and individual teams to understand and apply the scope specified by the client. Here we can say that the basis of the problem is the lack of clear and complete communication on the part of the project manager with the client. Another example is the lack of responsibility and professional attitude on the part of the project manager to specify all the details with the client. Here we can add possible situations such as lack of motivation, focus, and commitment.

The change of scope covers most of the teams together with the project manager. This reason may be a consequence of a dissatisfied customer who, based on a sample or result obtained at some stage of the project, is not satisfied with the quality or performance. In this case, the defect may be considered as a complex liability. Both the technical team and the product manager, IT specialists, and the project manager. There is a possibility that the project manager has not provided in his initial plan enough additional time in case of a request to change the scope, which would negatively affect the project and create a precondition for the occurrence of defects. In this case, the beginning of the problem in the event of a change in scope would be the wrong planning by the project manager. On the other hand, the change in scope may be required by customers who do not have a clear vision of their product from the beginning and often send a request to change the scope. In this situation, the role that has the greatest impact on the project concerning the occurrence of defects would be the role of the client or stakeholders. Reference: “Project management with multiple projects and stakeholders”, 2020 https://www.nebraskasocialstudies.org/project-management-with-multiple-projects-and-stakeholders/

The role of the project manager

The role of the project manager is key in the presence of such a problem. Reference: “The Project Manager and their responsibilities – how to become one”, 2019 https://wikipedia-lab.org/who-is-project-manager-responsibilities-and-how-to-become-a-project-manager/ Requirements are one of the most important units for the successful implementation of a project. Without their full understanding and without being described in detail and meaningfully (so that they meet all the criteria), the project can fail from the very beginning. Each client has individual requirements for each project and they guide the real part of the project. If the project manager did not request more information, clarification, or addition to the already provided requirements, then the project will be threatened by the appearance of defects as a result of development. In case the project manager ignores the poorly described requirements, then the technical or engineering team (or any other affected team) should escalate the problem of poorly described requirements again to the project manager. This is a possible scenario in real practice because the technical or engineering team (or any other team involved) will be prevented from working fully on the project. The lack of information in the poorly described requirements can affect various stages of development such as modeling, modification of detail, functions, control, materials, and others. The defects that have arisen here would be of very serious proportions and would in some cases lead to irreversible processes, large monetary and time losses.
Lack of communication, stress, and tension are other fundamental factors for poor productivity, lack of motivation and energy in teams. All these indicators may be due to poor management and consequent lack of established successful rules and strategies. The role of the manager is to control the processes and teams, the levels of stress and tension and to create a healthy work environment through daily communication with the members of his team. At the mental level among teams, a manager would be successful in his role only if the role of manager was replaced by the role of mentor.

How to reduce defects in the project?

First of all, I will take care of the better and more accurate tracking of each defect and description of its cause. For these purposes, as a project manager, I will make sure to inform my team about the seriousness of this task and will require results and possible optimization solutions from each team monthly. The results of tracking the defects will serve as a starting point in the analysis of the problem units among the teams, as well as the strengths and weaknesses in project processing. The information from the analysis will be the main reference point for future detail, optimization, reduction of time and resources for processing, which will inevitably increase the financial indicators and the incentive to work in the team.

The importance of communication

The lack of full communication is the problem of each category. Prevention for this would be the frequent but meaningful meetings, with pre-set topics of conversation. Also, another solution to reduce defects in all categories at the communication level would be to create a “Team Meeting Diary” as well as a “Lessons Learned”. This will undoubtedly help to maintain clear and consistent communication.
In this line of thinking, prevention against misunderstood scope would be to keep a “Diary of meetings with the client under project X”. In this case, the information in this diary could help to properly understand the scope or lead to questions. The answer to these questions gave a clearer picture of the scope and full understanding between the two parties.

The change of scope

Changing the scope is a possible part of any project, which sometimes depends on many stakeholders. Reference: “Change Control and Configuration Management in Project Management practices”, https://www.islandjournal.net/change-control-and-configuration-management-in-project-management-practices/ In that case, it would be more difficult to exercise control here. The decision from the client’s point of view is to agree on a fixed deadline from the start of the project, in which requests for change of scope are accepted. Let’s say that this deadline can be fixed at 2 weeks after the start of the project. After these 2 weeks, any request to change the scope will be entirely the responsibility of the client, guarantor of the project. It is good to specify that in case of a request for change after the allowed period of 2 weeks, the client is obliged to bear all associated costs. Also, that the contractor is not responsible for the project deadline in these circumstances.
To reduce the defects due to poorly described requirements, it is necessary to follow internal company standards of work as well as enhanced training on methods of working with existing customers and partners. This will help create a working model to be followed by all teams. In this way, the risk of poorly described requirements will be drastically reduced if all teams follow the imposed model and standard of work. This standard would not allow work with poorly described or missing instructions. In the presence of such, the project manager or the teams will be able to signal directly to the client and prevent the occurrence of defects in the development process.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s