The project manager - the technical skills
Concerns of Project Managers
Sam had a tedious journey from the mountain of the leadership guru. There were many steps along the way to the next mountain, where there was to be more wisdom necessary to build the raft. There were many along the way who offered suggestions. Sam noted a strange inconsistency between these people's opinions and trudged on to the top of the next mountain. There the great guru of technical skills provided some insights that made Sam confident that the raft was indeed a “possible dream.”
Editor's Note: The following introduction to this series will clarify the concept and purpose of the articles.
In the beginning there was the word and the word was “DOIT” And thus the first project manager received an assignment.
Sam's* reaction was normal for the species: “Golly, gee, what do I do now? We don't do projects.”
*Note: It is left to the reader to decide if Sam is short for Samuel or Samantha!
This is the fifth episode in the travels of Sam in search of the wisdom necessary to successfully execute this project.
Sam recalled that an earlier encounter had revealed the theory that, “You become a project manager one zero at a time.” If that is true, then there must be certain things that need to be learned first. What could these be? One guru provided a “Skill Inventory” that included leadership, technical and administrative skills of the project manager. That guru sent Sam on to visit three other project management gurus. Today Sam visits the guru of technical skills.
COMMUNICATING WITH TECHNICAL PEOPLE
One of the critical skills that differentiate a project manager from a technologist is the ability to communicate, both orally and in writing. Many people abhor expressing themselves orally in other than a one-on-one situation. If this is you, forget about becoming a project manager. On the other hand, if you avoid communicating to a group because of a feeling of inadequacy, there are some simple remedies.
Communicating with technical people requires most of the same skills that are required to communicate with other people. (This will be discussed in the next episode in this series dealing with administrative skills.) To communicate effectively with technical people you need to understand their technical concepts. Few people can be competent in more than a few technologies, but with proper formal and informal education you can understand the key concepts and principles. If your project involves the application of physical sciences, such as in engineering, it is helpful to understand physics and chemistry. The more you understand, the better. If the project involves social sciences, such as marketing or advertising, it is important to understand general psychology and sociology as well as consumer behavior.
In general, the less you understand of the other person's vocabulary, the more likely you are to be “snowed” and the less likely you are to gain the respect of that person.
Whatever the nature of the project, the project manager must have sufficient knowledge of the technologies involved to comprehend the problems involved. If the project involves engineering, the project manager must be able to demonstrate skills in at least one engineering discipline. If the project is creating a stage production, the project manager must be skilled in at least one aspect of the theater. In the beginning, you will be given a small piece of the project to manage. Indeed, you will probably do it all yourself, coordinating your activities with others who have a stakeholder's interest in that small part.
This first piece may involve a total expenditure of $1000 or so. Do it as well as you can! Remember that you are producing two things in the process: the product of the project and your boss's faith in you. If you perform well, you may be trusted with a $10,000 project. But this requires you to apply a broader repertoire of technologies. You have more to learn and demonstrate. Success at this level will likely lead to a $100,000 project. The broadening range of technologies involved will require a different type of knowledge. However, your reputation will, for the greater part of your career, depend on the technical expertise you demonstrated in these early projects.
UNDERSTAND THE TOOLS AND METHODOLOGIES OF RELEVANT TECHNOLOGY (I ES)
Each technology has its own repertoire of tools and methodologies. You need not be able to use each of them, but you must be able to understand their nature and underlying principles. For example, if the project involves metallurgy, you need not be able to run a hardness test, but it would be well to know that a Brinell is a test of metal hardness. If the project is a stage production, you need not be able to properly light a set, but you do need to recognize that a klieg is a high-intensity light. This level of understanding will help you understand what is involved in meeting an objective. It will also enhance the image that others on your team have of you and it will further reduce the probability of them being able to “snow” you.
UNDERSTANDING OF TECHNOLOGY AND TRENDS
Projects are the means of creating things for the future. On the largest, longest-duration projects, the product of the project may be obsolete before the project is completed. The project manager is often torn between accepting the current proven technology and taking the risk involved in adopting the technology that is state-of-the-art now and more likely to be a relevant technology when the project is finished. What are the risks? State-of-the-art technologies may increase the duration and cost of the project and may in fact fail. On the other side of the coin, older, proven technologies may fail to meet the performance requirements of increasingly demanding projects.
You must plan your reading and attendance at technical meetings carefully to ensure that you broaden your understanding of the range of technologies and their trends.
ABILITY TO MANAGE THE TECHNOLOGY
Understanding a technology is not the same as being able to manage that technology. Consider the “simple” technology of data analysis known as linear regression analysis (LRA). With the simplest knowledge of LRA you will be able to understand a projection into the future based on the ceteris paribus (all other things equal) assumption. If you are going to make a decision based on LRA, it would be advisable to know the five assumptions underlying the LRA model. It would be even better to know that there are tests to determine if any of these assumptions have been violated. You need not be able to perform those tests, but you should be able to ask questions about the results of those tests. For example, one of those assumptions is that the relationship between the independent and dependent variable is linear, i.e., looks like a straight line. Often, one look at the plotted data can provide a “gut reaction” about this assumption. Performing the appropriate test can give an answer that is far more reliable.
AIDING IN PROBLEM SOLVING
Working with your team members to aid in problem solving can be demanding. If it goes beyond aid, it weakens the team's ability to solve problems on their own. Don't jump in too fast! Consistent failure to aid will lead them to seek the help of others, thus weakening your ability to lead the team. Today, no one person can possess the expertise to solve all problems on a project. One person can learn to be a good listener and to ask questions using the standard reportorial words…what, where, when, why, and how. Consider the impact of comments such as:
- Tell me what you are trying to do.
- Tell me how you are doing it.
- What are the results?
- Why are the results not correct?
- Who can we call to help us understand the problem?
In most cases, the problem will be solved before asking the last question. Occasionally, you will be lucky and, often because you are less deeply involved, be able to identify the key factor causing the problem. Luck has been on my side on many occasions, especially on computer program debugging. While never a great programmer, ability to read code and see logical inconsistencies enabled me to identify coding problems quickly, sometimes to the consternation of some subordinates. This ability to comprehend what others are doing may well be the key to aiding in problem solving.
Earlier, we stated that the essence of project management is the integration of the elements of the project. This takes place in both the human and technical dimensions. In the human dimension, these trade-offs involve reallocating or reassigning resources to ensure they are adequate for both the work content and technical skill requirements. In the technical dimension, they involve reallocating technical performance requirements for components to ensure that the overall technical performance requirements of the product of the project are met in the most economical manner. This may require assessment of alternative technologies, methodologies, suppliers, materials, or components. The more complex the project, the less likely you are going to be able to perform such trade-offs. You will have to rely on other members of the team to bring their technical expertise to bear. You may even have to go outside the team, and even the organization.
What you will have to bring to bear in this analysis is the specification of the problem, the format in which information is to be presented, and the systems perspective. The latter is discussed in the next section.
Two errors that can be made in specifying the problem are focusing on symptoms and focusing on a single technology or component. Too often in both management and technical situations, the obviousness of symptoms can lead to myopia and failure to see the true problem. You must insist that the team stop long enough to assess this matter. Focusing on a single technology or component is tempting for two reasons. Team members will tend to perceive the situation from the perspective of their dominant discipline. Thus, an electrical engineer will bring to bear the most familiar tools and methodologies. On the other hand, some people will be glad to accept that it is an electrical engineering problem so they do not have to accept any responsibility for finding the solution.
The larger, more complex the project, the more important it is to have a systems perspective. Interestingly, this perspective is not held by the majority of people. Many years ago, an academic friend researched this question for a population of engineers. My friend developed a questionnaire that was able to distinguish the systems thinkers from the non-systems thinkers. Only about 10 percent of the subjects had this capability.
Very simply, the systems thinker is able to conceive of the final product of the project as an integrated whole. Dr. Jay Forrester, then at Massachusetts Institute of Technology, once said something like, “The only really valuable education for management is electrical engineering.” Dr. Forrester was reflecting on the notion that electrical engineering is taught in the dynamic mode of a flow process. That is a relevant observation for the systems way of thinking. The systems thinker is able to consider the dynamic nature of things. Those who are systems engineers could add a great deal to this discussion. They are invited to do so.
UNDERSTANDING OF MARKET AND PRODUCT APPLICATIONS
The greater the number of zeros in the total project budget, the greater the need for the project manager to understand the market for and the application of the product. For one thing, there are more variables, including greater investment and longer lead-time until realization of a return on investment. All these contribute to greater risk for the sponsor. Sensitivity to the concerns of the sponsor and skill in dealing with these concerns can lead to greater satisfaction of the sponsor upon completion of the project.
INTEGRATING TECHNICAL, BUSINESS, AND HUMAN OBJECTIVES
It is no longer sufficient to complete the project on schedule, within budget, and achieve the required technical performance. It must also be accomplished in a manner that is consistent with other business objectives. For example, failure to meet guidelines for minority contracting or environmental requirements can cause both the project team and the sponsor considerable headaches if not more serious troubles. Failure to meet health and safety expectations can cause the job to be shutdown and even business failure of the project contractor. In some jurisdictions, failure to deal adequately with labor agreements can lead to interminable delays and excessive costs.
UNIFYING THE TECHNICAL TEAM
This becomes increasingly demanding as the magnitude of the project increases. The project alignment process was developed to facilitate conveying of expectations of the project sponsor to the project team. But that is not enough. It must be a continuing process, as obstacles met and opportunities revealed during the project will inevitably lead to changes. These changes must be conveyed to the team in a manner that reaches the subconscious, so they become the prevalent way of thinking about the project.
Maintaining momentum on a project is always a challenge. The larger the project, the greater the challenge. Many project managers are using key events in the project as a cause for celebration. The Bad Creek Pumped Hydro showcase article in the August 1990 PMNETwork gave examples of this approach. Other techniques have been described in various articles over the years.
FOSTERING AN INNOVATIVE ENVIRONMENT
For many project managers, an “innovative project environment” is an oxymoron. While project management is about the managing of change, change itself can be the greatest source of risk on a project. Often the full implications of the change are not understood, not all affected people are informed, and unintended consequences are discovered. Thus, it is easy to understand the aversion to change initiated through innovation. On the other hand, many projects have been successful precisely because of innovative solutions to major problems. Effective change control and communication is essential for this to happen consistently.
Having resolved the project manager's mindset problem, how do you foster innovation? Perhaps it is easier to talk about how easy it is to destroy such an environment. Chewing out a project team member for making an error while attempting innovation is a sure way. The wound has already been suffered. Rubbing salt in it will only make it hurt worse. Far better to make the error a positive learning experience by taking the time to analyze what happened and how to prevent it the next time.
Sam breathed a sigh of relief It was cold up on the mountain and the wind was blowing. The lessons of the great technical guru had been extensive. On the other hand, the sigh of relief reflected Sam's confidence that many of the technical skills were already in place. Most of those that needed improvement were less relevant for the imminent project. The raft was indeed a possible dream, technically speaking, that is. Sam started preparing immediately for the trek down this mountain and up the next one to learn more about the administrative skills required.
Thamhain, Hans. 1991. Developing Project Management Skills. Project Management Journal, Vol XXII (Sept.), pp. 39-44. ❏
PMNETwork • March 1994