PMBOK Quick Implementation Guide - Standard Introduction, Tips for Successful PMBOK Managed Projects, FAQs, Mapping Responsibilities, Terms and Definitions

PMBOK Quick Implementation Guide: Standard Introduction, Tips for Successful PMBOK Managed Projects, FAQs, Mapping Responsibilities, Terms and Definitions

Notice of Rights: Copyright © Daniel Lawson. All rights reserved. No part of this book may be reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Notice of Liability: The information in this book is distributed on an “As Is” basis without warranty. While every precaution has been taken in the preparation of the book, neither the author nor the publisher shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions contained in this book or by the products described in it. Trademarks: Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations appear as requested by the owner of the trademark. All other product names and services identified throughout this book are used in editorial fashion only and for the benefit of such companies with no intention of infringement of the trademark. No such use, or the use of any trade name, is intended to convey endorsement or other affiliation with this book. ITIL® is a Registered Community Trade Mark of OGC (Office of Government Commerce, London, UK), and is Registered in the U.S. Patent and Trademark Office.

Write a Review and Receive a Bonus Emereo eBook of Your Choice

Up to $99 RRP – Absolutely Free If you recently bought this book we would love to hear from you – submit a review of this title and you’ll receive an additional free ebook of your choice from our catalog at http://www.emereo.org.

How Does it Work? Submit your review of this title via the online store where you purchased it. For example, to post a review on Amazon, just log in to your account and click on the ‘Create Your Own Review’ button (under ‘Customer Reviews’) on the relevant product page (you’ll find plenty of example product reviews on Amazon). If you purchased from a different online store, simply follow their procedures.

