Human resource management of software development projects-team configuration

A few days ago, I was invited to give a report on project human resource management, sharing team configuration issues in the software development project team. Just today, I am free to organize my documents and hope to communicate with more friends.

 

Reason:

1) software projects are people-oriented, and human resources are the most important and fundamental factors. They are the decisive resources in projects. The success or failure of a project usually depends on what kind of people are working on the project;

2) most problems, challenges, and risks in software projects are ultimately human problems. If we can better solve problems related to people, it will make the project go smoothly, increases the probability of success;

3) when talking about how a group of people work on a project together, the first thing to consider is how the team is configured. We often see the lessons of Project Failure Caused by incorrect team configuration; therefore, this first step is also a crucial step;

 

This article aims to discuss the problem of team configuration in the project. It does not want to summarize and summarize all the problems related to the team in an all-round way, nor expect the project to succeed if the problem is solved. I just want to take out some common risks in this regard as a reminder, and try to give some solutions to avoid repeated occurrence of similar problems. Of course, there are always more risks and countermeasures than the content I share, and I hope the readers can help me to supplement it.

 

The following is a summary of some common problems in project team Configuration:

1) The project is not configured with a required team role, or a role is not configured with full-time personnel. As a result, the responsibilities corresponding to this role are not fulfilled, or the performance fails to reach the expected level; for example, the project team does not have full-time testers;

2) the resources invested by the entire team in all required roles are not balanced; bottlenecks may occur in areas with too much investment, and vulnerabilities may occur in areas with too little investment; for example, the project management team has invested too much time on the customer side and has provided too little support within the team;

3) Although the roles are complete and the resources are evenly allocated, the resource capabilities are not as good as expected, and the actual implementation results cannot meet the needs, resulting in risks; for example, a key role of the project team should be assumed by a newbie;

 

The above are all problems found in some projects, or phenomena. Compared with the phenomenon, we are more concerned with the reasons behind the phenomenon and how to avoid similar problems. So, we must ask: how does the problem of team configuration occur? How can we discover and avoid it as soon as possible? This requires the "role identification" practice.

 

Badge recognition identifies all the roles required to successfully complete a project, clarifies their responsibilities and relationships, and analyzes the skills and capabilities required to correctly perform various duties, the process of recording the results. Obviously, we need to do three things: 1) identify all the roles required for project success; 2) clarify the roles and responsibilities of these roles; 3) Clarify the personnel responsible for these roles, skills and abilities;

 

In terms of personal experience, there are several common causes for team configuration problems. In many scenarios, some of the reasons are limited by external factors, but considering the project manager's responsibility for project success or failure, I think the responsibility for solving these problems should be put on the Project Manager:

1) The project manager does not identify roles, so it does not clarify which roles the project team needs? Therefore, we did not actively strive for these resources, or passively accept any existing resources or allocated resources, and did not consider the feasibility of resource adjustment. This led to random resource allocation, instead of being well-designed, there are problems such as incomplete roles, insufficient investment, and unbalanced roles. (My personal opinion on this issue is to do my best, listening to destiny-PM should try its best to win the required resources. Even if there is no permission, it is difficult to get the final result. There is still a difference between striving for and not fighting for it. At least seriously analyze and think about this issue, it is also good to communicate with relevant personnel about the possible impact of this problem );

2) obfuscated the concept of roles and members, or the project manager did not consider the feasibility that a member can assume multiple roles. The feasibility of One-and-multiple-roles is still available in many places. As long as you can find a way for Members to have multiple roles, even if the team is small and requires more roles, the roles can be configured one by one. (Obviously, the effect of configuring this role is better than that of not configuring this role. The effect of configuring a full-time employee is better than configuring a part-time employee. However, it is often limited to the existing conditions, the alternative is to use part-time configuration .)

3) The roles and responsibilities are not clearly defined. This is often the result of the absence of PM to define roles and describe roles. As a result, some roles and responsibilities are not clearly defined by the owner, these responsibilities with no clear owner are often not properly fulfilled.

4) Some roles do not work well to allow the same member to assume the same role. Many PM also considered the attempt to allow the member to have one or more roles, but they often give up after a simple attempt. I did not think carefully about which roles are suitable for merging, and which role colors are not suitable for assuming roles. In fact, there are also many problems and countermeasures. For example, in terms of software development, if the development and testing roles are both roles, there will be a conflict between the attacks, however, if it is changed to cross-test, it can be avoided as appropriate.

5) The team configuration cannot be dynamically corrected. As the project progresses, such as the stage changes, the members change, or the work content changes, the role configuration needs to be adjusted accordingly, if PM does not rethink team configuration at this time, it is easy to retain the previous team, but the configuration is different from the actual needs.

 

In conclusion, how can we discover and avoid team configuration problems as soon as possible? The answer is simple, that is, the PM should first and periodically identify team roles, compare the identified results with the current situation of the project team, and adjust the error in a timely manner, and actively exert their own influence to improve the team, to obtain the required resources, but if it is not enough, leave for the second place and consider part-time solutions. In addition, during the exchange that day, a friend mentioned the training. This is a good supplement, especially when the resources and skills do not match the project requirements, is a good choice.

It's always inactive, and there may be a lot of inconsiderate details, including. As long as my simple sharing can bring a little inspiration or thinking, and can play a role in attracting others, I am satisfied.

 

PS: the problem of team configuration mainly corresponds to Chapter 9 Human Resource Management Section 1-preparing human resource management plans in PMBOK.