Project management Discussion

pjm6005_lesson_2.pdf

Home >Business & Finance homework help >Operations Management homework help >Project management Discussion

Welcome to week 2, everyone! This week, we’ll move on from the project initiation phase and making sure our business requirements are clearly defined to the project planning phase and how to collect project and product requirements. As we saw in week 1, determining “scope” – exactly what SHOULD and SHOULD NOT be included in project plans is very challenging because every person involved with a project often has at least a slightly different view about “project scope.”

Recall from week 1 that “scope” is expressed in requirements. One of the ways we can make the process of determining project scope more straightforward (not the same thing as easier) is to develop and implement a formal plan for collecting these requirements. We’ll see this week that there are multiple possible techniques for requirements collection – so long as we have a solid understanding of the stakeholders who have these requirements. Onward!

The learning objectives for this week focus on two processes. As alluded to on the previous slide, we’ll focus on how to actually collect requirements. Before doing so, however, we need to have a strong understanding on where these requirements are coming from: the stakeholders involved with the project. We’ll examine the process of “stakeholder identification”, which actually includes not only identifying stakeholders but also classifying them according to interest, influence, and overall risk to the project.

As with most project management processes, we’ll see it’s important to document our requirements collection (and stakeholder identification) planning. We’ll conclude this week’s discussion by examining a Requirements Work Plan document, which will also be your written assignment for this week.

Here are the readings for this week, which focus on the “collect requirements” and “identify stakeholder” processes. As usual, you may find it useful to take an abbreviated look at the readings before the lecture, and then go back and review the material more closely after you’ve completed this lecture and have additional context. Be sure to also read the case study update provided with this week’s materials; you’ll need to refer to it in order to complete this week’s discussion board activities.

Consider that the definition of “scope” – that range of abilities, effectiveness, or actions discussed in week 1 – depends on who you ask One person’s view of whether a task is discussed in week 1 – depends on who you ask. One person s view of whether a task is “within scope” will vary from another’s, even if only slightly. Developing consensus on project scope, then, is tricky: it also depends on who you ask, and even how you ask them.

The first step in determining a project’s scope is to determine who to ask: who are the stakeholders associated with a project and how much weight should their opinions be stakeholders associated with a project, and how much weight should their opinions be given. Identifying project stakeholders is actually often harder than it sounds, because the concept of a “stakeholder” is so widely understood we don’t spend much time really thinking about it. As a result, lists of project stakeholders are often too narrow.

The formal definition of a stakeholder is provided here. Project stakeholders are more than just those people actively working on the project Stakeholders may feel positively than just those people actively working on the project. Stakeholders may feel positively or negatively about the project, and a common mistake in stakeholder analysis is to overlook any negatively-focused stakeholders.

As mentioned on the previous slide, there are some stakeholders that will be present on every project. Some stakeholders also have particular influence or interest in a project’s y p j p p j scope. The most common scope-focused project stakeholders are listed here and chances are you’re already familiar with all them, with the possible exception of the Business Lead, or Business Analyst.

Since the roles can seem very similar, let’s compare the responsibilities of the Project Sponsor, Project Manager, and Business Lead on the next few slides. p , j g ,

The Project Sponsor should be a role that is familiar to you, although a sponsor may also be referred to as the project’s “champion” or “owner.” A Project Sponsor is (usually) a more senior person within an organization, and is part of the decision- making processes that occur during project initiation (although the Project Sponsor may or may not be the generator of the business requirement the project was undertaken to satisfy.)

The Project Sponsor is not a member of the project team, but is a resource for the project team (and Project Manager) to use when additional support regarding resources or the project’s direction is needed.

In contrast to the Project Sponsor, the Project Manager is not only a member of the project team but is also the primary person responsible for managing the balance between a given budget, timeframe, and set of requirements (the triangular shapes above, as well as the picture of the stool, refer to the “triple-constraint theory” you likely have already encountered in your courseware. Recall the triple constraint theory says it’s not possible to modify a project’s schedule, or budget, or scope without also affecting at least one of the other two parameters. Sometime the “triple constraint theory” is also referred to as an “iron triangle” or a “3-legged stool” ) constraint theory is also referred to as an iron triangle or a 3 legged stool .)

A Project Manager may not be part of the process that determines a project’s scope, but the Project Manager is responsible for managing that scope once it’s defined.

Here’s a quick summary of the key differences between the Project Sponsor and Project Manager. Note in particular a Project Sponsor’s role (usually) in defining business and project scope and the Project Manager’s role in managing that scope.

If a Project Sponsor helps to define business and project scope, and a Project Manager is responsible for managing scope, how does this third role, the Business Lead, affect scope?

A Business Lead (also sometimes referred to as a Business Analyst) does much of the actual research and analysis within the project initiation phase. The feasibility studies, risk analyses, cost-benefit analysis, and evaluation of alternatives all typically fall within the Business Lead’s domain. A Business Lead may be given a general idea of a high-level business requirement and then is responsible not only for defining that high-level requirement in more specific and measurable terms but also then researching potential solutions to the business requirement.

