• Coding

  • [Discussion] Dealing With Frequently Changing Requirements

Hi everyone,

I am damn sure you've been in this situation before: You meet your client and agree on taking the project. The client sends you the project description and you get to work. A few days later, the client calls you up and tells you something has to change. Ok fine. Then a few days later, the client calls again and asks for more requirements and/or tells you more changes have to be done. Now, twelve hours of work need to be thrown away and you have to start over. You tell the client that you will have to charge them for the extra work. If the client was a good kind person, they would understand and gladly pay you. But, in most cases, the client isn't that nice guy and complains that those were some minor changes that aren't really worth mentioning.

Well, that was a brief description of the situation. I know you've met this type of clients before. How do you usually deal with those clients?!
You sign a short-term contract stating the job description, payment rate, and other points if desired (deadline, progress reports, that kind of stuff). That way, both of your rights and liabilities are clear. If the client doesn't agree => he/she isn't the nice person you described and is not worth working with. The clients need to understand that they're gonna pay for every hour you spend on the project whether they will keep it as is or imply some modifications later on. Any work done, no matter how small the modifications, is work, and you have the right to get paid for it.

Besides, didn't you agree on some sort of outline for conducting the project (be it a database, website, whatever)? Always agree on major guidelines (hold a brianstorming session) so that your vision of how to implement the project meets with the needs and requirements of the clients.
@mesa177: We already did that. My current client is a nice person actually. But sometimes it is really annoying to have spent quiet some time researching and working on something, and then you have to change everything and start all over. We actually signed contracts and then added some extra requirements which I will get paid for as well. Money is not an issue with this specific client, but it used to be with most of my other clients. But just like I said, it's not just the money, I just hate re-doing things over and over again. Even thought I'm trying to keep my code as abstract and flexible as possible, I still end up having to re-code things from scratch a few times.
This is actually a real-world issue that most major companies in the world have to deal with. Clients change their minds. That's how it works. They always do, always will. And it's not about to change.

There are however different things you could do:

1- Legally, you could sign a contract where you get paid by the hour, not by the quality of the end result. Some clients won't accept to sign that, but you can always suggest it.

2- You can try to limit the number of changes the client requires, by creating a fee per change system. Every time the client wants to change the modifications, he or she will have to pay.

3- The most interesting way: Learn to work with Agile.

I wish I had more time to expose better how Agile works. If people show interest, I could write a broader presentation.

Agile is a work methodology (or a group of methodologies) that have been developed in order to tackle the issue of clients changing the specs. The basic idea is the following: The later the change is made, the more difficult and costly it will be. So by implicating the client in the development, releasing often and stable, keeping the requirements per sprint to a minimum, you can achieve extremely high levels of flexibility.

Here's an article I wrote over a year ago about one of the coolest Agile methodologies: Scrum. Read it, and don't hesitate to ask if you have any question.
rahmu's Scrum approach is actually quite close to what I was going to suggest: Having progress meeting sessions is your best chance for flexibility. On the first meeting, you agree with the client on a general outline, then agree on what specs of the project to work with and reflect upon in the next progress meeting; this is what the "sprint" term indicates (right?). In each "sprint", you have a set of tasks that you have to work on and present a workable product or feature pertaining the tasks. It doesn't have to be perfect, just good enough to give a general idea about how you tackled the issue. If the client likes the approach, you later work on improving it. If not, you change your approach to present the second version of the "sprint" product. This way, you can minimize the work time and effort exerted on solving each set of tasks, and you can tackle the changes at an early stage rather than later where implementing the change is more difficult.

Now while Scrum targets working in a group, and your team is a one-man show, divide the project into a set of Scrum-teams each pertianing an aspect of the project (which will complied together at the end of the project). Alternate each Scrum-team with each progress meeting: For example, in week one you present Scrum-team 1 product. You discuss with the client what changes are needed, and implement them later on. However, Scrum-team 1 product needs time to fix, and may influence other Scrum-team products, so Scrum-team 2 product is presented in next week's progress meeting. This way, if Scrum-team 2 product needs changing which influences how Scrum-team 1 product is modified, you wouldn't have wasted time on modifying Scrum-team 1 product twice. It also can set a more clear way of how to tackle the tasks set for Scrum-team 3 and the others.

