Fluent Essays

Based off of the materials and concepts presented in this unit, respond to the question prompt below.  Provide 1 reason and justify your answer.   “You know your project scope probably needs to be changed when …..” By now you certainly appreciate how very challenging defining and planning project scope can be. Other project management areas have the project’s scope to work from; in this course, we literally had to create something from nothing. While the process of defining and planning project scope never really ends (few projects end with exactly the same set of requirements they began with), how often we need to update our project scope depends greatly on how well we manage and control the scope we’ve already defined. This lectures focuses on just that: how to keep the scope we planned for as much as possible and, when change is in fact required, how to change scope deliberately (and not by accident.) The final set of lesson objectives are identified above. You’ll notice there are TWO scope-related processes within the monitoring and controlling process group: validate scope and control scope. To complete those processes successfully, we’ll need to first review how to determine whether our project’s scope is healthy (are we satisfying defined requirements) and then, as a separate, deliberate step, decide whether to allow changes to the project’s scope or not. Finally, we’ll briefly review some “alternate” project management methodologies often used to define and control project scope when the project outcome itself isn’t well-defined: we’ll look at what “agile” project management really means and involves Before getting into this lecture further, it’s suggested you take a first pass at the required reading for this week, as listed above. You’ll notice that chapter 17 of the Project Management text is the reading assignment that discusses an alternate project methodology for planning and controlling projects in highly dynamic environment. We’ll examine how this methodology, known as agile project management, can be used to plan and control project scope when project outputs are so new, unpredictable, or innovative that solution requirements simply can’t be fully identified at the project’s outset 1 First things first: for discussion purposes, we need to assume we have officially moved beyond the project planning phase and our project has begun to execute. So at this point, assume we have already collected and documented a set of business and solution requirements (the processes we examined in the first 3 weeks of the course); we’ve written a scope statement that summarizes requirements documentation and all other known project parameters (as we did in course week 4); and we’ve created a strong work breakdown structure (the topic for course week 5.) We’ve also finished all other project planning processes, including schedule and budget development. Our team has begun to work on the tasks as outlined in the WBS. And then, of course, life happens. Events cause our project to vary from our plan – tasks may be delayed, expenditures may be higher, requirements may take more effort to satisfy. Now what? Just like in the first week of this course we had to deliberately decide we had a “problem to be solved” (and we saw that sometimes we don’t need to begin a new project as much as we thought we did), now we need to decide if the project plan really does need to be changed…BEFORE we actually make any changes. Many times, a project team simply reacts to an unplanned event without first analyzing the potential impact. This reaction can result in sudden changes to tasks, schedules, or budgets that create a bigger problem than the original unplanned event and make things worse rather than better. These uncontrolled changes are often referred to as scope “creep”, because not only are they unplanned but also many times the person(s) making sudden changes forgets to alert the rest of the team as to what changes have been made. The idea behind all project change control – scope control as well as other change control processes – is to slow down and make changes deliberately, if at all. First, not every unplanned event requires making a change to the project plan. Second, if changes are required, it’s important to first agree as a project team on how potential changes to the project plan will be proposed, reviewed and approved. Having such a “change plan” is the best way to expect – and then respond – to project change responsibly. 2 2 “Expecting” our project will need to change implies that we have an idea of what we’re changing from. In other words, we can’t change our project plan if we don’t have a good idea of what the project plan originally called for. As you already know, all projects have 3 primary characteristics: the project scope, the schedule, and the budget. Before we can make purposeful changes to any project plan, we have to be aware of what the project was supposed to be doing – expressed in scope, schedule, and budget terms. By the time the project planning phase is complete, we have broken down the project scope into tasks that were then sequenced into a project schedule and assigned resources, including monetary resources. This final project planning output that combines the scope, schedule, and cost plan together is known as a cost performance baseline. The baseline can tell us, for any day in the project, how much work was supposed to have been completed by now and how much we were supposed to spend to complete that work. We can draw the cost performance baseline graphically, and a picture of one is shown above. You can see the 3 primary attributes of the project: the schedule runs left to right along the X-axis and how much money we’ve spent so far is reflected on the Y-axis. Since each task in the WBS (our scope) has a planned duration AND cost, as tasks are completed costs will rise over time. If we plot these costs cumulatively on the graph, we can see a few costs at the beginning of the project, rising costs as the project is fully executing, and tapering costs as the project nears completion (the red dotted line shown above.) Having this cost performance baseline gives us something to refer to as the project actually executes to determine whether the project is progressing according to plan. If we didn’t create a baseline with sufficient detail (to the task level), then we can’t really know whether the project is “on plan” or not. The first step to “expecting” change on a project is having a strong baseline that tells you whether you actually have a problem that requires project plan modification. 3 Even if we have a well-developed cost performance baseline, the baseline is only what the project planned to do. The next step, of course, is to determine how the project is actually doing. Because the project’s baseline focuses on the project’s scope, schedule, and budget, we need to collect actual data about the scope, schedule, and budget. Where does this actual data come from? The short answer is “any way the project manager can find it.” Cost data is usually the easiest to find: actual costs are often captured in organizational financial systems. (Recall, however, our discussion about taking financial system structures into account when building the WBS. If financial systems don’t provide actual cost data that can be identified at the project task level, determining actual cost status by task may be difficult.) Schedule and task status can be harder to determine. Most often, project teams will hold regular status meetings, project review sessions, or submit formal reports where the “percent complete” of each task is identified as of a certain date – if the project team is aware of task progress. Clearly, educating the project team (and other project stakeholders) on how to assess task status is a critical part of analyzing project performance. The more the full project team is aware of project status (and how to describe it in common terms), the easier it is for the team to determine whether any changes to the project plan are required. 4 The last step in “expecting” change is actually making the change. Note the data that is required to get to this point: first, we had to have a baseline – a plan. Second, we had to gather actual project performance information. And, both these data points needed to be accurate (a challenge in itself.) Now we’re ready to compare the project plan against actual project performance, analyze any differences between the two, and decide what to do (if anything) about the difference. We also need to make this decision as a group: in order to avoid making changes that have undesirable effects on other areas of the project, the group of stakeholders responsible for reviewing and approving proposed changes to the project plan should represent all areas of the project. Such a group can be formal or informal but should adhere to a consistent process each time it meets to discuss potential changes to the project. These stakeholder groups have several different names; the most common is a Change Control Board. 5 To review our discussion thus far, the slide summarizes the basic components of all project change control processes (not just change processes related to scope.) All change control processes are similar because they all fall within a larger process known as “integrated change control”. Although our discussion going forward will focus solely on monitoring and controlling project scope, you might find it interesting to take a look at PMBOK® Guide chapter 4 that focuses on “project integration management”, particularly the processes that occur during project execution and beyond. 6 Let’s now examine what’s involved with monitoring and controlling project scope specifically. There are two processes associated with scope monitoring and control: “validate scope” and “control scope”. You may have noticed project scope is the only project management knowledge area that has TWO processes associated with monitoring and control. Every other specific project management topic – schedule, cost, risk, quality and others – has just one control-related process (take another look at the PMBOK® Guide page ) This is because the status of our project’s scope is more difficult to measure than the status of our schedule or budget, for example. Either the project is delayed, or it isn’t. We’ve either spent more than planned, or we haven’t. Project scope is more nuanced: it’s possible, in some cases, to “somewhat” satisfy a requirement (and, as we discussed very early in the course, project scope is a matter of opinion until written down and is even then usually still subject to debate.) We need a separate, formal process, then, to determine whether the scope-related outputs of our project are acceptable or not. The “validate scope” process provides this formal acceptance: either project deliverables are acceptable according to pre-defined acceptance criteria or they aren’t. This validation process is different than controlling project scope, which involves measuring the degree to which project scope is (or is not) on track and then acting accordingly. Let’s look more closely at the scope validation and scope control processes on the next few slides. 7 Here are the components of the “validate scope” process, in the usual format: inputs on are the left, tools and techniques for performing the process are in the middle, and the process outputs are on the right. Note that although the entire project management plan is cited as a input, the important components for the “validate scope” process are the scope baseline (which refers to the combination of the scope statement, the WBS, and the WBS Dictionary) and the scope change management processes contained in the scope management plan. As you might expect, the inputs to the “validate scope” process represent all the scope-related components from the project planning phase, with one exception. “Validated deliverables” isn’t an output of project planning, it’s the output of the “quality control” process. This implies that before verifying any deliverables are acceptable, we’ve already used quality control tools to affirm the deliverable performs per requirement. Keep in mind the “perform quality control” process also uses “inspection” as a tool (one tool among many), just like the “validate scope” process does. For this reason, some organizations will combine the “perform quality control” and “validate scope” processes if further quality control measurements (like statistical sampling, for instance) aren’t required. But if the “perform quality control” and “validate scope” processes both use inspection as a tool, then what’s the difference between the two processes? The difference is the output: quality control judges whether a deliverable is correct – to what degree a deliverable conforms to the predefined requirements established for it. Scope validation determines whether a deliverable is acceptable – according to pre-defined acceptance criteria. Shouldn’t requirements conformance and acceptance criteria be similar, if not the same? If requirements were well-written, yes: they should be exactly the same. If, however, requirements were not clearly written, then it’s possible for a deliverable not to conform to requirements but still be acceptable, especially if acceptance is loosely defined in contracts or other formal documents. Separating correctness and acceptance into two different processes allows a project team to analyze each deliverable from two different perspectives (and make deliverable changes, 8 as necessary, before declaring a deliverable to be “acceptable”.) 10 8 As mentioned on the previous slide, the biggest advantage to the validate scope process is its formality: when deliverables have been formally declared acceptable, it’s much easier to close out project tasks, contracts, and phases (including closing out the entire project itself.) In many cases, formal acceptance of all deliverables is a contractual requirement in order to consider a contract fully satisfied such that a vendor can request and receive payment. As you might expect, sometimes deliverables aren’t acceptable and modifications are necessary. This is why the “validate scope” process can also produce formal requests to change the project scope – and why a second scope control process is needed. Let’s now look at the “control scope” process. 9 Here are the process components for the “control scope” process. Note they’re very similar to the “validate scope” process, with a few important differences: Controlling scope is achieved by comparing the cost baseline (the project plan) to actual project data to date. This comparison – also known as variance analysis – can be done at any time during the project. Inspection (the single tool used to validate scope) can only be conducted when there are validated deliverables to inspect. The primary output of scope control isn’t final approval of the project’s scope (whereas “accepted deliverables” signified final deliverable approval in the “validate scope” process.) Instead, the primary output of scope control is an in-progress measurement of how the project scope is actually progressing compared to the project plan. Note here that “organizational process assets”, refers to any pre-existing, standardized processes an organization might use to control changes on a project. Although no two projects are exactly alike, most organizations prefer to use a standardized process for reviewing, analyzing, and formally approving proposed changes to any project, because doing so helps the environment around the project remain stable and predictable. Finally, it’s misleading to say there is only one primary tool and technique associated with scope control. “Variance analysis” – the act of comparing planned and actual project data – can be conducted using many tools. These tools can be fairly simple, such as progress reviews, status presentations, team status meetings. Depending on the complexity of the project (and the ability to measure planned and actual data quantifiably), variance analysis can also be conducted using different mathematical calculations (earned value management is one such form of variance 10 analysis). What’s most important about variance analysis, of course, is that it’s actually done: that a project team has accurate data about both the project plan and actual project performance. The degree to which variance analysis is conducted should reflect the project’s risk level, past history, and tolerance for variation from plan, but even simple projects require valid variance analysis in order to be able to decide whether change to the project plan is required. 10 The primary output to the scope control process is always a change to the project plan, it’s simply measurement of the difference between planned and actual project progress. This “work performance information” doesn’t necessarily mean changes to the project plan, project documents, or processes are required – changes are sometimes an output to scope control. Work performance information, in contrast, is always an output to scope control. That said, since changes to the project will at some point be inevitable, let’s examine what goes into a change request and how to complete one successfully. Completing a change request will be your written assignment for this week, so you may find the next slides particularly useful to review when preparing your assignment input. 11 The next few slides will discuss the entire process by which many organizations formally review project variance analysis data. Organizations may refer to the group of project stakeholders that examines project data and decides what actions are required by many different names; for discussion purposes in this class, we’ll refer to this stakeholder group as a Change Control Board. If project variance data seems to indicate change to the project plan is needed, that change is formally requesting using a change request form. Similar to other assignment templates, there is a change request template contained in this week’s “assignment” area on the course website. And, similar to other templates we’ve used in the course, there is no single format used for a change request – the format usually depends greatly on what an organization (or even specific Change Control Board) requires. The components of the change request template provided in course materials are common to most request forms, however, so we’ll next discuss each component. Regardless of the request format, however, all change requests share a common trait: they should be short – generally one page or less. Consider that a Change Control Board is likely reviewing multiple change proposals at a time and can’t afford to spend significant amounts of time reading pages of project data. This means, for each component of the change request, it’s important to be clear in a very concise way. 12 When completing a change request form, it’s often helpful to consider what a Change Control Board member would need to know if you were not present to explain the request. Consider the questions you would be asked. This begins with using a standardized name for the project (“website update”, for example) so that all changes requested of the same project are easy to identify. Similarly, a Change Control Board may decide to revisit a change request later in the project, so identifying the date the change request was originally submitted is an important way to show how long a decision on the proposed change has been outstanding. The most important component of a change request is the description of the change you’re requesting, which can be harder to articulate than it seems. Consider, if your change request was approved, what are you asking for? What exactly would you change in the project plan? Which task, requirement, output, or deliverable would change? What would change: the duration, the resources needed, or the nature of the task itself? Resist the temptation to explain why the change is needed in this section; most request forms summarize and justify the request in two separate sections. The most challenging part of describing the change needed is to do so concisely. Keep in mind a Change Control Board is often limited by the amount of time that can be spent reviewing change requests, so using a bulletized list or identifying tasks and requirements by tracking number may be helpful. More than two paragraphs is too long; expect that it will take a few attempts before a summary of the requested change is in final form. 13 As mentioned on the previous slide, details regarding the requested change and why the change is necessary are often (but not always) identified separately. Summarizing the requested change in one section and explaining why the change is needed in another section allows the reader – and the writer – to focus just on the change that’s needed, without immediately focusing on what’s happened to make the change necessary. Before making a decision, everyone wants to understand the potential consequences of that decision. As we saw earlier in this lecture, “consequences” on a project are generally measured in three ways: consequences to the project scope, consequences to the project schedule, and consequences to the project budget. Since, for purposes of this discussion, we’re focusing on scope-related change requests, and the triple- constraint theory tells us we can’t change the scope of the project without impacting at least the schedule or the budget, a change request needs to specifically identify what schedule and/or budget changes will be needed. 14 We saw earlier in this lecture that just because a project has varied from plan does not necessarily mean change is required. It’s possible that the variance from plan has a negligible impact, or that the variance is one-time occurrence that doesn’t require action (at least not at this time.) This is why it’s important to ask the question “what if we do nothing?” Sometimes, the answer is also “nothing”, or the result is so insignificant the best course of action is to continue to execute the plan. Sometimes a Change Control Board may decide to wait to approve a requested change until more project data is available. If this is the case, it also often means the project has assumed a certain amount of risk, so it’s important to keep track of project progress (using an updated Risk Register) and watch for any further variance from the project plan. It’s important a Change Control Board is made aware of the “ripple effect” of approving the requested change on other areas of the project. Will making this change impact any other tasks or deliverables? It’s most important to ensure that any approved changes to the project plan do not impact project requirements as much as possible – keep in mind those requirements (particularly business requirements) are the reason the project was undertaken. It’s still possible for a Change Control Board to approve a proposed change even if that change means modifying other requirements, but the idea is to approve such a change with full understanding of the complete effect the change will have. 15 Change Control Boards were originally established to standardize – and streamline – the process by which proposed changes to the project are reviewed and approved. Part of the benefit of having a Change Control Board is that project changes are generally identified, reviewed and approved more quickly than in organizations that don’t have Change Control Boards. That said, every decision-making body needs to be aware of any time constraints on its decisions. Sometimes, a proposed change to a project can only be made within a certain time window, or perhaps the cost of making a change will increase as time passes. If there’s a limited amount of time in which a proposed change can be made, it’s important to advise a Change Control Board of this time limitation. Finally, just as with other scope-related deliverables, it’s important that a change request receive formal approval, usually via signature. Who should sign the change request? Change approval authority can vary from project to project, but generally, the person (or people) who had authority to approve the original project scope (as identified in the signed scope statement) have similar authority to formally approve a change request. 16 While a standardized change request form is a good way to help a Change Control Board make decisions, generally more effort is required to help a Change Control Board work successfully. A few “best practices” associated with running Change Control Boards are identified above, and the most important best practice is identified first: educate the project team on how to deliberately and collaboratively change a project – before such changes are required. Educating the team (and the Change Control Board) is one of the best ways to help manage stakeholder expectations, as you saw from this week’s readings. If project stakeholders understand and are involved in establishing project change control parameters from the beginning, the possibility of scope “creep” drops significantly. Similarly, maintaining a record of project changes – both approved and denied project changes – via change logs or issue logs helps project stakeholders understand the status of the project and the best way to proceed going forward. 17 Before concluding the lecture, it’s a good idea to briefly identify and describe a project management methodology with which you may already be familiar with (or heard about): agile project management. Agile refers to a project management methodology that was designed specifically to define and control project scope in extremely dynamic environments. You may have noticed throughout this course we assumed once solution requirements were identified there might be minor changes needed but the majority of requirements would remain fixed. This may be true in a project environment where tools and outputs don’t change very often, but what happens when the project is producing an output so innovative we don’t even know what the final product might look like, or in a project environment where the tools needed to produce the final output are changing? Traditional (sometimes also referred to as “waterfall”) project management assumes stable and predictable project outputs, tools, and environment. Many projects – particularly information technology projects – cannot make this assumption. Within the technology world, for example, we are all familiar with how often hardware and software is updated to take advantage of improving technology. What if, however, the stakeholders (and their requirements) worked with the project team every day to define – and refine – requirements as the project progressed? What if project outputs were built in small pieces and requirements for yet-to-be-built product features weren’t defined until already-built features were tested? These are the ideas behind agile project management: that customers could work with the project team extremely frequently to identify, design, and test project outputs in extremely short cycles, only moving on to the next cycle when the outcome of the previous cycle was successful. While agile project management is certainly able to respond to changing project scope, it can also be difficult to implement, particularly with large stakeholder groups or stakeholders who aren’t willing (or able) to work very closely with the project design and implementation team. The success rate of agile projects, however, is growing, so it’s worthwhile to know about agile project methods and evaluate whether projects might benefit from them. Both your individual and discussion board assignments this week focus on developing change requests for case study projects. For the former, we will collectively act as a Change Control Board for the Rosa County case study and vote on proposed changes to the project. For individual assignment, you’ll need to submit two change requests for your individual case study project. 18