If much of this activity occurs during the project initiation phase, where y g p j p organizational leadership (including the Project Sponsor) is heavily involved, why aren’t these types of activities completed by the Project Sponsor or other senior leaders? The answer is often there simply isn’t time available. Also, a Business Lead may have specific analytic skills or research expertise that other stakeholders in the initiation phase don’t have, so the Business Lead provides of summary of research conducted. As you may have guessed, the Business Lead is also often the primary author of the business case document we examined as part of last week’s author of the business case document we examined as part of last week s discussions.

Given the description of the Business Lead on the previous slide, and how important it is for the Project Manager to thoroughly understand the business and project scope, would it simply make sense for a Project Manager to research and write the business case? Wouldn’t the Project Manager then have a more thorough understanding of the project purpose, benefits, costs, and risks?

Yes, the Project Manager would – and this is why some organizations don’t employ Business Leads. In organizations that don’t have Business Leads, a Project Manager is often asked to conduct project initiation and analysis research. Keep in mind, though, that the ability to write feasibility studies, and conduct market research and cost-benefit analysis are slightly different than the abilities needed to manage projects. Also, once a project is underway, the responsibilities of the Project Manager are increased: not only will the Project Manager be expected to manage the project but must also keep a close (and continual) eye on whether the business project but must also keep a close (and continual) eye on whether the business requirement(s) are in fact being honored as the project progresses. Since – particularly on large projects – project management is already a full-time job, overseeing project and business requirements can result in neither task being completed effectively.

This brings us to a common question: if project management is really all about balancing a project’s given schedule, budget, and requirements (scope), should the Project Manager play a significant role in collecting requirements if a Business Lead is available? Should a Project Manager concern him/herself too deeply with what a project’s requirements are, or should the Project Manager focus on how to ensure requirements are satisfied?

As this slide indicates, there are two different ways to answer this question. What do you think? This question is the first discussion board question for this week, so give the question some thought and explain your answer and rationale on the discussion board.

Regardless of who leads the process of defining business and project scope that process Regardless of who leads the process of defining business and project scope, that process centers around people. We’ve said that scope is a matter of opinion, so we need to be sure find the most appropriate opinions for the project. In other words, we need to seek out more than just the Project Sponsor, Project Manager, Business Lead, and Technical Lead when defining project scope; we need to identify all appropriate stakeholders.

The process by which we identify stakeholders is shown here Note the project charter The process by which we identify stakeholders is shown here. Note the project charter (which is informed by the business case) is an important input to identifying who project stakeholders are.

The “identify stakeholders” process is actually misnamed, because it involves more than just creating a list of all the stakeholders involved with a project Stakeholder than just creating a list of all the stakeholders involved with a project. Stakeholder identification is the first step, and even a simple brainstorming session among some of the project stakeholders can generate a robust list of all project stakeholders.

The second step in the “identify stakeholders” process is to analyze and classify project stakeholders according to their level of interest, influence (or power), risk, and direct involvement with the project. It’s not feasible (nor necessary) to collect requirements for each individual stakeholder; we need to collect requirements from q ; q an appropriate representative stakeholder sample. How should this sample be determined?

There are several tools and techniques used for determining which stakeholders should be involved in requirements collection. Three of those techniques are shown here. For example, we can classify stakeholders into different groups using the colors red, yellow and green, similar to traffic stoplights in the United States. A “red” stakeholder would be one who is highly interested, involved, influential, or poses significant risk to a project. A “green” stakeholder would be just the opposite: low-risk, low influence, or low interest. We can also use an even simpler technique and classify stakeholders into different levels (however many levels we desire) that and classify stakeholders into different levels (however many levels we desire) that indicate the same high (or medium, or low) levels of influence, interest, involvement or risk.

Your readings for this week also identify a classification tool referred to as a “power/interest” grid (see PMBOK® Guide 396-397.) How stakeholders are classified is a matter of team preference so long as whatever tool is used helps classified is a matter of team preference, so long as whatever tool is used helps determine who should be part of requirements collection.

Once we’ve identified and classified stakeholders we’re ready to create a plan for actually Once we ve identified and classified stakeholders, we re ready to create a plan for actually collecting requirements (note the output of the “identify stakeholders” process, the stakeholder register, is an input to the collect requirements process as shown here.)

Since the output of requirements collection – the actual requirements (and scope) of the project – will affect all other project activities, it’s important to treat the requirements collection process as a small project in itself Accordingly we need to identify the specific collection process as a small project in itself. Accordingly, we need to identify the specific tasks the collect requirements “project” will entail: we need to choose requirements collection methods that best fit the stakeholders, timeframe, and budget available.

Some of the most common requirements collection methods are listed here. Let’s examine them in greater detail on the next few slides.

Here’s the same list of requirements collection techniques, with the four most l d t h i hi hli ht d E h t h i h d t d commonly-used techniques highlighted. Each technique has advantages and

