Transparency in Project Management

 

Transparency is a business and engineering concept that describes how easy it is to see for everybody what is going on. It is especially important in Project Management as it involves multiple people working on the same tasks, interacting each with other, and solving common problems. This article is going to show some of the most common issues that appeared in Project Management and explain the difference between transparent and non-transparent ways to solve them.

If you are an experienced business person and know all the issues that may appear on a project, then feel free to scroll down to a solution. All other readers may proceed further and look at these problems in details.

Let us use a real-life software engineering project with a simple structure as an example. This example project involves one Customer, one Project Manager, one Software Architect, and three Software Developers.

Organizational Problem

Organizational Problem

Something did not go as planned, and organizational changes are needed. A Customer asked to redesign a feature — Project Manager has to clarify requirements, Software Architect has to redesign an architecture, Software Developers have to rewrite code.

Transparent Approach. The issue is clear for all team members, and they know how to deal with it. A Project Manager discussed new requirements with a Customer and informed all other team members about the changes via email. Software Architect designs an alternative architecture, draw several diagrams, and then discussed a new approach with Software Developers. Software Developers provided an estimation, checked with Project Manager when will be the best time to implement this feature and scheduled an implementation.

Non-transparent Approach. The issue is not clear, a solution may be wrong or incomplete; not all team members are aware of the problem. A Project Manager did not check all the requirements with a Customer and informed only Software Architect about the changes. Software Architect got incomplete requirements, designed a simple solution that does not match all Customer needs, and explained to Software Developers what to do. Software Developers are not aware of the original Customer requirements and have only an architectural breakdown without functional requirements. The implementation is scheduled for the very end of project development as feature priority was not defined.

Communication Problem

Communication Problem

Some team members do not have access to all information. They do not have an ability or do not want to discuss some issue. A Customer constantly asks to demonstrate him visual changes in an application, but Software Developers do no do that or do that only if extra time left. In their opinion, these changes are not that significant to show them.

Transparent Approach. Identify the issue and discuss it with all the involved team members. Agree on the solution and do it in a way that will not introduce additional communication problems. A Project Manager should check the overall priority of the features with Customer, explain Software Developers Customer's preferences and then build an agenda for the demo meetings. Software Developers should check this agenda with the Customer before each demo meeting, introduce changes if needed, and then follow this agenda. 

Non-transparent Approach. Existing issues only hidden but not solved. A Project Manager persuaded a Customer that visual changes are not that important. Software Developers are continuing to do not pay extra attention to user experience. The final application is painfully hard to use because of visual and UX issues.

Financial Problem

Financial Problem

Any budget limitation introduced after the project start. Lack of budget because of the extended scope of work. A Customer asked to add additional capabilities to existing features, but keep the budget the same.

Transparent Approach. Participants need to find an alternative that will satisfy all the needs without blowing a budget. A Project Manager discusses with Software Architect possible alternatives and workarounds. Need to discuss the chosen alternative solutions with a Customer and select one of them. Software Developers implement a new solution according to changed requirements with the same budget.

Non-transparent Approach. The budget limitation is taken into account only at the higher level without proper reorganization of work. The only solution is to remove essential activities from the scope of work. A Project Manager cuts the budget for quality assurance and performance testing. Team has no time to do that and skips these phases. The final application is slow and has tons of issues.

Time Allocation Problem

Time Allocation Problem

Any time limitation introduced after the project start. Lack of time because of the extended scope of work. A Customer significantly improved the amount of data that should be in a database. It requires architectural and code-level changes and raises the amount of time needed to import data.

Transparent Approach. Participants need to find an alternative within the specified time limit.  Software Architect, together with the Project Manager, checks the source of the new requirements. Need to discuss with a Customer alternative faster ways to perform an import and find the solution. Software Architect introduces changes in data storage layer architecture and import tools.

Non-transparent Approach. The time limitation is taken into account only at the higher level without proper reorganization of work. The scope of work decreased by removing essential activities. A Project Manager explains to a Customer that the application can not handle such amount of data without performance issues. A Customer agrees to have a worse performance to have the product finished in time.

Resource Allocation Problem

Resource Allocation Problem

Lack of physical resources (office, computers) or virtual resources (cloud environment). Not enough human resources to do a project. One of the Software Developers left the project for one month because of force majeure.

Transparent Approach. Discuss the issue with all team members. Try to find a substitute resource or decrease the scope of work. Project Manager, together with Software Architect, discusses possible ways to deliver requested features with only two developers. If no reasonable solution found Project Manager can discuss the least essential functions with a Customer and postpone their implementation.

Non-transparent Approach. Each team member solves the issue in his way. A Project Manager agreed with a Customer about a smaller scope of work. A Software Architect designed a less complicated solution to compensate for the lack of one Software Developer. Two remaining Software Developers decided to do not write tests and documentation to implement features in time.

Qualification Problem

Qualification Problem

One or multiple team members do not have the qualifications or experience to do the job. Software Architect does not know the technology stack of a new project. Software Developers never used the required framework. 

Transparent Approach. A Project Manager is aware of the qualification problem. Need to schedule and conduct additional training before the project start for Software Architect and Software Developer. Under-qualified team members substituted with more qualified people. 

Non-transparent Approach. A project started as is with under-qualified team members. Project goals not achieved. A solution designed by Software Architect has poor performance and not scalable. Lots of bugs on code level introduced by Software Developers. The final application is unusable.

Transparency as a Solution

Yes, some of the described problems might look a bit artificial or even silly. However, the transparent approach for all of them has a very similar structure. Let us check what it is.

Issue identification. It is the very first thing that you have to do. It is required to understand what is the issue, what areas are affected, and why this issue exists. Sometimes it may appear that this is not an issue at all, so there is no need to solve it. Sometimes the problem might be much bigger than it looked like at first glance.

Team awareness. All the team members that might be affected by the issue must be aware of it and have access to related information. It gives a better understanding of an issue scope, guarantees a quick response, and allows planning following steps.

Discussion. This stage may include multiple activities, depending on the issue. An initial analysis is used to provide general information and explain the scope of a problem. You may organize as a brainstorm or a regular discussion to find a solution. Then all the alternatives have to be evaluated, and you have to choose the one that suits the situation. 

Solution implementation. It is the part when you need to act. If you did everything else correctly, then it requires minimum organization activities.

Summary. Need to check and analyze the impact of the issue. Additional actions required to prevent such problems in the future may be discussed and planned for future implementation.

It is easy to see that transparency is pretty much essential at every stage of any problem-solving process. However, it requires maintaining proper communication inside a team. As a consequence, your team can handle pretty much every problem with the minimum impact to a project.