Puzzle Spectaculum: Project Management ... Part 3/4
Danijela Jerkovi?
Ba.Sci., CA Certified Accountant, CIA Certified Internal Auditor | Managing Director at Danijela Jerkovic's Services
The McGraw-Hill 36-Hour Course
PROJECT MANAGEMENT
Authors: Helena S.Cooke and Karen Tate
5. Planning Concepts
6. High-Level Planning
7. Detailed Planning for Execution
8. Building and Developing a Team
9. Facilitating Project Execution and Closeout
10. The Context for Project Management
11. Controlling Project Work
12. Organizational Project Management Maturity
13. Conclusion
Chapter 8:
BUILDING AND DEVELOPING TEAM
OVERVIEW AND GOALS
This chapter describes how the team is formed and presents some of the ways teams can be developed within a project.
Ultimately, however, the work is carried out by a team.
In the execution phase, the team puts its effort toward achieving a common goal, the project’s desired results. Getting the team to face the goal of the project directly, to work together effectively, to cooperate and integrate their work, and still to finish on time and on a budget is a challenge. Some techniques for team development are presented in this chapter. They involve applying the facilitating processes from project management, also known as knowledge areas.
The facilitating processes that focus on project plan execution are:
The areas that facilitate team development and a positive project culture include communication, team development, and human resources management, but to a certain extent, all of them are involved in creating an effective project team.
Being able to identify these processes and use them successfully is the hallmark of a professional in project management.
CREATING AN ENVIRONMENT FOR SUCCESS
Part of planning and executing a project is proactive—the project manager and team put their efforts and energies into doing things that must get done in order for the project to reach completion.
The project management professional combines the use of specific project processes with knowledge and wisdom from prior experience to create an environment for success.
Planning a project requires more than focusing on the work to be done. It requires planning the processes that will result in overall project success. These processes—often referred to as facilitating processes—are not always in the direct critical path of the project’s main activities. They enable the main activities by removing barriers, eliciting cooperation, and creating an environment of acceptance and support among team members, supporters, and stakeholders. Some facilitating processes are parallel to the phases and integrated within them. Most continue from the early initiation phase to the project’s closure.
THE IMPORTANCE OF COMMUNICATION ON PROJECTS
Most people can take a structured task in a structured work setting and bring it to the conclusion. But the people who can take a concept and convert it to action are a rare resource.
If team members are assigned to the project for a short period of time, much of what occurs on the project differs from their normal work. Even if the team has a general agreement on work methods, standards, processes, and a deliverable to be produced, the convergence of work from other groups and individuals inserts change into the process so that even a “tried and true” approach will need to be modified. The project manager sets the pace and tone for work by communicating what is expected of the team.
TEAM DEVELOPMENT
It is easy to underestimate the importance of teams in project management. The knowledge required to manage a team is a complex mix of human resources management, common sense, people skills, political and cultural know-how, technical understanding, and process facilitation. As technology advances, virtual projects are becoming more common, and multicultural teams increase diverse input into the process. Keeping the team working and preserving its cohesiveness throughout the project life cycle are significant challenges, especially where there is not a strong project management structure, such as a project management office, to help.
The first task in creating a team is to decide what kind of a team is best suited to the work of the project. Different team combinations and structures bring with them certain types of strengths.
The team is created by deciding how many individuals or groups will be needed and their composition. Then the team will need the definition of how they will work together, including:
An ideal team or subteam is five to seven people. An additional area of team development is training. While team members are expected to bring fully developed skills and capabilities to the team, they need training not only to learn the methods and approaches the project will use but also learn how to work effectively together. Training can include facilitated exercises, online or classroom training, and self-instruction modules. Training fills the gap between what the team members already know and what they need to learn to apply their abilities fully on the project.
HUMAN RESOURCES MANAGEMENT
Strategies for managing the resources of the project are put into play during the execution phase. While many projects focus on material resources, in a professional project, human resources often are the most costly and difficult resources to manage.
Valuable resources of money and time are spent just bringing the expertise of these diverse people to the team. Tapping their abilities early in the project maximizes the value that can be obtained by their unique knowledge, special skills, and differing perspectives.
CREATING TEAMS OF SIMILAR AND DISSIMILAR PEOPLE
Teams by their very nature will have a certain amount of diversity; judicious use of diverse team member backgrounds can bring specific talents to a project. Teams with members of similar backgrounds work easily together because they understand the norms of their group; they can quickly define a process or refine a product, but they are less likely to come up with a creative solution or a new process.
The project manager must be able to value, understand, and integrate these diverse points of view to explore possibly innovative solutions and at the same time stay on track, focused, and on the plan. Consider the differences in thinking styles. There are people whose dominant style is:
There are also different learning styles that need to be considered when conveying information to the team:
CREATING A PROJECT MANAGEMENT CULTURE
Because projects must operate differently from operations, they require a cooperative, creative, and mature culture. There is no time for hierarchy, arbitrary permissions, or distrust.
Everyone on the team is there because he or she has something valuable to offer. Everyone knows that individuals cannot succeed without the support of the team and that the team cannot succeed unless the team members are free to perform at their best. Some organizations arrange wilderness adventures or retreat to build the kind of team culture projects create. In an individual project, the project’s leadership sets the tone and environment for team trust and mutual cooperation. There is a place in project execution for technical knowledge, people skills, coordination skills, problem-solving skills, and even some “emotional intelligence.”
Processes That Promote Teamwork
People who work well together are able to focus on their work, deliver results on time, and meet a budget. In an effective project team, the entire team’s work is aligned with the project’s goals.
The project leaders and team members “own” their project plan, as well as the execution of that project plan. They are free to collaborate individually and as a group and address individual needs that are of concern to the team, but at the same time, they focus primarily on interdependent actions. While some decisions must be made by the leader, decisions are made primarily by consensus. Everyone participates, and team members feel empowered. Challenging questions are valued; conflict occurs, but people feel they are listened to and supported. The work environment honors individual diversity.
Building Trust
As a general rule, project management promotes trust within the team simply because the team is the only means to deliver the project. Promoting trust and teamwork is important to the project’s success. Distrust can erode quality, slow decisions, and fragment cooperation. Trust that exists in a team is affected by the team’s leadership, and the following processes—in addition to their contribution to standardization and integration of products—promote positive feelings of predictability and logic within the team.
Projects need:
Reinforcing Positive Culture through Autonomy
In a mature organization that understands and values project management, a detailed schedule is a tool for the team and for no one else. Management oversight will be based on the high-level schedule, except for spot checks of accuracy. Organizations that display the detailed schedule to all levels of management inside and outside the team may be playing politics or using fear and peer pressure to create an environment of compliance. More problems will be created by such visibility than will be resolved by it.
If the judgment of the project manager and project leadership is to have any weight, the resolution of a specific project management problem should be kept within the team. Project management is designed to be evaluated on results, not on the activity detail of getting there. In a professional environment, trust in individual performance is fundamental. In projects change is normal, and creative solutions may be needed that do not conform to traditional ways of doing things. On the other hand, if the new way is better, a new best practice may be created.
Reinforcing Positive Culture through Rewards
Rewards convey to the entire team what behavior is desired and reinforce success when it does occur. What leadership chooses to reward conveys to the rest of the team what values are to be recognized and what behavior is considered to be above the ordinary. A good amount of the potential for quality performance still rests with the individual’s own initiative. To tap individual initiative in a project management context and create a project management culture within the team, try giving rewards to reinforce:
Encourage peer recognition so that people get satisfaction from being recognized as worthy by their coworkers and so that the rewards are not unduly exaggerated in their importance. Save the team rewards for public recognition and staff meetings. Rewarding the team in such settings also conveys progress to observers and provides assurances that the project is still on track, on time, and on budget.
A word of caution: When very little structure exists, such as in the earliest stages of team activity, communications take on undue importance. It is prudent to select carefully what initial recognition is to be given and what that recognition conveys so that it elicits the desired response that this project team expects of every member.
To set work standards that support the team and quality performance:
TEAM BUILDING
When a team is formed, its members will go through stages of team development. The development stages have been defined crisply by one source as “forming, storming, norming, and performing.” In the earliest stages, individual team members are busy focusing on what is expected and what they are to do in their respective work roles. As dominance evolves and differences emerge, there is a predictable stage of internal conflict. Eventually, the group will evolve its own norms and begin to work effectively as a group.
When a team consists of members from different organizations or different cultures, team members should spend some time learning about the various cultures and environments.
To shorten the evolution of an effective team, team-building activities can be organized for the team by its leadership. Expectations for behavior and performance must be established promptly and in a cohesive manner when people first come into the project. When people arrive in a new work setting, they usually are open to new approaches. They will quickly form impressions of what is expected of them—in performance, in behavior toward others, and in teamwork. Having those standards laid out and communicated early in the project is important. If new standards are not established quickly, people go back to their prior work behavior.
Open discussion allows an airing of norms acceptable and not acceptable to the group and encourages discussion. Conduct periodic reviews with the group about how they feel things are going to ensure that hidden problems are not being ignored.
Creativity, hard work, finishing on time, and detailed factual analysis may be characteristics that are particularly valued in a project. Each member will bring different gifts to the benefit of the whole.
ESTABLISHING PROJECT MANAGEMENT CULTURE ON VIRTUAL PROJECTS
If a project team is not able to meet together, as in a virtual project, team members will need to participate in tasks using technology, contribute to common work products, and keep a paper trail for practically everything. On virtual projects, the team deduces norms for the project by observing who gets rewarded. Selecting the right individuals to recognize takes on exaggerated importance. Establishing best practices files, as well as 24- hour access, is just common sense.
Create an online project manual for round-the-clock reference on virtual projects. Having one place to look for guidance on performance standards creates a common ground. All the team members are here to work, and common standards give them something to comply with. Measures of quality communicated upfront direct the work toward agreed-on outcomes. They also enable people to be successful by defining success.
MANAGING TEAM RESOURCES
A project manager and team have finite resources to expend in delivering results on a project. Team members are assigned to work on the project for a specific period, and when that period is over, they are most likely expected to return to their regular jobs. They need to be able to start work promptly and work efficiently.
As a general rule, all the routine organization charts, job role descriptions, policies, rewards, and constraints that team members take for granted in the larger organization will need to be re-created in some form on the project. They need not be elaborate, but they are necessary. The extent and quality to which they are created depend on the level of maturity of the team in project management experience, the complexity of the project, and the support structure of the organization.
Getting agreement is important when the time exists to forge that agreement, but when time is short and the pressure is on, a single source of decisions allows people to move forward quickly together.
Team Meeting Procedures
Meetings help in getting group input and facilitate decision-making when these tasks can best be accomplished in a group setting.
Make the meetings as efficient as possible by using structured processes for project management and agendas that are intended for that type of meeting. Meeting procedures make meetings more productive; always have an agenda as a road map, and put the most important items first.
Post ground rules or principles that express how people agree they should work together; enforce them when discussions get out of line. Have stand-up meetings when they are never intended to last longer than a few minutes. Be brilliant, be brief, and be gone.
SUMMARY
This chapter focused on the team—creating it, developing it, and mobilizing its energies and talents toward the project’s ultimate goal.
When human talent is recruited to perform project work, team members often come from different work roles, different organization units, and even different cultures. It is up to the project manager to mold these individuals into a functioning and effective team.
Building a team means building trust and cooperation. The project needs everyone’s best efforts and can use the facilitating processes associated with communications and human resources management—plus group processes, principles, and techniques—to gain commitment and capture that extra edge of performance.
The goal of facilitating processes is to maximize positive influences and minimize the impact of negative influences.
Chapter 9:
FACILITATING PROJECT EXECUTION AND CLOSEOUT
OVERVIEW AND GOALS
This chapter describes the facilitating processes that a project leader and team use to implement a project and complete its deliverable.
The project phases described in previous chapters—initiation and planning—created a context for managing the project and delivering its benefits.
They are the point in the process where the parameters and requirements for the project are identified, developed in the project plan in adequate detail to manage a team, and built into infrastructure for executing that plan.
Addressing execution and closeout—the project manager and team use the work plans and infrastructure created during planning to carry out the work of the project. However, there is still a good deal to be done to ensure smooth execution. They must determine how facilitating processes can best be applied to ensure the success of the project. Some of the areas that facilitate project execution—scope management, risk management, communications management, human resources management, quality management, and procurement—also enable and advance the development of the product or deliverable.
Since facilitating processes are not sequential but rather are used throughout the entire project, each facilitating process area must be defined, developed, executed, and closed out. Each process must be integrated with the requirements of the project as well as the organization’s defined procedures that affect the project.?
Part of planning and executing a project is proactive—the project manager and team put their efforts and energies into doing things that must be done in order for the project to reach completion. Other parts are reactive— ensuring that the team works on what it should work on and not something else and that it does not lose focus or run out of time and resources before the project is complete.
Facilitating processes help the team to manage these challenges. The project manager combines the use of specific project processes with knowledge and wisdom from prior experience to create an environment for success.
When the deliverable is complete, it is turned over to the customer, and the sponsoring organization and the customer organization can realize the benefits of the project.
CREATING A SUCCESSFUL ENVIRONMENT WITH PROCESSES
Planning a project requires more than focusing on the work to be done. It requires planning the processes that will result in overall project success. These processes—often referred to as facilitating processes—are not always in the direct critical path of the project’s main activities. They enable the main activities by removing barriers, eliciting cooperation, and creating an environment of acceptance and support among team members, supporters, and stakeholders. Some facilitating processes are parallel to the project phases, integrated within them. Most continue from the early initiation phase to the project’s closure. Others are confined to a specific phrase such as project execution.
Project integration management focuses on the interrelationships of the parts of the project, ensuring that one area does not negatively affect another and getting the parts to perform effectively together.
The key documents that mark successive phases of initiation, planning, and execution provide evidence that project integration is taking place.
The processes that are used to develop the project’s deliverables also need to be identified, planned, and integrated so that they advance the project’s goals and intended outcome.
COMMUNICATIONS
The communications plan created during detailed planning is put into action when the execution phase begins. Startup information is distributed to members of the team, and announcements of the project’s implementation are sent to sponsors, customers, and stakeholders.
Reference materials are made available online for team members, and work methods and processes are explained. Immediate training is scheduled to inform the team of the project management process and how methods and tools will be applied.
Reliable, sound information is essential for a successful project. From the beginning, the team must have a vision of how the project will finish and what criteria must be met in order to declare the effort a success. The team also will need a variety of information regarding the project, its success factors, the business case, the deliverable’s requirements, and the technical methods and procedures that will result in a successful delivery. The entire project team also needs to be given a clear idea of what the client’s or customer’s needs are so that when faced with minor tradeoffs during execution tasks, those needs are not compromised.
Deciding how much structure is necessary requires a lot of knowledge, creativity, judgment, and wisdom.
Training the team in its work processes, both project management and technical work, helps to get the team working together more quickly. The project manager should specify which processes and templates everyone must follow and which are optional.
Partially developed forms for agendas, e-mails, reference file categories for the team, and reports can contain generic information from the start so that only specifics such as subtitles and dates or agenda items need to be added when they are used.
Identifying members of the team who are knowledgeable about communications methods and strategies can be useful when designing standard formats.
If central files for standard communications templates are set up in advance, valuable team effort is not wasted on overhead activities when the project is in full production mode on the deliverable.
Always presenting communications in the same format also helps the receiver to quickly identify what is being presented and go right to the essence of the message. The format conveys what is there, how it is to be used, and in what context. If good forms design practices are used, the data can be entered quickly and even added to later. Configuration control methods should show the proper version.
Communicating clearly is a way to manage risk through common understanding. Since creating, editing, and managing communications takes both time and effort, here are a few tips:
The central team can manage the routine aspects of communications. Repetitive tasks—such as keeping meeting minutes—can be assigned to specific individuals on subteams or rotated within the group.
Communicating through Reports and Data
The project communications plan should include a chart of what reports will be conveyed to the project’s stakeholders and team and who will be receiving the team’s reports. Some reports will be cyclic, and others will be event-driven. Since many people interacting with the project will be receiving information in different formats than what they are accustomed to, the project needs to set up definitions and possibly symbols to convey the importance and finality of that information. When people are asked to submit reports and data for the project, they also must know how accurate the data are or should be.
Distributing the Schedule
The deliverables schedule, as well as other versions of the schedule with target dates and tasks, can serve different purposes for different audiences.
The project management team will be using the schedule to promote desired behavior by selecting how it will be used with different audiences of stakeholders.
As a general rule, stakeholders should be provided with only the level of schedule detail that is appropriate to the amount of control they are authorized to execute if they do not like what they see.
Distributing Information to Stakeholders and the Team
An effective communications process takes an assertive stance to manage changes between what people expect and what is really relevant to complete the project. The plan identifies who will need what type of communications when, as well as the channels or medium to be used. If people are accustomed to receiving important information using certain channels or modes of communication, information received differently may not be taken seriously, and the communication may not achieve its intended goal.
The plan itself can be lean and simple. It lists the team members by type (technical or project management, subproject or contract), program manager, stakeholders, and support team (information technology, training). It records the communications methods, media, and schedule for distributing specific types of information to various project stakeholders. Whether it is a blanket announcement by e-mail or a personal address by executive management in a group meeting, the medium conveys information to the team as well as the content of the message.
The parts of a communications plan all serve a purpose; key people need to be involved in key areas of the project in order for the project to be effective.
Communication is everyone’s job, and changes and issues need to be communicated upward from project team members to team leadership, and direction, changes, logistics, status, and resolutions need to be communicated down to the team. Even with an effective process and a plan, a certain amount of miscommunication occurs on projects. The goal is to minimize the negative effects through systematic communications management.
MANAGING QUALITY
Ensuring quality on a project is a much larger topic than can be addressed in this chapter. Quality—meeting the agreed-on customer requirements—is a result of the convergence of many levels of effort on a project and is covered under scope management. A quality plan, established as part of the overall project plan, is the location for recording the project’s defined quality strategy. If standards, tolerances, and methods are defined for the organization as a whole, they also should be referred to in the quality plan. Any special applications or conditions required for the project to create a product or service that is unique or different need to be spelled out.?
Clearly defined customer requirements and managed customer expectations are shaped by the organization sponsoring the project and the maturity of the organization’s process environment.
However, quality is also a result of quality processes, particularly in project management. While the processes used to create the deliverable may be new, the processes to manage the project should be performed well and consistently.
While the entire project team is responsible for the quality, the project manager, working with the team’s leadership, takes explicit responsibility for the quality plan.
MANAGING COST
In many organizations, how money is managed can affect the profitability and financial health of the company. If the project can predict when resources will be needed, the organization can keep money in revenue-producing activities or investments until it is needed on the project. Cost-allocation formulas applied to the resource management plan during project planning can help to predict when needed resources must be available to the project to pay vendors, contractors, and fees, but adjustments and refinements need to be made throughout the execution phase to keep those predictions on target during changes.
By allocating the appropriate costs of project staff, financial resources, and material to each element of the plan, including sub-plans, timely access to capital and material can be predicted, and overruns can be extrapolated to dependent tasks if needed.
In profit-making organizations, staying in touch with financial managers throughout the project can help the project manager and team keep one finger on the pulse of the organization and address any special financial conditions that need to be accommodated during the project period.
Accountability
Estimating and forecasting prove their value during the execution phase. Whether or not members discuss it explicitly, the project team is accountable for responsible use of resources to every stakeholder, including other teams. If the project is to be successful and deliver its desired benefits to customers, it must be completed. Running short on resources inevitably will cause delays and can even cause project cancellation. While this is usually more of a concern to the organization as a whole than to the project team, it is important that team members recognize the negative effects of poor accountability. Executive sponsors may have specific legal accountability (Sarbanes-Oxley Act).
The administration is also part of project management accountability, particularly when it comes to contracts, subprojects, vendors, and legal advisors.
Logistics
In a construction project, logistics can mean getting the right materials to the right place for the tasks at hand. In modern professional projects, however, it also can mean not only getting the right people to the project at the right time but also getting the project sent to the right people as well.
Logistics planning needs to address not only the product development tasks but the project management tasks as well. Both need to be integrated for effective execution. More than one large project with several subprojects under it has found itself in trouble because the project plan included product development activities in its logistics planning but not the project management activities.
Ideally, program management and portfolio management would be used to integrate projects.
Contracts and Procurement
The many configurations of reward and penalty in contracting options can shape the cost and benefit of the contract to the project’s needs. It is important to remember, however, that the burden of communication can be increased, particularly if the work is not repetitive, standardized, and stable. Different interpretations and cultural expectations can wreak havoc on cooperative efforts, as well as create volatility when dependent deliverables eventually must be combined.
Specialists knowledgeable in contracting options and legal ramifications are a valuable resource to the team, but only after the project management professional has analyzed the “make or buy” decision thoroughly. The contractual arrangements always should be designed specifically to motivate and reinforce desired supplier behavior and compliance with requirements. Many organizations follow specific processes and procedures to be sure contracts are sound.?
领英推荐
MANAGING TIME
Many projects lose some or even all of their value if delivered late. This is particularly true of products in a competitive market, where market share goes to the first entry.
How team members and other personnel use and waste time affects the project.
Time is a resource. When an organization has decided that a need must be met through a project, the value of meeting that need may be amplified or diminished by time.
The Project Management Schedule
The duration of a project’s sequenced tasks is used to define the time window during which the project will create and deliver its product or service, and its benefits. Sometimes the duration of the project will be influenced by external elapsed time in the critical path of delivery: government reviews, external market influences, or delayed access to critical resources or approvals. The team is expected to anticipate these delays—to the extent possible—and include them when estimating tasks in the schedule. By the time the go/no-go decision is reached, the schedule is expected to be reasonably accurate.
?Some schedules can be done using automated tools; others—such as work leveling for professional assignments—must be done by analysis.
Communicating the Schedule
There are various ways to communicate the allocation of time in projects, including Gantt charts, flowcharts, sequenced processes, deliverable schedules, and resource time reporting. Even the time value of money and earned value tracking against a plan imply the expenditure of time.
MANAGING RISK
Given the “newness” of project initiatives, a certain amount of risk is inherent in them.
The risk of unknowns is the lack of ability to predict and control those unknowns. Using systematic methods of identifying risk, quantifying risk, prioritizing and tracking risk, and controlling the loss associated with risk-based problems helps deliver projects successfully. Depending on the risk tolerance of the organization sponsoring the project, the subject of risk management may or may not be a challenge. As in most other areas of project management, the ability to predict and prepare for exigencies is a critical success factor.
Risks can be categorized and compared with the project’s critical success factors: scope risk, schedule risk, financial risk, and so on. Since not all risks can be managed to owe to the constraints of time and effort, creating a risk management plan and strategy helps to keep real risks at the forefront and manages emerging risks using a process.
Discussing risk with the project’s sponsor and customer prepares them for what may arise later. For the team, predicting and controlling risk releases valuable time, resources, and energy to more critical functions of execution.
Some team members will resist risk management because avoiding risks that actually never happen does not merit much attention. On the other hand, fixing risks once they become problems allows someone to be a hero.
Methods for Managing Risk
Managing risk throughout the project requires that team members get involved in the risk management process.
One method of defining risk is to develop a list of potential threats to a project and to involve skeptics from the project initiation stage in the definition of those risks. To get technical team members active in the risk management process, use definitions and terms already familiar to them from their technical work so that they quickly see the value. Executives will be more comfortable seeing risks presented in charts or numerical rankings similar to the briefings they receive daily.
Categories of risk—such as organizational risk, technical risk, environmental risk, or legal risk—can be standard, and the particular instance to be managed can be placed in a subcategory under one of these headings.
Putting numbers at risk is an exercise in quantifying subjective judgments in order to arrange them in their appropriate priority. Once risks have been categorized, two numbers can be assigned—likelihood (probability) and seriousness (impact)—and multiplied for all the risks in a given category to determine which risks deserve the greatest attention. Some risks are highly threatening but unlikely to occur. Others are not so serious individually but collectively can add up to a serious concern. Some projects develop a symbol of emerging concern (such as the green, yellow, red stoplight motif) to alert the team to the level of concern of particular risks for particular tasks or stages of the work. If such a method is used, written agreed-on definitions are necessary so that the symbols can be used effectively over time.
Allocating and Tracking Risks
Individual subprojects or teams within a large project may be assigned to track risks most likely to emerge in their area of the project. They are also accountable for the countermeasures, mitigation, and contingency resources associated with those risks. Individual managers may be willing to accept responsibility for specific areas of risk that relate to their area of work. Some risks can be spread across the entire team, with individual team members responsible for tracking their status.
Responding to Risk
There are a number of ways to respond to risk. Sometimes the risk passes without incurring any problem; the avoidance plan or mitigation plan was successful in preventing the risk or reducing its impact. Taking out an insurance policy to transfer the risk (referred to as risk transference) or seeking legal advice may be called for on some projects, and even regular communication with specialists may be required in particularly volatile environments. These measures not only need to be in the risk plan and schedule, but their cost also needs to be in the budget. If specific documentation or compliance is required, the team needs to be informed. If the risk predicted does occur then the project must cover it out of contingency reserve funds or time.
A good fallback is to visit risk often and keep it up to date. Identify the types of risks, quantify the risk impact, and determine countermeasures. The countermeasures can be prevention, avoidance, transference, and mitigation. Select the most appropriate countermeasures to implement. Once the countermeasures have been decided on, put them in the schedule and the plan, with appropriate tasks and resources.
POLICY AND STANDARDS
The management policy and standards guiding the team need to be articulated and communicated so that they convey a common view to the diverse groups interacting with the project’s members. The core team most likely will be dealing with many different audiences. For internal projects, they will be interacting with managers, internal customers, technical teams, support personnel, and operations teams. For external or public projects, the core team is also likely to interact with:
Each group has different priorities guiding its work and its view of the project. If these groups are to support the goal and mission, they need to have a common understanding of how their support will be needed. The policy and standards that apply to the project may differ from those that apply in operations, or they may be applied differently because the project is creating something unique. Conveying that difference to stakeholders eases concerns and creates better understanding and support for the project.
PROJECT INTEGRATION MANAGEMENT
Project management is an integrative undertaking.
The complexities of iterative planning and definition require periodic integration of core processes with facilitating processes and of stable standard processes with processes that have been changed and adapted to fit the project.
For the product or deliverable, there are natural points in the project where integrated change control makes sense: at the end of each product development stage, at the end of lengthy consecutive tasks that are interdependent, and when different paths of the project converge.
Integrated change control is a review process to ensure that changes made to the deliverable product or processes are analyzed for potential negative effects on the requirements and desired outcome of the project.
Some product development processes used in operations do not lend themselves to application on projects. New or changed processes from the project need to be documented and refined for turnover to operations. Project management integration requires each project and product process to be appropriately aligned and connected with the other processes to facilitate their coordination. These process interactions often require tradeoffs among project requirements and objectives (PMBOK Guide 2004).
A final key point for integration occurs at the close of execution. At this point, the product or service that resulted from the project is turned over to its customers and users—or to operations or another project—and must be reconciled with the requirements and limitations agreed to during the initiation phase.
Integration is a skill that finds similarities, dependencies, and convergences by looking at a situation from several distinct views and aligning them into a comprehensive whole.
With integration, estimates and “actuals,” promised dates and delivery dates, and resource budgets and resource expenditures all become more credible as the project progresses. The term used to describe this phenomenon is progressive elaboration:
Progressive elaboration of product characteristics must be carefully coordinated with proper project scope definition, particularly if the project is performed under the contract.
When properly defined, the scope of the project—the work to be done—should remain constant even as the product characteristics are progressively elaborated.
The future direction that results from project integration management shapes the work still to come and steps over unnecessary complexity and confusion, focusing efforts—as always—on the end result.
ALL PROJECTS HAVE A BEGINNING AND AN END
Project closeout is a time when the value of planning and execution is demonstrated.
When the project’s deliverable—product, service, process, or plan—is turned over for use at the end of the execution phase, the expectations and promises that emerged during initiation are evaluated against actual results, and the benefits of the project are realized.
It is prudent to plan the project’s closing process in advance. Expert opinion and precedent are useful in planning the closeout phase. Other projects will have lessons to share, and improvements made in the planning phase can simplify the process. The complexity and structure of closeout vary depending on the size and type of project.
TURNOVER OF RESPONSIBILITY FOR DELIVERABLES
Turning over the project deliverables to the project customer occurs at the end of the execution phase, and during the closeout phase, the responsibility for the deliverable shifts to another group. At this phase of the project, technology transfer, training and operations functions, and maintenance responsibility all shift to the operational owner of the final deliverable. If acceptance criteria were clearly defined in planning, the customer and the team will know when they have met the requirements, and any minor issues that remain can be resolved.
Delivering the Product for Use and Closing Technical Work
The task of closing product work on the deliverable sometimes is “owned” by the lead technical team. Sometimes, however, it is handed off to a maintenance or support group. Specific responsibility needs to be established in advance as to who will complete the package of information, instructions, product startup, support, and services and make sure that the deliverable is operational.
Delivering the Business Value
The value of the project was established when it was first initiated.
At closeout, any variances are identified and explained, and “lessons learned” from the project are documented. Just as many levels of the organization have expectations about the project and its product, several levels are involved in closing out a project.
The organization’s investment of time, resources, and attention to the project’s completion is returned when the business value of the project is realized. The achievement of these goals is presented in the final closeout report. Typically, the close of a successful project is welcomed by the project’s sponsors and beneficiaries because they had already decided that the risks were worth the benefits. Seeing the project deliver the benefits is the payoff for taking those risks. If a change must occur, at least it can be done well, in a professional manner, with minimal disruption to existing areas.
Releasing Technical Resources
Resources that were important to execute the project are no longer necessary once the project team has completed its work. While the people who fostered the work, funded it and supported it through various changes are glad to see the project reach its conclusion because the benefits are likely to be realized at that point, team members, who have bonded and become involved in the daily affairs of the project, often are not so eager to see the project end. People who were assigned to the team most likely will be expected to transfer promptly back to their old job roles, and people who were contracted from outside will move on to another assignment.
Announcing Project Completion
Announcements to stakeholders and customers that the project is complete prepare line management to retrieve technical workers assigned to the project and the customer to apply the deliverable in its worksite. Public meetings on the deliverable(s) help to transition team members back to their line functions and recognize group achievement.
Administrative Closure
Members of the project management team often remain to close out the management tasks after the technical team is released. Legal and administrative closeout duties include disposal of unused resources and materials, addressing contractual agreements, administrative release and reassignment of technical team members to their other jobs, and updating of personnel records. Evaluations are filed, data are submitted to higher-level data files, and required documents on the project are sent to archives in case they are needed in following up loose ends or challenges. Recommended changes to processes are forwarded to operations. All these processes, forms, and data files need to be tasked to someone in the project plan before the project comes to its end so that they are completed before closure.
Team celebration also is an important task.
It serves several purposes:
Also, there needs to be a formal announcement of closure to all who interacted with the team and process. Communicating a closing team event is one way to make such an announcement without the expectation that anyone needs follow-up.
LESSONS LEARNED AND PROCESS IMPROVEMENTS
It is natural that the focus of the project will be on satisfying the business and functional requirements of the product itself more than on the lessons learned because this is what the team is rewarded for doing. Creating or refining the deliverable(s) has been the primary focus for some time. However, now that the product or service is complete, there is still a technical responsibility for capturing the important lessons that will improve future project efforts.
The project plan should specify responsibility for the final review and capturing lessons learned on the project. There also needs to be a process to capture improvements and best practices as part of closing the work associated with the deliverable. The closure is also the last opportunity to capture lessons learned for improving project management organizational processes to repeat the success in future projects. Some of the lessons learned can include refinements to the standard project process, estimating methods, historical data, and resource planning methods and tools, as well as metrics data collection points.
Technical and administrative support should be planned for the last phase of the project.
While the project budget is prepared during planning with an emphasis on delivery of the project results and deliverables to the customer (product closeout), it is important also to include in the budget a task for managing and disseminating project data within the sponsoring organization (administrative closeout) when the project is formally closed.
SUMMARY
This chapter covered the facilitating processes that support the core processes, particularly processes used in the execution phase.
These processes correspond to the “knowledge areas” on the project management professional certification exam presented initially in Chapter 1. These knowledge areas and their corresponding processes are flexible tools that a project management professional can use to create an environment for success on a project, and they are used to anticipate positive and negative influences on the successful outcome of the project. The goal of facilitating processes is to maximize positive influences and minimize the impact of negative influences.
The primary emphasis in professional projects is on completing the project and delivering its intended outcome, value, and benefits. Communicating the information and technical context for work, using risk management to prevent negative influences on the project, and adjusting the use of time and effort help the team to complete the deliverable(s) in the estimated time frames. Standards, policy, processes, methods, and documented expectations shape the work of professionals, and communicating in ways that make sense to different groups help to enlist their support and commitment to complete the project.
As project work is completed at the closeout phase, the requirements and success criteria are used to evaluate the project’s effectiveness and communicate the value of the effort to the customer and sponsor. The technical team disperses, the responsibility for upkeep and maintenance of the deliverable(s) shifts to external groups, and the project work and lessons learned are closed. Improvements are shared with future projects through best practices files and project archives. Stakeholders are notified that the project is over, and people return to their regular assignments.
Many of the elements from facilitating processes become controlling processes as well when applied with control priorities at the forefront. If proactive prevention—which is less costly—is effective, there is less need for control. Control can be focused on the areas where positive management of the critical path and critical success factors shape the final deliverable and ensure that it meets project requirements.
Chapter 10:
THE CONTEXT FOR PROJECT MANAGEMENT
OVERVIEW AND GOALS
This chapter describes the environment of quality and learning established for the project team. This context for project management enables the project management professional and team to capture and maintain the elements required for the quality execution of a successful project.
A carefully drawn scope statement establishes the boundaries within which the project team will conduct its work. The autonomy established for the project allows the team to operate freely within those boundaries. They may draw on any relevant processes, resources, and procedures from business operations to create the deliverables and outcome, but they also enjoy the freedom of internal decisions that encourage creative solutions to unexpected challenges
The organization should create an environment that supports the smooth delivery of the unique deliverable(s) to the sponsor and customer.
A knowledgeable and effective team working within a supportive environment from the sponsoring organization will increase the likelihood that the project will deliver results successfully and smoothly.
The project management knowledge possessed by the organization and the project manager is an underpinning for creating this environment. Knowledge provides a foundation for independent actions within the team and a common platform for developing strategy and group consensus on decisions and plans of action and desired outcomes. However, the project also must operate within the context of the sponsoring organization. The sponsoring organization helps to shape the project’s expectations. The project team must stay in line with management’s strategy, conform to organizational policies, and realign their work with shifting priorities as they change over time. It also must know, acknowledge, and respect the different expectations of quality the customer may have of the project deliverable(s).
The knowledge, skill, and ability of the project manager and project team are not the only determinants of context for project management.
If the larger organizational environment is not supportive of quality project management, the project team will have limited ability to succeed.
Ultimately, it is the responsibility of the project professionals—the project manager and team—to create an appropriate context for the project with the limited resources available. Creating this context can make all the difference in seeking and achieving quality.
While this chapter addresses methods and processes for establishing the context for quality on a project, it also touches on how to shape quality by directing the manner in which individual members of the team go about their work
QUALITY ASSUMPTIONS
Over the past decade, most organizations have adopted the concept that designing quality into products and services is a significant way to reduce costs and expedite results. People talk about how quality is “designed in, not inspected in.” The project’s approach can be established to address quality and prevent problems from being discovered too late to deliver a quality product or service. Rather than fixing things after they go wrong, the project team should focus on ways they can prevent problems from happening in the first place. Anticipating and preventing problems, weighing the costs and benefits of prevention, and choosing the appropriate actions are fundamental to project management. It is beneficial to challenge, ask questions, and bring issues to light. There likely will be enough unforeseen problems to fill available time once the project moves into execution.
How does the team determine what “right” is when there is so little precedent and so much is new?
One way is to get insight from external sources—best practices and technical standards—and to put proper processes in place. A second is to solicit input from carefully selected people outside the project.
Processes that bring quality workmanship to the project can help the team do what is “right” when performing work. People who have worked on similar projects are a good source of perspective. Planning processes should address as many facets of quality as possible to prevent the team from being blindsided downstream. Technical expertise can shed light on hidden issues. The team should reference these “lessons learned” from prior projects during planning. They can record the issues in the risk plan until more is known about the conditions and requirements under which the project will be operating.
There is always a process, even if it is a default process. Organizations in which processes are defined and used, and where the use of those processes is emphasized and enforced by management, get better results. There are both technical processes and project processes on a project. Both need to be managed consciously. Technical processes are brought into the project by the technical experts doing the work. Some project processes are defined by the organization. Others, however, will need to be created by the project manager and team.
Constantly challenging assumptions, raising questions, and looking for potential problems before they happen “clears the air.” Actively looking for challenges helps to make the invisible visible so that it can be managed.
The Project’s Risk Profile
There is a significantly different level of effort in managing risk between projects that are very risky and those that are more routine. In relatively routine projects, the risks that are present can be identified, analyzed, and ranked to focus on the most troublesome or the most threatening. In high-risk projects, risk management becomes part of every team process, and the entire team must be risk-focused in their work. In most organizations, there is a “process owner” for the technical processes. For those technical processes that contain more risk, that person will need to be engaged somehow in defining the proper approach to mitigate and manage those risks. If internal process specialists are not available, external sources can be found to provide advice on the risks and how they might be managed.
The decision-making process will need to be monitored and managed carefully in order to ensure that people do not revert by habit to “doing things the way we have always done them.”
Rote behavior in a high-risk environment can be dangerous.
The frequency of reviewing risks also will increase in a high-risk project. Rather than establishing a weekly or monthly cycle for a risk review, daily risk briefings may be needed. New insights and new sources of information can escalate new risks to the fore, changing the game plan while it is in progress.
Deliberate Managing of Change
Another key area for maintaining a positive context for project success is the acknowledgment and acceptance of change as a normal part of projects. Outside projects, a benefit of repetitive operations is that ineffective practices are eliminated from the process, streamlining the effort toward results.
?On projects—particularly high-risk projects—whenever a process is identified as ineffective or counterproductive, it must be changed promptly to avoid wasted effort. The team needs to be alert to this priority of change and responsive to team leadership direction.
Frequent change management briefings help to keep everyone working together and their priorities on track toward completion. Some people welcome change, but most do not accept it so readily. This resistance to change is part of the human condition—not knowing what the future will bring, still wishing to control it. To stay on top of this natural reluctance, teams need to make change more acceptable and break down resistance by making change management part of the project process.
People are at different levels of readiness for change.
On the bright side, if everyone else is going through the change, some people will feel lonely, increasing their likelihood to stop resisting and join the others.
Some principles for encouraging increasing acceptance of change include:
There are a number of necessary ingredients for change to be effective:
THE PROJECT CULTURE: CONTINUOUS LEARNING AND IMPROVEMENT
If a project team is successful at making management of change part of the project, the members of the team begin to look for improvements. At the end of every project, of course, good practice says that the team should get together and capture the lessons learned on the project. Immature management environments look for people to blame. Mature management environments look for ways to make everyone successful on the next project. People who take personal pride in their work use continuous learning and lessons learned to improve their own performance.
Some problems and errors are not crucial and will simply be ignored. In some work environments, seeing no problems at all is seen as an indicator that people are working too conservatively and are not addressing risks head-on.
Once people accept problem identification as a valued contribution to the project, the behavior, and skills that are valued are pointing out problems and articulating their potential influence and possible resolution.
This is one of the core skills in project management—finding problems before they happen, focusing on the process, not people, keeping the project work on track, and achieving the expected project results.
PROJECT DECISIONS AS AN ELEMENT OF QUALITY
Some decisions are straightforward and can be made without collaboration. Others require careful thought and the input of several people. How decisions are made on the project is one area where quality can be built into the process. In a project management context, there are effective and ineffective ways to make decisions. Using a good decision process is critical in the project environment, where so many decisions must be made.
Studies have shown that there are two distinct approaches—inquiry and advocacy—and that inquiry will produce better outcomes. David Garvin and Michael Roberto outlined these processes in a Harvard Business Review article in 2001.
Inquiry is “an open process designed to generate multiple alternatives, foster the exchange of ideas, and produce a well-tested solution.”
Advocacy is a process that treats decision-making.
Considering a variety of options and working together to find the best solution creates a proper context for anticipating, avoiding, and managing risk while staying focused on results.
Although one might envision a team making decisions in a conference room, quality decision-making can occur wherever the project takes place. A great example is the Wright Brothers’ approach to decisions when creating a way to control powered flight. It was a hundred years ago. They were just a team of two, but they did not let their limited numbers get in the way of quality decisions. as a contest where participants advocate for their position without considering other points of view.
THE WRIGHT BROTHERS’ PROJECT TO CREATE CONTROLLED FLIGHT
In 1903, Orville and Wilbur Wright became caught up in the flight fever of their day. For the previous two years, they had been actively watching other people in the air using balloons; some had even done some pretty spectacular things with gliders. The brothers became convinced that humans not only could fly but also could control powered flight.
Orville and Wilbur Wright were both tenacious inventors. They were much more than the popular image portrayed of them—bicycle vendors dabbling in flying machines. They were cutting-edge engineers. For the state of manufacturing technology of their day, they demonstrated considerable creativity and technical expertise. But they also were more than creative geniuses; they were aeronautical engineers without occupation to work in.
They experimented with options for power and the ratios of power and lift. At some point in moving from testing the concept to high-level planning, they decided that they actually could do it. They decided to embark on a project to prove the concept of powered flight.
In planning project execution, the brothers had a project development site and a project execution site that were in completely different locales. This was not done by accident. It actually was the result of careful planning.
Bicycle manufacturing was “high technology” in the early twentieth century, a perfect springboard for two brothers interested in flight. The emphasis on bicycle manufacturing was quite relevant to starting a project to prove the feasibility of controlled flight.?
The brothers had the technology to their advantage and even access to supportive resources.
Their project had all the standard challenges of doing something unique for the first time. There were a lot of unknowns. The decisions they made would affect the quality of their experiment, but they had no way to test the concepts on others because they were so new. Furthermore, it was dangerous. The wrong decisions could lead to disaster.
The brothers went back and forth between Dayton and Kitty Hawk, conducting tests and perfecting their designs. They used different instruments and different vehicles to prototype and test them. They knew that as time passed, winter drew near. They had a window of opportunity to carry out the flight. If too much time passed, they would be facing winter winds and weather. With the risks, everything had to be ready. And if everything was ready too late, they would have to wait until the next year.
The project execution phase-controlled flight—meant moving to a new location. In the summer of 1903, they built a more sophisticated aerodynamic airplane with the help of Charles Taylor, a machinist hired on from the Dayton Electric Company.
The Wright brothers had already set their quality standards for project completion before beginning execution. The plane had to respond to wind using controls, the pilot had to be onboard handling the plane, and the aircraft had to land higher than the takeoff point to prove that they were not just leveraging gravity and winds, something gliders had already accomplished. The first attempt lifted off the ground, but it landed downhill. Being lower than the point they took off from, they determined it had not “proved” powered flight. Considered unsuccessful, that flight by Wilbur was written off and not counted. By default, it was Orville’s turn in the pilot’s seat when the good run occurred.
The first powered flight of human beings truly was a project. It used conceptual development, initiation, research, specialists, planning, quality standards, use of prior project experience with nonpowered flight, site selection, team selection, quality-based decision methods, and metrics to establish quality gates for project completion. Once in the execution phase, it used controls, measurements, problem resolution, communications, risk management, and team management. The life cycle of the “product”—the aircraft—did not end with the project. It made many more flights promote aviation, and finally, retired, it provides history and inspiration to us today.
“Achieving the brothers’ dream of the first successful powered flight has had tremendous consequences for the United States and the world.”
Today they are considered breakthrough innovators. “True pioneers, the brothers possessed a combination of intellect, curiosity, and just plain gumption that exemplifies the best of the American Spirit.”
And, we might add, the best of project management. Remember, in 1904, the project management books we have today had not yet been written. The Wright brothers ran a project with rigor and discipline, planned and executed systematically. While they may not have had the process documentation or terminology, they ran a real project. Their team was, like all teams, soon forgotten, and their sister—who was the business brains behind the effort— is rarely mentioned. The public remembers the product, not the project.
PROJECT MANAGERS DO NOT ALWAYS GET HIGH VISIBILITY
Project managers do not always get visibility and often do not seek it. Results are what they are looking for. They apply all the knowledge, skill, planning, process, measures, controls, and team management needed to get results. When the project is over, they move on.
Some of the methods used on this project are still best practices from which we can learn:
questions.
Any person or group who has not been on a project team before may not recognize or acknowledge what it takes to do a good job of project management. They are more likely to focus on the end product, the service, or the final achievement.
It is important to remember, though, that they more often will remember that something did not work than if it was late or over budget. The project management professional must integrate the goals of executive management with the goals of the project. Often executive management gets the credit if the project is successful. It is probably a good thing that the adventure of project management has its own rewards.
STAYING ALIGNED WITH THE EXTERNAL ENVIRONMENT
While it is tempting to focus just on the work of the project and to perform the tasks laid out in the project plan, the environment can change, affecting the overall success of the project.
Knowledge about competing initiatives, impending changes, or threats may not change the actual tasks for completion, but they may have a significant effect on the communications plan.
SUMMARY
This chapter presented the importance of creating an environment of quality and learning on a project.
Creating a context for success on a project means defining what quality means for each project situation, and using a variety of ways to engage the team in performing quality work.
Leadership sets the standards and environment for quality on a project, and the focus should stay on producing results of value to the customer and the sponsor. Working with management, outside experts, and customer representatives requires awareness of their different performance viewpoints.
Taking a proactive approach to quality frees the professional team to get a consensus on what a good job looks like so that they can work together to define the best strategy and deliver a quality deliverable with all its associated benefits.
Once the team and management recognize that results provide the real value, the motives to hide problems, blame others, or dodge emerging issues drop to the wayside. Challenging assumptions, seeking different viewpoints, and capturing best practices through “lessons learned” all pay off in benefits for the entire team. The team’s leadership must decide how to best leverage the ideas, talents, and expertise available on a project, working with management, outside experts, and customer representatives.
Once the project context has been created for quality performance, timely results, and team efficiency, then the problems that emerge are no longer defined as individual personal problems; they are team challenges. Everyone works together to produce a quality end result.
Once a common vision has been agreed to and a common approach has been designed to deliver quality, then controls can be established to ensure that the project reaches closure still balancing schedule requirements with performance requirements and costs. The project context has been created that will allow success.
Book Availability Thanks To:
... and ...