Project Management Institute

A socio-technical model of project management

img

EXECUTIVE NOTEBOOK

Joan Knutson

Project management is a delicate balance of social and technical factors. This model shows how both are needed for effective project management.

The discipline of project management broadens and expands with each passing year. Ten years ago, it was viewed as administering schedule, cost, and resource data. This is still true. The planning, monitoring and tracking of tasks' start and end dates; the hours of commitment of human and nonhuman resources; and the dollars allocated to the commitment of those resources over time is a major part of the project manager's job.

Managing this type of data can be referred to as the “technical” side of the Socio-Technical Model of Project Management. The other side, the “socio-” or social aspect, addresses the management of the team/group dynamics within the project. This social part of project management has become more and more important through the years. Furthermore, the role of the project manager has become one not only of coordinating the tangible data around the project, but also one of becoming proficient at dealing with the intangible, behavioral aspects of the discipline.

Let's be more specific about this Socio-Technical Model of Project Management. Let's suggest that the model is made up of six subsets, each of which has a social, or people, facet as well as technical facet. These six subsets are: policies and procedures, resources, competencies and personalities, management and rewards, performance and metrics, and automation.

Policies and Procedures

A project management environment requires a set of rules by which the game is played. These are the policies and procedures that delineate who does what and when in the project management process. Examples of policies and procedures are authorization expenditure levels, status reporting requirements, and change of scope procedures.

Technical. If the project management culture in an organization requires rigor and structure, these policies and procedures can be documented to a level of detail that affords no possible chance of misinterpretation. In other project management cultures, intensive policies and procedures are not considered appropriate. The rules are conveyed more as flexible guidelines that are open to interpretation. Project management methodologies of either type are available off-the-shelf, ready to be customized. In extreme cases, some organizations develop the policies and procedures on the fly and they are handed down from one project generation to the next by word of mouth. However they are documented, policies and procedures provide project players with the technical direction to get their jobs done.

Social. Writing and distributing policies and procedures does not necessarily make them reality. There is a social aspect in this segment of the model. People who are asked to use the policies and procedures should have been part of their development so that they believe in the rules enough to follow them. Furthermore, the culture needs to support adherence to these guidelines and rules, for the good of the organization and success of the project players.

Resources

Projects succeed or fail by the availability of resources required to perform the work. These resources can be people, equipment, materials, transportation, and so on.

The role of the project manager has become one not only of coordinating the tangible data around the project, but also one of becoming proficient at dealing with the intangible, behavioral aspects of the discipline.

Technical. Analysis of what resources are required, how many resources are required, and when the resources are required is accomplished through a series of mathematical calculations. Allocation of the resources on a week-by-week basis is done through a process called resource loading. And if resources are overloaded or unavailable, the problems are solved using resource leveling techniques.

Social. However, all this number-crunching isn't the last word. Remember, in many cases the project planner performing these technical calculations has no authority or ownership of the resources required by the project. Therefore, the project planner must use his or her political and people skills to obtain commitment of the resources.

Competencies and Personalities

Projects are driven by people—not by charts, graphs and numbers. Abilities, both technical and behavioral, are key to getting the job done. This issue is beyond resource availability. This part of the Socio-Technical Model entails getting the right people on the right projects.

Technical. How do we match the correct people with the correct talents to the appropriate tasks? Each task on the work breakdown structure requires particular technical skills. The skills may be those learned at the university or in vocational training; they may be skills learned through advanced adult education, or on-the job. For example, does the project need a computer science graduate who is trained in COBOL programming? Or does the project need a very special type of COBOL programming to be employed on one particular hardware platform? Or going one step further, does this unique type of COBOL programming have to follow specific standards developed by our Information Systems organization? “Competency” means meeting a level of proficiency in specific skills.

Social. It's great when a project has the perfect, technically qualified people assigned to it. But what if there are not enough people with the competencies needed for all the projects? Or what if these perfect technical people can't get along with each other? Then the “politics of projects” rears its ugly head. This is the time when training comes into play—either providing training to increase project players' technical skills, or team-building training to enhance their ability to coexist.

Management and Rewards

The project may have competent people with personalities that work well together, but what if external factors are not driving the motivation of these perfect people? Management provides this driving motivation by setting the tone of the project culture. What if management is not giving clear direction, or what if the people who are attempting to do the best job possible are not being rewarded for all their hard work?

Technical. The technical side of the management and rewards aspect of the Socio-Technical Model revolves around the clarity of roles and responsibilities, and the criteria upon which rewards will be given. “Who is in charge?” needs to be answered to clarify roles and responsibilities. Each person needs to know what he or she is authorized to ask of others, what funds are allowed to be spent, what changes can be committed to without asking permission. Knowing one's boundaries is part of the battle. The other part is “What's in it for me?” Technically, that is resolved by implementing a straightforward performance appraisal review process in which the project leader is one of the key contributors to each project team member's appraisal.

Social. Again, in the technical aspect, we looked at the tangible rules and regulations. The social side of the issue revolves around management's awareness of the benefits and problems of project management. If management is aware (assuming they are qualified to manage), the support that makes project management successful will be available. The reward systems will follow. If management appreciates the job that is being done by the project players, they will see that these project players are rewarded.

Performance and Metrics

Much of what we have discussed so far is based on setting criteria upon which success can be measured, decisions made, and policies and procedures kept up to date. This is accomplished by keeping track of what is going on within the organization, and within the discipline of project management in other organizations. This means the compilation of performance standards and metrics against which current work can be graded, and from which future work can be planned.

Technical. Historical databases are compiled. For example, history can be compiled on reward structures across various projects within the organizations, benchmarked against other similar companies that do similar types of projects. Another example might be building a database on the actual commitment of specific resources during various projects to determine whether our resource loading and leveling techniques are valid. The technical aspect of performance and metrics is data accumulation and correlation.

Social. The social concern around building the technical historical databases described above is twofold: (1) how do we convince people we are not accumulating this data as the Gestapo would, trying to catch someone in a misstep, but because it will make us smarter project professionals in the future, and (2) with people as busy as they are, how do we convince them they have time to accumulate the data necessary to create a credible set of metrics and thus define acceptable performance?

Automation

Most of what I've talked about relative to the technical aspect of each of the sections above could be supported by automation.

Technical. The software of today and the upcoming software of tomorrow will make it easier for all of us to build databases, allocate resources, and determine competencies, training requirements, and commensurate rewards for our people. It is our job as project management professionals to explore the types of software available, to pick and choose products that will make our project organizations more effective, and to implement these products in an intelligent manner.

Social. Even though the technology is available, the social side of this issue is more difficult. Will people use the software? Will they care enough to enter data with integrity rather than just entering any data to get the job done or to hide their mistakes? Are they trained to use the software we give them? To make software support all the other aspects of the technical model of project management, we will have to be most concerned about the social issues.

Summary

By breaking the project management discipline down into six subsets, we've taken a different cut at analyzing the project management discipline. Each subset affects the success or failure of a project organization. And both the technical and the social (or behavioral) aspects have an impact on each subset.

The Socio-Technical Model of Project Management explores both aspects of our discipline. And as we explore, we should keep in mind the delicate balance and interdependence of both the technical and social attributes of the projects we are attempting to manage. ▄

Joan Knutson is president and founder of Project Mentors, a San Francisco-based project management consulting and training firm.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.

PM Network • August 1996

Advertisement

Advertisement

Related Content

Advertisement