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

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 ...


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 ...


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

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

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

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

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

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

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

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

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

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

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

If it's "required" to allow the project to work as it was functionally described in the specification, but it came out as you were working on the project, then it's both parties fault and you need to negotiate the terms with the client (costs/timelines). It might be good for you to give further details for a better answer.


1

Schedule a meeting with them to talk about the technical debt and the development process in general. Create an interesting presentation with images and figures to support you. Cover the following topics: the 'invisible' part of development. Not all dev activities result in a customer-facing feature. There is backend stuff, refactoring, research, ...


1

With one particular client, what we did is mark those cards as "Cancelled" status to keep track of the reason why we considered those out of scope. Then, to keep the backlog clean, we filtered those cards out of the actual board for the project. This way, they won't get in the way of daily work, but remain accessible for reference if needed.


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 ...


1

Sounds that you are looking for a Requirement Management Tool like Doors. This would be an off-topic question and you might find better answers in Software Recommendation StackExchange. Nevertheless, you are asking a project related question: How to deal with scope and scope changes. The general mechanism regarding scope and scope related changes are ...


1

You control scope, cost, schedule; everything you do responds to those numbers. First, I'd make sure that my team and if possibly my customer have received the requisite training (that's a joke - go view the video, you'll thank me). Then I just add the clients' requirements to the requirements, project the impact on cost, scope, schedule, and quality and ...


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