How does project management manage people with differing abilities?

Question

I once worked on an application programming project with three main tasks:

1. Build a system for analyzing a user situation
2. Integration with another piece of software
3. Organize the main architecture of the application

I would have been excellent at task 1 and terrible at task 2. My first coworker would have been fantastic at task 2 and terrible at task 3, and my second coworker would have been great at task 3 and terrible at task 1. Instead, we each got assigned the task we were worst at, and the app was a year over budget and about half the quality it could have been. Each of us was great at one task and lousy at one, and yet we all had the same job title.

How does project management address the issue of managing people with differing abilities?

Answer 1

There are a few factors to consider.

One would be the type of team. If the team is self-organizing, the individuals would not be assigned to tasks. Instead, the team would determine who should be involved in what tasks and what their level of involvement is. In a more directed team, a manager may be responsible for assigning the work to people.

The leadership style of the manager is also a factor. Some leaders and managers are more hands-off. Others are more involved, but focused on growing and developing the autonomy of the team. Others are more focused on directing toward goal achievement.

Regardless of the team and manager, there are some tools that can help the team make more informed decision. One tool that stands out in this situation would be a skills matrix or a competency matrix.

A skills matrix identifies the knowledge and skills needed by a team to achieve a project. In a software project, it could include things like programming languages, frameworks, tools and technologies. It may also include topics from the domain and knowledge areas like requirements engineering, architecture, design, and communication. Each individual on the team is rated in their knowledge and it makes the strengths and weaknesses of each individual more visible. It can also highlight gaps where the team may be missing key knowledge or skills that may be needed to execute on the project.

The tools can only help make things visible and understandable, though. If a skills matrix shows a gap in knowledge, someone has to work through this risk. It's also up to someone to look at the matrix when organizing and allocating work and use the information. It's also up to someone to maintain the matrix as the team's understanding of the necessary knowledge and skills changes.

Answer 2

You assign a human to a task the exact same way you assign a tool, albeit humans are more complex. The process of assignment is the same. If you need to cut something, you are not going to use the hammer. If you need to attach something to another thing, you are not going to use a chisel.

As a PM, you know the work package that has to be done, you know the raw materials that are needed, you know the tools that will be used, you know the human knowledge, skills, and abilities that are needed, and you know the quantity of all those things. If you are unaware of some of those elements, then you're not doing the PM job very well.

Answer 3

TL;DR

How does project management address the issue of managing people with differing abilities?

I don't think there's a single, canonical answer to this question. The approach depends on the project management framework, the skills and experience of the project leadership, and the company's culture.

As just one example, Scrum side-steps the problem of inefficient or counterproductive top-down or external assignment of tasks through the use of self-sufficient and self-organizing teams. The 2021 Scrum Guide states:

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

Other frameworks have other approaches, but the underlying problem you're describing is systemic and needs to be addressed as an organizational systems and process issue.

Some Useful Rules of Thumb

While there's no "one size fits all" answer to your question, the underlying problem of how to address skills and and tasking is inherent in the practice of effective project management. Each framework and practitioner is likely to have a slightly different approach. However, there are certainly some broad rules-of-thumb you can apply. These should generally include some or all of the following:

1. The project charter should clearly define the objectives of the project. People with knowledge of the problem domain should then be able to identify the key skills required to meet those objectives.
2. The budget for the project should be sufficient to ensure the project can be staffed with people with all the required skills, or contain budget for training people attached to the project on any missing skills. Pro tip: this isn't really an either/or thing; a good budget generally has buckets for both subject-matter experts and upskilling.
3. Team composition should generally contain all the skills needed to produce the project's deliverables. For example, most agile frameworks such as Scrum recommend that the team be cross-functional and self-sufficient to reduce (if not eliminate) reliance on external resources as much as possible. This in turn reduces drag and friction on the project, and enables better resource and process management within the project.
4. Agile frameworks generally rely on pull-queues, T-shaped people, and just-in-time planning. Collectively, these argue against the use (or even the value) of top-down task assignments. When done properly, projects formed around these principles avoid most of the problems you describe in your original question where you state that "We each got assigned the task we were worst at[.]"
5. Two key responsibilities for the project manager (or whoever is responsible for the framework implementation of the project) are communications facilitation and progress tracking. If the project is out of tolerances because of poor processes, insufficient tools or skills, or for any other reason, it is the role of project leadership to communicate the process issues to the team and to senior leadership. Unless problems are hauled into the light of day for inspection and adaptation, nothing will change.
6. Always remember that senior leadership is ultimately responsible for budget, staffing decisions, and company culture, and that they inherently own the outcome of any project. As a result, if they can't or won't help the team improve a defective process then they are most likely a key cause of the defective process. Q.E.D.

In my own professional experience, there are very few process problems that can't be solved by better communication and outcome-based progress tracking. Likewise, there are are almost no problems that can be solved by micromanagement, a refusal to address systemic organizational problems (e.g. poor hiring or team-formation practices), or a focus on individual utilization rather than outcome-based metrics. Push the former, avoid the latter, and you can generally improve almost any project.

Just remember that there's no silver bullet. Regardless of your framework or process, success is never guaranteed.

Answer 4

I once worked on a application programming project with three main tasks:

1. build a system for analyzing a user situation
2. integration with another piece of software
3. organize the main architecture of the application

These are exactly what you said: tasks. Developers should be working towards 'goals'. The goal being: deliver quality product in a reasonable timeline using all the resources & skillset available in an efficient manner.

Delivering on the goals as specified is extremely challenging:

• if there is 0 skillset/knowledge overlap
• if there are 0 resources available
• if timeline is yesterday
• if scope is not defined

You see, the above are extremities / worst case scenarios. You don't want worst case scenarios in your project. If you do have them, address them as quickly as possible and keep higher-ups notified until they are resolved. Once resolved, give your team credit, celebrate and highlight it as a achievement. Market it within the organization like you just landed on the moon or found a cure for fatal disease. Make it a big deal. It really is, so don't undermine the initiative and effort.

To improve skillset/knowledge overlap; create design & code walkthrough videos archive, have pair-programming sessions in early stages of the project, have another member perform testing/validation so that they can align perspectives and understanding.