8

I agree with CodeGnome's well-founded comments about change control procedures. However the scenario you described and your question could occur regardless of how effective your change control procedures are. For now let's assume you have good controls in place but are still concerned about "how do you handle people who obviously try to add and change scope ...


7

The Project Managers know there are other options that will work better. The implication behind this sentence is that the PMs know with absolute certainty the other options will work better. If my inference is right, I find that implication odd as I am not sure I have ever experienced a time when a complex problem had a solution that was guaranteed to ...


6

You don't need any of that; close your spreadsheets. You need a change management process which include a governing body. Scope changes via new requirements is the type of change that would go through this process. If approved, you get a new plan. You get to rebaseline. You get more money. You get more time. What you have now is scope creep. ...


5

Timing is Immaterial When you ask: How do you handle people who...change scope at the worst possible time in the project life cycle? you're missing the forest for the trees. It doesn't matter that the scope change comes at "the worst possible time." The issue is that your project should already have change controls in place to deal with scope issues and ...


5

TL;DR I probably would have picked "C" as well, but can see what they were trying to get at with their selected answer. I don't agree with it, but I can see the point. It's an academic answer that probably aligns with something in the PMBOK, but that doesn't mean it's either a great question or a great answer. Ivory Tower Answers Most tests, and ...


5

These are two judgement labels applied to the exact same behavior, based on the outcome. If you get it right, the customer is delighted. If you get it wrong, you gold plated and the customer is upset. I think the concept of gold plating in project management, and the teachings around the concept of avoidance, is based on the thought that the risk of ...


4

I've been dealing a lot with a scope creep over the last 2 years. I created a list of things that is a must to keep in mind in order to minimize the negative impact on the project. At first - you should realize that scope creep will happen! You should: know the requirements; know the client's expectations; have balls to say "No". Saying "Yes" to placate ...


4

Treat it as a change request. Assess the impact on scope, schedule, cost, quality, and conformance with mission needs. Find Key Performance indicators to discriminate between the options. Make sure that the stakeholders are aware. Then decide if the impact on the project is sufficient for you to walk away. Be careful; As @David Espina hints, their ...


4

One of the four values of agile is "Customer Collaboration over Contract Negotiation." The first thing to ask is "what is best for the customer?". Once you've done that, then you ask "is it covered by the contract?" and only then do you delve into the "do we ask for more $". Specifically focusing on your issue the first question I'd ask is who was ...


4

I see two (or well, three, if getting a new job counts ;-) ) possible ways to deal with such situations in general: When you receive a refusal like above: ask for clarification or more explanation, open a discussion to understand the other party's view and to come to a common agreement based on facts instead of feelings. To avoid receiving refusals: make ...


4

Let's pretend you had a physical card wall for a moment. You've got some cards that someone thought was a good idea, but on further review, they're not actually so great. What would you do with the cards? Would you create an separate section on your wall for these worthless ideas or would you chuck them in the nearest waste-bin? Yeah, you'd toss 'em, so ...


4

The accountability resides always with the project manager, the responsibility can be delegated. If you look at page 25 of PMBOK v 6, table 1.4 Process 5.2 Collect Requirements is specified as a PM accountability.


4

It’s All About Expectations “Unapproved” doesn’t really capture the essence of scope creep. In purely pragmatic terms, scope creep is a slow or gradual increase in scope beyond the original plan. A scope gap (which is not really a very common term, in my personal business experience) is just the shortfall between stakeholder expectations of included scope ...


3

There is a reason they call it the "iron triangle". Like another said, it often rights itself, but if all corners are fixed then quality or lack there off is often what is sacrificed. You get to choose one, in reality. If you are fixing cost/resources by having one dev, then that leaves you time or scope. If you have a deadline, then that leaves scope. ...


3

A simple burn down chart might do the trick. We'll side step estimating and the value of it right now, that's a longer term thing that will help in the long run. Instead we'll go with fixed time as it sounds like you have a really solid grasp of the work you have to do. Step 1: Determine the number of workable hours remaining in your project. This is ...


3

