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.
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.
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
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".
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
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.
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:
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.
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).
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.
