|< Day Day Up >|| |
A project is an uncertain business; the larger the project, the more uncertainty. It's for this reason, among others, that projects are broken down into smaller, more manageable phases. A project phase allows a project manager to see the project as a whole and yet still focus on completing the project one phase at a time.
Projects are temporary endeavors to create a unique product or service. All projects must have an end date. Between the project launch and the coveted end date, a project will pass through multiple phases. Consider a project to create a new electronic gadget. This gadget will have several phases to complete from concept to completion: product description, prototype, revision, testing, and so on. The completion of each phase brings the project closer to completion.
Think of any project you may have worked on: a technology rollout, constructing a building, integrating a new service into a business. Each of these projects will have logical phases that move the project from concept to completion. The sum of the project phases comprises the project life cycle.
A project life cycle is the duration of a project. Consider our project to create a new electronic gadget. Once the gadget is completed, has passed testing and regulations, the project doesn't continue-it's done. The life of the project is over and the goal of the project, to create a unique product in this case, has been met. There's no reason for the project to keep going-so its life cycle is over.
Every phase has deliverables. It's one of the main points to having phases. For example, your manager gives you a wieldy project that will require four years to complete and has a hefty budget of $16 million. Do you think management is going to say, 'Have fun-see you in four years?'
Oh, if only they would, right?
Of course, in most organizations, that's not going to happen. Management wants to see proof of progress, evidence of work completed, and good news of how well the project is moving. Phases are an ideal method of keeping management informed of the project progression. The following illustration depicts a project moving from conception to completion. At the end of each phase there is some deliverable that the project manager can show to management and customers.
Once a phase concludes, how does the project manager know it's safe to continue? Based on the size and type of the project, some form of scope verification must take place. Management and customers will want to see if the deliverable you have completed to date is in alignment with what they've expected.
Let's go back to that juicy project with the $16 million budget. We know management is not going to set us loose for four years. They'll want a schedule of when we'll be spending their money and what they'll be getting in return. And when will this fun happen? At the end of a project phase. The project manager will be accountable for several things at the end of a project phase:
The performance of the project to date
The performance of the project team to date
Proof of deliverables in the project phase
Verification of deliverables in alignment with the project scope
The verification of the performance and the project deliverables will be key to management determining if the project (cross your fingers) should continue or not. Imagine your project with $16 million has produced a lousy deliverable, outside of the project scope, and you've blown more than a few hundred thousand more than what you said it would take to get to this point in the project. Hmmm… Do you think the project will continue? An analysis by management will determine if the project should be killed or allowed to continue. The idea of killing a project at phases is why phase completion is also called a kill point. Uh, kill point for the project, not the project manager.
Money already spent on a project is called sunk costs and should not be taken into consideration when determining if a project should continue. Instead, the cost of the work to complete is one of the elements that should be taken into consideration when considering to kill a project.
Project phases are also known as stage gates. Stage gates are used often in manufacturing and product development. A stage gate allows a project to continue after performance and deliverable review against a set of predefined metrics. If the deliverables of the phase, or stage, met the predefined metrics, the project is allowed to continue. Should the deliverable not meet the metrics, the project may not be allowed to pass through the gate to move forward. In these unfortunate cases, the project may be terminated or sent through revisions to meet the predetermined metrics. The following illustration shows the advancement of the project through phases.
|On the Job|| |
As a project manager, you should identify the requirements as close to the project launch as possible. With the expectations and requirements, the project manager can know what the exit criteria for a phase may be and can plan accordingly. There are few things more frustrating than to get to the end of a project phase only to learn the exit criteria you had in mind is different than what the customer was expecting.
The completion of a phase may also be known as a phase exit. A phase exit requires the project deliverable meet some predetermined exit criteria. Exit criteria are typically inspection-specific and are scheduled events in the project schedule. Exit criteria can include many different activities, such as:
Sign-offs from the customer
Regulatory inspections and audits
The end of a project phase
You know you are moving towards completion when management and customers agree with the results of a project phase. Each project will have its own logical phases to completion. Imagine you're the project manager for a project to build a new house. There'd be some very logical phases to the completion of the project to build the house:
Requirements What type of house are you building? What are the characteristics of the house? What are the expectations from the people that will be living in the home?
Design The architects and the designers would work with the requirements to create the specifications for the house in alignment with the requirements of the customer.
Build Within this phase, there'd be logical activities and mini-phases necessary to reach the project completion, such as the foundation, the framing, the roofing, and so on.
Inspect Before the home owners moved into their new home, they'd want to inspect the house for the quality of the building and confirm its functionality.
Operational transfer Ah, yes, the home is complete and the homeowners have moved in, approving the project and thereby heralding its end.
Each phase within the preceding project has logical activities that dictate the point of the phase, the goal of each, and what the deliverables of each phase likely will be. At the end of each of the listed phases, there'd likely be an inspection and confirmation that the project is moving towards its completion. The completion of a phase allows a project to move into the next phase.
Projects are like snowflakes: no two are alike. Sure, sure, some may be similar, but when you get down to it-each project has its own unique attributes, activities, and requirements from stakeholders. Within each project, one attribute that typically varies from project to project is the project life cycle. As its name implies, the project life cycle determines not only the start of the project, but also when the project should be completed. All that stuff packed in between starting and ending? Those are the different phases of the project.
The PMP exam will test your knowledge on the outcome of project phases, rather than the idealistic outputs of a project phase. Know that each phase creates a deliverable of some sort and allows the project to move forward if the deliverables meet preset metrics.
In other words, the launch, series of phases, and project completion comprise the project life cycle. Each project will have similar project management activities, but the characteristics of the project life cycle will vary from project to project.
|On the Job|| |
Project feasibility studies can be a separate project.
The project's feasibility is part of the initiating processes. Once the need has been identified, a feasibility study is called for to determine if the need can realistically be met.
So how does a project get to be a project? In some organizations, it's pure luck. In most organizations, however, projects may begin with a feasibility study. Feasibility studies can be, and often are, part of the initiation process of a project. In some instances, a feasibility study may be treated as a stand-alone project. Let's assume that the feasibility of Project ABC is part of the project initiation phase. The outcome of the feasibility study may tell management several things:
Whether the concept should be mapped into a project or not
If the project concept is worth moving forward with
The expected cost and time needed to complete the concept
The benefits and costs to implement the project concept
A report on the needs of the organization and how the project concept can satisfy these needs
By now, you're more than familiar with the concept of a project's life cycle. You also know each project is different and that there are some attributes common across all project life cycles. For example, the concept of breaking the project apart into manageable phases to move towards completion is typical across most projects. As we've discussed, at the completion of a project phase, an inspection or audit is usually completed. This inspection confirms the project is in alignment with the requirements and expectations of the customer. If the results of the audit or briefing are not in alignment, then rework can happen, new expectations may be formulated, or the project may be killed.
Project life cycles, comprised of phases, move the project along. Project life cycles allow a project manager to determine several things about the project, such as:
What work will be completed in each phase of the project?
What resources, people, equipment, and facilities will be needed withineach phase?
What are the expected deliverables of each phase?
What is the expected cost to complete a project phase?
Which phases contain the highest amount of risk?
Armed with the appropriate information for each project phase, the project manager can plan for cost, schedules, resource availability, risk management, and other project management activities to ensure that the project progresses successfully.
While projects differ, there are also other common traits from project to project. The following lists a few examples:
Cost and resource requirements are lower at the beginning of a project, but grow as the project progresses. Once the project moves into the final closing process, costs and resource requirements taper off dramatically.
Projects fail at the beginning, not at the end. Projects are more likely to fail near their beginning-and more likely to succeed near the end of their life cycle. In other words, the odds of completing are low at launch and high at completion.
The further the project is from completing, the higher the risk and uncertainty. Risk and doubt decrease as the project moves closer to fulfilling the project vision.
Changes are easier and more likely at the early phases of the project life cycle than at the completion. Stakeholders can have a greater influence on the outcome of the project deliverables in the early phases, but in the final phases of the project life cycle, their influence on change diminishes. Thankfully. Changes at the beginning of the project generally cost less and have lower risk than changes at the end of a project.
There must be some distinction between the project life cycle and the product life cycle. We've covered the project life cycle-the accumulation of phases from start to completion within a project, but what is a product life cycle?
A product life cycle is the parent of projects. Consider a company that wants to sell a new type of lemon soft drink. One of the projects the company may undertake to sell their new lemon soft drink is to create television commercials showing how tasty their beverage is. The creation of the television commercial may be considered one project in support of the product creation.
Many other projects may fall under the creation of the lemon soft drink: research, creation and testing, packaging, and more. Each project, however, needs to support the ultimate product: the tasty, lemon soft drink. Thus, the product life cycle oversees the smaller projects within the process.
|On the Job|| |
This example can also be mapped to a program. A program coordinates and controls all of the projects to create the product.
You're the project manager for HollyWorks Productions. Your company would like to create a new video camera that allows consumers to make video productions that can be transferred to different media types such as VHS, DVDs, and PCs. The video camera must be small, light, and affordable. This project life cycle has several phases from concept to completion (see Figure 2-1). Remember, the project life cycle is unique to each project, so don't assume the phases within this sample will automatically map to any project you may be undertaking.
Figure 2-1: The project life cycle for Project HollyWorks
Proof-of-concept In this phase, you'll work with business analysts, electrical engineers, customers, and manufacturing experts to confirm that such a camera is feasible to make. You'll examine the projected costs and resources required to make such a camera. If things go well, management may even front you some cash to build a prototype.
First build Management loves the positive information you've discovered in the proof-of-concept phase-they've set a budget for your project to continue into development. Now you'll lead your project team through the process of designing and building a video camera according to the specifications from the stakeholders and management. Once the camera is built, your team will test, document, and adjust your camera for usability and feature-support.
Prototype manufacturing Things are going remarkably well with your video camera project. The project stakeholders loved the first-build and have made some refinements to the design. Your project team builds a working model, thereby moving into prototyping the video camera's manufacture, testing its cost effectiveness and ease of mass production. The vision of the project is becoming a reality.
Final build The prototype of the camera went fairly well. The project team has documented any flaws, and adjustments are being made. The project team is also working with the manufacturer to complete the requirements for materials and packaging. The project is nearing completion.
Operational transfer The project is complete. Your team has successfully designed, built, and moved into production, a wonderful, affordable video camera. Each phase of the project allowed the camera to move towards completion. As the project came closer and closer to moving into operations, risk and project fluctuation waned.
Stakeholders are those fine folks and organizations who are actively involved in the project, or will be affected by its outcome-in other words, people, groups, businesses, customers, and communities that have a vested interest in the project.
Stakeholders may like, love, or hate your project. Consider an organization that is hosting a project to move all their workers to a common word-processing application. Everyone within this organization must now use the same word-processing application. Your job, as the project manager, is to see that it happens.
Now, within your project, you've got stakeholders that like the project, being in favor of the project deliverable. Other stakeholders love the project-they cannot wait for all of the organization to use the same application for word processing. And, sigh, there are those stakeholders who are diehard fans of the application your project will take away from them. These folks hate your project.
|On the Job|| |
In high-profile projects, where stakeholders will be in conflict over the project purpose, deliverables, cost, and schedule, the project manager may want to use the Delphi Technique to gain anonymous consensus among stakeholders. The Delphi Technique allows stakeholders to offer opinions and input without fear of retribution from management.
Stakeholders, especially those not in favor of the project deliverable, may try to influence the project itself. This can be attempted in many ways, such as through:
Political capital leveraged to change the project deliverable
Change requests to alter the project deliverable
Scope addendums to add to the project deliverable
Sabotage, through physical acts or rumors, gossip, and negative influence
Projects don't last forever. Though projects may sometimes seem to last forever, they fortunately do not. Operations, however, do go on and on. Projects pass through logical phases to reach their completion, while operations may be influenced, or even created, by the outcome of a project.
The phases within a project create deliverables. The deliverables typically allow the project to move forward to the next phase-or allow the project to be terminated based on the quality, outcome, or condition of the phase deliverable. Some projects may use stage gates. Recall that stage gates allow a project to continue (after performance and deliverable review) against a set of predefined metrics. Other projects may use kill points. Kill points, like phase gates, are preset times placed in the project when it may, based on conditions and discovery within the phase, be 'killed.'
The project life cycle is different than the Project Management Life Cycle. The Project Management Life Cycle is comprised of the five project management processes (initiation, planning, execution, control, and closure). The project life cycle, meanwhile, is comprised of the logical phases within the project itself.
The project life cycle is affected by the project stakeholders. Project stakeholders have a vested interest in the outcome of the project. Stakeholders include the project manager, project team, management, customers, communities, and anyone affected by the project outcome. Project managers should scan the project outcome in order to identify all of the stakeholders and collect and record their expectations, concerns, and input regarding the project processes.
The project manager's power is relative to the organization structure he is operating within. A project manager in a functional organization will have relatively low authority. A project manager in a matrix environment can have low, balanced, or high authority over the project. A project manager in a projectized organization will have a high level of authority on the project. Essentially, the project manager's authority is typically inverse to the authority of the functional manager.
Your role as the project manager is to identify, align, and ascertain stakeholders and their expectations of the project. Stakeholder identification is not always as clear-cut as in the preceding example. Because stakeholders are identified as people that are affected by the outcome of your project, external customers may be stakeholders in your project, too.
Consider a company that is implementing a frequent customer discount project. External customers will use a card that tracks their purchases and gives them discounts on certain items they may buy. Is the customer in this instance a stakeholder? What if the customer doesn't want to use the card? Is she still a stakeholder?
Stakeholders can go by many different names: internal and external customers, project owners, financiers, contractors, family members, government regulatory agencies, communities, cities, citizens and more. The classification of stakeholders into categories is not as important as realizing and understanding stakeholders' concerns and expectations. The identification and classification of stakeholders does allow, however, the project manager to deliver effective and timely communications to the appropriate stakeholders.
Project managers must scan the project for hidden stakeholders. The project manager should investigate all parties affected by the project to identify all of the stakeholders-not just the obvious ones. Hidden stakeholders can influence the outcome of the project. They can also add cost, schedule requirements, or risk to a project.
Beyond those stakeholders affected by the project deliverable, there are key stakeholders on every project. Let's meet them.
Project manager The project manager is the person-ahem, you-that is accountable for managing the project. They guide the team through the project phases to completion.
Project customer The customer is the person or group that will use the project deliverable. In some instances, a project may have many different customers. Consider a book publisher for children. The bookstores distribute the children's book. The adults pay for the book. The children read the book. There is also some consideration given to the user versus the customer. The user uses the product; the customer pays for it. A stakeholder can be both a user and a customer.
Performing organization On your project, you'll have a project team. Who do the team members work for? The performing organization is the entity that employs the people responsible for completing the prject work. In some instances, the performing organization can be a vendor whose project team is completing the project work for another entity, the customer.
Project team The project team is the collection of individuals that will, hopefully, work together to ensure the success of the project. The project manager works with the project team to guide, schedule, and oversee the project work. The project team completes the project work.
Project sponsor The sponsor authorizes the project. This person or group ensures that the project manager has the necessary resources, including monies, to get the work done. The project sponsor is someone within the performing organization that has the power to authorize and sanction the project work, and is ultimately responsible for the project's success.
Ever had an experience that didn't live up to your expectations? Not much fun, is it? With project management and the large number of stakeholders, it's easy to see how some stakeholders' expectations won't be realistic due to cost, schedule, or feasibility. A project manager must find solutions to create win-win scenarios between stakeholders.
When it comes to stakeholder expectations, nothing beats documentation! Get stakeholder expectations in writing as soon as possible.
Consider a project to implement a new Customer Relationship Management software. In this project, there are three primary stakeholders with differing expectations:
The Sales Director primarily wants a technical solution that will ensure fast output of order placements, proposals, and customer contact information-regardless of the cost.
The Marketing Director primarily wants a technical solution that can track call volume, customer sales history, and trends with the least cost to implement.
The IT Director wants a technical solution that will fan into the existing network topology, have considerable ease of use, and reliability-without costing more than 20 percent of his budget for ongoing support.
In this scenario, the project manager will have to work with each of the stakeholders to determine a winning solution that satisfies all of the project requirements while appeasing the stakeholders' demands. Specifically, the solution for the conflict of stakeholders is to satisfy the needs of the customer first. Customer needs, or the business need of why the project was initiated, should guide the project through the project life cycle. Once the project scope is aligned with the customer's needs, the project manager may work to satisfy the differing expectations of the stakeholders.
Projects are not islands. They are components of larger entities that work to create a unique product or service. The larger entities, organizations, companies, or communities will have direct influence over the project itself. Consider the values, maturity, business model, culture, and traditions at work in any organization. All of these variables can influence the progress and outcome of the project.
Project managers must recognize the role of the project as a component within an organization. The role of the project, as a component, is to support the business model of the organization as a whole-not to necessarily replace it. You can see in Figure 2-2 the major layers and purpose of the components within most organizations. Note that each layer of the pyramid answers a specific question in relation to the project.
Figure 2-2: Each layer of an organization supports the layer above.
The Executive Layer sets the vision and strategy of the organization. The business layer asks, 'Why is the project important to our organization? Our vision? Our strategy?'
The Functional Management Layer of the pyramid must support the Executive Layer's objectives. Specifically, the Functional Management Layer is concerned with tactics to accomplish the vision and strategy as set by upper management. The Functional Management Layer asks, 'What is the project purpose? What business processes are affected?'
The Operational Layer of the pyramid supports the Executive and the Functional Management layers. This layer is concerned with the specifics of getting the work done. The Operational Layer asks, 'How can the work be accomplished? How can we reach the desired future state with these requirements?'
What kind of an organization are you in? Does your organization complete projects for other entities? Does your organization treat every process of an operation as an operation? Or does your organization not know what to do with people like you: project managers?
When it comes to project management, organizations fall into one of three models:
Completing projects for others These entities swoop into other organizations and complete the project work based on specifications, details, and specification documents. Classical examples of these types of organizations include consultants, architectural firms, technology integration companies, and advertising agencies.
Completing projects internally through a system These entities have adopted management by projects (discussed in Chapter 1). Recall that organizations using management by projects have accounting, time, and management systems in place to account for the time, cost, and worth of each project.
Completing projects as needed These non-project-centric entities can complete projects successfully, but may not have the project systems in place to efficiently support projects. The lack of a project support system can cause the project to succumb to additional risks, lack of organization, and reporting difficulties. Some organizations may have special internal business units to support the projects in motion that are separate from the accounting, time, and management systems used by the rest of the organization.
Know that customers can be internal or external but they all have the same theme: Customers pay for, or use, the product deliverables. In some instances, they'll pay for, and use, the deliverable.
Imagine what it may be like to work as a project manager within a bank in downtown London versus working as a project manager in a web development company in New Orleans. Can you picture a clear difference in the expected culture within these two entities? The organizational culture of an entity will have a direct influence on the success of a project. Organizational culture includes
Organization policies and procedures
Type of business
Maturity of business
As you can imagine, projects with more risk (and expected reward) may be welcome in an organization that readily accepts entrepreneurial ventures rather than in an organization that is less willing to accept chance and risk. Project formality is typically in alignment with the culture of an organization.
Another influence on the progress of a project is the management style of an organization. A project manager that is autocratic in nature will face challenges and opposition in organizations that allow and encourage self-led teams. A project manager must take cues from management as to how the management style of a project should operate. In other words, a project manager emulates the management style of the operating organization.
Organizations are structured into one of six models, the organizational structure of which will affect the project in some aspect. In particular, the organizational structure will set the level of authority, the level of autonomy, and the reporting structure that the project manager can expect to have within the project. Figure 2-3 shows the level of authority in each of the organizational structures for the project manager and the functional manager. The organizational structures we'll discuss include
Figure 2-3: Project managers can expect varying levels of authority in each of the organizational structures.
|On the Job|| |
Being able to recognize your organizational structure in regard to project management will allow you to leverage and position your role as a project manager effectively.
Functional organizations are entities that have a clear division regarding business units and their associated responsibility. For example, a functional organization may have an Accounting Department, Manufacturing Department, Research and Development Department, Marketing Department, and so on. Each department works as a separate entity within the organization and each employee works in a separate department. In these classical organizations, there is a clear distinction between an employee and a specific functional manager.
Functional organizations do complete projects, but these projects are specific to the function of the department the project falls into. For example, the IT Department could implement new software for the Finance Department. The role of the IT Department is separate from the Finance Department, but the coordination between the two functional departments would be evident. Communication between departments flows through functional managers down to the project team. Figure 2-4 depicts the relationship between business departments and the flow of communication between projects and departments.
Figure 2-4: Projects in functional organizations route communications through functional managers.
Project managers in functional organizations have the following attributes:
Report directly to a functional manager
The project manager may be known as a Project Coordinator or Team Leader
The project manager's role is part-time
The project team is part-time
The project manager may have little or no administrative staff to expedite the project management activities
Matrix structures are organizations that have a blend of departmental duties and employees together on a common project. Matrix structures allow for project team members to be from multiple departments working toward the project completion. In these instances, the project team members have more than one boss. Depending on the number of projects a team member is participating in, they may have to report to multiple project managers as well as their functional manager.
Weak matrix structures map closely to a functional structure. The project team may come from different departments, but the project manager reports directly to a specific functional manager. In weak matrix organizations, the project manager has the following attributes:
Management of a part-time project team
Project role is part-time
May be known as a project coordinator or team leader
May have part-time administrative staff to help expedite the project
A balanced matrix structure has many of the same attributes as a weak matrix, but the project manager has more time and power regarding the project. A balanced matrix still has time accountability issues for all the project team members since their functional managers will want reports on their time within the project. Attributes of a project manager in a balanced matrix are
Management of a part-time project team
Full-time role as a project manager
May have part-time administrative staff to help expedite the project
Strong matrix equates to a strong project manager. In a strong matrix organization, many of the same attributes for the project team exist, but the project manager gains power and time when it comes to project work. The project team may also have more time available for the project even though they may come from multiple departments within the organization. Attributes of a project manager in a strong matrix include
A reasonable to high level of power
Management of a part-time to nearly full-time project team
Full-time role as a project manager
Has a full-time administrative staff to help expedite the project
At the pinnacle of project management structures is the projectized structure. These organizational types group employees, collocated or not, by activities on a particular project. The project manager in a projectized structure may have complete, or very close to complete, power over the project team. Project managers in a projectized structure enjoy a high level of autonomy over their projects, but also have a higher level of responsibility regarding the project's success.
Project managers in a projectized structure have the following attributes:
High to complete authority over the project team
Works full-time on the project with his team (though there may be some slight variation)
Has a full-time administrative staff to help expedite the project
On paper, all of these organizational structures look great. In reality, there are very few companies that map only to one of these structures all of the time. For example, a company using the functional model may create a special project consisting of talent from many different departments. Such project teams report directly to a project manager and will work on a high-priority project for its duration. These entities are called composite organizations, in that they may be a blend of multiple organizational types. Figure 2-5 shows a sample of a composite structure.
Figure 2-5: Composite structures are blends of traditional organizational methods.
Table 2-1 shows the benefits and drawbacks of various organizational types.
The project manager has autonomy of the project decisions. Improves communication as teams focus on current project work.
Encourages competition between project teams. Project teams may stockpile resources. The project team may also lose focus towards the end of the project since they are uncertain about their next assignment.
Project team may be assigned to a project from 50 to 90 percent of its duration. The project manager has a high level of authority. This model also provides good communication.
Competition among project teams still exists. Overall costs may also increase due to redundant administrative staff among projects.
The project manager has balanced project authority with management. This model allows efficient use of functional resources.
The functional manager and the project manager may battle for project team members' time. Project team may feel they are reporting to multiple bosses.
The project manager has little project authority and acts as a project coordinator.
The project is more a part of the functional department operations than a separate activity. Project team resources may be divided amongst too many projects at once.
Ideal for organizations with recurring projects, such as manufacturing. Everyone on the project knows who is in charge: the functional manager.
The project manager has little, if any, project authority and may be known as a project expeditor.
In the last several years, there has been a surge in the popularity of the project office. The project office is the central source for project management support within an organization. So what can a project manager expect from the project office? How about:
Project management software
Training and mentoring
HR and project manager support
Access to knowledge repository
There is more to project management than just getting the work done. Inherent to the process of project management are 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.
The effective project manager will have experience, or guidance, in the general management skills we'll discuss in this section. These general management skills are needed in just about every project type-from architectural design to manufacturing. Other management skills are more specialized in nature, such as OSHA conformance in a manufacturing environment, and aren't needed in every project.
Project managers manage things, but lead people. What's the difference? Management is the process of getting the results that are expected by project stakeholders. Leadership is the ability to motivate and inspire individuals to work towards those expected results.
Ever work for a project manager that wasn't motivating or inspiring? 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 the perceived obstacles to get the work done. Motivation is a constant process that the project manager must have to help the team move towards completion-with passion and a profound reason to complete the work. Finally, motivation and inspiration must be real; a personal relationship with the project team to help them achieve their goals is mandatory.
Leadership and management are interrelated. You won't have effective leadership without management, and vice-versa. Know that leadership can also come from project team members, not just from the project manager.
Project Communication can be summed up as 'who needs what information and when.' Project managers spend the bulk of their time communicating information-not doing other activities. Therefore, they must be good communicators, promoting a clear, unambiguous exchange of information. Communication is a two-way street; it requires a sender and a receiver.
A key part of communication is active listening. This is the process by which the receiver restates what the sender has said in order to clarify and confirm the message. For example, a project team member tells the project manager that a work package will be done in seven days. The project manager clarifies and confirms by stating the work package will be done a week from today. This gives the project team member the opportunity to clarify that the work package will actually be done nine days from today, because of the upcoming weekend.
There are several communication avenues:
Listening and speaking
Written and oral
Internal to the project, such as project team member to team member
External to the project, such as the project manager to an external customer
Formal communications, such as reports and presentations
Informal communications, such as e-mails and 'hallway' meetings
Vertical communications, which follow the organizational flow chart
Horizontal communications, such as director to director within the organizational flow chart
Within management communication skills, there are also variables and elements unique to the flow of communication. While we'll discuss communications in full in Chapter 10, here are some key facts for now:
Sender-receiver models Communication requires a sender and receiver. Within this model, there may be multiple avenues to complete the flow of communication, but there may also be barriers to effective communication. Other variables within this model include recipient feedbacks, surveys, checklists, and confirmation of the sent message.
Media selection There are multiple choices when it comes to sending a message. Which one is appropriate? Based on the audience and the message being sent, the media should be in alignment. In other words, an ad-hoc hallway meeting is probably not the best communication avenue to explain a large variance in the project schedule.
Style The tone, structure, and formality of the message being sent should be in alignment with the audience and the content of the message.
Presentation When it comes to formal presentations, the presenter's oral and body language, visual aids, and handouts all influence the message being delivered.
Meeting management Meetings are forms of communication. How the meeting is led, managed, and controlled all influence the message being delivered. Agendas, minutes, and order are mandatory for effective communications within a meeting.
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. In some instances, typically in less than pleasant circumstances, negotiations may have to proceed with assistance. Specifically, mediation and arbitration are examples of assisted negotiations. Negotiation proceedings typically center on:
Changes to the project scope, schedule, or budget
Vendor terms and conditions
Project team member assignments and schedules
Resource constraints, such as facilities, travel issues, and team members with highly specialized skills
The purpose of negotiations is to reach a fair agreement among both parties.
Like riddles, puzzles, and cryptology? If so, you'll love this area of project management. 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. In any project, there are countless problems requiring viable solutions. And like any good puzzle, the solution to one portion of the problem may create more problems elsewhere.
The premise for problem solving is problem definition. Problem definition is the ability to discern between the cause and effect of the problem. This centers 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. 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.
Completing the PMP exam is an example of problem-solving skills. Even though you may argue that things described in this book don't work this way in your environment, know that the exam is not based on your environment. Learn the PMI method for passing the exam and allow that to influence your 'real-world' implementations.
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 within every organization. So where does project management fit into this rowdy scheme? Right smack in the middle.
These exam questions are very shallow. Don't read too much into the questions as far as political aspirations and influences go. Take each question at face value and assume all of the information given in the question is correct.
A project manager must understand all of the unspoken influences at work within an organization-as well as the formal channels that exist. A balance between the implied and the explicit will allow the project manager to take the project from launch to completion. We all reference politics in organizations with disdain. However, politics aren't always a bad thing. Politics can be used as leverage to align and direct people to accomplish activities-with motivation and purpose.
Social, economical, and environmental influences can cause a project to falter, stall, or fail completely. Awareness of potential influences outside of traditional management practices will help the project finish. The acknowledgement of such influences, from internal or external sources, allows the project manager and the project team to plan how to react to these influences in order for the project to succeed.
For example, consider a construction project that may reduce traffic flow to one lane over a bridge. Obviously, stakeholders in this instance are the commuters that travel over the bridge. Social influences are the people that are frustrated by the construction project, the people that live in the vicinity of the project, and even individuals or groups that believe their need for road repairs are more pressing than the repair of the bridge. These issues must all be addressed, on some level, for the project team to quickly and efficiently complete the project work.
The economical conditions in any organization are always present. The cost of a project must be weighed against the project's benefits and perceived worth. Projects may succumb to budget cuts, project priority, or their own failure based on the performance to date. Economic factors inside the organization may also hinder a project from moving forward. In other words, if the company sponsoring the project is not making money, projects may get axed in an effort to curb costs.
Finally, environmental influence on, and created by, the project must be considered. Let's revisit the construction project on the bridge. The construction project must consider the river below the bridge and how the construction may affect the water and wildlife. Consideration must not only be given to short-term effects that arise during the bridge's construction, but also to long-term effects that the construction may have on the environment?
In most projects, the social, economical, and environmental concerns must be evaluated, documented, and addressed within the project plan. Project managers can't have a come-what-may approach to these issues and expect to be successful.
Standards and regulations within any industry can affect a project's success. But what's the difference between a standard and a regulation? Standards are accepted practices that are not necessarily mandatory, while regulations are rules that must be followed-otherwise, fines, penalties, or even criminal charges may result.
For example, within information technology, there are standard sizes for CDs, DVDs, and floppy disks. Manufacturers generally map to these sizes for usability purposes. However, manufacturers can, and have, created other media that are slightly different in size and function than the standard. Consider the disposable, mini-CDs that hold short movies or advertisements for consumers. Some of these CDs come shaped like stars, footballs, and baseballs. Such products aren't exactly standard regarding format, but they don't break any regulations either. After a time though, standards can indeed become de facto regulations. They may begin as guidelines and then, due to marketplace circumstances, grow into an informal regulation.
An example of a regulation is a set rule or law. For example, the food packaging industry has some very particular regulations related to the packaging and delivery of food items. Violations of the regulations will result in fines and even more severe punishment. Regulations are more than suggestions-they are project requirements.
|On the Job|| |
Every industry has some standards and regulations. Knowing which ones affect your project before you begin your work will not only help the project to unfold smoothly, but will also allow for effective risk analysis. In some instances, the requirements of regulations can afford the project manager additional time and monies to complete a project.
If a project spans the globe, how will the project manager effectively manage and lead the project team? How will teams in Paris communicate with teams in Sydney? What about the language barriers, time zone differences, currency differences, regulations, laws, and social influences? All of these concerns must be taken into consideration early in the project. Tools can include teleconferences, travel, face-to-face meetings, team leaders, and subprojects.
As companies and projects span the globe to offer goods and services, the completion of those projects will rely more and more on individuals from varying educational backgrounds, social influences, and values. The project manager must create a plan that takes these issues into account.
Project plans must deal with many cultural influences: geographical, political, organizational, even relationships between individual team members. Projects in Dallas, Texas, have different cultural influences than projects taking place in Dublin, Ireland. Culture consists of the values, beliefs, political ties, religion, art, aspiration, and purpose of being. A project manager must take into consideration these various cultural influences and how they may affect the project's completion, schedule, scope, and cost.
|< Day Day Up >|| |