disadvantages, however, and some will be more appropriate for our project (and stakeholders) than others.

A summary of the main advantages and disadvantages of more common techniques is provided on the slides that follow.

Group creativity techniques (brainstorming is a primary example) and interviews are both very common requirements collection techniques. Both are relatively low cost, and most stakeholders are already familiar with how each technique works. Note that interviews allows for one-on-one follow-up questions, but that is both an advantage and disadvantage. One-on-one follow-up can provide deeper requirements analysis, but it doesn’t benefit from the perspective of a larger stakeholder group.

Two other very common requirements collection techniques are document analysis and observation.

Because document analysis is a review of existing materials (such as written policies, procedures, or manuals, for example), it is less subjective than other collection techniques. It relies heavily on current and accurate documentation, however, which may not always be possible.

Observation is the opposite of document analysis in that it is highly subjective: the process or activity being observed may be performed in a way that isn’t accurate, and the actions observed may vary greatly from stakeholder to stakeholder. This is why a combination of techniques is often required to get the most accurate view of project requirements. p j q

Focus groups and facilitated workshops are similar collection techniques in that they both involve larger groups of multiple stakeholders and both require strong facilitation. The difference between the two methods is that focus groups are designed to draw out more subjective requirements such as stakeholder attitudes and opinions. A facilitated workshop, on the other hand, is a specially-convened meeting designed to uncover all project requirements (not just subjective stakeholder reviews.)

Both are good techniques for collecting requirements in a relatively short period of time, but both techniques can be a challenge to schedule because of the larger number of stakeholders involved.

Two less common but still effective collection techniques, prototyping and reverse engineering, are discussed here. Building a prototype, or tangible sample of what the final product could look like, sounds time consuming and expensive, but for organizations who routinely build “beta” or “pilot” products a prototype can usually be developed fairly quickly and easily, without significant cost.

Reverse engineering is most often used when one organization is trying to create a product (or service) similar to something that has already been produced by another organization (usually a competitor.) The process begins by analyzing the end product and then trying to determine the steps taken to generate it.

Finally, surveys and questionnaires are the only collection technique that ask stakeholders questions directly and in writing, which means that no facilitation is needed. It’s also possible to send surveys and questionnaires to a large number of stakeholders (although response rate can sometimes be low.)

Because surveys and questionnaires aren’t facilitated in person, the questions these tools contain must be very clearly written, without any bias. Question development can sometimes be as challenging as in-person facilitation, so it’s important to involve someone specially skilled in writing questions for surveys and questionnaires.

If the process of collecting requirements is important enough to treat like a “mini- project”, then it should be summarized with a project plan. A Requirements Work Plan is just such a document.

As with last week’s Business Case, there’s a template for this week’s Requirements Work Plan (RWP) contained in the “assignments” area of this week’s course materials that you may find helpful to review while we discuss the RWP on the next few slides.

First, note that a Requirements Work Plan is NOT the same thing as “Requirements Documentation”. Requirements Documentation – the formal output of the entire “collect requirements” process – is the document that contains the actual requirements statements derived from the collection process. The Requirements q p q Work Plan is simply a formal document that organizes the requirements collection process so everyone involved is aware of the proposed collection methods, stakeholders, and expected timeframe. The RWP is the “mini project plan” focused just on the act of collecting requirements.

Similar to the background statement included in the business case last week, a Requirements Work Plan should always begin with a short summary of the project itself and the business need the project is supposed to satisfy. This Executive Summary should summarize the key information about the project and the requirements collection process such that someone who did not read the business case (or project charter) is able to understand enough project background to follow the information identified in the remainder of the Requirements Work Plan.

The second part of a Requirements Work Plan summarizes the stakeholder identification and analysis process. As such, it lists all the project stakeholders and describes how those stakeholders are classified, using one or more of the stakeholder analysis tools discussed earlier (the “stoplight” chart, numeric levels, or a power/interest grid.)

The longest section of the Requirements Work Plan identifies and describes the requirements collection tools and techniques that will be used, and the stakeholders that will be involved with each tool. It should also identify who will lead each collection effort.

The link between specific requirements collection tools and the stakeholders who will be involved with each tool should correspond to the stakeholder analysis findings identified in the previous section of the Requirements Work Plan. For example, highly influential or highly involved stakeholders merit more rigorous collection techniques than a simple survey or observation may provide. And, it may not be appropriate to conduct detailed interviews with stakeholders who are only casually involved.

Finally, as with any project plan, the Requirements Work Plan should include an estimate of how long each requirements collection task will take, and also an overall duration estimate for the entire requirements collection process.

This concludes the lecture for lesson 2. To complete your work for this week, you’ll need to respond to two discussion board questions this week, one of which is related to the case study update provided with this week’s readings. Your written assignment for this week is to create a Requirements Work Plan for your individual case study project, and specific details (and a template) for that assignment are provided on the “assignments” page of this week’s course materials.