Establishing Reporting Relationships

Establishing Reporting Relationships

When the staffing management plan has been started and assignment of people to roles has been done, the project manager can then define the reporting relationships expected to execute the project's activities. Organizations get depicted for a software development project in many ways. The first and most obvious representation of reporting relationships is the classic organization chart. In large project organizations, these can get messy-looking if taken to the lowest levels of the organization. Sometimes they bruise egos, too. Another kind of chart depicting relationships is the organization breakdown structure (OBS) for the project, which relates parts of the organization to the work breakdown structure (WBS) elements and shows which organizational units are responsible for which work packages. Fundamentally, the organization chart shows who gets direction from whom, and it identifies the paths of control for execution of the project activities in the WBS. The OBS shows which pieces of the total product are assigned to a given work group. These are useful representations for large projects, but they become awkward for small projects, where the WBS is comparatively small and individuals carry out the work packages.

Another useful tool is the project directory. This is simply a list of people working on the project, with appropriate contact information and group identity. It may even list stakeholders who are not part of the direct project team. This is useful to help maintain project stakeholder relationships. Even if all the team members come from the same company, grouping the project members in a separate directory is handy and useful. It also helps provide a sense of group identity. When the team members are extensively dispersed and come from different companies or organizations (such as subcontractors), the directory becomes even more valuable.

Responsibility Assignment Matrix

One of the most useful tools for dealing with resource assignments is the responsibility assignment matrix (RAM). This sometimes appears under other names, such as responsibility matrix, staffing matrix, linear responsibility chart (LRC), or some variation of these names. The RAM clearly identifies an individual's responsibilities and roles for work products and activities. It defines who does what for the project activities, and it can easily be expanded into a work product progress tracking sheet. The fundamental components of a responsibility assignment matrix (RAM) are shown in Figure 1.

Responsibility Assignment Matrix

Where more than one person is assigned to a particular task, the RAM can identify who has the lead responsibility, who has backup, and who approves or validates. It helps the project manager sort out the responsibility, authority, and accountability for a task. Personality and job fit are major determinants of a person's reliability in a role. Typical role assignments may be:

●  Approval - Approves the item as complete (L approves, if not indicated);

●  Lead - Has final responsibility for producing the item;

●  Secondary - Is the lead person's backup for the item, else is a C and R;

●  Contributor - Materially contributes to the item (includes R);

●  Reviewer - Has reviewer duties only for the item;

●  (None) - Is not expected to participate in producing or approving the item.

An example resource assignment matrix using the A, L, S, C, and R codes for a software development project is shown in Figure 2. It also shows how the RAM can be used to balance the workloads and to make sure that leadership roles are fairly distributed. Additional columns can be added to the right to track work product status.

Example Responsibility Assignment Matrix

Resource Leveling

Sometimes the needs for skills on the project are not suitable for the resource suppliers. That is, the timing of their participation is spotty, or "lumpy" as viewed on the resource histogram in Assigning Responsibilities to Individuals Figure 2. Preferably, you would like the roll-on and roll-off activities to occur only once for each resource on the project. For a software development project, we would like to concentrate the activities of the test engineers in the last few months of the development cycle rather than get them involved too much too early. This means that we should, if possible, try to schedule their activities on the various product components together, to maximize efficiency of their use. Often this is essential (such as with contracted labor) because the same resource may not be available later in the project. Another instance might be as shown in Figure 3, where, according to the scheduled work, we need too much of a resource in one or a few time periods, exceeding availability. In this case, we want to spread out the activities (flatten the histogram) so that usage never exceeds availability and we more efficiently use them while they are available (fill in the valleys between the peaks). This almost always lengthens the time required to complete the work, as shown by the arrow in Figure 3, but it makes the usage of the resource more efficient.

Resource Leveling

Project Management Resource Activities During Execution

Assigning resources to activities in a development project is only part of the project manager's job. Another big part is developing those resources into a working, high-performance team capable of tackling difficult assignments and adjusting to changing project circumstances as needed. The leader must manage all the different interfaces with other people and groups related to the product and the project. This is interface management, and it involves identifying, documenting, scheduling, communicating, and monitoring these interfaces throughout the course of the project.

Three types of interfaces need attention: personal, organizational, and system. The personal interface deals with all conflicts involving people in or related to the project. Because projects invariably have many opportunities for conflict, the project manager is faced with being referee and peacemaker between individuals. The organizational interface deals with conflicts due to varying organizational goals and the different management styles of the project and resource supplying organizations. The project manager must bridge the differences and smooth communication both inside and outside the immediate organization or project. The system interface deals with the product, facility, or other nonpeople interfaces developed by the project. This usually includes all the technical problems of the project. So, the project manager must manage these interfaces to balance and optimize human interaction and minimize hurdles to completing the work.


software development, wbs, project directory, responsibility assignment matrix, lrc
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2018 SPMInfoBlog.
Designed by TechPlus