Course Learning Outcomes for Unit II

Upon completion of this unit, students should be able to:

1. Prepare a final project report.

5.1           Explain basic concepts of projects and project success as it relates to project scope.

1. Determine project requirements using requirement collection tools and techniques.

6.1           Examine how some techniques support gathering requirements for a project.

6.2           Derive project requirements based on the objectives of the project.

Required Unit Resources

Chapter 3: Project Selection and Portfolio Management, pp. 80–111

Chapter 5: Scope Management, pp. 156–164

Unit Lesson

The subject for this unit closely aligns with the content of the project plan. However, only part of your scope is due in the Unit II Course Project assignment. The final components are due in Unit VIII. It is important to learn these concepts so you can successfully create a project plan and effectively manage a project.

Choosing Projects

To answer this question, there is much to consider. Organizations can be different in so many ways. Some organizations may be very loose with their projects, and some may want a formal project initiated for every non-simple change. Remember that having a project manager (PM) and formal project costs money. You have to weigh the costs of initiating and managing a project versus the loss of not being able to successfully implement new processes or new products or make major system changes. Many organizations do have a formal project request form or process, but in many cases, there also has to be a formal project selection process; which may be quantitative or qualitative in nature.

More qualitative or descriptive project selection considerations might include the risk to the organization, the impact on competitive advantage, or the effect on the company’s image. Another consideration might be how the project and its objectives fit into the organizational mission or strategic plan for the year. There also may be internal considerations. For example, updating an organization’s systems may not be considered a strategic objective, but employees have to be able to work efficiently and effectively or a company cannot remain competitive, can it? As discussed, every organization is unique, so the selection process is based on its needs. Starting on page 84 in your textbook, you can review the different screening methods and models.

From a quantitative or numerical perspective, some organizations may only consider projects based on the results of a cost-benefit analysis. If the benefits outweigh the costs, then it is added to the project list.

Calculating net present value (NPV) is one of the most popular project selection approaches; refer to page 95 in your textbook to review an example of NPV.

In some organizations with smaller or less formal project selection or prioritization processes, upper-level leaders may have been with the company their entire lives and know the business inside and out. In these cases, projects may be selected and prioritized based on expert knowledge. Conversely, in many organizations, project priority is generally decided by a committee or board based on criteria important to the organization.

Many organizations have a formal project portfolio. The project portfolio has to be managed so that funds and resources can be allocated in the best interest of the organization. As Pinto (2019) discussed, the criteria for prioritizing projects in a project portfolio may be cost, payout, pressure from the top, risk, strategic fit, and portfolio balance. In reality, a leader, such as a CEO, may override the priority list and request a project to be completed right away. Regardless, as new projects are added, the prioritization for existing projects will have to be revisited by leadership and may shift over time.

Managing Project Scope

As Pinto (2019) notes, project scope is “everything about a project-work content as well as expected outcomes” (p. 158). We have already learned about many of the aspects that make up a project’s scope. For example, you learned about goals, objectives, constraints, tasks, activities, resources, timeframes, and cost. Because we have to develop the project plan, its scope starts with a problem or a statement of need. What needs to be corrected, changed, upgraded, enhanced, or added?

The next part of project planning is gathering requirements. This can be a lengthy process, especially if many people are affected and in different ways. Requirements are the needs or specifications as gathered from stakeholders to meet the project’s objectives or goals. The requirements within a project can be very different based on the stakeholders. For example, if we have a newly developing product, what are the needs of the customer? What about the needs of the marketing department? What about the operations department where the product will be produced? What about customer service? Based on our discussion from Unit I, what are

the performance requirements? What features have to be included so that the customer is happy? For example, creating a new line of women’s shoes will have very different requirements if they are Adidas versus Gucci, right?

Once the PM has gathered requirements, other information has to be gathered. What is the state regarding the project? What else do we need to know? Perhaps New York fashion week is in one month and our marketing manager in this area is on leave. What should we do? What adjustments need to be made?

Next, we gather the constraints. What are our restrictions? Are we on a strict timeline? What is our budget? What about our resource availability? Many times, during certain times of the year, you have to consider that employees will be taking vacations and that resources may be limited.

Creating a line of sneakers would have different requirements than

creating a line of dress shoes.

(CFJ890, 2017)

After gathering all of this information, the PM needs to consider alternatives for the presented solution. The PM should have a clear statement outlining the project’s objectives. The PM should also have a clear business case for the project. As Pinto (2019) notes, a business case is support for the business need. The business case is justification for the project based on business needs. All of this is important information to have before we ever start the project.

Starting the Project

Usually, any project work starts with a statement of work (SOW), whether it is internal or external. In many cases, hiring an outside consultant or consulting company to do some work or an installation requires a signed SOW before they will begin any actual work. A SOW is very descriptive and contains key information about the project, including the objectives, a description of work to be done, outcomes, and restraints. In some cases, the SOW can be more general in nature, but in order to be more useful, it has to be very detailed. If you look on pages 162–163 in the textbook, you will see that a SOW can have multiple sections. In complex projects, a SOW may be 25 or more pages in length. In the case of external SOWs, stakeholders will review the SOW, and if they approve, they will sign off on it. It will also likely need a sign off from a leader or designee in the legal department.

After the completion of the SOW, the PM will receive a project charter, which is a formal document created by the project initiator that officially sanctions the project start. Is there a good business case? Are all of the project elements present and understood? Are all of the constraints reasonable? Is everyone on board? If so, the project charter is created, and the project starts.

Access the Project Charter Activity to review details and examples of the project charter.

You also have great examples in your textbook to refer to while you are working on your Unit II and Unit III Course Project assignments.

References

CFJ890. (2017). [Photograph]. Retrieved from https://pixabay.com/photos/trainers-adidas-tip-toes-2884476/ Pinto, J. K. (2019). Project management: Achieving competitive advantage (5th ed.). New York, NY: Pearson.