I have formulated and defined the following view over many years and now use it quite successfully when I am at an interview seeking a role, and of course in real life when managing projects. Successful delivery (Waterfall method) comprises the following key elements to the Five-point Plan (MarvTM) Know your requirements in clear, accurate and unambiguous ...


3

At our firm we have a few ways of tracking out-of-scope tickets, all of which have proved useful for different Product Owners depending on their style. Issue Type: In addition to JIRA's normal "User Story" issue type, we've created a separate type ("Iterative User Story," but you can call it whatever you want) that indicates an issue is outside of the scope ...


3

An easy solution would be to load the values in excel of your planned work, and then load the values of your actuals, and you can display progress using a cumulative graph. Here's an example: I used 155 as your planning value and loaded it assuming equal numbers each week, which produced a flat loaded schedule. Then I made up actual values but showed it ...


2

Crashing can be successful. I've done it. But most people make several mistakes: They UnderCrash usually crashing takes 3 to 5 times as much cost to successfully overcome the problems caused by the inertia of brooks law. Most people severely under calculate the amount of resource required to crash a project. A project that is 25% complete at the halfway ...


2

The triangle balances naturally. You can independently fix or manipulate one or two of the sides, but the third is dependent and will adjust to balance. But this is not your problem. Estimating is not your problem, either. You can estimate all day using all the tried and true leading estimating practices and it will not touch your dilemma. There is a ...


2

Generally a Project Manager is not the only person involved in estimation. They may involve some technical members who have experience of executing or who may be actually working on those projects. The Project Manager may need some help with estimations and work-breakdown which is normal. However, after it has been done and before it is sent to the client, ...


2

Focus on customer value. Just because the client thinks of a new function doesn't mean the one you are writing right now has lost its value. I try to follow these guidelines: - Slow down. Do not jump to the new scopy things. The original scope was analysed and considered carefully. The new scope probably just popped up. No way all the requirements and ...


2

In Business Requirements Document: A High-level Review the author defines business requirements as making reasonable estimates of how big a project is and how much it is going to cost. He then explains what would be in the Business Requirements Document (BRD): The most common objectives of the BRD are: - To gain agreement with stakeholders- To ...


2

TL;DR At this stage, the project manager's job is to provide a framework for the companies to address scope, and to estimate the budget and resources needed to deliver that scope. That's it! In situations like these, questions of fault (unless of course it's yours) are really outside a project manager's scope of responsibility. Rather than assign blame, or ...


2

Staring at a 20-page SOW and contract in the IT world, it sometimes is very hard to determine if a request is out of scope, so looking at your three-line description is even more difficult. It would depend on what you mean by "detailed" and how the additional work related to those details. Also, you commingled terms: specifications describe what will be ...


2

Preferred Solution Insist and/or suggest (depending on your culture/seniority) that a Change Management Procedure be put in place. The concept being: Since a Dev team's time is a zero-sum game, for everything they add they have to subtract something else (or extend a deadline). Alternate Solution If that's not possible, then you need to insist that ...


2

Scope change can be measured using project management software such as Jira. Perform an initial scoping exercise with the team at outset, and create tickets in the project management software. Create the tickets as individual user stories that are capable of being reasonably accurately estimated using story points. Collect the tickets into a backlog in a ...


1

In my experience, the document that will prevail will be the one signed off by both parts. If the BRD was very clear about 3 reports but the client wasn't aware of it, it's up to the project to absorb this mistake - and review ASAP the BRD for further gaps If the client was aware of the BRD and signed it off, it's a matter of replanning If there's no formal ...


1

The SOW is contractual. The BRD is a work product. The SOW will likely prevail if this ever ended up in dispute. That said, the BRD is not without weight. If the extra reports are onerous to build and will impact you from a cost perspective, then get the customer to the table and discuss more money. A reasonable customer will negotiate. An unreasonable ...


1

The basics of how to organize a project like this in Jira are well documented on well, Jira's Confluence site, and granularity issues are directly addressed in Atlassian's Delivery Vehicle's page. A very brief distilled answer is that: Create a User Story to document the tiniest unit of releasable feature (something that the customer can review, test and ...


Only top voted, non community-wiki answers of a minimum length are eligible