What Happens When I Submit my Review? Once you have submitted your review, send us an email via [email protected], and include a link to your review and a link to the free eBook you’d like as our thank-you (from http://www.emereo.org – choose any book you like from the catalog, up to $99 RRP). You will then receive a reply email back from us, complete with your bonus ebook download link. It's that simple!

Project Management

TABLE OF CONTENTS 1

INTRODUCTION ............................................................................. 7 1.1

WHAT IS PROJECT MANAGEMENT? ................................................... 7

2

A WORLD WITHOUT PROJECT MANAGEMENT ............................ 9

3

INTRODUCING PMBOK............................................................... 13

4

ADDING THE PROJECT MANAGER TO THE MIX ........................ 15

5 MANAGING THE CLIMATE OF A PROJECT FOCUSED ORGANIZATION................................................................................... 19 6 GROUPING THE PROJECT MANAGEMENT PROCESSES TOGETHER............................................................................................. 23 6.1 7

PLANNING THE PROJECT ............................................................ 29 7.1 7.2 7.3

8

INITIATING THE PROJECT .................................................................. 26 EXECUTING THE PROJECT ................................................................ 31 MONITORING AND CONTROLLING THE PROJECT .............................. 32 CLOSING THE PROJECT ................................................................... 34

FRAMING PROJECT MANAGEMENT .......................................... 37 8.1 THE PROJECT PLAN AS AN INTEGRATION PRODUCT ........................... 40 8.1.1 Developing the Project Plan ....................................... 42 8.1.2 Executing the Project Plan .......................................... 46 8.1.3 Controlling Change to the Project Plan .................... 47 8.2 PUTTING A STAKE IN THE GROUND – PROJECT SCOPE ....................... 50 8.2.1 Igniting the Project ....................................................... 50 8.2.2 Creating the Stake ....................................................... 52 8.2.3 Defining the Boundary Limits ....................................... 53 8.2.4 Announcing the Claim................................................. 56 8.2.5 Fending Off the Claim Jumpers .................................. 58 8.3 CONQUERING TIME ........................................................................ 61 8.3.1 Defining the Activity ..................................................... 62 8.3.2 Which Came First, the Chicken Or the Egg............... 64 8.3.3 Hard-Boiled or Soft-Boiled............................................ 68 8.3.4 Scheduling..................................................................... 71

3

Project Management

8.3.5 Controlling the Schedule ............................................. 74 8.4 BANKING ON IT .............................................................................. 74 9

LEANING ON RESOURCES .......................................................... 77 9.1.1 Applying Cost................................................................ 77 9.1.2 Budgeting the Project .................................................. 79 9.1.3 Controlling Cost ............................................................ 80 9.2 MANAGING THE RIGHT STUFF .......................................................... 80 9.2.1 Quality is Planned ......................................................... 81 9.2.2 Quality is Watched ....................................................... 84 9.2.3 Quality is Controlled ..................................................... 84 9.3 WORKING WITH PEOPLE .................................................................. 87 9.3.1 Working Together.......................................................... 88 9.3.2 Finding the Right People.............................................. 90 9.3.3 Developing Team ......................................................... 91 9.4 OPENING UP THE LINES OF COMMUNICATION .................................. 93 9.4.1 Laying the Infrastructure .............................................. 94 9.4.2 Making the Connection .............................................. 96 9.4.3 Cleaning Up Static........................................................ 96 9.4.4 Ending the Connection ............................................... 98 9.5 BASE JUMPING A PROJECT.............................................................. 99 9.5.1 The More Risk, the Better the Experience ................ 100 9.5.2 Extreme Sports or Golf?.............................................. 103 9.5.3 Be Prepared ................................................................ 105 9.5.4 Taking the Jump ......................................................... 106 9.6 GOING SHOPPING ....................................................................... 107 9.6.1 Creating a Shopping List............................................ 108 9.6.2 Walking the Mall ......................................................... 110 9.6.3 Window Shopping ...................................................... 111 9.6.4 Finding the Right Store ............................................... 111 9.6.5 Making the Purchase ................................................. 112 9.6.6 Wrapping It Up ............................................................ 113

10

CONCLUDING PROJECT MANAGEMENT ................................ 115

11

COMPARING PROJECT MANAGEMENT FRAMEWORKS......... 117

12

APPLYING CLOUD COMPUTING TO PROJECT MANAGEMENT 121 12.1 12.2

4

BENEFITING FROM CLOUD COMPUTING .................................... 121 THE EASE OF LINKING (HYPERLINKS)........................................... 123

Project Management

12.3 12.4 12.5 12.6 12.7 13

SUBSCRIBING TO SUCCESS (BLOGGING).................................... 126 INTERFACING WITH THE PROJECT (MASHUPS) ............................. 128 EVERYONE IS A PROJECT MANAGER (OPEN SOURCE) ............... 130 TREATING THE PROJECT AS PARTS, NOT THE WHOLE (REUSE) ....... 133 TESTING THE LIMITS (PORTABILITY) .............................................. 135

THE PERSPECTIVES OF PROJECT MANAGEMENT .................... 137 13.1 13.2 13.3

A PROJECT AS INFORMATION ................................................... 138 A PROJECT AS WORKFLOW ...................................................... 140 A PROJECT AS PEOPLE ............................................................. 142

14

SUMMARIZING PROJECT MANAGEMENT ............................... 145

15

REFERENCES .............................................................................. 147

5

Project Management

6

Project Management

1 Introduction 1.1 What is Project Management? The executive board has just convened and under discussion for today's meeting is a proposal for a new service. The board has been working for weeks on the company's future goals and the business sectors have been encouraged to find innovative ways to expand the company's business offerings. An enterprising young manager has suggested that given the current technology trends and the company's capabilities that a new service can be added to the business and provide the companies product line over the web. By the end of the meeting, the board is excited about the new venture and have given their full approval. The young manager is has been given total control over implementing the proposed service. Unfortunately, the board had a few conditions and he's not sure exactly how to proceed. Speaking to his colleagues, they suggest that the first thing to do is establish a project and start managing it. Whether the young manager realized it, the project had started without him. His friends are just encouraging him to acknowledge the work as a project; that is the set of steps necessary to bring a new product or service to the organization. A project is temporary: it has a definitive beginning and a definitive end. In this case, the beginning 7

Project Management

was the executive board's approval and the end is the validation that the new service has been properly implemented into the environment. Companies work and that work using falls into one of two categories: operations or projects. Both types of work require people to perform, are constrained by resources, and are planned, executed, and controlled. The difference in the two are that while projects are temporary and unique, operations are ongoing and repetitive. Operations typically take over when the project ends. In the example above, the new service will be implemented into the environment, where the operations will continue to monitor the service and make any improvements necessary. Project management is a disciplined approach to successfully handling these temporary endeavors. The discipline encompasses knowledge, skills, tools, and techniques. If the discipline is applied properly, the project should meet the requirements behind the service or product while balancing the demands on the project from expectations and needs behind scope, time, cost, and quality. Project management organizes the steps required to move from point A to Point B..

8

Project Management

2 A World Without Project Management Projects are a natural occurrence to any business that grows and expands its products, knowledge, or even its physical representation. From as small as adding a new room to the office building to creating a worldwide campaign for the next great product, projects exists in many forms within the walls of a company. Unfortunately, though projects are nature course of business, project management is not. Project management focuses on more than the end result, but also the journey getting there. Along the way, many hurdles may have to be overcome. The Standish Group reports that 31.1% of all projects will be canceled before they are ever completed and that 52.7 of the projects that are completed will cost 189% of the original estimate.1 In 2002, the National Audit Office and the Office of Government and Commerce gave the following reasons for project failures: • Lack of a clear link between the project and the organization's key strategic priorities. • Lack of clear senior management and ministerial ownership and leadership. • Lack of effective engagement with stakeholders. • Lack of skills and proven approach to project

9

Project Management

• • •

management and risk management Evaluation of proposals driven by initial price rather than long-term value for money Too little attention paid to breaking development and implementation into manageable steps Inadequate resources and skills to deliver the total portfolio.

The large the project, the more time or budget involved, the more opportunity there is to fail. Lawrence Cooper, CEO of ITSM Canada, provides a practical realization to project failures: Project timelines beyond 6-12 months generally result in a project going over budget and failure to deliver on the promised benefits – detailed project planning is hard to do beyond 6 months. • Failed projects usually suffer from a lack of focus and momentum after about the 5-6 month mark • Poorly defined scope (and requirements) and scope creep because of unclear goals objectives • No change control to handle scope changes • Lack of executive commitment and user interest due to the long timelines involved • Failure to communicate and act as a team • The wrong skills or not enough of the right skills.2 The problem is not isolated to the projects or how companies manage them. The persistence of project failure also exists because of the people managing the

10

Project Management

projects. Peter Gammon, senior consultant to Contact to Contract, offers the following points about project managers: • A 2003 survey with the Industry body INTELLECT showed that of the companies interviewed, only 42% of the project managers were accredited • Of the companies interviewed, 48% use a “home grown” methodology [of project management]. • Those who are accredited only use a part of the theory and methodology in the workplace. • Countries have local accreditation bodies (such as Prince2 in the UK). • There has traditionally not been a single global standard for project management accreditation. • Empirical observation suggests that most project The fact remains that without a disciplined approach to managing projects by capable people who can successfully manage projects, a company has the potential to lose time, money, effort, and possibly market value. Many companies focus on their operations because it is self-evident that the operations are the daily grind of doing business. And the operations of a company are very important to maintain. Unfortunately, they approach managing projects in the same way as they do approach managing operations. In many respects, the members of the project team are also involved in maintaining the operations of the business, and the work done on a project is covered on their job description as “additional duties as required.”

11

Project Management

For a project to be successful, two components must be in place: a discipline for managing the project and a person who can properly apply the discipline.

12

Project Management

3 Introducing PMBOK In 1969, five volunteers founded the Project Management Institute (PMI) to set standards for project management, conduct research in improving the way projects are managed, and to provide the growing number of project managers the opportunity to exchange knowledge and educate themselves in the disciplines of project management. Since then, PMI has been recognized by the American National Standards Institute (ANSI) as an accredited standards developer. One particular standard is the Guide to the Project Management Book of Knowledge (PMBOK Guide). The standard began in 1987 as an attempt to dot and standardize the information and practices of project management that has been generally accepted by the community of project managers. The PMBOK Guide breaks project management into 44 processes that loosely for into five basic process groups and nine areas of knowledge. The PMBOK is comprehensive enough to provide a general guide to managing most project and flexible enough to be adapted to specialized projects like construction or government which encouraged development of standards specific to those industries. The approach used by by PMBOK is compatible with ISO 9000 and the Software Engineering Institute's CMMI (Capability Maturity Model Integration). The processes found within the PMBOK overlap and 13

Project Management

interact throughout the life of a project which is defined in the five process groupings. Projects are focused on creating deliverables: tangible items which show the successful progress of the project. It’s not enough to simply go to the store, one must return with something. Deliverables play out the same concept: showing the efforts of the work by the team. At the core of creating deliverables is defining the work that needs to be done to meet the deliverable. This is accomplished by creating a Work Breakdown Structure (WBS). Attached to the WBS is a schedule for the work to be done along with the resources required to complete the work. Some of the tasks found in the WBS may have some interdependence with other tasks. Some share the same resources, even is the timing of the tasks are farther apart. Essentially, the project can be down into the deliverables, the WBS to meet the deliverables, the schedule for doing the work defined by the WBS, and the resources required to meet the schedule and WBS. The only thing left on the project is managing the execution of the schedule.

14

Project Management

4 Adding the Project Manager to the Mix For the discipline of project management to be properly applied, someone has to be assigned the task of doing so. This individual is referred to as the Project Manager. Though professional project managers do exist, many of the people managing projects are not project managers, but individuals who have some management authority and are usually a major stakeholder in the successful outcome of the project. Unfortunately, the numbers of projects that can be found in a company are at times much more than the group of professional project managers available to take them on. In these situations, companies usually assign a professional project manager to those projects that would have the greatest impact on the company if it succeeds or fails, allowing non-professionals to on the lower risk projects. In some cases, the body of professional project managers serve as mentors to those who are not certified as project managers. PMI has two credential programs in project management: a person can be a Project Management Professional (PMP) or a Certified Associate in Project Management (CAPM). The certified associate is an entry level certification into project management and is designed for members of the project team. Individuals have to apply to be a CAPM and prerequisites demand a High School diploma, associate's 15

Project Management

degree or higher and either 1500 fours of professional experience on a project management team or 23 hours of formal PMI certified project management training. Credentials require the passing of an exam based on PMBOK. Certification for PMP also requires an application. The eligibility beyond the application can take two forms. The first is an individual who has a High School diploma and an associate's degree or equivalent, a minimum five years of unique non-overlapping professional project management experience with at least 7500 hours leading and directing project tasks and 35 contact hours of formal PMI certified PMP training. The second is an individual who has a a bachelor's degree or equivalent, a minimum three years of unique non-overlapping professional project management experience with at least 4500 hours leading and directing project tasks and 35 contact hours of formal PMI certified PMP training. Project Managers have a unique responsibility inside the organization. They are responsible for changes to the business, in whatever way that change takes. In operational mode, the basic hierarchical structure of a business is a number of employees in various departments being managed by business managers who are responsible for a specific part of the business that may or may not have any understanding of other parts of the business and the impact their departments have on the business as a whole. The larger the company, the more layers of management 16

Project Management

that occur until the top executive managers who make the decisions that directly impact the business. The Project Manager typically takes direction from executive management or at the very least ensures that the project is in line with the guidance of the executive management. They work mostly with middle manager to obtain the resources necessary to execute the project, and typically require the workforce to successfully implement the product or service which is the focus of the project. The Project Manager typically works outside the operations of the business when working on a project, but they have to stay in touch with the operational portion to comprehend how the project will impact the operations or vice versa. In should be noted that the Project Manager alone does not successfully execute a project. Projects completed by a team of professionals who come from the operational side of the business are tasks to take guidance and assist the Project Manager to minimize the risk of implementing the project into the business operation. The knowledge, skills, and passion of the project team are ultimately just as important as the project manager and applying the discipline of project management. Because of this, it is very important to carefully consider the makeup of the project team and ensure that right people are assigned to the project. In addition to the core project team, there are typically other individuals who will provide their knowledge and skills as resources to the project as part of their own part in the operations.

17

Project Management

18

Project Management

5 Managing the Climate of a Project Focused Organization As already mentioned, a business can be described in terms of projects and operations. The day-to-day activities of the business usually focus on the operational aspects of the business. This is the environment which a project must be successful in. Remember that projects are temporary while operations are not. Projects usually focus on delivering change, while operations focus on maintaining the status quo or at least providing some continuous improvement. Inside this environment, the project may be influenced or impacted greatly by forces outside of the project. Since many of the members of the project team have primary responsibilities within the operations of the company, any problem disrupting those operations will have a negative impact on the project itself. Successful project management begins and ends with agreement by those individuals involved in the project or have the potential to be impacted negatively or positively by the existence or the result of the project. These individuals are called stakeholders are minimally made up of the project manager, the customer who will be using the product or server at project end, the performing organization which will 19

Project Management

do the work, and the sponsor who is the individual or group providing the necessary financial resources for the project. The success of the project relies on the project team identifying the stakeholders of the project and determining any expectations they may have on the project. Managing these expectations is just one of the major ways of ensuring that the project is successful. Unfortunately, managing expectations can be difficult because stakeholders may have different expectations which can be in conflict with the expectations of another stakeholder. Generally, most differences are resolved in favor of the customer. The organization itself can have a tremendous influence on a project. Project-based organizations typically will have systems in place that aid and address different aspects of project management; for instance, the financial systems will be designed to specifically handle the accounting, tracking, and reporting on multiple projects happening at the same time. Organizations not based on projects, such as manufacturing, are not likely to have systems in place to aid project management efforts, therefore placing the burden directly on the shoulders of the project manager. The project manager should be aware of the tools that the organization will provide and how they can be used or not used to aid the project. The culture of the organization can impact the project on many levels. Cultures are known because of their shared beliefs, values, norms, and expectations which are usually 20

Project Management

represented in their process and procedures or their response to authority, or other factors. Cultures that thrive inside an aggressive or entrepreneurial organization are more likely to take on projects that are highly innovative and risky. An organization that encourages the participation of all their employees may not work well with a project manager who is very rigid and by the book about how things are done in the project. Even managerial styles can come into play. As a result, project managers need to handle a variety of situations and people types at all times. They may have to serve several roles on the project. Though they are concerned with producing results expected by stakeholders as a project manager, they may also be responsible to lead the project by establishing the direction of the project, aligning people, motivating and inspiring the organization. Project managers have a responsibility for ensuring the lines of communication are open allow the exchange of information to never stop. Most importantly, project managers have to have skills in negotiating others into terms that are agreement to all parties. They have to be problem solvers. Project managers cannot allow themselves to be influenced by the organization, but must be able to understand the mechanics of the organization to be able to influence it instead. Still there are even forces outside of the organization that may influence the project and its work. Organizations in the health and government industries are highly regulated 21

Project Management

entities; any project from those organizations have to follow the standards and regulations that impact their industry. Every major business has some regulatory commitment to maintain and those can influence. Globalization is a push into doing business across national boundaries. As a result, more projects have stakeholders from across the globe. Implementing a product or service across multiple nations must be in compliance to the laws and political machinery of the nations involved. Additionally, the cultural influences of the world outside of the workplace have an impact on the project inside. The project manager and the team have to handle all the influences impacting the project from beginning to end.

22

Project Management

6 Grouping the Project Management Processes Together PMBOK treats project management as a set of processes. As processes, each set of activities have certain similar characteristics to them, namely they all have inputs, outputs, and the tools and techniques required. The processes however are not typically performed one after another but in conjunction with each other. In essence, the project is a group of processes interacting with each other all the time. At some stages of the project, some processes are focused on more than others and the focus changes at other stages of the process. The purpose of each process within project management is to create a definable and recognizable result. Processes fall into two categories. Ultimately, a project is concerned with bringing a new product or service to the environment, therefore one category of project processes focus on those processes that are most concerned with the specification and creation of the product or service. The lifecycle of the product is distinguishable from the lifecycle of the project. During the life a product, several projects will be initiated and executed for the benefit of the product. For instance, the development of a new release in software may be an entire project that is a small portion of the total life of the product. Therefore, the likelihood of processes that focus on the 23

Project Management

success of the product is high and these product-oriented processes are separate from the project management processes. The second category of processes are those that are strictly concerned with describing and organizing the work required by the project. The two sets of processes constantly work congruently with each other. The difference is one set is focused on managing the project, while the other focuses on the product of the project itself when the project ends, the project management processes will cease to continue, while the product-oriented processes will still be in place. The PMBOK organizes the project management processes into five process groups. The groups follow the project life cycle and consist of one or more of the 44 total processes found in the PMBOK. The groups are: • Initiate – the processes in this group are used to recognize that a project of phase should begin and gathers the commitment required to get it started. • Plan – part of the project is to devise and maintain a schedule of tasks and resources that are required to fulfill the business need the project is about to address. The processes in this group are used to identify the plan and resources for that schedule. • Executing – after creating a workable plan, the next set of processes provide the methods for coordinating the people and resources to execute the project tasks. • Controlling – Handling unexpected hurdles and 24

Project Management

•

keeping promises are two of the factors involved in ensuring the project is a success. This grouping of processes aids the project manager in ensuring the project objectives are met by monitoring and measuring the progress of the project. Closing – When the deliverables of the project are complete, the last set of processes formalize the acknowledgment that the project is complete and brings it to an orderly end.

The results of one process group is the input to the next group, though the processes are iterated. Though everything is planned out early on in the project, a change in requirements may require an update to the schedule later on in the project. As such, the project management processes are not single instance occurrences in the life cycle of a project, but overlapping activities which happen at varying degrees at every phase of the project. Additionally, the process groupings not only define the flow of the entire project life cycle, but also the general flow of each of the phases in the project. For instance, before a design document can be executed on, it must be “closed” out by customer acceptance. Therefore, the closing processes are utilized in some degree before leaving the planning phase of the project. Fortunately, the customer acceptance can serve to obtain commitment for execution phase which is the focus of the initiate processes. The advantage to reiterating the processes constantly throughout the project phases ensures that any new information impacting the project is handled appropriately 25

Project Management

and returns the focus of the process to meeting business need.

6.1 Initiating the Project Within a business there are a variety of ways in which a project can be initiated. Some companies insist on having a specific set of criteria established to determine whether a project is a project. Others treat any change to the environment as a project. Within IT companies, arguments have ensued around the difference between project management and change management, which is an IT operational process for controlling changes to the configuration of the IT infrastructure. Some companies do not recognize projects that do not have a certified project management professional leading them. Despite the varying definition of a project for a company may be, where the projects come from can also be confusing. Projects need executive support, so some people insists that true projects can only come from the top levels of the company. Others stand that the most effective projects stem from identifying problems by the workforce. Still others will state that projects are results of marketing innovative solutions to both the executives and the workforce, like a middle manager. Some projects are technical in nature, while others are business driven. Organizational changes are usually projects or projects can

26

Project Management

have an element of all types. Some projects add to the environment, while others take away. The basic fact is that every consideration already stated is valid and only shows the importance of understanding project management but also the importance of initiating a project appropriately. To initiate a project, one simply needs a commitment by the organization to begin the next phase of the project. The commitment should come from the stakeholders, those individuals responsible for the areas of business which are directly impacted by the results of the project. For the most part, the stakeholders will provide the necessary resources to successfully complete the project; the resources can be finances, people, information, equipment, or all of the above. If a department can absorb the cost of the project and provide all the resources, than a project can be initiate at the department level. However, if more resources are required than the department can provide, the proposal may need to go to the next higher level. In some cases, a project may be initiated simply to create a proper and comprehensive proposal for a project at the executive management level.

27

Project Management

28

Project Management

7 Planning the Project Projects generally involve doing something new in the environment. In a business context, something new or different typically translates into risk. Therefore, project planning is of utmost importance. Most of the project management processes can be found within the planning process group. This does not indicate that the bulk of project work is planning the e project, only the importance of the work. The amount of planning required is proportionate to the scope of the project, the risk associated to the endeavor, and the usefulness of the information developed inside the planning phase. The processes within the Planning group are further categorized as the core processes and the facilitating processes. The core processes have clear dependencies placed on them and have to be performed in the same order on most projects. These processes may be iterated several times during any phase of the project and include: • Scope Planning – develop a written scope statement to be used in future decisions related to the project. • Scope Definition – divide the major project deliverables into smaller, manageable components. • Activity Definition – identify the activities required to product each major project deliverable. • Activity Sequencing – identify and document the dependencies between activities. • Activity Duration Estimating – creation of estimates 29

Project Management

•

•

• •

for the number of work periods required to complete individual activities. Schedule Development – create a project schedule based on activity sequencing, activity duration, and resource requirements. Resource Planning – determine what resources and their quantities are required to perform activities. Resources can be people, equipment and materials. Cost Estimating – develop an estimate of the resource cost required to complete the project. Project Plan Development – use the results of the preceding process to create a coherent and consistent document.

The facilitating processes are used based on the nature of the project. Some projects are no risk processes so some of the risk management processes would not be used compared to a highly aggressive and risky project. However, these processes are not optional; they are simply performed intermittently as the need arises. • Quality Planning – identify and satisfy any relevant quality standards. • Organizational Planning – identify, document, and assign project roles, responsibility and reporting requirements. • Staff Acquisition – obtain the appropriate human resources needed for the project. • Communications Planning – determine the information and needs for communication of the stakeholders, creating an understanding for who gets 30

Project Management

•

• •

• •

what information, when they will get the information, and in what manner it will be conveyed. Risk Identification – determine the risks that will most likely impact the project and document the characteristics of the risks. Risk Quantification – evaluate the individual risks to determine the range of possible project outcomes. Risk Response Development – determine the steps for opportunities and responses to threats to the project. Procurement Planning – determine what to procure and when. Solicitation Planning – document product requirements and identify potential sources.

7.1 Executing the Project The bulk of project work is done under the Execution process group. This is the time when the project team takes what was detailed out in the planning phase and executed according to design. Core and facilitating processes exist within this process group also the process Project Plan Execution being the only core process. The facilitating processes include: • Scope Verification – obtain formal acceptance of the project scope. • Quality Assurance – evaluate overall project performance regularly to ensure that the project will 31

Project Management

• •

• • •

meet the relevant quality standards. Team Development – develop skills of individuals and groups to enhance project performance. Information Distribution – ensure that the necessary information is available project stakeholders in a timely manner. Solicitation – when appropriate, obtain quotations, bids, offers, or proposals. Source Selection – choose from among potential sellers. Contract Administration – manage relationships with sellers.

7.2 Monitoring and Controlling the Project During the execution of the process any number of things could happen. The hopes of the project team are that the planning performed before the execution was extensive enough to identify and plan for all the hurdles that may occur. In all likelihood, no matter how much planning was done, something will always occur during execution. The best a project manager can do is catching the problem quickly and resolve. Therefore, the project's performance should constantly be measured to identify variances from the plan. These variances are entered into the control processes in the nine processes areas. If the variances are significant, adjustments are made to the plan. For instance, if a finish date for an activity is missed, then any later

32

Project Management

dependence need to be pushed out or other plans put in place to return to the planned schedule. The core processes for the Process group, Controlling and Monitoring include Performance Reporting and Overall Change Control. Performance Reporting supports the collection and dissemination of performance information. This information typically takes the form of status reporting, progress measurements, and forecasting. Ideally, the areas that are measures are project dates, resource use, and cost. The intent is identify if the project is on track and if not, how far above or below the planned estimates. The second core process is Overall Change Control. Whenever the project is off track either by being under the estimate or over the estimate, the project may need to be adjusted. The need for a change is a possibility based on the extent of the project planning performed. Some project planners may make a single value estimate. Others create a range for the estimate, creating a worst case and best case estimate for time, money, and resources. In the second estimate style, the variance may force a change if it falls outside the estimate range. If a change is required, it can have an impact on every future aspect of the project just like ripple across water. Many aspects of the schedule, the budget, or the resources may be hard coded to the plan meaning that they cannot be changed. The planning should have identified these situations and revisiting the plan should adjust to meet these objectives.

33

Project Management

Facilitating processes serve to support the core processes. They include: • Scope Change Control – control change to project scope. • Schedule Control – control changes to the project schedule. • Cost Control – control changes to the project budget. • Quality Control – monitor project results for compliance to quality standards that apply and identify methods for resolving noncompliance. • Risk Response Control – respond to changes in risk over the life of the project.

7.3 Closing the Project Closing out the project involves two processes: Administrative Closure and Contract Close-out. Administrative Closure happens at the end of each project phase and the end of the project to formally close out the cycle of work. The purpose of this process is to generate, gather, and disseminate information related to the cycle being closed. The information will typically consist of reporting on the work that has been done and the resources that were used. The information is usually supplied to business managers, human resources, or financial accountants, as well as stakeholders. A project typically starts with a contract, or a written agreement describing the scope and deliverables of the 34

Project Management

project. Contract Close-out encompasses the activities required to validate that the project has met the terms of the written agreement. It allows the project manager to go back to the customer and finalize any outstanding issues or discoveries that may have risen out of the course of the project but not resolved usually because the action would have been outside the scope of the project.

35

Project Management

36

Project Management

8 Framing Project Management To this point, the project and the disciplines used to manage the project have been discussed in terms of cycles, both for the project phases and the life cycle of the process. Core processes in the project cycle build on each other to transform input into a workable result for the next phase of the project. The core must be used on all projects. Facilitating processes exist to support the core processes. Although all the facilitating processes are utilized in a project, their use is varied based on the situation at hand. Many people would think that executing a project is simply doing the work to create a deliverable and, though that this is part of a project and the bulk of the effort for the project, it is not all of what encompasses successfully completing the project. There are nine areas of knowledge that are applied to the discipline of project management, each covers a portion of the necessary disciplines required to move a project from beginning to end. The 44 processes utilized to create the cycles are broken down into these nine knowledge areas. They are: • Project Integration Management handles the coordination of key elements of the project. The processes included in this area are project plan development, project plan execution, and overall change control. 37

Project Management

•

•

•

•

•

•

38

Project Scope Management ensures that the work required to successfully complete the project are included in the project plan. Any work that is not required for the success of the project is kept out of the scope. The included processes are initiation, scope planning, scope definition, scope verification, and scope change control. Project Time Management ensures the timely completion of the project. Activity definition, activity sequencing, activity duration estimating, schedule development, and schedule control are the processes contained within this area. Project Cost Management ensures that the project is completed within the approved budget. Contained in this area are resource planning, cost estimating, cost budgeting, and cost control. Project Quality Management ensures the project meets the needs that the project intended to fulfill. The knowledge area contains the processes of quality planning, quality assurance, and quality control. Project Human Resource Management makes effective use of the people involved with the project. Contained in the knowledge area are organizational planning, staff acquisition, and team development. Project Communications Management ensures that the generation, collection, dissemination, storage, and disposition of information is performed in an appropriate and timely manner. The included processes are communications planning, information

Project Management

•

•

distribution, performance reporting, and administrative closure. Project Risk Management focuses on those processes that are used to identify, analyze, and respond to risks to the project. The processes contained in this knowledge area are risk identification, risk quantification, risk response development, and risk response control. Project Procurement Management assists in the acquisition of goods and services from outside the performing organization. The processes included are procurement planning, solicitation planning, solicitation, source selection, contract administration, and contract close-out.

The knowledge required for managing projects are usually specific to the project management discipline, however sometimes overlap is found with other management disciplines. General management focuses on the planning, organization, staffing, execution, and control of the operations. Many of the disciplines used in project management are also found in general management including organizational behavior, financial forecasting, and planning techniques. Some projects are definable by the industries that they are utilized. Called application areas, the projects found within these areas have common elements significant to related projects but not needed in all projects. The applications areas are generally defined as technical elements which are found in software development, pharmaceuticals, and construction 39

Project Management

engineering projects; management elements found in government contracting and new product development; and industry groups such as automotive, chemicals, and financial services. The processes used by project management interact with the processes within an individual knowledge area as well as interact with the processes in other knowledge areas. How or when the processes interact depend on the type of project involved, the application area, the management structure of the performing organization, and the constraints and limitations on the project. Although the practice and experience of project management have determined the common trends of process interactions, the processes may overlap or interact in ways that specified in any documentation. The intention of any process description is to provide the project manager and team enough knowledge to discern when a process is being initiated.

8.1 The Project Plan as an Integration Product The project manager's primary responsibility is to deliver acceptable results to the customer in a timely and affordable manner. To accomplish this, a great deal of coordination of the project elements is required. Project Integration Management provides the framework for this coordination. The processes that make up this framework assisting in the development, execution, and change of the overall project plan. 40

Project Management

There are many processes found in project management that deal with the specific planning of project components, such as time, resources, and budget. The plans need to be integrated together as a whole and then executed. As the project progresses, events may occur that impact one or more of the plans and they have to be reevaluated and adjusted. When the individual plans are readjusted, the overall project plan also needs to be adjusted. While integration of the project processes is important, several other integration activities are also required. A work of the project must integrate with the ongoing operations of the business. Operations will not halt or be slowed simply because a project exists. Many business operations have deadlines, quotas, and expectations placed on them. The project cannot interfere with the fulfillment of those operational objectives. Many operations have continual improvement mechanisms in place, so the construct of the operational state at the beginning of a project may be different than the operational state at the end of project. Staying abreast of any operational changes can be valuable information for the success or failure of a project. Sometimes, issues are identified that are not within the scope of the project to resolve but once communicated, a resolution is sought through another project or through the operational improvement processes of the business. Awareness of these actions is prudent for coordinating project activities. Additionally, deliverables to the project may be found: these are products that are necessary to the 41

Project Management

project but are outside of the scope of the project either because they are assumed to already exist or because they are performed by members outside of the body of stakeholders. For example, an assessment of power consumption may be the product of the electrical engineering department and required by the project, but the creation of the assessment is outside the boundaries of the project. In this case, the project manager needs to integrate the activities of the project to coincide with the development of the assessment of an outside entity, namely the electrical engineering department. Quality assessment because of regulatory standards may require the skills of a quality management professional, but the assigned project work is only one task in the project. This professional may not become a core team member for the project, so the project manager has to coordinate with the quality control department to ensure that the work is done in a timely manner.

8.1.1 Developing the Project Plan The major focus of the integration management processes is the creation and maintenance of the project plan. The project plan is a consistent and coherent document that encompasses the outputs of the planning processes to guide both project execution and project control. The project plan is a living document, subject to change throughout the life of the project. The goal of project management is to identify a final project plan as quickly as 42

Project Management

possible and apply change control to the project plan to manage how and when the plan is changed. The purpose of the project plan is to guide project execution, document project assumptions, document plan decisions with primary paths and alternate paths if any, facilitate communication with all stakeholders, define key management reviews, and provide the baseline for measurement project effectiveness, progress and control. In addition to the outputs of other planning processes, the development of the project plan can also include historical information, organizational policies, constraints and assumptions. Historical information is typically consulted on during other planning processes and involves statistical information, past project information, and other information that may affect how the project proceeds. For instance, budget constraints may be time stamped; that is, the project has a certain amount of money for a set time but a different amount after a specific date. This can impact how and when money is spent on the project. Or this is the second time this project has been initiated. The first attempt failed and the project manager looks at the conditions of the failed attempt to ensure the same mistakes are not repeated. Every organization has formal and informal policies that may affect the project. Many of these policies will come from governing entities outside of the project that have responsibilities related to the operational side of the business. The more common governing entities are

43

Project Management

responsible for quality management, personnel administration, and financial controls. Assumptions and constraints are factors that affect the project planning, execution, and outcome. Assumptions are typically generated within the planning stage and should be noted in all occurrences. For instance, the delivery date of a resource is uncertain, so the project team assumes a specific date for planning purposes. Assumptions are considered to be true, real, or certain for the project plan. As the project progresses, the assumptions may prove to be false, unreal, or uncertain and the project plan is impacted. There is an element of risk involved with assumptions. Constraints are defined factors that limit the project in some way. A budget is a constraint that limits the amount of money spent. A time table limits the amount of time given to complete the project. The scope of the project constrains the work done by the project. Contracts provide a number of constraints that must be incorporated into the project and adhered to under all conditions. The tools and techniques utilized for development of the project plan include any number of methodologies available for project planning, the skills and knowledge of the stakeholders, and any adopted Project Management Information System (PMIS) by the company. Many ways for organizing and presenting project plans can be found and many have the same common elements found in them. PMBOK does not require any particular method be used to develop, organize, or present a project plan be used; it 44

Project Management

does however identify those elements that have recognized value to the project. Some of the elements promoted for the final draft of a project plan include: • Project charter • Description of the approach or strategy for project management • Scope statement with project deliverables and objectives • Work Breakdown Structure (WBS) • Cost estimates, scheduled start dates, and responsibility assignments integrated with the WBS • Performance measurements baselines, specifically around cost and time • Major milestones and target dates • Key or required staff • Key risks, including constraints and assumptions and the responses planned for each • Subsidiary management plans, i.e. scope, time, budget, etc. • Open issues and pending decisions Also included could be the following supporting details: • Additional information found during the planning phase but does impact the planned scope of the project • Technical documentation such as requirements, specifications, and designs • Documentation of relevant standards and regulations.

45

Project Management

8.1.2 Executing the Project Plan The primary process of providing the project deliverables and meeting project objectives will be performed in the project plan execution process. The guide to project execution is the final project plan and any supporting details, organizational policies and/or procedures that need to be followed, and as the project progresses, any corrective action put into place to realign the project. The execution of the project plan relies heavily on the team members of the project and any key individuals required to support the product or service that the project is affecting. As such, skill and knowledge related to the product or services is typically the most important requirement for successful execution. To ensure that the proper staffing is in place at any given time of the project, a work authorization system may be involved. This form procedure ensures that the right people are working the project at the right time by fulfilling written authorizations. The authorization typically includes the required skills and knowledge, the work to be done, and the time and cost limitations in place for the activity. To properly execute the project plans, general management skills may be required, such as leadership, communication, and negotiating. These skills will definitely be required by the project manager, but may also be necessary for the team members of the project. In many situations, team members may be tasked with activities that will be 46

Project Management

performed away from any of the other team members in parallel to the activities assigned to those team members. Status review meetings provide an opportunity for the project team to communicate with each other on the progress of their assigned tasks, to communicate any issues and risks that may have been identified, or to declare any dependencies that need to be fulfilled. Project team members may be asked to update any existing project management information systems that may require project progress information. Depending on the system and the work involved, the task of updating the system may fall on the project manager to complete. The execution of the project plan lead to either work results or change requests. Either the activities identified by the project plan produced the result intended or they didn't. Many times, the expectation of the work results are unfulfilled because of a change of assumptions, constraints, issue, or misinformation. The result may require a change to the project which is initiated by the creation of a change request.

8.1.3 Controlling Change to the Project Plan Changes to the project plan have to be coordinated and controls to minimize the impact of the change to the entire project. In most projects, change will be present, therefore it is prudent for the project manager to plan for change and establish controls from the very beginning of the project on 47

Project Management

how and when changes will be made to the project plan. The requirement of change control is rooted in: • The necessity of maintaining performance baselines. Every change should be reflected in the project plan, but only changes in scope will change the performance baselines established. • The possibility of changes to product scope forcing a change to project scope and minimizing the impact of such as change. • Coordinating changes across knowledge areas: a change in schedule may impact cost, risk, quality, and staffing. Overall change control utilizes the project plan as the basis for its work. The process is initiated by performance reports and change requests. Typically, a formal, documented set of procedures for controlling change is already in place for use by the project. If not, the project team may have to develop one. Many change control systems apply a formal review and approve procedure and the opportunity for stakeholders to approve or reject a change request. Most change control systems have the ability to handle emergencies; these are changes that need to be approved and executed but cannot wait for formal review of the change request. Some systems will even allow for “automatic” approvals for certain predefined changes. All changes must be properly and completely documented. Configuration management is used by change control as a documented procedure for applying technical and 48

Project Management

administrative direction and monitoring. The purpose of configuration management form a project perspective is that it identifies and documents the functional and physical characteristics of an item or system, controls the changes to such characteristics, record and report any changes made, and audit the items or systems to verify requirement conformity. It is important to note a change control process may exist within the operational aspect of the business as well as the project management aspect. Sometimes, the process is different for both but they use the same change control system. Sometimes the process utilizes completely different systems that need to talk to each other. Any some instances such as configuration management require that both systems provide the necessary output of changes to the appropriate parties. Change control may utilize performance measurement, the project management information system, and additional planning as tools and techniques for ensure success for controlling change. Change request going through the overall change control process typically result into updates to the project plan, corrective action and/or an exercise called lessons learned which identifies the causes of project variances and the reasons for actions resolving or mitigating the variance.

49

Project Management

8.2 Putting a Stake in the Ground – Project Scope One of the hardest components of a project to maintain is project scope. The scope of the project details all the work required by the project to deliver and only the work required. Unfortunately, influences from business culture, social cultures, issues, risks, and discoveries will be constantly at play. Because many of the project team members will be working within the operational side of the business, they will see or hear of activities, technologies, or decisions that may impact the project. They may pressured to do additional work to incorporate ideas, concepts, activities, or even technologies, or feel that the incorporation is necessary themselves and take it on. The problem is that anything that changes the intended execution of the project plan is a change that most be controlled properly. The result is actively preventing these influences from impacting the project plan or graciously accepting the influences through change control.

8.2.1 Igniting the Project The scope of the project essentially shields the project from outside influences and change control is the gate where those influences are allowed to enter. As a result, scope protects the integrity of the project and ensures its success within the context of its predefined requirements, deliverables, and constraints. Scope is typically the very 50

Project Management

first step in initiating formal acceptance of a project. When projects are authorized, they are typically associated with a basic scope statement. Though some work may be necessary to define the scope more, the project can be recognized in general terms. Many projects are a result of one of more reasons: the most common are a demand in the market, a new business need. A customer request, a technological advance, or a legal requirement. In initiating a project, some description of the expected product or service is provided that is mapped to the reasons already mentioned as well as how the product and service apply to fulfilling the strategic plans of the business. Information aiding the selection of the project may be included, such as financial return, market share, public perception and more. Many companies have some method for selecting project. Those methods usually fall into two categories. The company may select projects based on benefit analysis, generally using comparative approaches, scoring models, benefit contribution, or economic models. The method using benefit measurement is typically used one the companies has several projects being proposed and have to choose some over others. However, some companies base their decisions not on the comparative benefits of the projects proposed, but on the definable improvements to the current operational environment. These proposed improvements are typically the result of intense mathematical models using programming algorithms to promote optimization opportunities for the business. Some businesses use a combination of both methods. In some 51

Project Management

cases, project initiation requires the use of expert judgment from different parties. These experts may be found in other departments, outside consultants, professional and technical associations, or industry groups. The goal of initiating a project is to have agreement for the project. Once the project is agreed to, a project charter is created that formally recognizes the project's existence and includes the business need that the project is addressing as well as the description of the product or service that will be the primary result of the project. A project manager is identified and assigned to the project and basic constraints and assumptions are generated. The initiation process is used not only at the beginning of the project but also the beginning of each project phase.

8.2.2 Creating the Stake The key deliverable of project scope planning is a written scope statement, a document that serve as the basis for future project decisions with specific criteria to determine if the project of phase has been completed successfully. For most projects, the components of the scope statement are already present and the document just needs to be written. The inputs to the planning the scope is the description of the product or service, the project charter, constraints and assumptions. Several tools and techniques assist in creating the scope statement. The first is any product analysis that allows a 52

Project Management

greater understanding of the product or service which the project will deliver. These techniques can include anything from systems engineering analysis to analysis for value or function, or more. The point is to understand the product or service sufficiently to address the boundaries required to deliver it. Obtaining a benefit/cost analysis provides the estimated outlays and returns of various project alternatives as well as the relative desirability of those alternatives. These alternatives are typically generated through numerous general management approaches including brainstorming and lateral thinking. The scope statement should include directly or by referencing other document the justification for the project, a brief summary describing the product, a list of all deliverables expected from the project, and the objectives of the project. In addition to the scope statement, any supporting details related to the scope and its development should remain accessible as well as a plan for managing scope throughout the project.

8.2.3 Defining the Boundary Limits When creating the scope statement, a list of project deliverables were created. Some projects have huge deliverables or more than the usual number of deliverables, both situations requiring that major project deliverables be broken into smaller, more manageable components of the 53

Project Management

project. The purpose of this breakdown is to improve the accuracy for estimating cost, time, and resources, define a better baseline for performance measuring, and to facilitate clear assignments of responsibility. The need to define the scope into smaller components is critical to the success of the project. To assist in defining the scope are the scope statement, the constraints and assumptions already obtained on the project, any historical information and the outputs of process in other knowledge areas to identify the possible impact on the project scope definition? At this point, the project manager may begin looking at templates for the work breakdown structure or the WBS from a previous project. Though each project is unique, WBSs are often reused for deliverables that are similar to some extent. Especially for manufacturing or development industries, many projects may have similar enough activities that a template can be used. However, a template should not be used to take a short cut in developing the scope and project plan of a project, but to be used a guide to ensure that many of the steps required for a particular type of project is included. The real work of defining scope is the breaking down of the project deliverables into manageable components. The process for this activity is called decomposition. The first step is to identify the major elements of the project. These usually are the project deliverables and the project 54

Project Management

management tasks. They may be further broken down to reflect the different phases of the project. If an adequate estimate for time and cost can be applied to the different deliverables at this time, then provide those estimates. The third step is to identify the elements of the deliverable. These elements should be described in terms of tangible, verifiable results to properly facilitate measuring performance. For each element, apply a cost and time estimate to it if possible. After creating the deliverable and its elements, the correctness of the decomposition needs to be verified. Some questions to ask during the verification step are: • Are the lower level elements both necessary and sufficient for completion of the decomposed item? • Is each item clear and complete in its definition? • Can each item be appropriately scheduled, budgeted, and assigned? At the end of the decomposition, a complete work breakdown structure is available. The WBS serves as a deliverable-oriented grouping of project elements that defines the detailed scope of the project. Activities not in the WBS are not part of the scope of the project. The WBS is not a presentation method; however, the WBS is sometimes presented in a readable form like a chart or unstructured activity list.

55

Project Management

Each item in the WBS is typically assigned a unique identifier and collectively known as a code of accounts. Groupings of items at the lowest levels of the WBS are called work packages. The purpose of the identifier and work packages are to provide a consistent method of identifying items in future communications. Along with the identifier, each work element should have a description attached to it. These descriptions are collected into a WBS dictionary. The entire WBS now becomes a project result for scope verification.

8.2.4 Announcing the Claim To this point the project team has been working to understand the real scope of the project or phase. They have identified what is supposed to be done through the project and how it will be done. They have provided the cost, time, and resource estimates they believe are necessary to complete the project successfully. The format they have used to organize and communicate this information are the scope statement and the WBS. Now is the time to ensure that the other stakeholders agree. The scope verification process is the avenue to obtain formal acceptance of the project scope. In later parts of the project, it is the process used to obtain acceptance that the scope has been fulfilled. If the project is terminated prematurely, the scope verification process will establish and document the level and extent of completion already made on the project. 56

Project Management

Sometimes scope verification is confused with quality control since both are concerned with the end result of a project. However, they are not the same. Acceptance of the work result is the concern of scope verification while the correctness of the work result is the concern of quality control. To initiate the scope verification process, the project work must have created a result either fully complete or partially complete. Initially, the result is the scope statement and the WBS, but later the result is a product from executing the project plan. Along with the products coming out of the execution phase, documents describing the products should be included for review. These descriptions can take the forms of technical documentation, drawings, specifications, plans, etc. and vary from one application area to the next. Together, the product and the supporting documentation will inspected by the stakeholders. The inspection may require any form of measuring, examining, and testing the product. Most stakeholders are looking to determine if the product conforms to the initial requirements presented at the beginning of the project. Inspections can happen at any time during the project and though the project manager may have scheduled some inspections within the project plan, unplanned inspections may be asked for. The term “inspection” is often replaced by calling the activity reviews, product reviews, audits, or walk-throughs. In some 57

Project Management

application areas, these different terms have different meanings with very specific agendas attached to them. The purpose of the inspection and the scope verification process in which it occurs is the formal acceptance of the work result. Sometimes, the acceptance is conditional especially on product that are partially completed at the end of a phase.

8.2.5 Fending Off the Claim Jumpers As the project proceeds, several influences may appear that threaten the scope of the project. Discovery of a similar project with a slightly different scope from another area of the business may result in the merging of the work of the two projects. Identifying a needed resource or improvement in the operational side may encourage the operational side to attempt to have the project perform the work instead of utilizing the resources and operational budget. Changes in priority on the operational side may change the already limited resources and budget available to the project. Changes in strategic direction may change the direction of the project or new partnerships created on the operational side of the business may introduce new stakeholders to the project who have different expectations or agendas. Even the individuals who are part of the project team may come to the project with their own agendas and expectations of what the project must do.

58

Project Management

These influences are not always negative but they do need to be controlled. The means for that control is the scope change control process. The process is concerned with three primary objectives: 1. Determining when and how scope changes have occurred. 2. Ensuring the factors that are changing scope are influenced sufficiently to have the changes be beneficial to the project. 3. Managing the actual change in scope when and if they occur so that they are properly integrated with the other control processes handling time, cost, quality, etc. Scope change control starts with the WBS, performance reports, change requests, and the scope management plan. The WBS defines the baseline to the project's scope. Any changes to the WBS whether intentional or not is a potential change to the scope of the project, specifically in the area of adding or removing activities. Performance reporting on the project or the interim product may identify issues that need to be addressed. Change requests can happen in a variety of ways and from any direction. Most change requests occur because of an external event like a change in regulations, an error or omission to defining the product or the project, or a value adding change to the environment such as new technologies are now available which will reduce costs if taken advantage. To change the scope, the project will use whatever system they have in place to control scope changes. The system is 59

Project Management

usually described in the scope management plan and is the set of procedures used to manage scope changes properly. The system defines the paperwork necessary, the tracking systems that need to be used, and the approval levels for authorizing changes to the scope. The scope change control system should be integrated into the overall change control system as well as any systems that are in place to control product scope. If the project is a result of a contract, the scope change control system must comply with any contractual provisions that are relevant. Many times a potential change in scope is the result of an identified variance in performance reporting. Or performance reporting may be able to identify the magnitude of any variance on a proposed change in scope. Either way, the use of performance measurement can be a helpful tool to determine the success and validity of creating a change in scope. At the very least, changes in scope may impact what is being measured or how it is being interpreted. Scope changes may require changes to the WBS or the previous analysis of alternative approaches. The result of changing scope requires the appropriate modifications to the original agreed-upon scope as defined by the WBS with the adjustments to cost, time, quality, or resources that may apply. Scope changes are always fed back through the planning processes and the appropriate technical and planning documents are updated. The stakeholders are notified of scope changes. Any corrective actions required to ensure that project performance stays in 60

Project Management

line with the project plan is taken and the lessons learned identifying the cause of variance in performance and the reasoning behind the corrective action should be documented.

8.3 Conquering Time One of the defining characteristics of a project is that it is temporary: a project has a definite start date and a definitive end date. Though the exact dates may be negotiable, it is clear that time is a limited resource for the project. To successfully manage a project within that limit, project time management is a knowledge area that is consistently and effectively utilized throughout the life cycle of the project. The PMBOK processes found within the knowledge area of project time management includes activity definition, activity sequencing, activity duration estimating, schedule development, and schedule control. Using these processes, the project team determines that specific activities that are required to produce the desired project deliverables. These activities will typically have some interdependencies attached to them; that is, one activity may require that another activity be finished before it is started. Additionally, the project team will determine the number of work periods required to complete the individual activities. A work period may be represented in hours, days, weeks, or even months but is consistent throughout 61

Project Management

the project. All this information is now compiled into a schedule to be used by the project manager to build the WBS and resultant project plan. The processes found within time management are sometimes so tightly linked that the individual processes are difficult to distinguish when performing, especially on smaller project. They can be performed by a single individual who is probably fulfilling the process requirements for all the processes simultaneously. However, the processes for activity sequencing, activity duration estimating, and schedule development are distinct processes using different tools and techniques for each.

8.3.1 Defining the Activity The first step in time management is determining what needs to be done. The process activity definition focuses on identifying and documenting the specific activities required producing the deliverables of the project. The work done through this process is very similar to the work done in defining the scope, the change is the perspective used: time. To start defining the activities, the process uses the WBS, the scope statement, historical information relevant to the project, constraints and assumptions. Decomposition is used to subdivide the project elements into smaller more manageable components. When decomposition was used in defining the scope, the goal was to breakdown the 62

Project Management

project into deliverables or tangible items that could be delivered. Decomposition from the perspective of time management breaks down the deliverables into activities or action steps required to produce the deliverables. In some application areas, the WBS and the activity list are concurrently developed. During decomposition, templates may be available to determine the action steps required especially in situations where a deliverable is similar to another deliverable on another project. The results of activity definition is the activity list and any supporting detail. The activity list is an extension of the WBS. From a project perspective, there is a distinction between work and activity. For instance in an IT project for a help desk, a defined work item may be be acquire power. The activities required to acquire power may include assessing current power capabilities, creating work orders for new or changes in outlets, negotiating with power company, fulfilling on work orders, testing power capabilities, etc. The list of activities provide greater detail for completing the work described in the WBS. In other terms, the WBS defines what needs to be done while the activity list defines how it is done. Especially for large projects, communicating the project in terms of activity lists is not seen, though those lists are used to clearly define the progress of the work required. In developing the activity lists, the project team may identify additional deliverables that need to be added to the WBS or clarification or corrections to the descriptions found in the WBS. These

63

Project Management

updates are often called refinements and occur most often when the project includes new or unproven technology.

8.3.2 Which Came First, the Chicken Or the Egg Once the activity list has been generated, the project team needs to determine the order in which the activities are performed and when they need to be performed to meet project objectives. The activity sequencing process focuses the effort to identify and document the dependencies between activities. The process is either done manually or through the aid of a computer. To start the process, the project team will need the activity list, the product description, the constraints and assumptions. They will also require a list or understanding of the dependencies on the project. There are three categories of dependencies that the project team will deal with, mandatory, discretionary, and external. Mandatory dependencies are inherent in the work being done. Physical limitations are primary examples of mandatory requirements. If the project was to build a house, completing the roof cannot be done before the walls are put up. Therefore the roof has a dependency on the walls and it is mandatory because it has to happen. Mandatory requirements are also called hard logic. Discretionary dependencies are placed on an activity by the project team. This dependency describes a situation where 64

Project Management

a set of activities can be performed in any sequence, but the project team desires a specific sequence to be utilized. The reasoning behind the decision may be a result of determining best practices in an application area or some unusual aspect of the project where the specified sequence becomes more desirable. The use of discretionary dependencies should be limited because it will limit the scheduling options later. These types of dependencies are often referred to as preferred logic, preferential logic, or soft logic. External dependencies occur when project activities have some requirement on non-project activities. A software development project is depending on the delivery and setup of hardware. A construction project requires an environmental hearing on a location before site preparation can begin. These dependencies are noted in the activity list and used during scheduling. There are several methods for determining and presenting activity sequences. The first method is called precedence diagramming (PDM). It constructs a project network diagram connecting nodes, or activities, with arrows to show dependencies. Most project management software packages use this method. The method defines four dependency relationships: • Finish-to-start is the most common logical relationship and describes the relationship where one activity must finish before the next activity is started. 65

Project Management

•

•

•

66

Finish-to-finish describes situations where one activity must finish before another activity can finish. This is common when parallel work is being done like modules in a software package. There is no dependencies between the modules to require one being done before the other, but since the modules all make up the software package, they all must be completed before the package is complete. Start-to-start relationships describe situations where one activity must start before the next activity can start. There are few times when this relationship is used. A basic example of this is driving a car. Before actually driving out of the driveway, the ignition of the car must be started. Without starting the car, the next activity cannot even be started. Using the Finish-to-start relationship can also be applied here and is sometimes more desirable when using a project management software package because unexpected results may be produced later on. Start-to-finish is the rarest logical relationship defined and typically only by professional scheduling engineers. The relationship described calls for an activity to start before the next activity can end. This is a very precise calculation. One of the simplest examples is the school lunch bell. Most people would say that lunch began when the school lunch bell rings. But in the perspective of the classroom, when the school bell rings, class ends. From the second viewpoint, it is the start of the school bell that

Project Management

ends the teaching of the class. Another method for sequencing activities is the arrow diagramming method (ADM). Similar to the PDM in that it uses arrows connecting codes to describe dependencies, the ADM only uses finish-to-start relationships and as such has become the technique of choice in some application areas. To handle other logical relationships, the creation of dummy activities may be required. Neither PDM nor ADM allow for sequential activities that loop such as software testing, or conditional activities such as updates to the design if inspection discovers an error. To handle project that handle these situations, a method is available called conditional diagramming. Of course, some activities of a project may be similar to the activities performed on a previous project and have become templates. For activity sequencing, these standardized activities are referred to as network templates, subnets, or fragments. These subnets are particularly useful for duplicate activities within a project such as building floors in a high rise building, or clinical trials at a pharmaceutical company, or developing several modules of a software package. The primary result of the activity sequencing process is the project network diagram. The diagram is a schematic representation of the projects activities and the logical dependencies between them. The diagram is accompanied by a summary narrative to describe the sequencing 67

Project Management

approach and descriptions of any unusual sequences. Out of the sequencing work, updates to the original activity list may have been identified which may also require updates to the WBS. The project team must not update the WBS directly without first updating the activity list.

8.3.3 Hard-Boiled or Soft-Boiled To this point, the project team has determined the activities that are required to produce the deliverable and the sequence required of those activities. The next step is to determine how much time will be required to perform each activity. To do this involves the activity duration estimating process. The person on the project with the most experience in the nature of the work typically does the estimating. The estimation is done based in work periods, whether it is hours, days, weeks, or months. The work period must be consistent throughout the project. The most common work period is the day, but the decision on duration should be based on the type of work required. If most of the activities involved take only a few minutes to perform, than a shorter duration may be required. In estimating the duration, the project team needs to take into consideration elapsed time. For example, while painting may take a day, it requires 48 hours to fully dry. That means the total duration for the activity is actually three days. However, the day of the week in which the activity is performed or weekend and holidays may have an impact on how the duration is 68

Project Management

perceived. If painting is scheduled for a Friday and no work is done until the following Monday, though the duration is three calendar days, the reality is one business day. Most project management scheduling programs handle these types of problems automatically. Whatever, the case, specific notes should be included to explain any timing considerations. For instance, an activity such as obtain quote may require 15 minutes of effort from the project team to contact a contractor but the duration estimate is four days to allow time for the contractor to schedule a visit, created and deliver an estimate. To begin estimating the duration of the activities, the activity lists is required, along with the constraints and assumptions already developed on the project. Historical information should be included from previous projects and commercial duration estimating databases which provide standard recommendations or policies such as how long paint should dry or how long a government agency takes to respond to a request. The experience that the individual project team members bring provide historical information to the project. Additionally, resources requirements and capabilities are necessary because they both can impact the duration of the activity. Generally speaking, if an activity can be done in four days by one person, it can be done by two people in two days. Also one person working half-time will take twice as long as another person working full-time. The capabilities of the resources also will impact the activity duration. Given everything being equal except experience, 69

Project Management

someone during the activity required for the last ten years is more likely to perform faster than a person who has done the same work for only one year. This is one of the reasons that some projects include in estimating duration a worst case and best case duration to the project. A worst case duration is the longest expected time required to complete the work while the best case is the shortest. Though both estimates may be available, the project manager usually manages to a mean of the two. The tools and techniques used to estimate duration start with expert judgment. This is the reason for having team members assigned to the project who will be executing the project as well. When they create the estimate, they are declaring a commitment to the duration. When the amount of detailed information about the project is limited, analogous, or top-down, estimating is performed. This method uses the actual duration of a previous, similar activity as the basis from creating an estimate for the current project. Analogous estimating is most successful when the previous activities are similar in actuality and not just in appearance and the individuals preparing the estimates have the expertise required. Another method for estimating is simulations. This method allows the project team to enter numerous assumptions which are used to calculate multiple durations. The most common form of simulation is the Monte Carlo Analysis. The end of the process produces the estimates of activity duration. As mentioned before, durations are typically 70

Project Management

delivered as a range of possible results: for instance 2 weeks plus/minus 2 days to indicate the activity will be done in no less than 8 days and no more than 12. Sometimes probability estimates are provided: for instance 15 % probability that an activity will take more than 2 weeks leaving an 85% chance that it will take less. In addition to the actual estimates, any assumptions used to create the durations should be included as well as potential updates to the activity list which may have been found.

8.3.4 Scheduling The next step is to schedule the activities using a calendar. Typically done by the project manager with the aid of the project team, the start and end dates for each of the project activities is determined. To initiate building the schedule, the necessarily inputs are the project network diagram, the activity duration estimates, resource requirements, resource pool descriptions especially with shared resources, calendars, constraints and assumptions, and leads and lags times. Inside the constraints, two major categories have an impact on scheduling: imposed dates by the company, the stakeholders, of the contract, and key events or milestones which when scheduled cannot be changed without changing expectations. Lead and lag times are also important to consider. Lead times are often required to allow for preparation before performing an activity. Lag times are generally the time between two activities, such as the wait time between ordering and installing equipment. 71

Project Management

Scheduling is most often done using mathematical analysis which calculates the early and late start and finish dates theoretically for all project activities without considering resource limitations. The dates derived from mathematical analysis are not the schedule but rather the time which the activities should be scheduled given resource limitations and other constraints. Several mathematical analysis techniques exist: • Critical Path Method (CPM) calculates a single deterministic start and finish date based on the sequential network logic and a single duration estimate. The purpose of CPM is to determine which activities have the least flexibility in regards to scheduling. • Graphical Evaluation and Review Technique (GERT) utilizes probability in both network logic and activity duration estimates to determine the best schedule. • Program Evaluation and Review Technique (PERT) uses sequential network logic and a weighted average duration estimate to calculate project duration. • A special case of mathematical analysis is found with duration compression which looks for ways to shorten the project schedule without changing project scope. It includes techniques like crashing which analysis the trade-offs between costs and schedule to identify where to obtain the greatest amount of time compressions for the least amount of cost. Fest tracking is another technique which looks at performing tasks in parallel which would normally 72

Project Management

be done in sequential order. Crashing sometimes results in increased cost while fast tracking can lead to rework and increased risk. Simulation can be used to create a recommended schedule like mathematical analysis. Any of the methods mentioned typically provides a preliminary schedule without applying any knowledge about resource availability, capabilities, or constraints. Resource leveling heuristics are applied to the schedule to handle resource constraints. Resource leveling often creates project durations that are longer than the preliminary schedule. Many of the project management software packages provide the functions to perform mathematical analysis and resource leveling. The result of the effort is the project schedule with the planned start date and expected finish date of every activity within the project. The project schedule is considered preliminary until all the resources assignments have been confirmed. The project schedule can be represented in summary form as a master schedule or in detail .Though it is usually found in tabular form, presentations usually find the project schedule shown graphically using project network diagrams with assigned dated, bar charts showing the start and end dates (sometimes called Gantt charts), milestone charts which focus only on key deliverables, or time scale network diagrams which are a combination of the project network diagram and bar charts.

73

Project Management

Also included with the project schedule are any supporting detail, the plan for managing the schedule and any updates to the resource requirements?

8.3.5 Controlling the Schedule Schedule control is a process very similar to the control scope change process but from a duration estimate perspective. The same inputs are used and similar outputs are generated. The same tools and techniques are used, except the use of the schedule change control system. Because it should be linked into the same overall change control system as scope management, it may have the same system.

8.4 Banking On It The project team has formulated the scope of the project determining what the deliverables will be and the general work requirements of those deliverables. The deliverables were assessed to determine the activities required to product them and estimates were provided to each of the activities for the duration the effort. Out of the work, the project team has a work breakdown structure and a project schedule. In much the same way that the project is given a limited time frame to complete the work, the project also is provided a budget. Project cost management is the knowledge areas consisting of processes utilized to determine and management cost on the project. The 74

Project Management

primary concern of the cost management is the cost resources for completing project activities; however not at the expense of increased cost elsewhere. Though quality management is concerned with the correctness of the deliverable, the costs associated with producing a quality deliverable should be addressed at the beginning of the project. For example, engineering projects that limit the number of design reviews may reduce project costs but increase operational costs. This is often referred to as lifecycle costing. Cost management for a project is typically balanced with the processes for cost management for the entire business. In some companies, many of the mechanisms for predicting and analyzing the financial performance of a product are done outside of the project; in others, project cost management. Stakeholders may measure costs in different ways and at different time, forcing the project to understand the information requirements of the stakeholders for reporting purposes. Project cost management deals with resource planning, cost estimation, cost budgeting, and cost controls. In some projects, these areas are often viewed as a single process, but each has different tools and techniques used to complete the work.

75

Project Management

76

Project Management

9 Leaning on Resources To complete a project, physical resources are necessary whether they are in the form of people, equipment, or materials. Identifying the resources required and the quantity needed is the focus of resource planning. Planning for resources start with the WBS, historical information, the scope statement and policies of the organization referencing staffing, rental and purchase guidelines. Additionally, any description of the resources that are potentially available. This description is commonly called the resource pool description and it varies from project to project and even throughout the project. For instance, the pool may consist of software developers for an application project at the beginning a project, but later on have more detail to only include Java programmers. The primary tool used for resource planning is expert judgment which can come from the project team members, other units in the company, consultants, professional and technical associations and industry groups. The purpose of resource planning is the creation of resource requirements.

9.1.1 Applying Cost Having identified the resource requirements, the project team can develop an approximation of the costs required to complete the project activities. For projects working under 77

Project Management

a contract, a distinction exists between cost estimation and pricing. Cost estimating produces an assessment of the quantitative result, how much it will cost the performing organization to provide the product and service. Pricing, on the other hand, is a business decision on how much the performing organization will charge for the product of service. Some issues have been opened because project cost estimation was done after contract negotiation and therefore, the pricing is lower than the estimate. Other times, the project cost estimate forced the pricing up too high for the product of service to be sold. Ultimately, the goal of the project is to deliver a quality product or service in the shortest amount of time and at the lowest cost possible. To begin cost estimation, the project team should have access to the WBS, the resource requirements, the activity duration estimates, historical information. A chart of accounts is required that describes the coding structure for reporting financial information to the company's ledger. Finally, the resource rates for personnel, equipment, and materials are needed by the project team. If the actual rates are not known, than the rates themselves have to be estimated. The project team uses all these resources to begin estimating the cost for each activity. The team can use analogous estimating by looking at the actual costs used in a previous, similar project. This method of estimation is generally less costly to utilize but also less accurate. 78

Project Management

Another method is parametric modeling which uses project characteristics in a mathematical model to predict costs. The cost and accuracy of parametric models vary but are more reliable when the historical information creating the model are accurate, the parameters used are quantifiable, and the same model can be used for small projects and large projects. Bottom-up estimation estimates the individual work items and then summarizes the individual estimates to obtain the project total. No matter the method used, the result eventually will be a cost estimate for the project. The estimate reflects the likely costs of the required resources. All resources that will be charged to the project must be estimated and will include, but not limited to, labor. Materials, supplies, and even special considerations like inflation or cost reserve. Costs should be represented using a consistent expression, normally units of currency. However other units may be used like staff hours or staff days but ultimately need to be expressed in units of currency. Along with the cost estimate any supporting documentation for understanding the estimate s and a plan for managing costs should be included.

9.1.2 Budgeting the Project While estimating costs for the activities may identify the likely expenses for the project, a budget involves distributing a financial pool across the work items. Cost budgeting establishes a cost baseline for measurement 79

Project Management

project performance. Cost estimates, the WBS, and the project schedule are used to create the cost baseline, which is a time-phased budget used to measure and monitor cost performance on the project.

9.1.3 Controlling Cost As with scope and time, controlling costs are very similar as a process. A cost change control system should be in pace which interacts with the overall change control system. Changes in cost may impact scope, time and resources.

9.2 Managing the Right Stuff Unfortunately, project may be started and completed, but are not successful. The project may have been done on time and according to budget and still fail. As far as managing the project, the team was successful, but the product or service that it delivers does not satisfy the needs expected. Essentially, the tangible aspects of the project were delivered, but the intangible aspects were not. What was missing from project like this was a balanced focus on quality management. Project Quality Management from the PMBOK is compatible with ISO 9000 and 10000 series of standards and guidelines. Using these series as the basis for describing quality management, PMBOK quality management is compatible with proprietary approaches like 80

Project Management

Deming, Juran, Crosby, and others and non-proprietary approaches like Total Quality Management (TQM), Continuous Improvement, Lean Six Sigma, and others. Project quality management addresses both the management of the project and the product. Failure to meet quality requirements in either area can have serious consequences for the stakeholders. Current quality management disciplines complement PMBOK project quality management disciplines. Both recognize the opportunity of customer satisfaction through conformance to specification and fitness for use, management responsibility, processes within phases, and the importance of avoiding mistakes over correcting them. Quality is “the totality of characteristics of an entity that bear its ability to satisfy stated or implied needs.” Putting this definition into the context of a project, the goal of project quality management is to turn all implied needs into stated needs through project scope management. One important concept for project teams is the difference between quality and grade. Grade often speaks to the functional use of a product, so a product with low functionality may have a low grade and still be a quality product.

9.2.1 Quality is Planned The most important part of project quality management is understanding the relevant quality standards that could impact the project and putting plans into place that will meet those standards. Quality standards can apply to the 81

Project Management

project, the disciplines of project management, the reporting, the product and other deliverables. Essentially, every aspect of the project and the work done inside of the project. One tenet of quality management is that quality is planned in, not inspected in. The first requirement for planning quality is the understanding the quality policy which describes “the overall intentions and directions of as organization with regard to quality, as formally expressed by top management.” The quality policy of the performing organization is automatically adopted for the project. If the performing organization does not have a formal policy, the project team will have to develop one. If the project is being performed by multiple organizations, a quality policy that encompasses the intentions and directions of all the organizations will need to be developed. Other inputs to quality planning are the scope statement, the product description, standard and regulations, and outputs from other processes. With these inputs the planning can start. The benefit of meeting requirements for quality is typically less rework, which typically leads to higher productivity, lower costs, and increased satisfaction to the stakeholder. The cost of meeting requirements is the expense spent undertaking the activities of quality management. A benefit/cost analysis will assist the project is justifying the quality management activities on the project.

82

Project Management

To measure performance to quality, the project may start with benchmarking; comparing the project practices that are being done or planned to be done with the practices of other projects to generate ideas for improvement and provide a standard to measure from. Understanding how elements within a project or deliverables relate can provide information on where quality issues may occur. Flowcharting provides a number of ways to create this understanding. Cause-and-effect diagrams show how various elements can cause an effect, or problem. These diagrams are also referred to as Ishikawa diagrams or fishbone diagrams. System or process flowcharts also show how various elements interrelate. An analytical technique called design of experiments are often used to understand different quality issues or potentials for the product. The technique use assists in identifying the variables that have the most impact on the quality of the overall outcome. The goal of quality planning is to identify where the potential risks to quality will acquire and place plans around ensuring the quality of the project and the product. The prime result of quality planning is the documentation addressing the methods used to control assures and improves quality on the project. Included with the plan are operational definitions which document what something is and how it is measured by the quality control process. These very specific documents are sometimes referred to as metrics. Supporting documentation may be included to the plan and

83

Project Management

the definitions: one supporting document may be numerous checklists to be used on the project.

9.2.2 Quality is Watched The quality system created or utilized by the project team will have systematic activities involved to bring confidence to the project and stakeholders that relevant quality standards are being met. These activities will be performed throughout the life of the project. In many instances, a Quality Assurance Department will be performing the work, or they could be providing governance over ensuring that the project team does the work. Project Quality Assurance begins with the quality management plan, the operational definitions, and results to quality control measurements. Those inputs are used during quality audits to the project and the products of the project. Improvements to quality from the audits are identified and communicated. Those improvements exist to increase the effectiveness and efficiency of the project. Those improvements typically go through the control change process to be implemented.

9.2.3 Quality is Controlled Monitoring the specific project results for compliance with relevant quality standards is the function of quality control. The process also identifies ways to eliminate the sources of unsatisfactory results. The results of the project 84

Project Management

encompass both product results in the form of deliverables and management results in the form of cost and schedule performance. The project team should have a working understanding of the statistical methods used in quality control, such as sampling and probability. Additionally, they should understand the differences of: • Prevention and inspection – keeping errors out of the process versus out of the hands of the customer. • Attribute sampling and variable sampling – results conforming absolute adherence versus degree of adherence. • Special causes and random causes – unusual events versus normal process variation. • Tolerances and control limits – acceptable result versus controlled result. Both product and project results are used with the quality management plan and operational definitions to initiate the quality control process. The process utilizes a number of tools and techniques to perform the necessary work. One of the simplest techniques is inspection over the work result. By measuring, examining, and testing the result, the individual or group inspecting the result can identify the characteristics that are most satisfactory and ask pertinent questions on the whole or specific parts of the result. Mathematical analysis can be performed and presented in the form of control charts, pareto diagrams, statistical sampling and flowcharting. Each of these methods have advantages over the other for displaying different types of 85

Project Management

information. Control charts are appropriate for showing results over time and are used to determine if a process such as cost or scheduling are in control. Pareto diagrams are histograms and used typically to identify the frequency of occurrences. Statistical sampling is a method for inspecting a portion of a large population to identify major characteristics of the whole populations. Samplings can be made up of the customer base, a whole of requested changes, or any large pool of results related to the project or product. Flowcharting is used to identify the causes of problems. Trend analysis is another mathematical techniques used to provide forecasting information on quality performance. Using historical data, the analysis is used to identify where potential problems may occur in the future and allow the opportunity to correct. Trend analysis can be used to forecast technical performance of the product as well as cost and schedule performance of the project. The results of quality control are in the form of quality improvements, acceptance decisions, and completed checklists. These results are typically used to make adjustments to the process or force additional action to rework an item. Rework is the frequent cause of delays in schedule and going over budget especially when unanticipated. The goal of the project team is to minimize the amount of rework required on a project.

86

Project Management

9.3 Working with People Despite the work involved with scope, schedules, budgets, and quality, the core of the project involves working with people. The intention of project human resource management is to effectively use the people assigned to the project, including sponsors, customers, individual contributors, and external representatives. The knowledge area encompasses the processes of organizational planning, staff acquisition, and team development. Much has been writing about dealing with people inside the business world. Books can be found to handle general management skills of leadership, communication, and negotiation. Or motivational books describing the differences and techniques of delegating, coaching, mentoring, or motivating individuals. If a person is looking for ways to build teams, manage conflict, or group dynamics, they can find it. Even subjects like performance appraisals, recruitment, retention, labor relations, regulation compliance, and other administration skills have sufficient resources on the shelves. All of this material is applicable to project management with caution. Many of these books focus on building long-term, ongoing relationships in the business community. Projects are naturally temporary, so relationships are typically new and in place for a finite period of time. The nature and number of people assigned to the project vary and not always consistent with the size of the project. Many of the administration duties of human resources are the direct responsibility of the project team, 87

Project Management

though they need to be aware of the requirements to ensure compliance.

9.3.1 Working Together Project human resources management begins by understanding the relationships between people. Organizational planning assists in identifying, documenting, and assigning project roles, responsibilities and reporting relationships. Those assignments may be to individuals or to groups who are either a part of the performing organization or external to it. Most of the work of organizational planning is done in the early stages of the project, though changes to the team may occur in the later stages. The project's organizational structure will have a direct impact on the communication requirements on the project and therefore organizational planning is tightly linked with communications planning. A number of items are required for successful organizational planning, the first being the project interfaces. Three types are interfaces typically exist on a project: organizational. Technical, and interpersonal. Organizational interfaces are the reporting relationships among different organizational units. These reporting relationships may be formal or informal. The reporting requirements may consist of formal, structured and detailed reports provided with some determined frequency or a notification of an event. Understanding these interfaces will assist in understanding the potential reporting structures of 88

Project Management

the project as well as stakeholders. Technical interfaces define the working interfaces between technical disciplines, essentially establishing how the operational side of the business work together. Similar relationships may be duplicated within the project. Interpersonal interfaces focus on the relationships between the individual members working on the project. With the project interfaces, the project utilizes the staffing requirements which include what skills are required and when, templates, stakeholder analysis and constraints. For organizational planning the constraints may take the form of the organizational structure of the performing organization, contractual agreements with unions or other employee groups, the preferences of the project management team, or even the expected staff assignments. Many companies have a number of policies, guidelines, and procedures in place to support project human resources, as well as the general body of knowledge related to organizational theory. The principle objective of organizational planning is the assignments of roles and responsibilities. These assignments may vary over time, though most assignments will be made to members of the project team who are actively working the project and should not change during the project. Project roles are and responsibilities are closely connected to the project scope definition; a Responsibility Assignment Matrix (RAM) is often used to show the relationship.

89

Project Management

To manage the assignments, a staffing management plan is created. Particular attention should be made to describe how project team members are to be released when they are no longer required on the project. Along with the plan may be a graphical display of the reporting structure used on the project. This display is typically in the form of an organizational chart. Any supporting detail for determining the assignments, the plan, or the reporting structure should be included as well.

9.3.2 Finding the Right People One of the easiest and hardest activities on a project may be finding the right people to be on the project team. This is partially due to the realistic certainty that the “best” people are not available. So whoever is assigned to the project must be able to meet project requirements. Unfortunately, a constraint may be in place to force the assignment of a single option for a particular spot on the project team. Though in many companies, the assignments are typically given to people who have been on projects before, so a strong working relationship may already be in place for the majority of the project team. To acquire the proper staff, a project manager typically must communicate the staffing requirements to the appropriate managers, either human resource for all or individual department heads. In some cases, a choice needs to be made from a pool of staff resources. TO make this choice, the project manager and business manager will 90

Project Management

usually look at previous experience, personal interests, characteristics and availability. In some instances, the right person needs to be recruited. The techniques used to acquire staff range from preassignment to negotiating to procurement. Preassignments are typical of a competitive proposal where specific individuals were promised to be part of the project. Negotiation may be required with the business manager to obtain the right person at the right time. If a person cannot be found within the performing organization to fulfill some portion of the project requirements, the project may have to look at external resources to hire or contract in. Whatever the method for acquiring staff, the end result will be project staff assigned to every activities found into the project plan. Many projects will create a directory of the project team.

9.3.3 Developing Team The intent behind developing a team is to improve the individual contributions of stakeholders and their ability to work as a team. Individual development servers the team while team development service the project. In matrix organizations team development can sometimes be difficult since the individual team members are accountable to a functional manager and a project manager at the same time. In these situations, effective management of the dual 91

Project Management

reporting relationship is a critical success factor for the project. Team development begins with the project staff, the project plan, the staff management plan, performance reports, and external feedback. To develop the team, the initial step may be to train the individuals or group to enhance the skills, knowledge, and capabilities in order to properly fulfill the activity requirements of the project. Working with the group, team-building activities may be used to have the group recognize and utilize the individual strengths of the team members. The purpose of team-building in this sense is to improve team performance. Some projects require team members who are located throughout the global, with little or no potential for the team to be physically located together as a team. Especially for large projects, collocation may be a necessary requirement to have the majority of the team working together. Even on smaller projects where members tend to do their duties at their desk or on the floor, it can prove beneficial to have the team meet in a conference room periodically to focus on the project. One development tool that can be sometimes overlooked on projects is a system for rewarding and recognizing individual and group contributions. Typically, if such a system exists it is utilized at the end of a project, however some benefit may be obtained by using it at the end of each phase, especially on large or complex projects. Many companies already have a system in place for the 92

Project Management

operational portion of the business and are adopted for project management. Sometimes, these systems are inappropriate or difficult to fit into the project management model. Therefore, some companies have adopted separate systems for project management use. The intent of team building is to improve performance on the project. Improvements in individual skills allow a person to complete activities more effectively. Improvements in team behaviors allow the team to focus on the technical activities of the project. Improvements in both areas help to identify and develop better practices for project management. Additionally, focus on individual and team development also provides awareness to sufficiently provide information for performance appraisals.

9.4 Opening up the Lines of Communication In addition to the activities required to manage a project and to produce a product through the project, the most important aspect to a project is the communication structure that it uses. Throughout the life of the project, information is being generated, collected, stored, disseminated, and disposed of constantly. A project is successful because of the critical links between people, ideas, and information. Every person involved in the project must be able to send and receive information in the language of project management.

93

Project Management

Project communication management incorporates the processes of communication planning, information distribution, performance reporting, and administrative closure. In incorporates all general information and education associated with building effective communication skills used by general business models. The actual implementation of a communication structure on a project may be influenced by the cultural, technical, and behavioral aspects of the communication practices already found in the performing organization or its customer.

9.4.1 Laying the Infrastructure Communications planning involves identifying and understanding the needs of the stakeholders in the areas of information and communication: who needs what when and how should it be presented. The need for communication is self-evident for project work, the information needs and the method for distributing that information may differ from one project to the next. Compiling the individual needs of the stakeholders will provide the basic requirements for communication on the project. The requirements will focus on the type and format of the information requirements with an analysis of the value of that information. The value applied can be used to determine how project resources are used: if the communication contributes to the success of the project, resources will be provided, but where the contribution will lead to failure of the project, resources will be denied. 94

Project Management

The technologies or methods available to transfer information is a critical component to project success, especially in cases where new technologies are used and the stakeholders are not yet “trained” in its use. Some of the considerations for the technology used are the immediacy of the information need, the availability of the technology, the expected project staffing, and the length of the project. Depending on these considerations, the project may adopt an extensively constructed avenue to communicate information or they may simply supply presentation materials to a board meeting. The result is a comprehensive communication plan which includes: • A collection and filing structure for storing information. • A distribution structure detailing who will get information and how. • A description of the information to be distributed, like status reports, data, schedules, technical documentation, etc. The description will include the format used, the content expectations, the level of detail and the conventions and definitions used. • Production schedules for when the different types of communications will be produced. • Methods for accessing information between scheduled communications. • A method for updating or refining the communications management plan...

95

Project Management

9.4.2 Making the Connection Once the communication plan is in place, the next requirement on the project is to ensure the right information is to the right people at the right time. This includes following the communication plan as well as handling unexpected requests for information. The process of information distribution handles the dissemination of information on the project. The most important component of information distribution is the effective communication skill of the person responsible for managing communications. This skill will ensure that the information being communicated is clear, concise, and fulfills the requirements of all parties involved. They will also utilize the appropriate system for delivering the information. Two tools may be used for communications: the information retrieval system and the information distribution system. The first is a passive approach for sharing information that used any variety of mediums. The second is an active method of sending information to appropriate parties using several possible methods. The primary result of information distribution is the creation, sharing, and storage of project records.

9.4.3 Cleaning Up Static The greatest piece of information for the project to have and to share is its performance record. Whether reporting 96

Project Management

where the project is (status), what it has accomplished (progress), or predicting future events in status and progress (forecast), the information has great interests to all persons involved in the project. Essentially it answers the question of project value to the business. Performance reporting includes the process activities required to collect and distribute information related to performance on the project. Using the project plan as a basis, performance reporting looks at the work results. Are the deliverables fully or partially completed? Is the project on time, ahead of schedule, or behind schedule? Are the project costs in line or above or below budget? Are there any issues currently present that need to be resolved at this time? Some of the tools used to define the performance of the project are performance reviews, variance analysis, trend analysis, and earned value analysis. Earned value analysis is the most commonly used form of performance measuring. It used the scope, cost, and schedule of the project to determine the measure and calculates three key values for each activity in the project. • The budgeted cost of work scheduled (BCWS) identifies the portion of the approved cost estimate planned to be spent during any given period, or the estimated cost of performing the activity. • The actual cost of work performed (ACWP) identifies the total direct and indirect costs attributed to the performed work in any given period, or the actual 97

Project Management

cost of performing the activity. • The budget cost of work performed (BCWP), or earned value, is a percentage of the total budget equal to the percentage of the work actually completed. So how much money was spent to perform a specific amount of work. The three values above are used in combination to identify cost variance (CV), schedule variance (SV), and cost performance index (CPI). These measurements explain how far off of budget and schedule the project through CV and SV measurements. The CPI measurement is used to forecast project cost at completion. Some application areas use another measurement to forecast project completion date called schedule performance index (SPI). The performance reports are delivered using whatever system was described in the communication plan. In addition, improvements or corrective actions may have been identified which need to go through the change control process.

9.4.4 Ending the Connection At either the end of a project phase or the end of a project, the process for administrative closure will be called. The purpose of this process is to complete any administrative work that may be required by the project. It begins with verifying and documenting project results with the intent to obtain formal acceptance of the project deliverables by the sponsor, client, or customer. The process entails collecting 98

Project Management

all pertinent project records, ensuring that they reflect the final specification of the deliverables, the analysis of project success and effectiveness, and making the information available as well as archiving it for future use. Administrative closure works best when it is done throughout the project to end phases, and is considered poorly done when the entirety of the project close is done at the end of the project. The chief inputs to the administrative closure are the performance measurement and the documentation pertinent to the deliverables or the product of the project. Other documentation may be available. At the end of the administrative closure process, the project team will have formal acceptance of the product of the project or phase, the project documents will be indexed and archived, and any lessons learned from the project will be documented and communicated.

9.5 Base Jumping a Project With any endeavor, a number of concerns and issues may be introduced that cause doubt on the success of the endeavor. For a project, these are items that question whether a particular deliverable or activity can be delivered as intended in the time frame or budget allotted to it, or using the resources assigned to it. At the end, any issue to this effect is considered a risk to the project and risks can be managed. Project risk management is the PMBOK 99

Project Management

knowledge area that concerns itself with identifying, analyzing and responding to risk. With any endeavor that has risk associated with it, the key to success is first understand the risk and then to prepare for it. For the most part risk is not eliminated, but by planning for it, the impact of the risk can be avoided or mitigated to prevent severe impact to the project. Project risk management involves the following processes: risk identification, risk quantification, risk response development, and risk response control.

9.5.1 The More Risk, the Better the Experience Identifying and understanding risk to the project is the goal of risk identification. It is not a one-time process for the project but is done consistently throughout the project whenever the ability of the activity to be performed as intended with the associated cost, schedule, and resources is questioned. The risks identified can be internal or external in relation to the project. Internal risks are those that the project team can impact or control. External risks are beyond the immediate control and influence of the project team. Though any time a performance of the project is questioned, not all the concerns behind the question will become risks. Risks are in the strictest sense only those items that have the possibility to causing harm or loss to the project or the product of the project. From a project management perspective, risk management broadens its scope to include those items that can help or 100

Project Management

aid the project or product of the project. Project risk is found in both opportunities and threats. The reasoning behind viewing opportunities as risks is rooted in the possibility portion of the risk definition. For instance, an opportunity to utilize new technology that was not introduced when defining the scope may reduce the time required to complete the project by weeks and improve the quality of the product, but with an increase of the budget by 10%. Where the opportunity shows up as positively for time and quality, there is a risk to scope and cost. More work is required to justify any changes to the project. Because of the project perspective to introduce opportunities as well as threats as risks, the people involved with the project should be encouraged to identify as many potential risks as possible to the project. To aid in discovering risks, the team may use the description of the product, the outputs of other planning processes specifically the WBS, cost and duration estimates, staffing plan, and procurement management plan. Historical information may serve to identify risks as well as plans to handle the risk. Some of the tools used by the project team to identify and document the characteristics of risks are checklists, flowcharts, and even interviews with various stakeholders and experts. At the end of the process, the project team will has a list of potential risk events, the symptoms of risk and the sources of risk. Potential risk events are discrete occurrences that may affect the project. A project member leaving the team is a potential risk event. If the probability 101

Project Management

of occurrence or magnitude of loss is relatively high, these risk events should be added to the sources of risk. Most potential risk events are never application area specific, though a list of common risk events can usually be identified for each application area. Descriptions of potential risk events should include estimates for the probability that the risk will occur, the alternative outcomes of the event, the expected timing of the event, and the anticipated frequency. Potential risk events identified early in the project may have broader descriptions applied to them, so it is prudent to provide more detail to them later in the project. The source of risk is categories of possible risk events. The distinction between potential and possible can be hazy at times. The importance is actually how the risk is managed. Possible risks event are more like to happen, have a greater magnitude of loss if it ever does happen, or it is an immediate concern of one or more of the stakeholders that has to be addressed. The list of sources should be comprehensive. Common sources of risk include: • changes in requirements • design errors, omissions, and misunderstandings • poorly defined or understood roles and responsibilities • poor estimates • insufficient skill in staff Descriptions for the sources of risks should include the probability of occurrence, the range of possible outcomes, expected timing, and frequency of the risk. 102

Project Management

In addition to the potential risk events and the sources of risk, the process should identify triggers, or risk symptoms. These are indirect manifestations of actual risk events. For example, a key member being involved in an accident may cause a strain on the schedule.

9.5.2 Extreme Sports or Golf? Having identified all the risks associated to the project isn't enough to manage that risk. Each risk required some form of evaluation to assess whether the risk warrants a response outside of the normal course of a project. This is risk quantification. Someone who is parachuting for the first time will recognize the risk of the chute not opening. This is the same risk that an experienced jumper has, but the process is no different for the new or the experienced person: both need to ensure that the chute is properly packed. A number of factors may be used to evaluate and ascertain any warranted responses. Some of the factors may include: • Opportunities and threats that interact in unanticipated ways, e.g. new technology saves time but costs more. • A single risk event having multiple effects on the project. • Opportunities for one stakeholder may prove to be a threat to another. • Techniques used creating a false impression of precision and reliability. 103

Project Management

One of the key inputs to risk quantification is the tolerance to risk that the stakeholders have. Different organizations and different individuals can have different tolerances for risk. For instance, a very profitable company will be more willing to spend more money on a project than a company that is breaking even. Some companies classify budget overruns and schedule delays differently causing a certain percentage overrun to be high risk for one and low risk for the other. A company trying to take market share from its competitors may be willing to spend more to introduce a new technology to the product. Whatever the reason for the tolerance, it serves as a filter to the quantification of risk. Using those tolerances, the sources of risk, the potential risk events, cost estimates, and the activity duration estimates, the project team will attempt to evaluate and quantify the risks. One method for quantifying a risk is to apply an expected monetary value. This takes into account the probability of the risk event as well as an estimate for the monetary gain or loss of the event. Both tangibles and intangibles should be represented in the earned monetary value. In addition to this method, the project team may use statistical sums, simulation, decision trees and expert judgment to understand and quantify the risk. There are typically to paths coming out of the risk quantification process: choosing to pursue a particular

104

Project Management

opportunity or respond to a particular risk, and ignore an opportunity or accept a risk.

9.5.3 Be Prepared Responding to risk fall into three possible actions: avoidance, mitigation, and acceptance. Avoidance is the actions takes to eliminate the risk, most notably by eliminating the cause. Not all risk can be eliminated. In these cases, the next set of actions focus on reducing the risk by reducing the probability of occurrence. The purpose of mitigation is to impact the expected monetary value of the risk. When the risk cannot be eliminated or the mitigated, the next action is to accept the risk as is. Acceptance can become active such as putting a contingency plan in place, or passive like taken on higher costs if the risk occurs. The risk response development process assists in building the steps for taking on opportunities and responding to threats. Taking the outputs of the risk quantification process, development of the responses to opportunities and threats are created. In some cases, the responses may require the procurement of goods or services from outside of the project organization, specifically when the risks are associated with a particular technology. Often, procurement simply changes one risk to another, a technology solution to a risk that requires procuring a specific type of equipment, may mitigate the immediate risk, but create another risk to the project costs. 105

Project Management

Another appropriate response is the creation of contingency plans or strategic alternatives. Contingency planning involves defining what steps will be taken if and when a risk event occurs. To prevent or avoid risks, alternate strategies may be utilized, such as spending more time in the design phase to decrease the number of changes that happen during development. In some cases, risks will require some insurance or bonding as a response. This is particular response is appropriate when there is a substantial expected monetary value and the probability of occurrence is likely to high and the cost of having the insurance outweighs the cost of not. All responses to risk will be documented in the risk management plan as well as additional procedures for handling risks that are identified later in the project. The documented risk responses may serve as inputs to other processes in project management. Contingency plans are organized appropriately to allow for quick access if a covered risk occurs. As a measure to offset the cost of risk to the schedule or budget, a financial or time reserve may be created. Sometimes, a reserve is specific to a category of risk with multiple reserves defined to handle more than one category. For some risk responses, contractual agreements may need to be in place.

9.5.4 Taking the Jump

106

Project Management

Risk response control executes the risk management plan to appropriately respond to risk events during the project. If changes happen during the project, the potential for risk exists and the cycle of identifying, quantifying, and responding to that risk is initiated again. The risk response control processes take the plan, the actual risk events, and any additional identification of risks can executes the responses. In some cases, the responses are not as effective as planned or a new risk appears that needs immediate response. In these situations, workarounds may be employed which are unplanned responses to risk events that immediately reduces the impact of the risk on the project. Even with workarounds in place or when one is not appropriate, additional risk response development may be required.

9.6 Going Shopping For some projects, equipment and materials requirements make the need for procurement processes to be in placed to acquire the appropriate goods and services for sources outside of the performing organization. The knowledge area includes the processes of procurement planning, solicitation planning, solicitation, source selection, contract administration, and contract close-out.

107

Project Management

9.6.1 Creating a Shopping List Procurement planning identifies the needs of the project which are best fulfilled by the acquisition of products and services from outside of the project organization. The process contains steps for deciding whether to procure, how to procure, what to procure, how much, and when to procure. When the decision to procure a product or service is made, the processes from solicitation planning to contract close-out will be used for each product or service to be procured outside of the performing organization. If the project or service can be obtained from within the performing organization, the processes will not be utilized. To starting planning for the procurement of products and services, the project team will utilize the scope statement and the product description to understand the needs of the project. If a formal contracting group exists for procurement activities, the procedures for interacting with the group will be accessed. If no group exists the project team will need the skill and expertise required to support procurement activities. Market conditions can influence procurement decisions as they describe what is available, from whom, and under what terms and conditions. Other constraints and assumptions that have been found throughout the project management processes may also impact procurement decisions. To continue the decision making process, the use of makeor-buy analysis may be utilized. This is a general 108

Project Management

management technique used to determine if the building of a particular product will be more cost effective than actually procuring the product. Some projects may be utilized to procure items for the growth of operations that is clearly outside of the intentional scope of the project. For instance, the rental of a large piece of equipment for construction projects may be the typical procedure for the e performing organization, however recent increases in its use may force a business decision to procure the equipment. Procurement can include purchase, lease, renting, or donation. In some instances, contractual agreements are required. Most contracts fall into one of three categories: fixed price, cost reimbursable, and unit price contracts. If the procurement of a product or service involves a fixed total price for a well-defined product, the contract is considered fixed price. How well the product is defined will reduce the risk associated with the purchase. Cost reimbursable contracts involve payments to the total price. The costs are classified as direct and indirect costs: direct costs are those incurred for the direct benefit of the project and indirect costs, or overhead, are the costs of doing business. Unit price contracts provided for payments based on a preset price per unit of service or product. The total value of the contract is based on the quantities obtained. The result of procurement planning is the procurement management plan and the statements of work. The statement of work (SOW) provides sufficient detail of the

109

Project Management

item to be procured for the prospective sellers to determine their capabilities for providing the item.

9.6.2 Walking the Mall When the procurement needs of the project have been determined and the statements of work created, the next step is to prepare to find potential providers. This typically involves using standard forms to create contracts, bid documents, and descriptions. Different procurement documents exist and may be used: • Invitation for Bid (IFB) requests sellers to provide a price for the procurement item. • Request for Proposal (RFP) asks for an explanation of the services provided with the pricing. • Request for Quotation (RFQ) are similar to IFBs. • Invitation for Negotiation are similar to RFPs • Contractor Initial Response is to identify interested sellers. Along with the procurement documents, the need for evaluation criteria from which to determine the right proposal is required. Evaluations can be objective or subjective and are typically a part of the procurement documents. Some criteria may include an understanding of need, overall cost, technical capability, management approach, and financial capability.

110

Project Management

9.6.3 Window Shopping The project team typically will provide some time for proposals to be made by sellers. The time allotted should be defined by the project plan. Some organizations have lists on prospective sellers that may be used. If these lists are not available, the project team will need to create one and in doing so perform some research to obtain the credibility of potential sellers. To solicit prospective sellers, the project team may advertise their need. They may also directly invite perspective sellers. In some instances, bidder conferences may be called. These are meetings designed to ensure that prospective sellers have a clear, common understanding the procurement before the creation of any proposals. The intention of all solicitation activities is to increase the number of proposals to the procurement item. In some cases, a limit is applied to the number of proposals which are accepted.

9.6.4 Finding the Right Store Source selection provides the methods for receive proposals, applying the evaluation criteria, and choosing the right seller. The process is not always easy. Price may be a determinant for most items off-the-shelf, but the lowest price may not be sufficient if the item cannot be delivered on time. Many proposals have to be balanced between technical approach and price. The more technical the 111

Project Management

approach, the more costly the item. For critical products, multiple sources may be necessary. In determining the appropriate seller, a screening system may be in place to identify the most potential of the proposals while a weighting system attempts to quantify the proposals. In the end, most purchases require some form of contract negotiation. The contracts will be used to ensure that the procurement items are delivered within cost and per the pricing negotiated.

9.6.5 Making the Purchase Contracts sign for the procurement items and now the project team has assurances in place to have the services, the equipment, and materials in place to successfully execute the project. Making sure that the seller meets the contractual requirements detailed in these documents is the work of contract administration. For some companies, this work is performing by a central department. For large projects, the key purpose for contract administration is the management of interfaces between multiple suppliers. However, contracts are managed or why, the project team must understand the legal nature of the contractual relationships in place to be acutely aware of the legal implications of the actions taken when administration the contract. Contract administration is used in conjunction with other project management processes to cover some of the 112

Project Management

requirements of effectively executing a project with contracts. Project execution authorizes any work required by outside contractors at the appropriate time in the project. To monitor contractor cost, schedule, and technical performance, the performance reporting process is utilized. Quality control assists in inspecting and verifying the adequacy of the product and services from the contractor. Nay changes involving the contract are handled through the change control process. To manage payment schedules requires financial management. Throughout the process, correspondence, contract changes, and payment requests are the output expected of the process.

9.6.6 Wrapping It Up Contract close-out is a similar process to administrative closure as it involves product verification and administrative close-out. The difference is that this process focuses on the completion of the contract and may consist of specific procedures that handle the legalities that exist. The intent of the process is obtaining formal acceptance of completion. In many cases, the supplier may also have a contract close-out procedure that they need to follow. Working with the supplier in this matter will speed up the effort.

113

Project Management

114

Project Management

10 Concluding Project Management Project management from the perspective of PMBOK is an extensive and comprehensive set of processes that cover most situations and concerns experienced on a project. For specific application areas, slight differences may be found during the execution of the project management disciplines. The use of templates and historical information will serve to increase the effectiveness and efficiency of the project in numerous processes. For organizations which expect to handle projects in the long term, it is advisable to create an infrastructure to assist in managing and collaborating on project as well as to create historical documentation. Certification of individuals serving as project managers and even those expected to be on project teams is equally desirable.

115

Project Management

116

Project Management

11 Comparing Project Management Frameworks PMBOK is not the only project management framework though it is an internationally recognized standard. A number of other frameworks are available and some are gaining popularity in the business world: of not is the United Kingdom recognized PRINCE2 (Projects IN Controlled Environments). PRINCE2 is an open method for projects that are driven by business case rather than customer requirement driven. The framework does not claim to be complete and focuses on key risk areas only. This is a definite departure from the comprehensive PMBOK. Another difference is PRINCE2's focus as implementation methodology rather than the whole project methodology. PRINCE2 creates a framework based on the life cycle of a project. The method recognizes that project management processes can be found at the project level and the stage (phase) level... There are eight major processes in the framework from “Starting up a Project” to “Closing a Project.” Six focus on the life cycle while two, “Directing a Project” and “Managing stage Boundaries,” are used throughout the project. The eight processes are supported by 45 sub-processes. This is comparable to PMBOK's five process areas and 44 processes. The actual correlation between the two frameworks is below: 117

Project Management

PMBOK

PRINCE2

Initiating

Starting Up Directing Managing Stage Boundaries

Planning

Initiating Planning Managing Stage Boundaries

Executing

Managing Product Delivery Directing

Controlling

Controlling a Stage Directing

Closing

Managing Stage Boundaries

PRINCE2 is document heavy with descriptions to 33 standard management “products.” There is no notable difference from the “products” of PMBOK. PMBOK focuses on the foundations of project management, separating the discipline into nine knowledge areas. PRINCE2 has eight components making up the framework. The similarities are: PMBOK Knowledge Areas

PRINCE2 Components

Integration Management Combined Processes and Components Change Control Scope Management Time Management Cost Management

Plans Business Case

Quality Management

Quality

118

Project Management

Configuration Management Risk Management

Risk

Communication Management

Controls

Human Resource Management

Organization

Procurement Management

Not covered

Two obvious differences are present with PRINCE2. It uses Configuration Management as a way to manage assets. The assets include the products of the project as well as products (deliverables) from the project. Additionally, procurement management is missing. PRINCE2 has its strengths. The organization of the project is highly defined with roles and responsibilities clearly laid out. Ownership and accountability is with the project team and project boards (owners), rather than a collection of stakeholders. The process structure is integrated and clear in its flow. It fits into ISO 9000 Quality Management System and is consistent with SEIs Capability Maturity Model Level 5. Though differences exist between PMBOK and PRINCE2, benefits are achieved through the use of both. PRINCE2 has a methodology structure that is easier to implement. That implementation should be done inside the knowledge of PMBOK, even using a certified PMP. Using the key components and techniques from PRINCE2, PMBOK can 119

Project Management

be used to add depth to the implementation and for additional techniques. The result is a project management program that addresses the practices of a global community of project managers.

120

Project Management

12 Applying Cloud Computing to Project Management 12.1 Benefiting from Cloud Computing The benefits of cloud computing fall into quicker implementations and lower costs while providing greater scalability, adaptability, and reliability to the environment. Especially in terms of web applications, a solution can be available at any time in any location on the planet by any person. As use of the application increases or decreases, the cloud solution adjusts accordingly. The previous pages attempted to show the benefits of project management applied to cloud computing. The following pages will explore the benefits of cloud computing to project management. Some of the ideas explored here have solutions found within the cloud environment, especially in Independent Software Environments (IDEs) used for software development. Cloud computing solutions exploit a number of distinct technologies. • Virtualization is a technique used to create an abstract rendering of a physical component. For instance, storage volumes can be virtualized. With a virtual volume, the storage capacity can be increased, partitioned without partitioning the physical drive, or merging the volume with other 121

Project Management

•

•

storage devices to create a single large volume. Virtualization allows for increased scalability, reliability, and portability to occur. Web 2.0 is a perspective change for how to use the web. Often referred to as a technology, Web 2.0 provides a number of options that make web applications just as rich as desktop applications. Open source is a concept supporting total collaboration between developer and user. Often attributed to application development, the concept is also applicable to any number of solutions where user knowledge is utilized extensively to generate the product that the user is concurrently using. The idea ultimately encourages development in production.

Seven benefits are available to project management when adapting cloud computing capabilities: • The ability to interlink distinct components together as a complete whole. For instance, linking activity with cost, time, risks, quality, and resources. Many project management solutions already do this to some extent; however, with cloud computing the options can be expanded to include historical information, feedback, and particular notes. • To support communication specifically with stakeholders requiring performance reports, the use of subscription services allow distribution of information to have greater potential and customizable by the stakeholders themselves. 122

Project Management

•

•

•

•

•

Many aspects of project management can be present at any given time and with an application, the possibility of an interface that allows each aspect to deliver is highly probable with web applications. One of the risks to project management is ensuring that all the right players are involved in the project to ensure that everything that needs to be done on the project has been planned. With cloud computing, participation by all parties is possible. The core tenet of cloud computing is the ability to focus on components as parts of the whole allowing an individual component to be added, removed, expanded, and reused without impact the whole. The capabilities of the web allow portability. First of all, a web application can be accessed anywhere, at anytime, by anyone with only a browser and a connection to the Internet. Second, with the business logic of the application on an Internet server, nothing is lost between multiple users. A main drive of web applications and cloud computing is improved, richer user experience. Improving the experience of individuals on a project will encourage communication, productivity, and morale.

12.2 The Ease of Linking (Hyperlinks) Looking at the construction of the web, one will see a series of documents in place, basically organized through the URL 123

Project Management

hierarchy, and with some programming scripts to provide some interest. Though all of these components make up an effective website and web application, the one construct that makes the web the web has always been the ability to hyperlink. Hyperlinks are connections from an original page to a source document. By clinking on a hyperlink, a user can be moved from one page to another with just one click. By hovering over the link, information can be made available to the user. Through searches, multiple hyperlinks can be generated on a single page based on relevancy for the users to peruse. Hyperlinks can be used to transform basic pieces of data into rich volumes of information by creating relationships. In the back end of an application a database is usually found that holds data and created relationships with that basic data, such as a person's name and their job position. Using the web and hyperlinks, building relationships can be expanded to incorporate multiple databases. So in addition to a name and a job position, the person's personal profile and the job description for the position can be connected. This connection can be presented as links in a single page or the full or partial renderings of the sources can be presented. There are several perspectives that are prevalent in project management, each with some level of importance to the users. But the perspectives all rely on the need to understand the relationships with different pieces of data. Most project management solutions handle the basic 124

Project Management

relationships, such as the relationship between activity, cost, schedule, and resources. Some solutions even provide notes for referencing. However with hyper linking, any document or parts of a document can be referenced allowing risks and risk responses. Contractual terms, historical information, procurement proposals and supplier information, quality requirements, and the like can be linked to a single activity. By having the activity show all related information pertaining to it, all participants on the project can better understand and manage the work expected. The greatest aspect of this solution is that the information can exist in multiple databases and separated locations. Even connections with existing and past projects can be made. In situations where similar project are performed, like building a house with similar designs, connections can be made very easily. Why make these connections? Each constructed building can have its unique attributes: location, features, options, even contractors can be different. Using the designs as the starting point, a construction company can identify and compare the differences between buildings using the same design. The opportunities available are to assist in understanding requirements, risks, and unplanned threats to a particular project. For instance by referencing contractors familiar with the design, a replacement contractor can be found quickly if the original supplier is unable to do the job. What is linked and to what extent the linkages are made is left only to the imagination of the performing organization. 125

Project Management

12.3 Subscribing to Success (Blogging) Imagine compiling information into the next status report, categorizing it and posting it out to the web. Without any extra effort, a notification of the report is sent to every stakeholder interested in the project. Within minutes, responses to the report start to show up in the next day, all the responses are compiled for the project team meeting to review and answer. The situation just provided is just one of the ways blogs can assist in project management. Blogs utilize a subscription web service to ensure that people who want to be informed are. Used by a number of columnists, professional and amateur, on the web, a blog is a mechanism used to post information; with logic to identify who is interested in the information for a notice to be sent. The identity of interested parties was provided by the people themselves when they “subscribed” to the blog. Since a blog is basically a web page, the format of the report can include anything that a typical web page can include. Imagine again that the project is going along nicely. Coming into work early, the computer is turned on and waiting for you is a list of all the project activities that are currently being performed, the one that were completed the previous day, and the ones that are late are highlighted. As a project manager, the list includes all the activities of the project. As a project team member, the list includes only those which are assigned to them or have a dependency

126

Project Management

on. The mechanism used to compile this information from a project plan is the same used by blogs. At the heart of the blogging feature is the RSS technology. Really Simple Syndication (RSS) allow a person to subscribe to a web page so that when it changes, they are notified. The technology is not attached to the webpage though, but to the link between the user and the web page. A RSS feed allows these links to exist. Aside from blogging, the RSS technology has made another significant contribution: permalinks, or permanent links. With the permalink feature, users can link to other user’s websites, link to individual comments on a page, use “trackbacks” to other links to the page by other others, or respond to those other links, thus creating a two-way link. In project management, permalinks can provided a variety of associations between items. For instance, dependencies within a project can use permalinks to make two way associations possible, so that the project team can identify the activities and their dependencies, both dependent upon as well as depended for. Hyperlinks provided a way to show one way relationships between two items. RSS has allowed two way associations to be made. The use of RSS in blogging solutions has provided a new platform for gaining information within business. For project management, it’s a simple way of keeping stakeholders informed of what is going on with the project.

127

Project Management

12.4 Interfacing with the Project (Mashups) During project management, the number of items to be monitored and controlled is considerable. For the project manager, the concerns to be watchful of include: • Is the scope of the project intact? What are the current issues impacting scope? • Are we on schedule? What's late? What is about to start? What is about to finish? What issues are impacting the schedule? • Are we in budget? Where are we about to go over? What threats are present impacting project costs? • Who is supposed to be performing activities on the project today? Are all the equipment and materials required available? What issues do we have against resources? • What is the next milestone? How close are we? • When the next meeting? What information needs to be communicated? • What risks are important to monitor today? This is just a sampling of what the project manager is looking at for the day, or the week. And they are not alone. Though the focus of the information may be different, the project team members and the stakeholders are looking at similar information. Unfortunately, the information that any person is looking at is typically located in several locations. In order to get the information, the source needs to be retrieved and scanned to find the information.

128

Project Management

Using a project management engine as a web application, the information from these multiple sources can be retrieved, compiled, and presented to the user in a single interface. The technique used to make this possible is commonly referred to as a “mashups.” They are web applications designed to allow the user to customize their web interface to allow multiple sources of information to be presented at the same time. With the ability to customize the interface, the user can determine what information needs to be displayed at any given time. Each user could have a different interface to the project, one specifically designed by them to meet their information concerns. To allow mashups to work, the application developer simply needs to link the source of the information to the application. Some translation may be required to build relationships and associations, but once the information is readable and the criteria is set for how it is read it is ready. At that point, the source becomes a component in the list of components available for the user, like a catalog. The developer can also create relationships between multiple sets of data; for instance, mapping the project plans to the risk responses to change requests. Each piece of data is found in different sources, but is combined to show in the user's interface of the project.

129

Project Management

12.5 Everyone is a Project Manager (Open Source) One of the constraints of the tools used for project management is that they are built for use by project managers. Though nothing is wrong in this, it does alienate other people who are not familiar with project management needs and concerns. In some cases, these people are simply involved to provide resources to the project. Unfortunately, they are being asked to use these tools. And even with project managers, one characteristic starts coming into play: the behaviors of the individual start to change to accommodate the tool. This characteristic always becomes a problem. Extreme adversity towards changing behaviors will result in the tool not being used at all. Modest adversity often leads to not using it to its fullest capabilities or incorrectly. Though the initial focus is on a project management tool, the same characteristic can be found inside a project. Many projects claim to fail because of lack of teamwork, communication, and understanding. Though these reasons are valid, the more likely source of failed projects is forced behavior changes. When an individual or group is forced to behave contrary to their nature or experience, resistance starts to appear. If the resistance is coming from one or two individuals on a project because they are new to project management, concerns with project failure will not come up, though a risk may be present. But when the behaviors of 130

Project Management

the entire team are being asked to change, the probability of failure increases. An easy solution to this problem is readily available: encouraged participation in every aspect of the project and the project management tool. The philosophy behind this solution is “open sourcing” the project or tool. How is this done? Starting with the project, it means making the project plan a truly living project. In many project management situations, the individual contributions to the project plan are made and compiled by the project manager. The organization of the project plan is completed by the project manager and reviewed with the project team during a meeting when the plan is distributed. Collaboration is controlled and input to the plan before, during, and after is often filtered. This is the traditional method of project planning. However, what if the project plan is located in a central location that everyone updates. As people update, feedback is provided on specific entries detailing requirements, dependencies, risks, or questions. The critical components of the plan are quickly identified and agreed upon by the team. The organization of the plan may be directed by the project manager, but everyone has a say in its construction. And when the plan is complete, the collaboration continues with change controls in place. Eventually, the project plan will be complete and have a richer quality to them than typically available through traditional means. And the trend of open sources has shown that the work is done in far less time than the

131

Project Management

traditional method because the collaborative component has improved. The same method can be applied to the project management tool. By allowing users to input their needs into the project management tool, eventually a tool is available for use by all users, not just project managers. The core of the tool or the project does not change, just the behavior changes to match that of the project management team. Such changes to behavior characteristics within an application required extensive budgets to build and maintain customized applications, some of which were never fully used by the users. In the cloud, the application is developed as it’s being used as and at a far less investment than traditionally required. The underlining theme behind open sourcing is collaboration at any time for anything. The theme continues during project execution. Traditionally, when a problem arises during the performance of an activity, the performing party notifies the project manager and the two may attempt to find a resolution. Other team members may get involved at the request of the performing party or the project manager, but the group looking at the problem is still restricted. In a collaborative environment, everyone has the opportunity to be involved. In most cases, the problem will be resolved faster with a better, more creative solution and in project management; the risks involved are minimized to the greatest extent. Some people may claim that the old adage “too many cooks in the kitchen...” but the truth is, in 132

Project Management

the largest, most prestigious kitchens of the world, there are always more than one cook.

12.6 Treating the Project as Parts, not the Whole (Reuse) With mashups, different components could be used to create a user interface. The constructs of these components had to be designed and developed, but once done could be used by anyone. Variables set in the components could be changed by the user to allow for further focus on the information retrieved. With blogs and other RSS feeds, users can identify the parts of the project that they want to be regularly informed. The number of feeds available may reach the hundreds, but the user only wants one or two that suits their needs. The concept of reusing predefined components is prevalent in web design and cloud computing. It provides the development of a particular product to be completed much quicker, at far less cost, and fewer risks. Especially for organizations that perform projects of a similar nature repeatedly, such as building a house, or application, or a prototype, the concept of reusing project plans is an attractive notion. PMBOK even encourages the use of historical information and templates to create the necessary documentation on a project. But every project is unique, so some care has to be made to ensure that adoption of historical information is not made blindly. This 133

Project Management

does not mean that reuse capabilities cannot be encouraged. Separating a project into its core deliverables, a project can be split into components. Each component will have its basic relationships, requirements, dependencies, and risks defined. These interactions will exist internally to the components as well as the external interactions identified. By having multiple components available, a project team can identify the components that are required for the project and add it. Changes to the component for a specific project can be noted and used as historical data for the next project without changing the core component. Thinking of the project as a product, the ability to reuse components provides a cheaper, quicker product to market than recreation from scratch. By breaking projects down into reusable components, the technique is now more scalable, flexible, and reliable than traditional methods. How does cloud computing support this endeavor. By using links, entire components can be added to a project plan with the click of a mouse. In minutes, the majority of a project can be created with all the relationships and pertinent information intact. At this time, cloud computing solutions allow business applications to be built in a matter of minutes using components already available. The concept is the same, using the project as the basis for the application. Referring to the relationships is not restricted to the relationships between information, and also the processes of project management. The different 134

Project Management

components can include the various tools used by project management, like a change control system, or risk response system, or project monitoring systems, or performance reporting. Normally these systems are not interrelated. In web applications, the business logic can stay where it exists, however the presentation layer can show information, workflow, and indicators to be used actively by the project team and stakeholders.

12.7 Testing the Limits (Portability) Portability is a great advantage to any endeavor. Using the web as the basis for building, monitoring, and executing a project, portability is automatically provided. Using a browser and a connection to the Internet, a user can access a project from any location in the world, at any time. In many situations, the performing party is executing on the project several tasks defined by the project at any given times. Many tasks, especially in manufacturing and construction, require not being readily accessible to the project plan to update the situation. So the performing party waits to the end of the day to update the project plan and any related materials. This is particularly valid when the software used to update the project plan is sitting on the computer at the office. However if the performing party had a hand held device able to connect to the Internet like a phone, they could make an update to the project plan on the spot.

135

Project Management

The concept of portability is a simple one. More importantly are the benefits that appear by using a web-based project management. Many project management programs are very expensive and providing a license to every member of a project management team may not be a cost effective solution. Many project managers have filled the gap by taking status updates from member s and updating the plan themselves. However, everyone typically has access to a browser allowing them to update the plan as members of the project team. This potentially reduces the administrative work performed by the project manager while also significantly reducing the cost of licensing of the tools. In cloud computing solutions, the usage is typically monitored and charged, so a company may have several full time project members with a couple of dozen part time members. Traditionally, everyone had one full license despite the usage. With a cloud solution, the usage of the members can be added up and charged. So inactive members would not prove to be an additional cost to license for the company.

136

Project Management

13 The Perspectives of Project Management When looking at project management, many perspectives can be taken. The first sets of perspectives are those by the participants of the project. Each role on the project has a different perspective, or interest in the project. Executive management is often interested solely in the success or failure of the project and how the project impacts the strategy of the company. They tend to focus on details related scope and risk with a broad overview of other areas. Stakeholders tend to look at the impact o f the project on the operations of the company. Their focus is on status on the budget, the schedule, and the resources of the project. The supplies and contractors are looking for what needs to be done and when. Project team members focused on the deliverables and what they need to do make it happen. The project manager has concerns in every area, but their focus tends to stay within the boundaries of control and communication. In the same way that roles can provide different perspectives found on a project, the individual assignments of a person can also control perspective. Just looking at executive management for instance, the CEO may be interested in overall success of the project while the CFO focuses their interest on the financial success and the CIO is focused on the success of the schedule. Especially on 137

Project Management

large projects, a single individual may be immediately concerned with a single aspect of the project based on their participation. Acknowledging the different perspectives is imperative to successful negotiating the way a project will work. Making an attempt to understand the requirements from these perspectives provide useful information for determining the methods used to run a project. Meeting the needs of all these perspectives will be a difficult undertaking and highly discouraged. However, there are three general perspectives that may be useful in identifying or building a project management tool: • Project management as information • Project management as workflow • Project management as people

13.1 A Project as Information Creating a project requires the collection, organization, generation, and distribution of a tremendous amount of information. Historical data is used to assist decision making along with analysis of other sets of information. The scope of the project is typically a compilation of inputs from several sources to define, expand, or constrict accordingly. The work breakdown structure, activities, cost and schedule estimates are all used to build a proper project plan. With all this data come the constraints,

138

Project Management

assumptions, risks, regulatory requirements that can be applied to individual items on the project plan. A project generates a lot of information, one of the greatest feats for a project is organization that information in such a way that any particular piece of information is readily found and available. Many of the tools used to house the data may not only be in separate locations but be under separate rules for identifying and organization. One financial tool may focus on account codes as the basis for querying, while the change control system is using a unique identifier. How the two tools are connected typically requires a change in one of the tools. In a web solution, the connection is made outside of the two tools and displaying the information from both in a single page. T The key is through vitalizing the organization of the information. From a web application perspective, it does not matter where or how the information is stored or managed. Through virtualization, an entire filing system can be created to retrieve information. Because of its digital nature, the information does not need to be physically moved to be in the filing system, as the system makes a note of where it is located. When a person retrieves the information, the system simple goes to the location of the information and pulls it for view. In addition, a web form could be filled out by a user and several databases could be updated using the information provided.

139

Project Management

13.2 A Project as Workflow A project is a series of processes that are used and reused. The high level flow of work is initiate, plan, execute, control, and close which describes the phases and the work done inside the phases. Particularly during the execute and control phases, any number of processes may be initiated, for instance risk management. Specifically, an activity identifies a potential risk during its execution. The risk needs to be evaluated and quantified. At the same time, a workaround may be performed. Risk management and project execution are working simultaneously. After the risk is quantified, a response is created. The effort handling the risk has just gone through three processes. The response itself has forced a change to the project, requiring the use of the change control processes. At this point, the impact of the risk and its response now has been routed through the appropriate aspects of the project: scope management, cost management, time management, quality management, resource management, and the like. Each of these areas will undertake their processes to determine the impact and change the project appropriately. As the risk response goes through these knowledge areas, some control and monitoring needs to be in effect until the overall change is approved. Once approved, the change is executed and the project continues. The example used above shows the flow of work through nearly half of the 44 processes of PMBOK the actual time it took to execute all these processes could be a couple of 140

Project Management

days a maybe just a few minutes depending on the problem and its impact. Project management is simply a series of workflows to handle different situations. The example above showed the flow through the processes. For each process as a set of roles and responsibilities. Another workflow perspective is the flow of work through roles. Same situation: a risk is found by an executing party, communicated to the project manager and a workaround initiated by the executing party. The project manager with the information available identifies the risk, quantifies, and creates a response, or send the information to an “expert” to do that work. When the work is done, the project manager sends the risk response to the appropriate stakeholders to obtain feedback on impact to cost, schedule, resources, and the like. At the same time, they may notify all the stakeholders of the problem. Once the stakeholders finish their evaluation, the change control system is updated with approvals. The change request is now sent back to the performing a party or another party based on the nature of the response to have the change executed. The execution of the project even has a workflow element rendered by the dependencies of the project activities. Execute one activity which initiates the next, which initiates the next until all the activities are completed. Sometimes, an activity will initiate two or more additional activities. Sometimes multiple activities need to be completed before a particular activity is initiate. Each activity may have a different performing party required to execute. Sometimes 141

Project Management

the performing party may be an individual or a group of individuals. A project is a myriad of possible workflows. Controlling and monitoring the work through the project is one of the primary responsibilities of the project manager and in many cases, having a handling on managing the work through multiple workflows is essential. Web-based project management is one way to identify, manage, and control workflows present on the project. Through connecting multiple systems together as well as predefining interested parties, the initiation of work can provide the necessary updates, record generations, notifications, and triggers to move the work as well as track it.

13.3 A Project as People Despite all the plans, reports, and supporting documentation required by project management, the results are still dependent on people. Though there are a number of tools, techniques, and processes available for identifying what to do and how to do it, the work is still executed by people. Tapping into people is essential for the success of a project. Web-based solutions allow people to tap into the project, each other, and themselves. The same solutions allow for the project to tap into the people. In the end, the experience becomes a richer, more exciting adventure for 142

Project Management

collaboration and excellence. Whatever the methods, the use of a web solution for project management allows for greater productivity, reliability, and greater gains because of the potential growth of the project team and associated stakeholder.

143

Project Management

144

Project Management

14 Summarizing Management

Project

Project management based on PMBOK is a disciplined approach to manage project: temporary endeavors focused on producing a new and unique product of service. The PMBOK identifies 44 processes essential to project management success. The processes are viewed in two ways: as process areas or knowledge areas. Five processes areas acknowledge the life cycle flow of projects from the initial creation of the project; to planning the costs, schedules, resources, and risks of the project; to executing the plan; to controlling that the plan is executed properly and handling any disruptions; to finally closing the project due to completion or failure. The nine knowledge areas focus on the disciplines of project management: project integration, project scope, procurement, communications, project closure, and project management of cost, time, staff, risk, and quality. The processes are iterative requiring their use several times during the project. They are also integrated with relationships found across the entire spectrum. PMBOK makes the complex issues of project management easier. For cloud computing solutions, the use of project management it creating, expanding and changing those solutions provides greater control over the business 145

Project Management

concerns of using these solutions. Luckily, project management is compatible with other standard that may already be in place for any solution providers. For IT infrastructures, PMBOK works well with ITIL. For application development, PMBOK works well with agile methods. While project management can aid web-based solutions, the same solutions can serve to benefit project management. The different technologies and features allow better organization of information, better communication, and greater understanding of the project at any given time.

146

Project Management

15 References Cooper, Lawrence. Implementing ITIL using the PMBOK Guide in Four Repeatable Steps. 2006: Global Knowledge. http://images.globalknowledge.com/wwwimages/whitepaper pdf/WP_Cooper_PM_ITIL.pdf Duncan, William R. A Guide to the Project Management Body or Knowledge. 1996: PMI. http://www.unipi.gr/akad_tmhm/biom_dioik_tech/files/pmbo k.pdf Wojcik, Dr. Ronald J. PMBOK Approach Insights for Software Development Projects. Pragmatic! Solutions. http://www.pragmatic-solutions.com/attachments/2006WhitePaper-PMBOK.pdf Gammon, Peter. PMBOK – Making it Work. 2006: Contact to ContRact. http://www.promsg.bcs.org/histevents/pdfs/psg0503%20-%20PMBOK.pdf McVearry, Kenneth A. What is the PMBOK and What Can It Do For Me? Osmose Utilities Services. http://www.gisdevelopment.net/proceedings/gita/2005/pape rs/43.pdf Johnson, Matt. Fostering a Good Project Environment through Your Project's Culture and Communications – Its 147

Project Management

Critical Components for Success. http://pmiwic.org/presentations/Your%20Project's%20Cultur e%20and%20CommunicationsIts%20Critical%20Components%20for%20Success_r2.pdf Budiman, Linda. Complimentary Relationship Between ITIL and PMBOK. CSC. http://www.pmiwdc.org/files/presentations/presentation2008 08Chantilly.pdf Cooper, Lawrence. ITIL V3 and the PMBOK – Distinct but Complementary. 2008: Global Knowledge. http://images.globalknowledge.com/wwwimages/whitepaper pdf/WP_Cooper_ITILV3PMBOK_Q21.pdf Blend Approach of IT Service Management and PMBOK for Application Support Project. http://hosteddocs.ittoolbox.com/GT120505.pdf Koch, Alan S. Are Agile Methods Compatible with the PMBOK? January 6, 2004: Pittsburgh Project Management Institute. http://www.pittsburghpmi.org/documents/meetings/presenta tions/AgileManifesto-PMBOK.pdf Udo, Nathalie and Koppensteiner, Sonja. Will Agile Development Change The Way We Manage Software Projects? 2003: Projectway, LLC. http://www.assistpoint.com/paper_agilevspmbok.pdf

148

Project Management

Agile Processes. http://www.objectmentor.com/resources/articles/agileProces s.pdf ccpace. Agile Project Management. http://www.ccpace.com/Resources/documents/AgileProject Management.pdf

Siegeluab, Jay M. How PRINCE2 Can Complement PMBOK and Your PMP. January 8, 2004: PMI/Westchester Chapter. http://www.pmiwestchester.org/downloads/Prince2PMBOK. pdf Wideman, R, Max. Comparing PRINCE2 with PMBoK. 2002: AEW Services. http://www.maxwideman.com/papers/comparing/comparing. pdf Wikipedia. Project Management Institute (PMI). http://en.wikipedia.org/wiki/Project_Management_Institute Wikipedia. Project Management Professional. http://en.wikipedia.org/wiki/Project_Management_Professio nal

149

Project Management

INDEX* A acceptance 56-8, 105 activities next 65-6 non-project 65 activity definition 38, 61, 63 activity duration 30, 38, 61-2, 68-70 activity duration estimates 70-2, 78, 104 activity list 63-5, 68-9, 71 activity sequencing 30, 38, 61-2, 67 ADM (arrow diagramming method) 67 agendas 58 Agile Project Management 149 agreement 19, 21, 34-5, 52 American National Standards Institute (ANSI) 13 analysis benefit/cost 53, 82 earned value 97 mathematical 72-3, 85 trend 86, 97 ANSI (American National Standards Institute) 13 application 16, 121, 123-4, 129, 132-4 application areas 39-40, 57, 63, 65, 67, 102, 115 Applying Cost 4, 77 approach, disciplined 8, 11, 145 arrow diagramming method (ADM) 67 assessment 42, 78 assets 119 assignments 88-90, 137 assumptions 43-5, 47, 52, 54, 62, 64, 69-71, 108 authorizations 46 B bar charts 73 blogging 4, 126-7 blogs 126-7, 133 board 7 browser 123, 135-6 budget 10, 33, 38, 41, 44-5, 58, 74, 79-80, 86-7, 97-9, 101, 106, 128, 132, 137 budget cost 98 building 67, 71, 87, 94, 105, 109, 125, 133, 135, 138

150

Project Management

business 7, 9, 11, 16-17, 19, 22, 24, 26-7, 41, 43, 49-52, 58, 75, 93, 97, 109 [2] business decision 78, 109 business logic 123, 135 business managers 16, 34, 90-1 business operations 17, 41 business work 89 business world 87, 117 C calendars 71 capabilities 69, 73, 92, 110, 123 power 63 CAPM (Certified Associate in Project Management) 15 Certified Associate in Project Management (CAPM) 15 certified PMP training 16 certified project management training 16 change control 10, 33, 37, 43, 48-50, 131 change control process 49, 98, 113, 140 change control system 48-9, 60, 74, 80, 135, 139, 141 change requests 47-9, 59, 129, 141 changes, potential 59-60 chute 103 class 66-7 Closing a Project 117 closure, administrative 34, 39, 94, 98-9, 113 cloud computing 4, 121, 123, 133 benefits of 121 cloud computing solutions 134, 136, 145 collaboration 131-2 commitment 24-5, 27, 70 common work period 68 communication, scheduled 95 communication plan 96, 98 communication skills, effective 94, 96 companies 2, 7, 9-11, 15-16, 19, 26, 44, 51, 71, 75, 77, 89-90, 923, 104, 112, 136-7 companies work 8 Comparing Project 117 completion 55-6, 98, 113, 145 compliance 22, 34, 84, 88 components 12, 29, 52-4, 62, 95-6, 118, 123-4, 129, 131, 133-4 Computing to Project Management 121 concept 14, 50, 81, 122, 133-4, 136

151

Project Management

Concluding Project 115 connections 4, 96, 98, 123-5, 135, 139 constraints 40, 43-5, 47, 50, 52, 54, 62, 64, 69, 71-3, 89-90, 108, 130, 138 resource 73 construction 13, 39, 123, 131, 135 contingency plans 105-6 contract 11, 34, 39, 44, 60, 71, 78, 91, 107-10, 112-13 contract administration 39, 107, 112 Contract Close-out 34-5 contractors 69, 113, 125, 137 contractual agreements 89, 106, 109 contributions 91, 94, 127, 131 control changes 34 control charts 85-6 control product scope 60 control workflows 142 Controlling 3, 32-3, 74, 118, 142 controlling change 3, 26, 47-9 Controlling Cost 4, 80 Cooper 147-8 coordination 37, 40 core processes 29, 31, 33-4, 37 core project team 17 corrective actions 46, 49, 60-1, 98 correctness 55, 57, 75 cost 8-9, 27, 33, 38, 45, 55-6, 59-60, 72, 77-80, 85-6, 97, 101, 105-6, 109-10, 136, 145 [10] associated 100 budgeted 97 direct 109 estimated 97 estimating 54, 79 increased 73, 75 indirect 97, 109 likely 79 lower 82, 121 lowest 78 managing 79 measure 75 operational 75 cost baseline 79-80 cost budgeting 38, 75, 79 cost change control system 80

152

Project Management

cost cost cost cost cost

controls 38, 75 estimates 79-80, 97, 104 estimation 75, 78 limitations 46 management 75, 140 Project 38 cost performance index (CPI) 98 cost reserve 79 cost resources 75 cost variance (CV) 98 CPI (cost performance index) 98 CPM (Critical Path Method) 72 crashing 72-3 creation 23, 29, 42, 47, 67, 77, 96, 106, 111 Critical Path Method (CPM) 72 Cultures 20-1 currency, units of 79 customize 129 CV (cost variance) 98 cycles 34, 37, 107 D databases, multiple 124-5 date, forecast project completion 98 decomposition 54-5, 62-3 definitions, operational 83-5 degree 16, 25, 85 deliverables 14, 25, 34, 41, 50, 53-5, 62-3, 74, 82-3, 85, 97, 99, 119, 137 departments 16, 27, 52, 112 electrical engineering 42 dependencies 29, 47, 64-7, 126-7, 131, 134, 141 discretionary 64-5 descriptions 51-2, 56-7, 63, 68, 77, 95, 101-2, 110, 118 designations 2 development 23, 40, 42-4, 53, 105-6, 122, 133 diagrams 67, 83 pareto 85-6 project network 65, 67, 71, 73 time scale network 73 differences 8, 20, 24, 26, 81, 85, 87, 113, 115, 117-19, 125 Directing a Project 117 direction 17, 21, 58-9 disciplines 8, 12, 37, 39, 118

153

Project Management

disciplines of project management 13, 15, 17, 37, 39, 82, 115, 145 document project assumptions 43 duration 68-71, 74 E effectiveness, measurement project 43 effort 11, 14, 37, 64, 69, 73-4, 113 aid project management 20 endeavor 29, 99-100, 134-5 entities 2, 42-3, 81 environment 8, 19, 23, 26-7, 29, 59, 121 en.wikipedia.org/wiki/Project 149 equipment 27, 30, 77-8, 105, 107, 109, 112, 128 estimates 9, 29-30, 33, 55, 69-71, 74, 78-9, 102, 104 evaluation criteria 110-11 events 41, 85, 88, 97, 102, 104 execute 17, 24, 46, 107, 112, 140-1 execution 14, 32, 39-40, 44, 46-7, 115, 140-1 expectations 8, 20, 41, 47, 58 experience 4, 40, 68-9, 91, 100, 123, 130, 142 unique non-overlapping professional project management extent 33, 54, 56, 122, 125 External risks 100 F factors 21, 25, 44, 59, 103 finish 65-6, 72, 128 flow 25, 119, 140-1 flowcharting 83, 85-6 forecast project cost 98 forecasting information 86 formal acceptance 31, 56, 58, 98-9 formal PMI, contact hours of 16 format 56, 94-5, 126 framework 40, 117-18 Framing Project 37 FRAMING PROJECT MANAGEMENT 3 G GERT (Graphical Evaluation and Review Technique) Global Knowledge 147-8 goal 7, 42, 52, 62, 78, 81, 83, 86, 100 Good Project Environment 147 goods 39, 105, 107

154

72

16

Project Management

grade 81 Graphical Evaluation and Review Technique (GERT) 72 group 15, 20, 23-5, 32, 85, 88, 92, 108, 130, 132, 142 grouping 3, 23, 25 guidance 17 guide 13, 42, 46, 54, 147 guide project execution 43 H High School 15-16 historical information 43, 54, 62, 69, 77-9, 101, 115, 122, 125, 133 hours 16, 61, 68 human resources 30, 34, 87, 89-90 hyperlinks 4, 123-4, 127 I identifier 56 IFBs (Invitation for Bid) 110 impacting project costs 128 implementation 10, 94, 119-20 improvements 8, 51, 58, 83-4, 93, 98 individuals 15, 17, 19, 27, 32, 58, 70, 87-8, 91-2, 104, 115, 123, 130, 142 information 2, 5, 13, 21, 25, 27, 29-34, 38, 41, 43, 45, 93-7, 1249, 133-5, 138-9, 141 [7] accessing 95 compiling 126 disseminate 34 distribute 97 financial 78 performance 33 pertinent 134 post 126 project progress 47 retrieve 139 right 96 sending 96 sharing 96 statistical 43 storing 95 supplier 125 transfer 95 information aiding 51 information distribution 94, 96, 122

155

Project Management

information distribution system 96 information retrieval system 96 inspection 57-8, 67, 85 insurance 106 Integration Management, Project 37 Integration Product 3, 40 intentions 2, 40, 82, 87, 111 interact 40, 103 interfaces 88-9, 112, 123, 129 Internet 123, 135 Invitation for Bid (IFBs) 110 items 14, 49, 55-6, 63, 86, 88, 99-100, 110-12, 127-8, 139 defined work 63 ITIL 146, 148 J job position

124

K knowledge 8-9, 13, 17, 37, 39-40, 44, 46, 73, 89, 92, 119, 147 knowledge areas 37-40, 48, 54, 61, 74, 87, 107, 118, 140, 145 L Lawrence 147-8 liability 2 license 136 life cycle 25, 37, 61, 117 lifecycle 23 limited resources 58, 61 links 93, 124, 127, 129, 134 list 53, 63-4, 101-2, 111, 126, 129 location 65, 121, 125, 128, 131, 135, 139 logical relationships 66-7 loss 2, 100, 102, 104 M magnitude 60, 102 management 9, 16, 37, 39, 81, 112, 115, 145, 149 configuration 48-9, 119 executive 17, 137 Project Communications 38 management cost 74 manager, young 7 managers, professional project 15

156

Project Management

Managing Stage Boundaries 118 mashups 4, 128-9, 133 meeting 7, 111, 128, 131, 138 meeting project objectives 46 members 11, 15, 19, 42, 89, 92, 136 time project 136 methods, traditional 131-2, 134 minutes 68-9, 126, 134, 141 misinformation 47 mitigation 105 model 79 modules 66-7 monetary value, expected 104-6 money 11, 33, 43-4, 98, 104 monitor contractor cost 113 monitor cost performance 80 monitor project results 34 Most project management scheduling programs 69 Most project management software packages 65 Most project management solutions 124 N network logic 72 sequential 72 O operational state 41 operations 8, 11, 17, 19, 39, 41, 109, 137 organization 3, 7, 16, 19-22, 27, 39, 43, 77, 82, 104, 111, 115, 119, 131, 133, 138-9 [1] performing 19, 39-40, 78, 82, 88-9, 91, 94, 107-9, 125 organizational planning 30, 38, 87-9 P pages, single 124, 139 parties 21, 49, 52, 96, 123, 126, 141-2 executing 141 performing 132, 135, 141-2 payments 109 pdf 147-9 PDM 65, 67 performance 39, 54, 59-61, 80, 93-4, 97, 100, 113, 132, 135 permalinks 127 person 2, 12, 15, 68-70, 87, 91, 93, 96-7, 103, 121, 124, 127-8,

157

Project Management

137, 139 right 91 perspectives 62-3, 66, 115, 124, 137-8 workflow 141 Perspectives of Project Management 137 PERSPECTIVES of PROJECT MANAGEMENT 5 PERT (Program Evaluation and Review Technique) 72 phases 25, 27, 29, 37, 55-6, 58, 81, 92, 99, 117, 140 project of 24, 52 Pittsburgh Project Management Institute 148 planning 3, 29, 32-3, 39, 41, 49, 52, 77, 82, 100, 108, 118, 145 planning phase 25, 29, 31, 45 planning processes 42-3, 60, 101 PMBOK 3, 13, 16, 23-4, 44, 80, 99, 115, 117-19, 133, 140, 145-9 PMBOK Approach Insights for Software Development Projects 147 PMBOK Guide 13, 147 PMBOK Guide breaks project management 13 PMBOK quality management 80 PMI (Project Management Institute) 13, 15, 147, 149 PMIS (Project Management Information System) 44, 47, 49 PMP (Project Management Professional) 15-16, 149 policies, organizational 43, 46 portability 5, 122-3, 135-6 potential risk events 101-4 power 63 preassignment 91 price 110-11 fixed 109 pricing 78, 110, 112 PRINCE2 117-19, 149 probability 71-2, 85, 101-2, 104-6, 131 problem 10, 32, 50, 69, 83, 86, 130-2, 141 process group 24-5, 31, 33 processes, facilitating 29-31, 37 procure 31, 108-9 procurement 91, 105, 108-11, 145 procurement documents 110 procurement items 110-12 procurement management 119 Project 39 procurement planning 39, 107-9 product 2, 7-9, 17, 19, 22-4, 41-2, 46, 51-3, 57-9, 74-5, 80-6, 99101, 108-9, 112-13, 118-19, 133-4 [5] expected 51

158

Project Management

interim 59 quicker 134 unique 145 well-defined 109 product names 2 product-oriented processes 24 product scope 48 product verification 113 productivity 82, 123, 143 Program Evaluation and Review Technique (PERT) 72 project application 77 breaking 134 complex 92 construction 65, 109 engineering 40, 75 failed 10, 130 large 63, 79, 92, 112, 138 living 131 lower risk 15 managing 11, 15, 39 multiple 20 quality management disciplines complement PMBOK 81 selecting 51 specialized 13 support 89 way 13 project activities 41, 65, 71-2, 77, 126, 141 completing 75 project alternatives 53 Project-based organizations 20 project boards 119 project budget 34 project charter 52 project closure 145 project components 41 project constrains 44 project control 42 project cost estimate 78 project cost estimation 78 project cost management 74-5 project costs 75, 97, 105 project cycle 37 project decisions 52

159

Project Management

project deliverables 29, 45-6, 53-4, 61, 98 project details 50 project documents 99 project durations 72-3 project elements 40, 55, 62 project execution 42, 46, 113, 132, 140 project failures 9-10, 130 project information 43 project initiation 52 project integration 145 Project Integration Management 40 project interfaces 88-9 project level 117 project life cycle 24-5 project management 3-23, 25-33, 35-57, 59-67, 69-71, 73-80, 825, 87-93, 95-100, 102-4, 106, 108-9, 114-24, 126-8, 130-8, 140-7 [1] benefit 146 certified 26 understanding 27 web-based 136, 142 138 project management accreditation 11 Project Management Agile Processes 149 project management aid 101 project management application areas 58 project management approach 68, 112 project management assumptions 139 Project Management Body 147 Project Management Book of Knowledge 13 project management collaboration 143 Project Management Copyright 2 Project Management Critical Components for Success 148 project management days 141 Project Management Deming 81 project management distribution 39 project management engine 129 Project Management Facilitating processes 34 PROJECT MANAGEMENT FRAMEWORKS 4, 117 project management information 86 Project Management Information System (PMIS) 44, 47, 49 Project Management Information System, adopted 44 project management information systems 47, 49 Project Management Institute, see PMI

160

Project Management

project management interact 40 project management item 110 project management model 93 project management opportunity 105 project management perspective 100 project management processes 3, 24-5, 29, 108, 112, 117 Project Management Professional (PMP) 15-16, 149 project management programs 120, 136 Project Management Project communication management 94 project management relationships 125 project management requirements 113 Project Management Risk response control executes 107 Project Management Scheduling 72 project management situations 131 project management software packages 66, 73 project management solutions 122 project management success 24, 145 Project Management TABLE of CONTENTS 3 project management team 16, 89, 132, 136 project management tool 130-2, 138 Project Management Using 129 Project Management.pdf 149 project managers 3-4, 11, 13, 15-17, 19-22, 25, 32, 40, 42-3, 467, 70-1, 90-1, 128, 130-2, 136-7, 141-2 [8] project member 101 project methodology 117 project monitoring systems 135 project objectives 25, 64 project organization 105, 108 project outcomes 31 project performance 31-2, 60 project perspective 49, 63, 101 project phases 25, 34, 37, 52, 98 project plan 3, 38, 40-50, 54, 57, 61-2, 91-2, 97, 111, 127, 129, 131, 134-5, 138-9 final 42, 46 project plan development 37 project plan execution 37 project plan execution process 46 project planners 33 project planning 10, 29, 33, 44, 131 project practices 83 project processes 41 project processes focus 23

161

Project Management

Project Quality Assurance 84 project quality management 80-1 project requirements 90-1 project resources 94 project results 56, 84-5, 98 project risk 101 project risk management 99-100 project roles 30, 89 assigning 88 project schedule 30, 34, 72-4, 80 project scope 3, 31, 34, 48, 50, 56, 145 changing 72 project scope definition 54, 89 project scope management 38, 81 project scope planning 52 project staff 91-2 project staffing, expected 95 project stakeholders 32 project success 95, 99 project tasks 16, 24 project team 17, 19-20, 31-2, 47-8, 61, 63-5, 68-71, 74, 77-8, 812, 84-7, 89-91, 99-101, 104, 111-12, 134-6 [11] project team meeting 126 project team members 47, 50, 69, 77, 90, 126, 128, 137 project team uses 78 project time management 61 project timelines 10 project value 97 project variances 49 project work 57, 94 assigned 42 bulk of 29, 31 projects activities 67 projects claim 130 Project's Culture and Communications 147 project's existence 52 project's performance 32 projects stem, effective 26 Projectway 148 publisher 2 Q quality 4, 8, 48, 59-60, 75, 81-4, 87, 101, 118, 122, 131, 145 quality control 38, 57, 84-6, 113

162

Project Management

quality control process 83, 85 quality management 42, 44, 75, 80, 82, 118, 140 Project 38 quality management activities 82 quality management plan 84-5 Quality Management System 119 quality planning 38, 82-3 quality policy 82 quality standards, relevant 30, 32, 81, 84 R RAM (Responsibility Assignment Matrix) 89 Really Simple Syndication, see RSS relationships 32, 65-6, 87-90, 124-5, 129, 134, 145 reporting 88, 92 reliability 103, 121-2, 143 Request for Proposal (RFP) 110 Request for Quotation (RFQ) 110 resistance 130 resource cost 30 resource estimates 56 resource leveling 73 resource limitations 72 resource management human 87, 119 Project Human 38 resource planning 38, 75, 77 resource pool descriptions 71, 77 resource requirements 30, 71, 74, 77-8 resources 4, 8, 14, 17, 24, 27, 30, 33-4, 41, 44, 54, 58, 60, 77-80, 94, 99-100 [9] responses 21, 31, 45, 103, 105-7, 126, 140-1 responsibilities 21, 30, 43, 54, 88-9, 102, 119, 141 Responsibility Assignment Matrix (RAM) 89 reusing project plans 133 review, formal 48 rework 73, 82, 86 RFP (Request for Proposal) 110 RFQ (Request for Quotation) 110 risk events 102-4, 106-7 risk identification 39, 100, 107 risk management 100, 119, 140 Project 39 risk management plan 106-7

163

Project Management

risk quantification 39, 100, 103-4 risk quantification process 104-5 risk responses 106, 125, 129, 140-1 risk symptoms 101, 103 risks 4, 17, 29, 31, 34, 39, 44, 47-8, 50, 99-107, 109, 122-3, 125, 130-4, 139-41, 145 [3] covered 106 handling 106 high 104 increased 73 low 104 potential 83, 101, 140 required staff Key 45 sources of 101-4 understanding 100 risks event 102 roof 64 RSS (Really Simple Syndication) 127, 133 RSS technology 127 S sampling, statistical 85-6 schedule 3, 14, 24-5, 33, 48, 62, 69, 71-4, 86-7, 95, 97-8, 100, 103, 106, 128, 137 [4] preliminary 73 schedule change control system 74 schedule control 38, 61, 74 schedule development 38, 61-2 schedule estimates 138 schedule performance 85-6 schedule performance index (SPI) 98 schedule variance (SV) 98 scheduling 3, 65, 71-2, 86 scope 8, 10, 29, 34-5, 38, 41-2, 44-5, 48, 50-6, 58-60, 62, 74, 80, 87, 100-1, 137-8 [2] changing 59-60 project's 59 scope change control 38, 59 scope change control system 60 scope changes 59-60 scope management 74, 140 scope management plan 59-60 Scope Management Time Management Cost Management 118 scope planning 38

164

Project Management

scope statement 29, 52-4, 56-7, 62, 77, 82, 108 scope verification 38, 56-7 scope verification process 56-8 sellers 2, 32, 110-12 prospective 110-11 sequence 65, 68 Service Management and PMBOK for Application Support Project 148 services 2, 7-8, 17, 22-3, 39, 46, 51-3, 78, 80, 105, 107-10, 11213, 145 new 7-8 product of 78 simulation 70, 73, 104 skills 8-10, 17, 21, 32, 42, 44, 46, 89, 92-3, 96, 108 Software Development Projects 65 software package 66-7 Software Projects 148 solicitation planning 39, 107-8 solutions 121-2, 125, 131, 142, 145-7 web-based 142, 146 sources 84, 102, 107, 124, 128-9, 138 multiple 112, 129 sourcing, open 131-2 SPI (schedule performance index) 98 staff 90-1, 102, 145 stakeholders 9, 15, 19-22, 27, 30, 34, 42-4, 48, 56-8, 75, 81-2, 945, 101-4, 122, 126-8, 141 [8] standards 13, 22, 45, 80-1 start 7, 62, 64, 66, 71, 73, 82-3, 128, 130 Starting up a Project 117 statement, project management Scope 45 structure 88, 90, 95 organizational 88-9 subnets 67 Successful project management 19 Summarizing Project 145 supplier 113, 125 SV (schedule variance) 98 systems 20, 47-9, 53, 59-60, 74, 83, 92-3, 96, 98, 135, 139 T tap 142 tasks 14-15, 17, 24, 42, 47, 55, 135 team 14, 17, 22, 40, 78, 80, 87-8, 91-3, 101, 131

165

Project Management

team development 38, 87, 92-3 matrix organizations 91 team development service 91 team members 46-7, 70, 91-2, 132 teamwork 130 technologies 50, 64, 95, 105, 122, 127, 146 new 59, 95, 101, 103-4 templates 54, 63, 67, 89, 115, 133 network 67 tepaper pdf/WP 147-8 theme 132 threats 31, 101, 103, 105, 128 time management 62, 140 Project 38 tolerances 104 tools 8, 20, 23, 44, 49, 52, 60, 62, 70, 74-5, 85, 96-7, 101, 130-2, 135-6, 139 [1] Total Quality Management (TQM) 81 TQM (Total Quality Management) 81 track 33, 142 trademarks 2 U unit price contracts 109 updates 25, 47, 49, 67-8, 74, 131, 135-6, 142 usage 136 users 122, 124, 127, 129, 132-3, 135, 139 uses project characteristics 79 V variances

32-3, 49, 60-1

W walls 9, 64 WBS (Work Breakdown Structure) 14, 45, 54-7, 59-60, 62-3, 68, 74, 77-8, 80, 101, 138 web 7, 122-4, 126, 135 web applications 121-4, 129, 135 web page 126-7 Wikipedia 149 work 7-8, 14, 20-1, 24, 34, 37-8, 46-8, 50-1, 62-3, 68-70, 74-5, 84-5, 97-8, 109-10, 112-13, 140-2 [15] work authorization system 46 work breakdown structure 14, 54, 74, 138

166

Project Management

complete 55 objectives 45 Work Breakdown Structure, see WBS work element 56 work packages 56 workarounds 107, 140-1 workflow element 141 workflows 5, 135, 138, 140-2 multiple 142 workforce 17, 26 workplace 11, 22

167