Project estimation with increasing requirements

Question

Making a project estimation with given a requirements set is one thing.

But, what happens when the user suddenly starts changing them on the fly and starts adding new requirements to the already defined set? And even goes to an extent to be mad about why the project is not finished in the originally planned time frame.

How should I deal with these situations? Proposing some methodologies and readings could be helpful.

Methodologies are useless here. It is necessary to make it clear that requirement changes come at a cost, and that's a customer relations issue. Some methodologies are better than others at handling changes, but none will handle scope creep with no additional cost in time. — David Thornley, Mar 25 '11 at 19:48

Robert Harvey · Accepted Answer · 2011-03-25T19:39:54.947

11

You have to make it clear to the customer that requirement changes are also changes in scope, and provide updates to the estimates every time there is a change to the requirements.

Project estimates are called estimates for a reason. They are not promises. If the customer wants to make them promises, that's a different deal; you now have to provide much larger estimates that have a higher probability of success, using frozen requirements.

Most project estimates provide a certain level of padding, anywhere from 20% to 100% time premium (or more) over an ideal estimate. Make sure your estimates include this padding.

Agile methodologies exist that provide better visibility for the customer, so that they can have a better idea of the effort involved, and how his changes are impacting the timelines.

edited Mar 25 '11 at 19:39

answered Mar 25 '11 at 18:22

Robert Harvey

198,589
55
464
673

I fail to see how agile helps. In fact it most likely hinders visibility since the end project date is more fuzzy. Whereas a more waterfall approach will say, sure if we add these requirements it is going to add 3 months to the schedule and X dollars to the cost. – Dunk Mar 29 '11 at 19:15
1

@Dunk: What I mean by visibility is the ability of the customer to "see" how his changes are impacting the project. Visibility is not a promise; it's just an open-door policy. Waterfall doesn't guarantee good estimates. If anything, waterfall must insist that the customer not make *any* changes, if the estimates are to be useful. – Robert Harvey Mar 29 '11 at 19:22
1

Agile gives the customer an illusion of being in the loop, which in turn gives them some idea of the impact their changing requirements may have on the development cycle. As such it can be a tool to teach customers a lesson about what their attitude can do to a project. – jwenting Mar 30 '11 at 06:35

score 6 · Answer 2 · answered Mar 25 '11 at 18:22

You need to update the estimates when they update requirements, and have a defined spec of what the client will accept as "done". "My previous estimate was for feature set X, Y. If you want me to add Z, I estimate that will extend the delivery date by...", etc

score 4 · Answer 3 · answered Mar 25 '11 at 20:04

4

You should formally communicate impact on schedule and cost to the customer and the management when changing the requirements or adding new ones. Do your best to impose formal approval mechanism so they think deeply before they ask for anything new or any change. Otherwise you will keep hearing "I want you to add XYZ" and later "Did I say XYZ I meant ABC".

answered Mar 25 '11 at 20:04

M.Sameer

1,374
4
11
20

Any suggested resources/readings, shared experiences on this formal approach? – TheBoyan Mar 25 '11 at 20:17
1

What I mean is to do the following: (1) Ask for one person (may be per topic)to act as the requirement provider. (2) Accept only written requests. If you get request by phone call or verbal communication or meeting you should write the minutes and the requirements and say clearly what you are going to do and send it by email or written format and include the needed extra time. (3) when informing your technical leader state the impacted areas of the application so he can either advice you of better approach or support you in your decision. – M.Sameer Mar 25 '11 at 20:35
1

(4) If you receive requests in written format but they are unorganized or unclear, you may propose templates for Change Requests. (5) Keep track of all change requests because it's very important for project manager to know the instability of requirements. If you want you may read about Requirements Definition and Management, Change Management and CMMI. – M.Sameer Mar 25 '11 at 20:39

score 3 · Answer 4 · answered Feb 15 '12 at 13:48

Think of your project as a triangle (a PM buddy of mine actually made a physical triangle he used for added effect). The edges are called time, cost and scope. You tell your client that he can have control of 2 sides, but you (responsible for delivery) must have control of at least one.

So, you can do it fast and cheap - but then you have to have the power to cut scope.

Or, you can get more features, but that will take either more time or more money.

Read more at http://en.wikipedia.org/wiki/Project_triangle

score 2 · Answer 5 · edited Feb 15 '12 at 10:32

You can try to implement Scrum, an agile methodology which, according to your situation, could be very helpful.

From Wikipedia:

Scrum is a process skeleton that contains sets of practices and predefined roles. The main roles in Scrum are:

the “ScrumMaster”, who maintains the processes (typically in lieu of a project manager)

the “Product Owner”, who represents the stakeholders and the business

the “Team”, a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

During each “sprint”, typically a two to four week period (with the length being decided by the team), the team creates a potentially shippable product increment (for example, working and tested software). The set of features that go into a sprint come from the product “backlog”, which is a prioritized set of high level requirements of work to be done. Which backlog items go into the sprint is determined during the sprint planning meeting.

A bigger project will likely take more time, scrum or no scrum. Agile will likely make it easier to swap features around, and make it easier to deliver something useful if a deadline is suddenly imposed. It won't stop feature creep. — David Thornley, Mar 25 '11 at 19:46

score 2 · Answer 6 · edited Apr 12 '17 at 07:31

It's not about methodologies, but about communication with a customer.

I had many situations where customers wanted to constantly add new features to a non-finished project, and were surprised why it would increase the overall cost and delays. The context and the personality of those customers being different, it required different approaches, but I may try to isolate some guidelines and advice:

Ensure that a customer has an access to the general information required to understand why a change in a requirement may impact both cost and delay. In other words, publish some articles about those things, explaining what a non-technical person may not know at all.

For example, for most people, it's totally weird that a change they consider tiny may have a huge impact on the project and be very expensive (see example in my question). If they ask to do some changes, and every time you tell them, without explaining anything, that they would have to pay thousands of dollars when they expected it for free or for a few dozens of dollars, they would probably think you're just stealing their money. This is especially true since some unethical programmers and software companies develop unmaintainable products (so you can't ask to change it later by a normal developer), then ask you to pay too much for every modification.

Ensure that a customer has understood why the specific change she wants has an impact on a cost. For that, you can give her the links to your articles (see the previous point), or just summarize, in a non-technical way, what is required in order to make a requested change.

Such explanations are also a good idea since they enable your customer to have a better understanding of the product and the change. In a few cases, some of my customers ended by saying that the change they wanted was not too smart, and that they will do it in other way. You can also suggest things. It is highly appreciated by some customers (warning: some other hate it), and shows that you know what are you talking about (by comparison to the code monkey who just translates the requirements into code, without thinking too much about the possible approaches).

Ensure that a customer cannot do whatever she want, unless she's really sure. For some people, the only way is to lock the requirements definitively before starting to code. Otherwise, it is a disaster, and the project will never end. For others, it's just a good idea to never see an unterminated project (in general my customers have live access to the unterminated product very early, so they can make comments/adjustments early too).

For example, I had a customer who, after sending "final" requirements, sent, on average, ten mails per day with ten requirement changes, going from minor modifications ("Can you change the border width of the middle zone on the home page from three to six pixels ?") to the changes which affected the whole project (after two months of development, one week before the release : "Finally, I think ASP.NET is a bad idea. Could you switch to PHP please?").

So for that customer, we were forced to lock all requirements before writing code. It was written in the contract. No changes were accepted before the final release.

It wasn't too bad, finally, since curiously it us allowed to be very organized: the project was released, according to the old requirements, and then, a few days later, we started the next version from scratch with a completely different set of requirements.

Project estimation with increasing requirements

6 Answers6