Hope you got a clear idea of what I meant.

PS: Nice article rahmu :)
@rahmu, thanks for the Scrum link, I've been researching it lately and that was really useful. Do you think it can apply to single-person "teams" as well? The recommended size is 5-8 people.

Usually, when I'm asked to make a change to a product in the middle or late in my development process I do one of two things:

1. If it will require too much work and throwing things away, I schedule it for the next development cycle. I say, "this revision of the software won't have the feature you want, but it's planned for the next release".

2. If it doesn't take too much work but it's a secondary feature, I put it at the end of my to-do list. If I get to it, great. If not, it goes in the next release.

The reason I can get away with this is because I'm not a freelancer, I have the authority to prioritize features the way I see fit as long as the releases are stable and working. Of course, there will be times when someone walks in and says, "This is a priority! Get it done ASAP!". In that case, I really have no choice and I have to drop what I'm doing and build that feature.

I came across this article recently. It's about being a consultant but it applies to freelance programming as well. Here's a quote:
Consulting maxim:
Your customers are buying your judgment, not just your time
@mesa177:
Here's a small distinction essential to Scrum: the product delivered at the end of each sprint should be stable, tested and production-ready. Sure your product at the end of sprint 1 would be very low on features (probably do only one thing). But it has to do it right and bug-free. Remember, you're delivering a finished product to the client.

About working in Agile alone. I have never made the experiment, but strongly encourage people to try. Here are some true advantages I see:

* Running different sprints, and showing an end product to the client every time will make him involved in the development process and will give you a greater flexibility in case he decides to change his mind.

* You get paid by sprints, so you don't mind how many changes the client does.

* You get to focus on one thing (or a small number of things) at a time. Instead of working on the "whole project", you get rid of the distractions and focus on getting your job done.
@rahmu: That is a great article. I like this methodology but I do not think it's very applicable to my situation. My team is just the designer and me. The designer was late in delivering the design so I've been spending the past few weeks optimizing my domain model. If this methodology is supposed to manage teams, and sprints would be 2-4 weeks long, then I wonder how long would a sprint be in the case of a one programmer effort.
rahmu wroteIf people show interest, I could write a broader presentation.
I am definitely interested! I've seen the word "Agile" in several articles and blogs before, but I never got into knowing what "Agile Development" actually is. So, an overview and a few examples (pertinent to my situation: one programmer only) would be very much appreciated.
in the contract, i make my clients sign on 2 major modifications within the first quarter of the time from the day the contract is signed to the deadline and 3 minor modifications on the whole duration of the project, (minor and major are defined by ME) anything extra requires extra resources be it time or money, be clear from the start, no one is supposed to be nice in the world of business, they are supposed to complain to try and get it for free, i know i would do the same if i am not bound by a contract,
I have not have that exact situation, where I had to throw away 12 hour of work! If I had the customer's agreement on what I just did, then I guess I would have the confidence to say "no" (or rather make it clear why it's a bad idea) because it is too much work - unless it is really justified work.
In your case what you describe can also be symptoms of general dissatisfaction and doubts from the customer...
In any case I think a freelancer must be involved in the project as more then a programmer, sometimes the customer is ignorant about the consequences of his demands and you have to save him from himself.
The way you deal with the customer may also give him an impression that this is easy work. Make it look serious!
Another thing I have learned to do is require a 25% down payment when work starts.

Besides, that's not how things work AFAIK, you only code one time, and you do that once the design is fixed, including the GUI and everything. It's the first time I hear about such stuff... It doesn't make sense to me, why would anyone throw away money and delay results... they're supposed to be in a hurry to see it working.

