Read Aloud the Text Content

This audio was created by Woord's Text to Speech service by content creators from all around the world.

Text Content or SSML code:

As you can see, this is quite a list. This text simply can’t cover the entire project management plan in one chapter, so the contents of the plan are developed throughout the next several chapters. Even though this is quite a long list, it doesn’t necessarily take a long time to develop each piece of the plan. Organizations that are successful at project management have examples and templates already set up for each deliverable. A project manager should be able to start with the default cost management plan or a plan from a prior project and just customize it for the current project. Organizations and project managers who use standard processes and templates have a significant advantage in terms of cost, time, and accuracy over those who create a new plan from scratch for each and every project. Many organizations not only have documented templates for each part of the plan but also may have slightly different standard formats, based on different project characteristics, such as size, complexity, length, and risk level. For example, a small, lowrisk project would have a shorter and less formal project planning document than a large, complex project with members of the project team spread out all over the world. In addition, many organizations base their plans on a published methodology such as PMI’s PMBOK or IEEEEIA 12207 and then customize it to fit their culture andor industry segment. To find more information on these methodologies and others, see the reading list at the end of the chapter. Project teams make their most expensive in terms of both time and money mistakes during the planning phase of a project. A project team may do little or no planning, or it may plan incorrectly. By definition, a project is unique and has never been done before, so planning is crucial. McConnell 1998 states that errors found “upstream” during the planning phase cost on the order of 200 times less to fix than errors found “downstream,” during the building of the product. Therefore, more time spent upstream reduces the number of costly mistakes later on, reducing the overall cost of the project. Cleland and Ireland write that “the most important responsibility of the project team is to develop the project plan in consort with other supportive stakeholders” 2002, p. 309. Decisions made during the initiation and planning phases of a project set the direction as well as the boundaries within which the project is executed. Planning is not an easy part of the project manage 134 Part 2 • Project Initiation and Planning Methods ment process. Few people have the ability to see into the future and plan for the unexpected. Some refer to it as an art more than a science. Although planning is crucial, project teams must be careful to avoid overplanning the planning must be appropriate to the size, complexity, and risk of the project. Project managers must be careful to avoid what many systems analysis text books refer to as “analysis paralysis”—getting stuck in the analysis phase, trying to get everything defined perfectly. Planning requires time, resources, and cost, so care must be taken to do it correctly. Because we can’t see far into the future, planning must be done as a progressive elaboration process, with each iterative cycle becoming more accurate and more complete. T. Capers Jones summed it up this way “The seeds of major software disasters are usually sown in the first three months of commencing the software project. Hasty scheduling, irrational commitments, unprofessional estimating techniques, carelessness of the project management function are the factors that tend to introduce terminal problems” 1998, p. 120. The authors of this text often tell students and organizations that if we don’t plan anything, then we can never be late or wrong how cool, but then how do we know when we are right or when we are done with a project Inadequate planning is one of the major reasons that many projects never get completed. Kerzner writes “The project manager is the key to successful project planning. It is desirable that the project manager be involved from project conception through execution. Project planning must be systematic, flexible enough to handle unique activities, disciplined through reviews and controls, and capable of accepting multifunctional inputs. Successful project managers realize that project planning is an iterative process and must be performed throughout the life of the project” 2003, p. 378. Remember from the project life cycle presented in Chapter 2 and the iterative approach to running a project that planning isn’t done just once but is a continuous process of adaptation and change. Project planning activities at this point move from the Integration Management knowledge area into the Scope Management knowledge area, which consists of these processes plan scope management, collect requirements, define scope, and create the WBS. Examining the project charter can tell you why you are working on the project, but it doesn’t give you enough detail about the actual work activities needed to deliver the stated objectives. The first step in building the project management plan is to break down the highlevel objectives from the project charter into smaller and smaller requirement pieces, otherwise known as performing systems analysis. PROJECT MANAGEMENT CONCEPTS SCOPE MANAGEMENT PLANNING As discussed in Chapter 1, one of the keys to delivering a successful project is having a complete statement of the product requirements. By building on the objectives listed in the project charter, you can build a more complete scope statement. Before or in conjunction with building the scope statement, the team should document the scope management plan consisting of how the project scope will be defined, validated, and controlled. The building of the scope statement, like other project artifacts, should not be done in isolation. A project manager should involve the project team and stakeholders where appropriate. The project manager must use a process that allows and encourages stakeholder involvement in the definition of the product scope. As depicted in the opening chapter map figure, the key deliverables from scope planning are the requirements Chapter 5 • Project Scope and Resource Planning 135 documents, scope statement, WBS, and the WBS dictionary. Each of these deliverables should be created for every project, regardless of size. A project’s scope comes from many sources. In addition to stakeholders and the other members of the team contributing ideas, other sources of scope may be existing industry standards, organizational culture, or government regulations. For example, in 2002, the U.S. Congress enacted a new set of corporate governance and financial reporting requirements, referred to as the SarbanesOxley Act. This act established, among other items, financial reporting requirements for all publicly traded organizations. Because most financial data exists in one or more computer applications, compliance with the act has required many new IT projects. The act describes what information is to be reported but leaves it up to individual companies to figure out how to produce the information. Another example of project scope being driven by government regulations is the 1996 Health Insurance Portability and Accountability Act HIPAA. HIPAA provides national guidelines on the privacy of electronic health care records. The legislation is broken down into three parts privacy, code sets, and security. The size and depth of the scope statement depends on the following characteristics Cleland, 2002 • Project size, including the number of people, dollar value, duration, and geographic span • Degree of risk to the business • Cash requirements, such as length of time for return on investment and initial cash requirements • Technology utilized for example, maturity, experience of current staff with the technology • Project team experience with technology, business, and industry • Nature of the deliverables, such as whether this is a new product or service, an upgrade, or a repair • Strategic importance of the project to the organization • Project definition for example, whether the requirements are undefined, partially defined, or poorly defined This list helps frame the information project managers include in the scope statement and also helps describe items that won’t be included in the project, which can be just as important as describing what is included. Everyone needs to be very clear on what requirements are included and what requirements are not included. Specifically listing the items not included helps ensure that stakeholders understand the boundaries of the project, improve communications, and aid project managers in managing stakeholder expectations. The scope statement appears within the scope management plan, which is used to describe how the project team will define the project scope, develop the detailed project scope statement, define and develop the WBS, verify the project scope, and control the project scope. So far in the discussion of scope planning, the text has explained how the team begins to define the detailed project scope statement. The next section contains a description of how to build the WBS, and Chapter 12 presents several ways to control project scope using an integrated change control process. One of the key uses for the scope management plan is to prevent scope creep. Remember from Chapter 1 that the main goal of a project is to deliver the successful finished project within scope, time, and cost constraints. It is nearly impossible to meet any of these targets if the scope is continually growing and changing. Scope creep happens for many reasons for example the marketing department 136 Part 2 • Project Initiation and Planning Methods may want to get ahead of the competition, the software developers might want to learn about the latest new tool or technique, or the key stakeholder may have recently read an article about the next great feature and want it added to the application. If scope is defined correctly and the team follows a disciplined change control process, scope creep can be minimized or avoided. Collecting Requirements Scope definition is accomplished by conducting a requirements elicitation and analysis exercise, getting help from subject matter experts SMEs, and using the results of the stakeholder analysis. The assumptions and constraints first identified on the project charter can now be updated and expanded as well. The requirements elicitation and analysis process is done not by the project manager but by skilled business or systems analysts, who have many tools to aid them in their job. It is not the intent in this text to cover the aspects of the business or systems analysis profession we leave that up to the many fine business analysis and systems analysis and design textbooks on the market. But one technique that bears mentioning is called PIECES Wetherbe, 1994, which describes different categories of potential requirements • Performance—Fixing or improving performance, work throughput issues, transactions, or request response times • Information—Fixing or improving all forms of information, including stored data elements, input processes and data, output processes, format, timing, and content • Economics—Fixing or improving a company’s economic situation, with expenses and revenue, new markets, new products, faster product releases, and so on • Control and security—Fixing or improving control and security of all company electronic assets • Efficiency—Fixing or improving resource people, machines, computers, networks productivity and efficiency • Service—Fixing or improving service usability, accuracy, reliability, adaptability, and compatibility The list is not exhaustive but offers a framework to aid the analyst in capturing requirements. Subject matter experts SMEs aid the systems analysts in their quest for an accurate list of requirements, including both project requirements and product requirements. Project requirements may consist of business requirements, communication requirements, levels of status reporting, and so on. Product requirements may consist of technical requirements, security requirements, safety requirements, performance requirements, and so on. See the discussion earlier in this chapter about the PIECES framework. SMEs can be from inside or outside the organization. They are individuals who have intimate knowledge of how the product of the project is supposed to function. They should be consulted throughout the entire project for input into and acceptance of the requirements. Capturing input of SMEs and other interested project stakeholders is done via the stakeholder analysis, using a variety of techniques brainstorming sessions, interviews, focus groups, workshops, questionnaires and surveys, observations, and system prototypes. Chapter 5 • Project Scope and Resource Planning 137 The requirements should be documented using a requirements management system, preferably an electronic system to aid the team in improving communication, traceability, and visibility. The requirements documentation may consist of the following • Functional and nonfunctional system requirements • Business rules • Project requirements • Impacts on any other systems andor departments • Support and training requirements • Specific acceptance criteria for each requirement or set of requirements • Quality requirements The final step in eliciting requirements is to document how requirements will be managed throughout the project. The following questions need to be addressed and then input into the requirements traceability matrix defined next • Who has authority to update the list of requirements • What process will be used to manage the changes to the requirements • How are requirements prioritized In other words, which ones are done first or are done at all • How are requirements traced from discovery to system design to prototype to finished product The requirements traceability matrix RTM is used to document the links between the requirements for the product that is being built and the artifacts developed to implement and verify those requirements see figure 51. These artifacts may include use cases, user stories, design specifications, software components, test plans, and test cases. Tracing requirements assist the project team to understand which parts of the design and software implement the user’s requirements, and which tests are necessary to verify that the user’s requirements have been understood and implemented correctly. A good RTM provides forward and backward traceability. Meaning, a requirement can be traced to a test, and a test can be traced to a requirement. A requirements traceability matrix is created when the requirements are first approved or baselined. It is then updated and reviewed throughout the project’s life cycle whenever new artifacts are produced that are related to the requirements. In addition, changes to the requirements are also tracked in the RTM. This assists the project team in assessing the impact a change may have by tracing the affected requirement to all the artifacts to which it is linked. Work Breakdown Structure When the product and project requirements have been discovered and documented and the scope statement has been created, the next step is to begin building the work breakdown structure WBS, which organizes the total scope of the project. A project is created to do something—to produce an outcome or a deliverable. The WBS exists and is organized around the project deliverables. Haugan 2002 describes what he calls the 100 percent rule The WBS represents 100 percent of the work required to produce the product, and all subtasks must add up to 100 percent of the total scope and shouldn’t go over 100 percent. As soon as you define more than 100 percent of the scope, 138 Part 2 • Project Initiation and Planning Methods you have committed to doing more than you agreed to do, given current resources—and thus scope creep has begun. The WBS is used for many different purposes throughout the project, so it is extremely important to get it as accurate as possible. The following is a list of uses for the WBS • Guide the work of the entire project team • Facilitate communication between all stakeholders and the project team • Aid the team in building the schedule and budget • Assign the right person to the right task • Get the project to a completed state • Aid in quality control • Assign responsibility for each task • Reduce scope creep • Aid in budget and schedule progress reporting and performance reporting • Aid in examining alternative steps in building a product BUILDING THE WBS Many techniques exist for aiding a project team in building a complete and accurate WBS. Many people believe that building an accurate WBS that meets the 100 percent rule is more of an art than a science, and it takes years of experience to become proficient at it. The techniques described next analogy, topdown, bottomup, and the thread method are used by novices and professionals alike to aid in creating a complete WBS. Regardless of the technique used, the WBS is an evolving, dynamic artifact as the project moves forward, the WBS gets more detailed and more accurate. Three of the four techniques analogy, topdown, and the thread method use the concept of decomposition to break down the work into its component parts. The bottomup technique does decomposition in reverse. Regardless of the technique you use, the 100 percent rule exists at every level of the WBS. Each set of tasks created should deliver 100 percent of the work required to create the deliverable. THE ANALOGY TECHNIQUE A WBS is first created by looking for a similar project done in the past and using its WBS as a starting point. The team simply copies the WBS from the previous similar project and changes the name. The team must then begin reviewing the FIGURE 51 Requirements Traceability Matrix Chapter 5 • Project Scope and Resource Planning 139 WBS to make any necessary changes for the new project. IT projects fall into three broad categories new functionality maintenance or conversion of an existing system to a new platform, a new vendor, or a new user interface. Identifying an IT project as one of these three categories can help you find similar projects to use in building a WBS. The analogy technique • Is the fastest path to a completed WBS • Is a valuable tool for brainstorming a new project and looking for deliverables • Enhances crossproject consistency • Improves budget and time estimates • Improves resource allocations The following issues are associated with using the analogy technique • The team needs to ensure that the previous WBS is completely understood and similar. • The team needs to make sure the previous WBS is accurate and updated. • The team needs to critically review the previous WBS and its appropriateness for the new project. THE TOPDOWN TECHNIQUE If a similar project’s WBS doesn’t exist, you must start from scratch. You can use the topdown approach during a brainstorming session, with SMEs, stakeholders, and team members. The team first looks at the list of objectives from the project charter and uses them to determine a highlevel list of deliverables that will be used to build the final product. Each deliverable is then decomposed into smaller and smaller steps needed to create that deliverable. This process continues until all objectives have been decomposed sufficiently see Chapter 6 for more definition on the level of decomposition necessary. The topdown technique • Ensures that a project is organized logically, based on the nature of the project • Promotes stakeholder participation in the planning phase of the project • Can help all participants better understand the entire project The following issues are involved in using the topdown technique • The team needs to ensure that major objectives are not forgotten. • The team needs to decompose the tasks to appropriate levels. • It can be timeconsuming, so it’s important to guard against “analysis paralysis.” • Cost and time estimates are more difficult to create and generally less accurate than with the analogy approach. THE BOTTOMUP TECHNIQUE If a similar project’s WBS doesn’t exist but the team is very familiar with this type of project, you can start from scratch with the bottomup technique. Like the topdown approach, this approach is also generally done during a brainstorming session, with SMEs, stakeholders, and team members. The team first looks at the list of objectives from the project charter and generates a list of lowlevel activities that will be needed to complete the objectives. The team then groups together the tasks by deliverable. This process continues until all relevant tasks have been grouped into subgroups that directly tie to a major objective. Often, multiple levels of subgroups must be created to create a tie between the lowlevel task and the project objectives. The bottomup technique 140 Part 2 • Project Initiation and Planning Methods • Promotes stakeholder participation in the planning phase of the project • Can create a greater understanding of the entire project by all participants • May lead to a more complete list of tasks The following issues are involved in using the bottomup technique • It can be difficult to organize the process into logical steps or phases. • The team needs to ensure that objectives are not forgotten. • It is difficult to retain the focus on the big picture. • It is difficult to generate a complete list of tasks. THE THREAD TECHNIQUE The thread technique is generally used in conjunction with one of the other three techniques. Instead of looking at all of the project’s objectives, the group concentrates on them one at a time generally evaluating the most complex issues or highestpriority objectives first and decomposes it into lower levels of detail or higher levels, if using the bottomup approach. The objectives are evaluated one at a time. The thread technique • Promotes stakeholder participation in the planning phase of the project • Can help all participants better understand the project • Provides greater control and focus in brainstorming sessions • Generally tackles the most important stakeholder objectives first The following issues are involved in using the thread technique • The team needs to be careful not to lose focus of the big picture. • The team needs to be careful not to lose sight of the effect one objective may have on another. • It increases the need for communication. • It is most successful when the project leader and team have a good understanding of the project’s objectives. This list of techniques is not meant to be all encompassing there are many other possibilities. For instance, when working on U.S. government contracts, contractors are generally given a standard format to follow so that each contractor’s piece of the overall project follows the same format. Which technique you use to create the WBS depends on the following • The existence of a similar project—If a similar project exits, you would use the analogy approach. • The experience level of the project manager and team—If the project manager and team have little experience, you’d choose the topdown approach. Conversely, if they have many years of experience, you’d choose the bottomup approach. • The uniqueness of the product or process—If the product or process is unique—that is, has never been done before in this company or by this team—you might choose the topdown approach. WBS Structure A WBS can be structured in different formats, depending on the type and needs of the project. A WBS can be structured around the product functionality or feature list or user Chapter 5 • Project Scope and Resource Planning 141 New company web site Build user interface standards Customer security Product search Product selection add to order Review purchase history Color schemes Menu locations formats Browsers supported Style sheets Navigation schemes Level 1 Partial Level 2 Level 0 FIGURE 52A WBS by Product Subparts story or around process phases. Figures 52A, 52B, and 52C are examples of WBSs. Figure 52A is an example of a WBS structured around the subparts of a web development product, Figure 52B is a WBS structured around the phases of a generic systems development methodology, and Figure 52C is an example of a WBS presented in outline form. Notice in Figure 52C that only one of the Level 1 tasks is decomposed into Level 2 tasks. This is perfectly okay not all legs of the WBS must be decomposed down to the same level. The amount of decomposition depends on the needs of the individual tasks. One PROVEN STRATEGIES AND HINTS TO SUCCESS IN AN AGILE WORLD Successful agilebased projects do utilize a work breakdown structure WBS. In many cases for those who say otherwise, it is a matter of misunderstanding. Remember that the definition of a WBS from PMI is “a deliverableoriented hierarchical decomposition of the work to be executed by the project team.” A WBS is not a schedule or a description of the processes followed to perform the work. In most projects, and especially agilebased projects, the building of the WBS is done in a progressive elaboration fashion. Rarely can the team define the entire contents of the WBS at the beginning of the project. In an agilebased method, the deliverables on the WBS become user stories agile units of work understood inside and outside of the project team. The agile team may create a WBS that looks similar in format to this example Remember that the WBS is a great communication tool for both the project team and the stakeholders to convey total work, work interdependencies, and progress. 142 Part 2 • Project Initiation and Planning Methods may need to be broken down further than others to make sure it delivers one outcome, can be assigned to one person, and can be budgeted for in terms of time and cost. Chapter 6 describes how far you should go in decomposing tasks. The following are some best practices to keep in mind when building the WBS, regardless of technique or format • Each WBS element represents a single deliverable. • The 100 percent rule applies to all levels. • Each deliverable is distinct. • Accountability for each task can be assigned to one team member. • Not all elements of the WBS need to be decomposed to the same depth. • Reporting and control mechanisms need to be included. • The team needs to be prepared for changes. WBS Dictionary During the process of creating a WBS, you should also be building the WBS dictionary. Many organizations refer to these two artifacts as just the WBS. The WBS dictionary is the repository for detailed information about the WBS and consists of the following information New company web site User requirements Analysis Design Construction Deployment Problem statement User interviews Context diagram Highlevel use cases Use case diagram Level 1 Partial Level 2 Level 0 FIGURE 52B WBS by Phase 0 New company web site 1.0 Build user interface standards 1.1 Color schemes 1.2 Menu locationsformats 1.3 Browsers supported 1.4 Style sheets 1.5 Navigation schemes 2.0 Customer security 3.0 Product search 4.0 Product selection–add to order 5.0 Review purchase history FIGURE 52C WBS in Outline Form Chapter 5 • Project Scope and Resource Planning 143 • Control accounts for example, accounting or finance department account codes used in the accounting system to track costs • Statement of workdescribing thedetails ofthe work involvedin creating each ­deliverable • The responsible organization that is, who is responsible for each deliverable • The schedule for major milestones • Contract information, if an outside vendor is involved • Quality requirements • Estimates of costs and resources required When you have the WBS and the WBS dictionary created, the next activity is to find the right human resources to assign to each task, based on budget requirements, time availability, skill sets, motivation, and other criteria. The process of project resource planning is discussed in the next section. PROJECT MANAGEMENT CONCEPTS RESOURCE PLANNING Project resource planning includes the processes required to identify and acquire the resources necessary for successful completion of the project including humans, technology, space, and so forth. These processes are created to ensure that the right resource is available to the team at the right time and place. The planning for physical resources will be covered later in the text. The remainder of this chapter is dedicated to human resource planning. Planning for human resources generally the most difficult and timeconsuming involves identifying and then documenting the project roles that must be staffed for example, database analysts, software developers, systems analysts, SMEs, network engineers, user interface designers, identifying who has what authority for example, to make staffing decisions, budget decisions, scope decisions, and producing the staffing management plan deliverable. This section describes the managerial knowledge and skills that a project manager needs in order to be successful. In Tom DeMarco’s fictional work The Deadline, he tells the story of an experienced project manager who is kidnapped and forced into managing an extremely large IT project. The large IT project experiences nearly every type of major problem imaginable. The story is told in a very humorous way, with just enough reality to make some excellent points about managing IT projects. One of the key statements DeMarco makes is that one of the most difficult tasks a project manager performs is matching project tasks to the appropriate resources. Some individuals love to be challenged and want to take on the hardest tasks. Others just want to come to work, do what they need to do, and then leave—they don’t really like to be pushed and challenged. A project manager needs to figure out what motivates each individual on the team and assign just the right amount and type of work to each person. Unfortunately, just assigning the right task to the right individual might not be enough. A project manager must also understand how to continually motivate and influence members of the team to get work accomplished on time and on budget within quality requirements a major problem is that team members officially report to someone else in the organization for their performance appraisals, which determine their pay rates. Functional managers for example, accounting manager, warehouse supervisor have the luxury of working with the same individuals over greater lengths of time, which allows them to build relationships and get to know each worker in addition, they are responsible for the pay raises of those who work for them. Project managers in a functional organization or a matrix organization 144 Part 2 • Project Initiation and Planning Methods don’t have the luxury of time some team members may be assigned to them for very short periods, making it more difficult to figure out what motivates each team member. The next section of the chapter answers the following questions • Assign the right tasks to the right person • Motivate the team to perform at peak performance, with the highest quality • Obtain the needed power and authority to manage the entire project Human Resource Research Finding ways to motivate workers has been a major concern for managers throughout history. In the early 1900s researchers began exploring and formalizing concepts and theories of human behavior. Many of these original theories are still being studied and expanded upon today. Successful project managers must understand human behavior in order to motivate team members to achieve project objectives. The following sections review the research work of some key individuals in the area of human behavior Abraham Maslow, Douglas McGregor, William Ouchi, and Frederick Herzberg. ABRAHAM MASLOW THE HIERARCHY OF NEEDS Abraham Maslow identified a prioritized hierarchy of needs that motivate workers to do their best work. The levels, from lowest to highest, are physiological needs, safety needs, social needs, esteem needs, and selfactualization needs. The levels are often depicted in a triangle with physiological needs listed on the bottom and selfactualization at the top point. The essence of the hierarchy is that a worker will not be motivated by any higherlevel needs until his or her lowerlevel needs have been satisfied. Once a lowerlevel need is satisfied, a worker will seek satisfaction at the next level. The following are brief definitions of the levels • Physiological—Air, food, water, clothing, shelter, and sleep. • Safety—Economic security, protection from harm and violence, and secure employment. • Social—Love, belonging, togetherness, approval, group inclusion, and friendship. • Esteem—Selfrespect, reputation, recognition, and selfconfidence. • Selfactualization—Need to make the most of unique abilities and to strive to perform maximally. A project manager must understand the needs of all members of the team in order to help them perform at their best. To do this, the project manager must understand where on the hierarchy a team member is currently located. In the IT industry in the United States, workers are generally paid fairly well in comparison to those in other industries, so a worker’s basic physiological needs are probably being met. The next level is safety needs. As a project comes to a close, workers may be nervous about what their next project is going to be and may not be concentrating on the current task. In an organization that has recently done some outsourcing moving jobs outside the organization, workers may be concentrating more on finding ways to keep their job than on performing well on the nearly finished project. Techniques to aid in the project closing process and outsourcing issues are both covered in Chapter 14 of this text. For now, a project manager needs to be aware of the obstacles to team performance and address them to satisfy the safety needs of the team. Chapter 5 • Project Scope and Resource Planning 145 The next level on the hierarchy is social needs. Workers at this level are trying to satisfy their need for a sense of belonging and acceptance by the team. Chapter 10 covers several techniques to aid project managers in improving team interaction. Most workers want to be accepted by their peers, want to form friendships, and need the approval of others. Project managers need to learn to build inclusive teams, which will allow acceptance to occur. Most of the time, these social activities have nothing to do with building the actual product but are necessary to meet the needs of the team members, which should translate into a betterfunctioning team and a higherquality product. Next on the hierarchy is the esteem level. At this level, workers are looking for individual recognition for their efforts from the team and organization. IT workers tend to especially need peer recognition. They strive to be known as experts in their particular fields of expertise. Software developers want to be the first to write tricky bits of code, and network engineers want to solve difficult throughput issues. Recognition can be accomplished in a myriad of ways, many of which are discussed in Chapter 10. For example, one technique that has worked is the use of an old bowling trophy. In one project, the software developers were working in a fourthgeneration language that had a few shortcomings. They were constantly fighting the language to deliver the final product. Each week during status meetings, they would discuss the latest workarounds they had built. As the weeks passed, it became a competition to see who could come up with the best fix. The project manager decided to start recognizing the person who came up with the best, most imaginative solution he used as a prize an old small bowling trophy, with a small piece of paper attached, labeled “best bug fixer.” Each week during the status meeting, the traveling trophy was awarded to the person who had created the most beneficial workaround, and it turned out to be a highly sought recognition. A simple technique had a huge impact on the morale of team members and on project outcomes. The final level on the hierarchy is selfactualization. At this level, workers have managed to satisfy all their lowerlevel needs and they are striving to make themselves better at what they do either at work or outside of work. For team members at this level, the project manager needs to supply a work environment that allows time for training and personal growth. For a project manager, team members at this level are generally the most rewarding to work with. Theory X Worker A Worker B Worker C Theory Y FIGURE 53 Theory X, Theory Y Worker Continuum DOUGLAS MCGREGOR THEORY X AND THEORY Y EMPLOYEES The work of Douglas McGregor can help a project manager understand how to use an appropriate leadership style to approach workers. McGregor placed workers into two distinct categories Theory X and Theory Y. Theory X workers are inherently lazy and require constant direct supervision in order to perform work. Theory X workers dislike work and avoid it whenever possible. To get them to work, a supervisor must use punishment as the motivator. A manager with this type of worker uses an authoritarian approach to decision making. Theory Y workers are the opposite They enjoy work and can be trusted to work efficiently without direct supervision. These workers are motivated by the work itself and need little motivation from their manager. Managers with these workers exercise a participative style of group decision making. 146 Part 2 • Project Initiation and Planning Methods Workers come in many forms, some leaning toward Theory X, some toward Theory Y, and everything in between see Figure 53. A project manager needs to figure out where on this line each team member sits and treat them all appropriately. Making this difficult job even harder, workers change over time and move to different points on the continuum. Just because you have worked with someone before doesn’t mean his or her needs will remain the same. Some individuals work extremely well on their own and need little supervision. They are very responsible and tend to flourish in the right situations. Other workers need daily supervision. They are less organized and need someone to help prioritize their work. This doesn’t mean that one worker does better or more work than the other it just means that one will require more of the manager’s time. The sooner a manager understands each worker and accepts that different individuals require different attention and management styles, the more successful a project manager will be running projects. WILLIAM OUCHI THEORY Z EMPLOYEES William Ouchi added a third dimension or theory of workers Theory Z. Theory Z workers emphasizes a more Japanese culturalbased approach. These workers are more participative and are capable of performing many and varied tasks at different levels of responsibilities. Management techniques with Theory Z workers emphasize things such as job rotation, broadening of skills, generalization versus specialization of skills, and the need for continuous training. FREDERICK HERZBERG MOTIVATION HYGIENE THEORY Frederick Herzberg, whose research was based somewhat on Maslow’s hierarchy of needs, found that the factors causing job satisfaction implying motivation are different from those causing job dissatisfaction. Herzberg combined the three lower levels of Maslow’s hierarchy into one category, called hygiene factors. These hygiene factors include the company, management philosophies, security, status, salary, and interpersonal relations. Herzberg found that these items, if present, don’t motivate employees to perform better, but if they are missing, the employees are dissatisfied with their jobs and are not motivated. The second category involves more of the actual work that people do on the job and falls into the two upper levels of Maslow’s hierarchy—esteem and ­selfactualization. If workers experience these levels, they tend to be more satisfied, happier, and more productive. A key component of Herzberg’s research for managers to realize is that the factors are not simply opposites of each other. For example, a bad salary is definitely a demotivator to most, but a good salary is not necessarily a strong motivator. If the worker dislikes the job, her coworkers, and company policies, salary will not be enough to keep her motivated. Managers must find factors that not only increase worker satisfaction and motivation, but also prevent dissatisfaction. The following lists present such factors Factors leading to Dissatisfaction • Too much supervision • Company policies • Relationship with supervisor • Work conditions • Relationship with peers • Salary Chapter 5 • Project Scope and Resource Planning 147 Factors leading to Satisfaction • Recognition • Work itself • Achievement • Responsibility • Growth in and outside of the job • Advancement Getting to know each member of the team and finding out what motivates each is a difficult task, especially on shortterm projects. But the ability to accomplish this feat separates average project managers from great ones. Some best practices to follow when directing the work of others include • Taking the time to know each individual oneonone • Keepingandcommunicatingapositive attitude abouttheproject,the team, andthe company • Assigning the appropriate level of work to each worker • Communicating often and openly • Making each worker feel appreciated for his or her particular contribution to the project • Making sure each worker has the proper training • Rewarding members of the team fairly and consistently Authority, Influence, and Power Most project managers must run projects with crossfunctional workers who don’t report to them in the official company organizational chart. In this situation, workers on the project have two bosses the project manager and a functional manager. To further complicate the issue, many workers are part of more than one team, giving them yet another voice to listen to. As a result, workers face conflicting priorities and demands. To be successful, in addition to discovering individual worker needs and motivations, project managers must have the needed authority and power to direct the work required to accomplish the goals and objectives of the project. Authority is defined as either legal or acquired authority. In the traditional theory of management, authority is granted from a superior to a subordinate or is legal authority. Legal authority is granted to an individual by virtue of their position in the company or given by a senior member of the management staff. Acquired authority or power is gained from one’s peers, based on the perceived knowledge of the individual, his or her interpersonal skills, or work experience on similar projects. Unfortunately, in many IT projects, project managers are not granted the needed legal authority to be successful and so must become good at acquiring authority. Thamhain and Wilemon identified the following project managerinfluence types 1999 • Expertise—The project team may see the project manager as having superior content knowledge of the business, past project success, and an appreciation of the technology. • Work challenge—The project manager may have some control over who gets assigned what work. • Salary influence—The project manager may have input directly or indirectly into the worker’s salary. 148 Part 2 • Project Initiation and Planning Methods • Friendship—Personal relationships may be established between the project manager and others. • Future work assignments—The project manager may have influence on a worker’s future work assignment. • Promotion—The project manager may have input directly or indirectly on a worker’s future position promotions. • Authority—Superiors may delegate or give power to a project manager. • Fund allocations—The project manager may have influence on how the project budget is spent. • Penalty—The project manager may be able to penalize nonperforming team members. Of these nine influence types, three were found to offer the project manager the best chance for success expertise, work challenge, and salary influence. The influence types least likely to help a project manager succeed are fund allocation, authority, and penalty. The other types fall somewhere in the middle. What this means to project managers is that to obtain higher productivity commitments from workers assigned to their projects, they should strive to influence the team by using their business and technology expertise, assign the right amount of challenging work to the right workers, and try to create an environment in which they have influence on salaries. Many companies have added a section to their yearly salary review process that includes input from project managers on the work an individual performed. Project managers can receive project authority in several ways. It can be delegated to them from senior management, it can be earned from running many prior successful projects, or they may hold a senior position in the company. Because project managers are generally not given a lot of delegated authority, they must learn to use interpersonal influences. Managers may have five interpersonal influence types • Legitimate or formal—These managers receive support because the project team perceives that the project manager has the right to issue directives. • Reward—These managers receive support because the project team perceives that the project manager has the ability to influence financial rewards such as salaries, bonuses, and promotions. • Penalty—These managers receive support because the project team perceives that they have the ability to punish workers by withholding rewards or assigning nonrewarding work. • Expert—These managers receive support because the project team perceives that they have the knowledge and skills needed to be successful. • Referent—These managers receive support because the project team has great faith in their abilities, based on their personal presence. Examples of individuals who held referent power are John F. Kennedy and Martin Luther King, Jr. To sum up this part of the chapter on human resources planning, Stephen Covey, a respected management researcher and author of The 7 Habits of Highly Effective People 1990, offered some great advice for individuals to become better team participants and project leaders. His work was not directed specifically at project leaders, but it definitely applies and offers guidance on becoming an effective leader without sacrificing your personal life and growth. The major points from his book are summarized here, with their implications for project managers and teams Chapter 5 • Project Scope and Resource Planning 149 1. Be proactive—Individuals should focus their efforts and attention on the long term and to think in terms of the longterm consequences of their actions. Individuals have options about how they respond to different situations and should adopt an attitude of understanding the power they have to respond to what happens and make the most of their opportunities. Successful project managers adopt the attitude that they can make a positive difference in almost everything they experience during a project changes, late work, problem stakeholders, and so on. The other six habits require that this proactive attitude be adopted. 2. Begin with the end in mind—Covey refers to this as the habit of personal leadership— setting goals for where you want to take your life and then tracking your progress. Before you can reach your goals, you must set them, which requires introspection. An effective project manager continually sets goals for himself and his projects and aids members of his team to set goals as well. 3. Put first things first—Individuals need to organize and plan their path to reaching their goals. Project managers must be excellent time managers. They must learn to manage their own time as well as the time of others. Successful project managers learn to concentrate their efforts on activities that maximize their chances of reaching their goals. 4. Think win–win—This habit is the first that directly speaks to being a better ­project manager. Project managers can’t deliver projects by themselves it takes a team effort, with everyone working toward the goals of the project to be successful. Project managers learn the art of compromise and constantly seek win–win decisions. 5. Seek first to understand and then to be understood—This is a great philosophy for all. Think about the fact that a physician must first understand the symptoms thoroughly before prescribing a medication. Similarly, project managers must learn to be excellent listeners, seeking first to listen and understand stakeholders and team members. 6. Synergize—Synergy means that the whole is greater than the sum of the parts. Project managers learn techniques for getting teams to perform as teams and not as a bunch of individuals. The final solution is always better when everyone is involved and allowed to contribute. 7. Sharpen the saw—This is called the habit of selfrenewal. It is broken down into four parts spiritual, mental, physical, and social. Being a project manager can be very stressful and timeconsuming. A project manager must take the time to rejuvenate, doing the things he or she likes to do away from work for example, sailing, golfing, reading. A project manager also needs to find time for continued traininglearning to reach the personal goals he or she set as part of the first habit. Resource Planning Deliverables The deliverables from the resource planning part of the project plan are the physical resource management plan, possibly the project roles and responsibilities matrix, the project organizational chart, and the staffing management plan, which are all part of the overall Resource Management Plan deliverable listed in the chapter map figure at the beginning of this chapter. For every project, regardless of size, the project manager should create a roles and responsibilities matrix to be sure everyone knows their responsibilities. The physical resource management plan, project organizational chart, and staffing management plan may not need to be formal documents unless the size of the project requires it. Generally, once the project gets above 5 team members, the project manager should consider creating these project artifacts. The physical resource management plan is described in more detail in chapter 9 of this text. 150 Part 2 • Project Initiation and Planning Methods ROLES AND RESPONSIBILITIES MATRIX One important deliverable during the planning phase of the project is the roles and responsibilities matrix RRM, also called a RACI matrix, referring to the legend in figure 54. After the initial WBS is created, the project manager needs to decide who is needed to perform the individual activities. Based on new knowledge gained in the preceding section, the project manager will be able to assign the right work to the appropriate individuals. Early in the project, at the time of the project charter or the initial draft of the WBS, the project manager might not have enough details to assign an individual person to each activity, and it is perfectly acceptable to use a title systems analyst or a department name finance instead of names of individuals. ­Figure 54 shows an example of an RRM using role names. Another important function of the RRM is to define the level of responsibility that each person, title, or department will have for each objective or activity. Activity Task 1 Task 2 Task 3 Task 4 Task 5 Project Manager A R R R C Database Analyst I C C C R Accounting Supervisor A C C C I CFO A R A C C Lead Systems Analyst C C I R I Inventory Control Supervisor C C C I I Legend R Responsible A Approval C Consult or review I Inform or act as SME Responsible Party FIGURE 54 Roles and Responsibilities Matrix PROVEN STRATEGIES AND HINTS TO SUCCESS IN AN AGILE WORLD Care must be taken when building the best team of human resources possible for an agile based IT project. Agile based teams work best when they follow these guidelines • Team Size is kept to less than 10 individuals. • The team is colocated—moved to the same physical location and hopefully right next to each other. • Based on project requirements the team consists of a crossfunctional group who can design, build, test, and deliver the user story solution all within a short period of time—2 to 4 weeks without outside expertise or at least this is kept to a minimum. • The teams are empowered, selforganizing, consistent with low turnover, and selfmanaged. • Each team also contains 1 team lead Scrum calls this the Scrum Master soft skills of a project leader but less of the technical skills of planning and scheduling . • Each member of the team is fully dedicated to a single team. • Each team actively engages with other teams to manage dependencies and resolve impediments. • Each member of the team tends to be a generalist—or someone who has one or more technical specialties to contribute. Chapter 5 • Project Scope and Resource Planning 151 Program manager Project leader Resource manager IT software manager CFO FIGURE 55 Project Organizational Chart The activities listed on the RRM are generally at a summary level initially early in the project, and as the project proceeds, they are expanded to include lowerlevel activities. A responsible party is assigned to each activity or task at one of four levels getting the activity completed, getting approval of the work product created in each activity, consulting or reviewing, or informing as an SME. The RRM is first generated for the project charter and evolves into finer levels of detail as the project evolves. The RRM is not a static document but changes as facets of the project change. The benefits associated with having an RRM created for the project are • Better communication with stakeholders and team members • Ability to make decisions more quickly due to roles being clearly spelled out • Ability to more quickly familiarize new members of the team with the project • Ability to gain commitment from all • The potential to see and deal with conflict early • Improved teamwork The RRM does have some drawbacks, including the following • Just because the project manager has it in writing doesn’t make it happen the project manager must still manage the effort. • It can look overly simplistic. • It can sometimes be difficult to define or get a responsible party to agree on a particularrole. The RRM is especially important when part of the project is outsourced andor offshored. In these cases, the RRM must clearly delineate who is doing what on the project. We discuss this topic in more detail in Chapter 14 of this text. PROJECT ORGANIZATIONAL CHART After completing an RRM, a project manager is ready to create the project organizational chart, which is similar in concept to the organizational chart for the entire company but is specific to a project or program. Not every project will have its own project organizational chart generally, it is used only when the project is of sufficient size to warrant its use see Figure 55. A project organizational chart has many of the same benefits as an RRM in documenting roles and aiding communication. A key suggestion when dealing with project organizational charts is not to forget about the informal relationships that exist between individuals, just like on the organizational chart for the entire company described in Chapter 2. These informal relationships can cause the project leader many headaches if they are unknown or ignored. 152 Part 2 • Project Initiation and Planning Methods STAFFING MANAGEMENT PLAN The final deliverable from resource planning is the staffing management plan, which consists of the following elements • The process to follow when adding or removing people from the project • The process to follow in assigning work and managing different groups of workers • A list of training needed and the process for scheduling and funding the training • The process for awarding bonuses both monetary and nonmonetary • Any safety issues that need to be followed • Any specific human resources policies that need to be included • Specific risks associated with assigned human resources When crafting the initial or early staffing plan and project schedule, never start with a plan that requires resources to work overtime to complete the project successfully. Working overtime—whether compensated or not—on a prolonged basis will very soon begin to cause disharmony in the team. Working overtime once at the end of a project to deliver on time will work once or twice, but if it becomes the norm, stakeholders and your team will soon begin to avoid your projects and not trust the schedules you develop. Always start with a plan that can be accomplished without requiring workers to work long hours over extended periods of time. THE SCOPE AND RESOURCE PLANNING PROCESS The process for scope and resource planning involves the following steps Step 1. Use an existing scope management plan from a previous similar project. If one is not available, you must begin building one from scratch with the elements mentioned earlier in this chapter. Step 2. Perform the requirements discovery and documentation process and begin building the requirements traceability matrix. Step 3. Begin building the scope statement, starting with the project charter and the preliminary scope statement, if one exists. Step 4. Build the WBS, using a WBS from a similar project or one of the other methods mentioned in the chapter, depending on the nature of the project and the team resources. Step 5. With the assistance of SMEs, assign resources to tasks and build the roles and responsibilities matrix. Step 6. If needed, build the project organizational chart and physical management plan. Step 7. Build the staffing management plan, starting with one from a similar project or a template. HOW TO CONDUCT THE SCOPE AND RESOURCE PLANNING PROCESSES This last section of the chapter uses the process outlined in the previous section to provide examples of deliverables for the scope planning process and the resource planning process. Before proceeding, take time to reread and review the R S Amusements Services case study. In Event 5 at the beginning of this chapter, Kevin and Jeff are meeting with Reid Chapter 5 • Project Scope and Resource Planning 153 Lewis to discuss the next steps in the process of implementing the three applications asset management, collection management, and customer management. Kevin and Jeff begin explaining the next steps in the project management process. Let’s now work through each of these next steps for the asset management project. Step 1 Create the Scope Management Plan Jeff and Kevin will supply a plan that they have used on similar projects and tailor it to this project. The changed plan is outlined below • Definition of scope—The project team leaders are the steering committee members established in Chapter 4 Reid Lewis, Danny Calloway, Diana Brooks, Mark Lewis, and Ashley Brooks. These will also be the primary decision makers in decisions regarding the scope of the project. This group will meet to discuss what is and is not included in the scope of the asset management project. Each member has one vote, but the group will need to have four out of five votes to pass any issue. This will help alleviate major issues related to split votes and morale on the team. The group will meet daily until the scope statement and WBS are completed. When the project begins, the group will meet virtually every day but in person only once per week. • Development of the WBS—Kevin and Jeff supplied a WBS from a similar project they worked on previously. The group reviewed the WBS and changed it to fit the asset management project at R S Amusements Services. A brainstorming session will be held to identify all needed changes. The team will then review the current document for one week and write up reasons and justifications for any further changes. The group will meet again and make decisions on all requested changes. This process will continue until a consensus decision is made on the final content of the scope statement and resulting WBS. • Scope verification—A final verification of the scope statement will be done by selecting key individuals from each relevant functional area of the company. The team leaders will meet with their respective departments and conduct similar brainstorming sessions to make sure nothing has been missed. • Change control—Kevin and Jeff supplied a standard integrated change control process that has been used on many previous projects. The process will need to be changed slightly to fit this project and, most importantly, this company. The integrated change control process is explained in detail in Chapter 12. Step 2 Perform the Requirements Discovery and Documentation Process PPMS has several skilled systems analysts on staff to help R S discover and document all the needed requirements for the new asset management system. These requirements will be used to build the requirements traceability matrix, the scope statement, and subsequent WBS. Jeff and Kevin have selected a systems analyst, David Irwin, who has four years of experience working with small to medium businesses. Because David hasn’t worked with a business quite like R S, he will need a little extra time to get up to speed and learn about the business and the project. David plans to use small group discussions and individual interviews to build the initial list of requirements. 154 Part 2 • Project Initiation and Planning Methods SCOPE STATEMENT Project Asset Management System AMS As of Date April 2, 2009 Functional Requirements • System shall have the ability to track location and inventory amount of every item in current inventory as well as in the field. The tracking of inventory will be done by barcode scanner. The warehouse workers and service technicians will all have portable wireless scanners. Anytime inventory is moved, it will be scanned into the system for realtime data updates. • Item codes need to support 25 alphanumeric characters • Track up to two item codes for each item to support vendor numbers and internal numbering • Inventory amounts on hand, on order, available, reorder quantity, lead time, discrepancy alerts • Maintain history of cost changes and turn rates • Items in inventory include game machines, maintenance supplies, dollar bill changers, and external speakers. All items to be labeled with bar codes. • Support cycle counting, stock count calendars, inventory snapshots • Multiple units of measure each, ounce, and so on. • Warranty information • Inventory information is updated continually in realtime. Each worker in the field will have a portable unit that will store changes until the worker returns to the office. Once back in the office, the worker will plug in the unit to update the central database. • Ability to store up to 500 changes in memory of each unit • Backup battery packs and auto chargers • Generate purchase requisitions when inventory reaches minimum levels. Each inventory item will have its own minimum and maximum inventory levels. • Purchase amounts to receive discounts • Vendor information • Pricing information, quantity breaks, percentage of list, percentage markup • Contract information • Vendor ratings • Multiple shipping methods • The system shall allow authorized users of the system to create ad hoc reports on an asneeded basis • Reports can be printed or displayed online • The system shall track vendor information such as name, address, merchandise, prices, quality, delivery options, and timeliness. NonFunctional Requirements • System shall be secure from inside and outside the organization • User will need a user ID and password for access to the system • User roles will be set up in the system • System shall have the ability to support a 40 percent per year growth rate in assets Step 3 Create the Scope Statement Starting with the project charter and the requirements documentation developed earlier, the team put together the following scope statement Chapter 5 • Project Scope and Resource Planning 155 • System shall be available from 700 a.m. until 530 p.m. Monday through Friday 100 percent of the time and other hours 90 percent of the time. Success Criteria • Find and purchase an asset management software package that fulfills at least 75 percent of the stated requirements within given budget constraints that is integrated or can be easily integrated with general ledger, customer management, and collection management • Improve productivity of warehouse staff, asset management staff, service technicians, and collections representatives by 50 percent collectively • Reduce inventory carrying costs by 20 percent • Improve customer satisfaction ratings, based on an annual survey mechanism • Implementation within 18 months Constraints • Stay within stated budget numbers • R S staff are not 100 percent dedicated to this project • Delivery of this project needs to be done in parallel with collection management and customer management Assumptions • A software vendor solution can be found to meet user requirements and budget constraints • Each member of the R S staff is in support of the new software Risks • Maintaining enduser involvement • Obtaining a clear and comprehensive statement of requirements • Finding suitable software package with reliable vendor within budget constraints HighLevel Schedule • Requirements documentation statement of work, 2 months • Softwarehardware purchase and install, 6 months • Gap analysis, 2 months • Custom software, 2 months HighLevel Cost Estimate first year • Additional hardware needed, 40,000 • Software package, 25,000 • Custom code, 30,000 • Overhead contribution, 5,000 Step 4 Create the WBS As mentioned earlier, a similar project was used to obtain the first pass at a complete WBS. Jeff and Kevin, working with the R S staff, made changes reflecting the needs of the asset management software implementation project. They followed a similar process