Skip to main content
Business LibreTexts

1.2: Project Management Overview

  • Page ID
    21298
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)

    ( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\id}{\mathrm{id}}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\kernel}{\mathrm{null}\,}\)

    \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\)

    \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\)

    \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    \( \newcommand{\vectorA}[1]{\vec{#1}}      % arrow\)

    \( \newcommand{\vectorAt}[1]{\vec{\text{#1}}}      % arrow\)

    \( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vectorC}[1]{\textbf{#1}} \)

    \( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)

    \( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)

    \( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)

    \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \(\newcommand{\avec}{\mathbf a}\) \(\newcommand{\bvec}{\mathbf b}\) \(\newcommand{\cvec}{\mathbf c}\) \(\newcommand{\dvec}{\mathbf d}\) \(\newcommand{\dtil}{\widetilde{\mathbf d}}\) \(\newcommand{\evec}{\mathbf e}\) \(\newcommand{\fvec}{\mathbf f}\) \(\newcommand{\nvec}{\mathbf n}\) \(\newcommand{\pvec}{\mathbf p}\) \(\newcommand{\qvec}{\mathbf q}\) \(\newcommand{\svec}{\mathbf s}\) \(\newcommand{\tvec}{\mathbf t}\) \(\newcommand{\uvec}{\mathbf u}\) \(\newcommand{\vvec}{\mathbf v}\) \(\newcommand{\wvec}{\mathbf w}\) \(\newcommand{\xvec}{\mathbf x}\) \(\newcommand{\yvec}{\mathbf y}\) \(\newcommand{\zvec}{\mathbf z}\) \(\newcommand{\rvec}{\mathbf r}\) \(\newcommand{\mvec}{\mathbf m}\) \(\newcommand{\zerovec}{\mathbf 0}\) \(\newcommand{\onevec}{\mathbf 1}\) \(\newcommand{\real}{\mathbb R}\) \(\newcommand{\twovec}[2]{\left[\begin{array}{r}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\ctwovec}[2]{\left[\begin{array}{c}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\threevec}[3]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\cthreevec}[3]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\fourvec}[4]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\cfourvec}[4]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\fivevec}[5]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\cfivevec}[5]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\mattwo}[4]{\left[\begin{array}{rr}#1 \amp #2 \\ #3 \amp #4 \\ \end{array}\right]}\) \(\newcommand{\laspan}[1]{\text{Span}\{#1\}}\) \(\newcommand{\bcal}{\cal B}\) \(\newcommand{\ccal}{\cal C}\) \(\newcommand{\scal}{\cal S}\) \(\newcommand{\wcal}{\cal W}\) \(\newcommand{\ecal}{\cal E}\) \(\newcommand{\coords}[2]{\left\{#1\right\}_{#2}}\) \(\newcommand{\gray}[1]{\color{gray}{#1}}\) \(\newcommand{\lgray}[1]{\color{lightgray}{#1}}\) \(\newcommand{\rank}{\operatorname{rank}}\) \(\newcommand{\row}{\text{Row}}\) \(\newcommand{\col}{\text{Col}}\) \(\renewcommand{\row}{\text{Row}}\) \(\newcommand{\nul}{\text{Nul}}\) \(\newcommand{\var}{\text{Var}}\) \(\newcommand{\corr}{\text{corr}}\) \(\newcommand{\len}[1]{\left|#1\right|}\) \(\newcommand{\bbar}{\overline{\bvec}}\) \(\newcommand{\bhat}{\widehat{\bvec}}\) \(\newcommand{\bperp}{\bvec^\perp}\) \(\newcommand{\xhat}{\widehat{\xvec}}\) \(\newcommand{\vhat}{\widehat{\vvec}}\) \(\newcommand{\uhat}{\widehat{\uvec}}\) \(\newcommand{\what}{\widehat{\wvec}}\) \(\newcommand{\Sighat}{\widehat{\Sigma}}\) \(\newcommand{\lt}{<}\) \(\newcommand{\gt}{>}\) \(\newcommand{\amp}{&}\) \(\definecolor{fillinmathshade}{gray}{0.9}\)

    The starting point in discussing how projects should be properly managed is to first understand what a project is and, just as importantly, what it is not.

    People have been undertaking projects since the earliest days of organized human activity. The hunting parties of our prehistoric ancestors were projects, for example; they were temporary undertakings directed at the goal of obtaining meat for the community. Large complex projects have also been with us for a long time. The pyramids and the Great Wall of China were in their day of roughly the same dimensions as the Apollo project to send men to the moon. We use the term “project” frequently in our daily conversations. A husband, for example may tell his wife, “My main project for this weekend is to straighten out the garage.” Going hunting, building pyramids, and fixing faucets all share certain features that make them projects.

    Project Attributes

    A project has distinctive attributes that distinguish it from ongoing work or business operations. Projects are temporary in nature. They are not an everyday business process and have definitive start dates and end dates. This characteristic is important because a large part of the project effort is dedicated to ensuring that the project is completed at the appointed time. To do this, schedules are created showing when tasks should begin and end. Projects can last minutes, hours, days, weeks, months, or years.

    Projects exist to bring about a product or service that hasn’t existed before. In this sense, a project is unique. Unique means that this is new; this has never been done before. Maybe it’s been done in a very similar fashion before but never exactly in this way. For example, Ford Motor Company is in the business of designing and assembling cars. Each model that Ford designs and produces can be considered a project. The models differ from each other in their features and are marketed to people with various needs. An SUV serves a different purpose and clientele than a luxury car. The design and marketing of these two models are unique projects. However, the actual assembly of the cars is considered an operation (i.e., a repetitive process that is followed for most makes and models).

    In contrast with projects, operations are ongoing and repetitive. They involve work that is continuous without an ending date and with the same processes repeated to produce the same results. The purpose of operations is to keep the organization functioning while the purpose of a project is to meet its goals and conclude. Therefore, operations are ongoing while projects are unique and temporary.

    A project is completed when its goals and objectives are accomplished. It is these goals that drive the project, and all the planning and implementation efforts undertaken to achieve them. Sometimes projects end when it is determined that the goals and objectives cannot be accomplished or when the product or service of the project is no longer needed and the project is cancelled.

    Definition of a Project

    There are many written definitions of a project. All of them contain the key elements described above. For those looking for a formal definition of a project, the Project Management Institute (PMI) defines a project as a temporary endeavor undertaken to create a unique product, service, or result. The temporary nature of projects indicates a definite beginning and end. The end is reached when the project’s objectives have been achieved or when the project is terminated because its objectives will not or cannot be met, or when the need for the project no longer exists.

    Project Characteristics

    When considering whether or not you have a project on your hands, there are some things to keep in mind. First, is it a project or an ongoing operation? Second, if it is a project, who are the stakeholders? And third, what characteristics distinguish this endeavor as a project?

    Projects have several characteristics:

    • Projects are unique.
    • Projects are temporary in nature and have a definite beginning and ending date.
    • Projects are completed when the project goals are achieved or it’s determined the project is no longer viable.

    A successful project is one that meets or exceeds the expectations of the stakeholders.

    Consider the following scenario: The vice-president (VP) of marketing approaches you with a fabulous idea. (Obviously it must be “fabulous” because he thought of it.) He wants to set up kiosks in local grocery stores as mini-offices. These offices will offer customers the ability to sign up for car and home insurance services as well as make their bill payments. He believes that the exposure in grocery stores will increase awareness of the company’s offerings. He told you that senior management has already cleared the project, and he’ll dedicate as many resources to this as he can. He wants the new kiosks in place in 12 selected stores in a major city by the end of the year. Finally, he has assigned you to head up this project.

    Your first question should be, “Is it a project?” This may seem elementary, but confusing projects with ongoing operations happens often. Projects are temporary in nature, have definite start and end dates, result in the creation of a unique product or service, and are completed when their goals and objectives have been met and signed off by the stakeholders.

    Using these criteria, let’s examine the assignment from the VP of marketing to determine if it is a project:

    • Is it unique? Yes, because the kiosks don’t exist in the local grocery stores. This is a new way of offering the company’s services to its customer base. While the service the company is offering isn’t new, the way it is presenting its services is.
    • Does the product have a limited timeframe? Yes, the start date of this project is today, and the end date is the end of next year. It is a temporary endeavor.
    • Is there a way to determine when the project is completed? Yes, the kiosks will be installed and the services will be offered from them. Once all the kiosks are installed and operating, the project will come to a close.
    • Is there a way to determine stakeholder satisfaction? Yes, the expectations of the stakeholders will be documented in the form of requirements during the planning processes. These requirements will be compared to the finished product to determine if it meets the expectations of the stakeholder.

    If the answer is yes to all these questions, then we have a project.

    The Process of Project Management

    You’ve determined that you have a project. What now? The notes you scribbled down on the back of the napkin at lunch are a start, but not exactly good project management practice. Too often, organizations follow Nike’s advice when it comes to managing projects when they “just do it.” An assignment is made, and the project team members jump directly into the development of the product or service requested. In the end, the delivered product doesn’t meet the expectations of the customer. Unfortunately, many projects follow this poorly constructed path, and that is a primary contributor to a large percentage of projects not meeting their original objectives, as defined by performance, schedule, and budget.

    In the United States, more than $250 billion is spent each year on information technology (IT) application development in approximately 175,000 projects. The Standish Group (a Boston-based leader in project and value performance research) released the summary version of their 2009 CHAOS Report that tracks project failure rates across a broad range of companies and industries (Figure 2.1).

    Chaosreport2009.jpg
    Figure 2.1: Summary of 2009 Standish Group CHAOS report.

    Jim Johnson, chairman of the Standish Group, has stated that “this year’s results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions, 44% were challenged-which are late, over budget, and/or with less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used.”

    When are companies going to stop wasting billions of dollars on failed projects? The vast majority of this waste is completely avoidable: simply get the right business needs (requirements) understood early in the process and ensure that project management techniques are applied and followed, and the project activities are monitored.

    Applying good project management discipline is the way to help reduce the risks. Having good project management skills does not completely eliminate problems, risks, or surprises. The value of good project management is that you have standard processes in place to deal with all contingencies.

    Project management is the application of knowledge, skills, tools, and techniques applied to project activities in order to meet the project requirements. Project management is a process that includes planning, putting the project plan into action, and measuring progress and performance.

    Managing a project includes identifying your project’s requirements and writing down what everyone needs from the project. What are the objectives for your project? When everyone understands the goal, it’s much easier to keep them all on the right path. Make sure you set goals that everyone agrees on to avoid team conflicts later on. Understanding and addressing the needs of everyone affected by the project means the end result of your project is far more likely to satisfy your stakeholders. Last but not least, as project manager, you will also be balancing the many competing project constraints.

    On any project, you will have a number of project constraints that are competing for your attention. They are cost, scope, quality, risk, resources, and time.

    • Cost is the budget approved for the project including all necessary expenses needed to deliver the project. Within organizations, project managers have to balance between not running out of money and not underspending because many projects receive funds or grants that have contract clauses with a “use it or lose it” approach to project funds. Poorly executed budget plans can result in a last-minute rush to spend the allocated funds. For virtually all projects, cost is ultimately a limiting constraint; few projects can go over budget without eventually requiring a corrective action.
    • Scope is what the project is trying to achieve. It entails all the work involved in delivering the project outcomes and the processes used to produce them. It is the reason and the purpose of the project.
    • Quality is a combination of the standards and criteria to which the project’s products must be delivered for them to perform effectively. The product must perform to provide the functionality expected, solve the identified problem, and deliver the benefit and value expected. It must also meet other performance requirements, or service levels, such as availability, reliability, and maintainability, and have acceptable finish and polish. Quality on a project is controlled through quality assurance (QA), which is the process of evaluating overall project performance on a regular basis to provide confidence that the project will satisfy the relevant quality standards.
    • Risk is defined by potential external events that will have a negative impact on your project if they occur. Risk refers to the combination of the probability the event will occur and the impact on the project if the event occurs. If the combination of the probability of the occurrence and the impact on the project is too high, you should identify the potential event as a risk and put a proactive plan in place to manage the risk.
    • Resources are required to carry out the project tasks. They can be people, equipment, facilities, funding, or anything else capable of definition (usually other than labour) required for the completion of a project activity.
    • Time is defined as the time to complete the project. Time is often the most frequent project oversight in developing projects. This is reflected in missed deadlines and incomplete deliverables. Proper control of the schedule requires the careful identification of tasks to be performed and accurate estimations of their durations, the sequence in which they are going to be done, and how people and other resources are to be allocated. Any schedule should take into account vacations and holidays.

    You may have heard of the term “triple constraint,” which traditionally consisted of only time, cost, and scope. These are the primary competing project constraints that you have to be most aware of. The triple constraint is illustrated in the form of a triangle to visualize the project work and see the relationship between the scope/quality, schedule/time, and cost/resource (Figure 2.2). In this triangle, each side represents one of the constraints (or related constraints) wherein any changes to any one side cause a change in the other sides. The best projects have a perfectly balanced triangle. Maintaining this balance is difficult because projects are prone to change. For example, if scope increases, cost and time may increase disproportionately. Alternatively, if the amount of money you have for your project decreases, you may be able to do as much, but your time may increase.

    Triple-constraint-triangle-300x219.jpg
    Figure 2.2: A schematic of the triple constraint triangle.

    Your project may have additional constraints that you must face, and as the project manager, you have to balance the needs of these constraints against the needs of the stakeholders and your project goals. For instance, if your sponsor wants to add functionality to the original scope, you will very likely need more money to finish the project, or if they cut the budget, you will have to reduce the quality of your scope, and if you don’t get the appropriate resources to work on your project tasks, you will have to extend your schedule because the resources you have take much longer to finish the work.

    You get the idea; the constraints are all dependent on each other. Think of all of these constraints as the classic carnival game of Whac-a-mole (Figure 2.3). Each time you try to push one mole back in the hole, another one pops out. The best advice is to rely on your project team to keep these moles in place.

    Whac-a-mole-300x199.jpg
    Figure 2.3: Whac-a-mole.

    Here is an example of a project that cut quality because the project costs were fixed. The P-36 oil platform (Figure 2.4) was the largest footing production platform in the world capable of processing 180,000 barrels of oil per day and 5.2 million cubic metres of gas per day. Located in the Roncador Field, Campos Basin, Brazil, the P-36 was operated by Petrobras.

    Petrobras P-36 Sinking
    Figure 2.4.: The Petrobras P-36 oil platform sinking.

    In March 2001, the P-36 was producing around 84,000 barrels of oil and 1.3 million cubic metres of gas per day when it became destabilized by two explosions and subsequently sank in 3,900 feet of water with 1,650 short tons of crude oil remaining on board, killing 11 people. The sinking is attributed to a complete failure in quality assurance, and pressure for increased production led to corners being cut on safety procedures. It is listed as one of the most expensive accidents with a price tag of $515,000,000.

    The following quotes are from a Petrobras executive, citing the benefits of cutting quality assurance and inspection costs on the project.

    “Petrobras has established new global benchmarks for the generation of exceptional share­holder wealth through an aggressive and innovative program of cost cutting on its P36 production facility.”

    “Conventional constraints have been successfully challenged and replaced with new paradigms appropriate to the globalized corporate market place.”

    “Elimination of these unnecessary straitjackets has empowered the project’s suppliers and contractors to propose highly economical solutions, with the win-win bonus of enhanced profitability margins for themselves.”

    “The P36 platform shows the shape of things to come in the unregulated global market economy of the 21st century.”

    The dynamic trade-offs between the project constraint values have been humorously and accurately described in Figure 2.5.

    Good-quick-cheap-300x114.jpg
    Figure 2.5: Good, Quick, Cheap: Choose two. A sign seen at an automotive repair shop. [Image Description]

    Project Management Expertise

    In order for you, as the project manager, to manage the competing project constraints and the project as a whole, there are some areas of expertise you should bring to the project team (Figure 2.11). They are knowledge of the application area and the standards and regulations in your industry, understanding of the project environment, general management knowledge and skills, and interpersonal skills. It should be noted that industry expertise is not in a certain field but the expertise to run the project. So while knowledge of the type of industry is important, you will have a project team supporting you in this endeavor. For example, if you are managing a project that is building an oil platform, you would not be expected to have a detailed understanding of the engineering since your team will have mechanical and civil engineers who will provide the appropriate expertise; however, it would definitely help if you understood this type of work.

    Let’s take a look at each of these areas in more detail.

    Application knowledge

    By standards, we mean guidelines or preferred approaches that are not necessarily mandatory. In contrast, when referring to regulations we mean mandatory rules that must be followed, such as government-imposed requirements through laws. It should go without saying that as a professional, you’re required to follow all applicable laws and rules that apply to your industry, organization, or project. Every industry has standards and regulations. Knowing which ones affect your project before you begin work will not only help the project to unfold smoothly, but will also allow for effective risk analysis.

    areas-of-expertise.jpg
    Figure 2.6: Areas of expertise that a project manager should bring to the project team.

    Some projects require specific skills in certain application areas. Application areas are made up of categories of projects that have common elements. They can be defined by industry group (pharmaceutical, financial, etc.), department (accounting, marketing, legal, etc.), technology (software development, engineering, etc), or management specialties (procurement, research and development, etc.). These application areas are usually concerned with disciplines, regulations, and the specific needs of the project, the customer, or the industry. For example, most government agencies have specific procurement rules that apply to their projects that wouldn’t be applicable in the construction industry. The pharmaceutical industry is interested in regulations set forth by government regulators, whereas the automotive industry has little or no concern for either of these types of regulations. You need to stay up-to-date regarding your industry so that you can apply your knowledge effectively. Today’s fast-paced advances can leave you behind fairly quickly if you don’t stay abreast of current trends.

    Having some level of experience in the application area you’re working in will give you an advantage when it comes to project management. While you can call in experts who have the application area knowledge, it doesn’t hurt for you to understand the specific aspects of the application areas of your project.

    Understanding the Project Environment

    There are many factors that need to be understood within your project environment (Figure 2.7). At one level, you need to think in terms of the cultural and social environments (i.e., people, demographics, and education). The international and political environment is where you need to understand about different countries’ cultural influences. Then we move to the physical environment; here we think about time zones. Think about different countries and how differently your project will be executed whether it is just in your country or if it involves an international project team that is distributed throughout the world in five different countries.

    Consider the cultural, social, international, political, and physical environments of a project
    Figure 2.7: The important factors to consider within the project environment.

    Of all the factors, the physical ones are the easiest to understand, and it is the cultural and international factors that are often misunderstood or ignored. How we deal with clients, customers, or project members from other countries can be critical to the success of the project. For example, the culture of the United States values accomplishments and individualism. Americans tend to be informal and call each other by first names, even if having just met. Europeans tend to be more formal, using surnames instead of first names in a business setting, even if they know each other well. In addition, their communication style is more formal than in the United States, and while they tend to value individualism, they also value history, hierarchy, and loyalty. The Japanese, on the other hand, tend to communicate indirectly and consider themselves part of a group, not as individuals. The Japanese value hard work and success, as most of us do.

    How a product is received can be very dependent on the international cultural differences. For example, in the 1990s, when many large American and European telecommunications companies were cultivating new markets in Asia, their customer’s cultural differences often produced unexpected situations. Western companies planned their telephone systems to work the same way in Asia as they did in Europe and the United States. But the protocol of conversation was different. Call-waiting, a popular feature in the West, is considered impolite in some parts of Asia. This cultural blunder could have been avoided had the team captured the project environment requirements and involved the customer.

    It is often the simplest things that can cause trouble since, unsurprisingly, in different countries, people do things differently. One of the most notorious examples of this is also one of the most simple: date formats. What day and month is 2/8/2009? Of course it depends where you come from; in North America it is February 8th while in Europe (and much of the rest of the world) it is 2nd August. Clearly, when schedules and deadlines are being defined it is important that everyone is clear on the format used.

    The diversity of practices and cultures and its impact on products in general and on software in particular goes well beyond the date issue. You may be managing a project to create a new website for a company that sells products worldwide. There are language and presentation style issues to take into consideration; converting the site into different languages isn’t enough. It is obvious that you need to ensure the translation is correct; however, the presentation layer will have its own set of requirements for different cultures. The left side of a website may be the first focus of attention for a Canadian; the right side would be the initial focus for anyone from the Middle East, as both Arabic and Hebrew are written from right to left. Colors also have different meanings in different cultures. White, which is a sign of purity in North America (e.g., a bride’s wedding dress), and thus would be a favoured background colour in North America, signifies death in Japan (e.g., a burial shroud). Table 2.1 summarizes different meanings of common colours.

    Table 2.1: The meaning of colours in various cultures.
    Colour United States China Japan Egypt France
    Red Danger, stop Happiness Anger, danger Death Aristocracy
    Blue Sadness, melancholy Heavens, clouds Villainy Virtue, faith, truth Freedom, peace
    Green Novice, apprentice Ming dynasty, heavens Future, youth, energy Fertility, strength Criminality
    Yellow Cowardice Birth, wealth Grace, nobility Happiness, prosperity Temporary
    White Purity Death, purity Death Joy Naturality

    Project managers in multicultural projects must appreciate the culture dimensions and try to learn relevant customs, courtesies, and business protocols before taking responsibility for managing an international project. A project manager must take into consideration these various cultural influences and how they may affect the project’s completion, schedule, scope, and cost.

    Management Knowledge and Skills

    As the project manager, you have to rely on your project management knowledge and your general manage­ment skills. Here, we are thinking of items like your ability to plan the project, execute it properly, and of course control it and bring it to a successful conclusion, along with your ability to guide the project team to achieve project objectives and balance project constraints.

    There is more to project management than just getting the work done. Inherent in the process of project management are the general management skills that allow the project manager to complete the project with some level of efficiency and control. In some respects, managing a project is similar to running a business: there are risk and rewards, finance and accounting activities, human resource issues, time management, stress management, and a purpose for the project to exist. General management skills are needed in every project.

    Interpersonal Skills

    Last but not least you also have to bring the ability into the project to manage personal relationships and deal with personnel issues as they arise. Here were talking about your interpersonal skills as shown in Figure 2.8.

    Communication

    Project managers spend 90% of their time communicating. Therefore they must be good communicators, promoting clear, unambiguous exchange of information. As a project manager, it is your job to keep a number of people well informed. It is essential that your project staff know what is expected of them: what they have to do, when they have to do it, and what budget and time constraints and quality specifications they are working toward. If project staff members do not know what their tasks are, or how to accomplish them, then the entire project will grind to a halt. If you do not know what the project staff is (or often is not) doing, then you will be unable to monitor project progress. Finally, if you are uncertain of what the customer expects of you, then the project will not even get off the ground. Project communication can thus be summed up as knowing “who needs what information and when” and making sure they have it.

    Interpersonal-skills-1-300x101.jpg
    Figure 2.8: Interpersonal skills required of a project manager.

    All projects require sound communication plans, but not all projects will have the same types of commu­nication or the same methods for distributing the information. For example, will information be distributed via mail or email, is there a shared website, or are face-to-face meetings required? The communication management plan documents how the communication needs of the stakeholders will be met, including the types of information that will be communicated, who will communicate them, and who will receive them; the methods used to communicate; the timing and frequency of communication; the method for updating the plan as the project progresses, including the escalation process; and a glossary of common terms.

    Influence

    Project management is about getting things done. Every organization is different in its policies, modes of operations, and underlying culture. There are political alliances, differing motivations, conflicting interests, and power struggles. A project manager must understand all of the unspoken influences at work within an organization.

    Leadership

    Leadership is the ability to motivate and inspire individuals to work toward expected results. Leaders inspire vision and rally people around common goals. A good project manager can motivate and inspire the project team to see the vision and value of the project. The project manager as a leader can inspire the project team to find a solution to overcome perceived obstacles to get the work done.

    Motivation

    Motivation helps people work more efficiently and produce better results. Motivation is a constant process that the project manager must guide to help the team move toward completion with passion and a profound reason to complete the work. Motivating the team is accomplished by using a variety of team-building techniques and exercises. Team building is simply getting a diverse group of people to work together in the most efficient and effective manner possible. This may involve management events as well as individual actions designed to improve team performance.

    Recognition and rewards are an important part of team motivations. They are formal ways of recognizing and promoting desirable behaviour and are most effective when carried out by the management team and the project manager. Consider individual preferences and cultural differences when using rewards and recognition. Some people don’t like to be recognized in front of a group; others thrive on it.

    Negotiation

    Project managers must negotiate for the good of the project. In any project, the project manager, the project sponsor, and the project team will have to negotiate with stakeholders, vendors, and customers to reach a level of agreement acceptable to all parties involved in the negotiation process.

    Problem Solving

    Problem solving is the ability to understand the heart of a problem, look for a viable solution, and then make a decision to implement that solution. The starting point for problem solving is problem definition. Problem definition is the ability to understand the cause and effect of the problem; this centres on root-cause analysis. If a project manager treats only the symptoms of a problem rather than its cause, the symptoms will perpetuate and continue through the project life. Even worse, treating a symptom may result in a greater problem. For example, increasing the ampere rating of a fuse in your car because the old one keeps blowing does not solve the problem of an electrical short that could result in a fire. Root-cause analysis looks beyond the immediate symptoms to the cause of the symptoms, which then affords opportunities for solutions. Once the root of a problem has been identified, a decision must be made to effectively address the problem.

    Solutions can be presented from vendors, the project team, the project manager, or various stakeholders. A viable solution focuses on more than just the problem; it looks at the cause and effect of the solution itself. In addition, a timely decision is needed or the window of opportunity may pass and then a new decision will be needed to address the problem. As in most cases, the worst thing you can do is nothing.

    All of these interpersonal skills will be used in all areas of project management. Start practicing now because it’s guaranteed that you’ll need these skills on your next project.

    Image Descriptions

    Figure 2.5 image description: The sign says, “We can do good, quick, and cheap work. You can have any two but not all three. 1. Good, quick work won’t be cheap. 2. Good, cheap work won’t be quick. 3. Quick, cheap work won’t be good.” [Return to Figure 2.5]

    Text Attributions

    Media Attributions


    This page titled 1.2: Project Management Overview is shared under a CC BY-SA license and was authored, remixed, and/or curated by Adrienne Watt (BCCampus) .

    • Was this article helpful?