PS: I'm not saying it's your fault - I don't know the details but have a feeling it's not - I'm just trying to help.
In Lebanon, with clients failing to describe their main requirements, two main development models come into hand:
Iterative model:



and Spiral model:



I prefer the spiral model since it has prototyping. One thing about the customers, is that they might forget about some main features up until they see a prototype, not to mention, they might hate something about the interface or how things turned out to be. So by doing prototypes and constantly showing the customer what was implemented so far, could save a lot of trouble with fickle minds.

I work in a bank as a developer, so our customers are actually the other departments in our bank, requesting programs to ease their work. By God are they fickle... sometimes they even request stuff that can't be implemented because of logic error, but this is another issue here :P.
the iterative model shows fast development, but the overall design and structure of the project is weak and badly constructed. I usually use the water-fall model. Functionality is brainstormed first (take your time with this stage, extend this stage as long as needed), then lock your functionality list (no more from the customer), finish the project according to the functionality list approved before, test. If the functionality needs to be changed then now is the good time. Go over the new functionality (also take your time with it), lock the new functionality list, develop, and test. the cycle goes on and on till the project is finished. then you charge on how many functionalities have been developed (including the ones that were changed). sounds fair to me.
TDD(TFD) + DDD = Win!

(So many Ds!)
MrClass wrotethe iterative model shows fast development, but the overall design and structure of the project is weak and badly constructed. I usually use the water-fall model. Functionality is brainstormed first (take your time with this stage, extend this stage as long as needed), then lock your functionality list (no more from the customer), finish the project according to the functionality list approved before, test. If the functionality needs to be changed then now is the good time. Go over the new functionality (also take your time with it), lock the new functionality list, develop, and test. the cycle goes on and on till the project is finished. then you charge on how many functionalities have been developed (including the ones that were changed). sounds fair to me.
Agreed, even though if the functionality to be changed hits the core of the design, changing things would be quite costly. This is one of the main disadvantages of the Waterfall model.

The nice thing about the spiral model is that you will not only help out the customer with deciding on the requirements, but also the development will be consistent with what they want it to be, but in the end it all boils down to what type of developed program/customers you have :).
7 days later
rahmu wrote3- The most interesting way: Learn to work with Agile.

I wish I had more time to expose better how Agile works. If people show interest, I could write a broader presentation.
Here's a very nice overview of Agile: The Possible Future of Agile by Mike Beedle, one of the creators of Agile. Definitely worth watching.

And rahmu, I'm still waiting the broader presentation. In particular, I'm interested in knowing how Agile methodologies could improve my workflow as an individual programmer (although, from what I understood from Mike's talk, Agile is only relevant to teams and enterprises, or maybe because he was mostly talking about Scrum?)
As I said before, I have never heard of anyone working Agile individually. It doesn't mean that it cannot be done necessarily, but you could try and tell us what happens. I think you should try to learn some Agile methods like Scrum or Xtreme Programming (XP) and then drop the parts that do not suit you individually.

In other words, I don't think you can apply Agile "by the book" if you're working alone, but still there's a lot you could learn from Agile.


Here are some cool things you could learn. They're not easy, but extremely beneficial in the long run.

* Test Driven Development (TDD). Writing proper tests (unit + functional), will help you greatly in controlling the quality of your products. A small presentation I had written.

* Continuous Integration (CI). You can read about CI on the Wikipedia page, or this article. I strongly suggest you take a look at Hudson, the best CI server in the market. Oh, and it's open source :^)

Coupling TDD and CI will take a lot of efforts at first, but you will definitely see a huge difference on your coding once it is set. Part of my job during my last internship was to set up this system and believe me it made a difference.

There are also great personal time management techniques you could learn. Here are a couple I know pretty well:

* Get Things Done
* Personal Kanban.

Anyway, here are the techniques I am familiar with. Don't hesitate to ask more about them, I'll help as much as I can. I also will write soon a broader presentation on Agile methods, (however let's face it, Agile is best done when working in teams).