5 ms·

This is how we work with clients

64 points by flexterra 14y ago

goyalpulkit 14y ago
> We also explain the client that anything that does not get revisions or comments from them is automatically approved. A really good post. I hate it when the clients ask for last minute features (for free) after not saying a thing about this during the development.
- jpadilla_ 14y ago
  The great thing about this method is that when that happens the client is clear about that, we get to add another whole step, and charge for it.
paulbennett 14y ago
We too employ a 2-iteration process to the design/UI/IA stages, however I don't understand why the client should still have the option to make 2 iterations of changes during the development and especially deployment stages of a project. The elweb illustrated process appears to miss out a key section - functional specification. We derive our func specs from scoping meetings, navigation structure, required content etc. which is then presented to the client along with user journey flow diagrams. This is presented and discussed before the design stage - thus the functionality is agreed upon far before development happens. With this approach we don't run into the situation where the client wants to make changes during development which could potentially greatly extend a project's timescale (cost is less of an issue as it passed onto the client anyway).
- jpadilla_ 14y ago
  The process shown on elweb is just to illustrated the 2-iteration process, not a concrete example on how to make a website, more like an example of using the 2-iteration process on various steps of a project.
13hours 14y ago
We run an Agile process where the client is involved as Product Owner in the team. The client can add stories at any stage, and set the priority in the backlog at any time. They just can't change the current sprint's stories and priorities. That way they can make as many changes as they want, and the impact of those changes are always visible. Why limit the client to an arbitrary number of changes (like 2 in this example?) The whole idea of Agile development is that we cannot know everything in the beginning, so we spec as much as we can in the beginning, and leave room to change our minds at a later stage. Of course, we explain this way of working up front as well, and we make the benefits clear to the client. They have to buy into this before we start with anything. It works very well when they do buy in though.
- gk1 14y ago
  I assume you're not charging a flat fee, then? The approach described by OP provides much more certainty in terms of scope and budget, which a lot of clients prefer and allows for easier planning of resources for the managers. How do you deal with resource planning and also billing?
  - 13hours 14y ago
    We don't do flat fee no. We convince clients it's not a good idea for them to do flat fee, because it takes longer, and we build in a margin to cover our risk, so they usually pay more with flat fee. By making every step of the process visible to them, and charging them for what we do as we go along, we can save them money and time.
- rmrfrmrf 14y ago
  I like to feel the sense of completion of a project. When you let clients run amok adding requirements as they see fit, it lowers my morale as the project completion time drags on longer and longer.
  - 13hours 14y ago
    We've (almost) never had the feeling of "running amok". Communication is key, and constant feedback from the client helps us to make small adjustments often. That usually keeps them from making large changes at late stages, because we are evolving the project with them. Changes are usually an evolution, not a revolution, if that makes sense. The times where the changes were big and late, it was usually down to bad communication at an earlier stage.
digitalengineer 14y ago
I know the flow, use one myself for one of the biggest corporations out there. But in my experience it's more "This is how we wish to work with clients". I see a lot of "squeezing the agency" going on these days. (As in non-paid extra work and revisions despite agreements on how to work).
- msrpotus 14y ago
  It's important to set limits and explicitly say that changes made after approval will cost extra. Otherwise, they'lll just push you to do as much for free as they can get.
- gk1 14y ago
  There's always an "Oh, I thought of one more small thing..."
  - jpadilla_ 14y ago
    Indeed, and that usually becomes a problem at any stage of the project, usually converting it into a longer project, and if you're not careful you will surely loose money and precious time.
  - digitalengineer 14y ago
    Or the "YOU forgot about my remark 3 weeks ago regarding the -insert little detail that doesn't mean jack sh*t but I want it done anyways- ... (Sorry to rant)
- mikeryan 14y ago
  Yeah there's some stuff here which we won't see fly with our clients. Every step has at least 2 iterations. Sounds great but whats an "iteration"? Is a design of a whole website? What if they want a few tweaks on the about page after the second iteration because that area wasn't fully fleshed out originally? We also explain the client that anything that does not get revisions or comments from them is automatically approved Never, ever will this language be approved by our larger clients. We can sometimes get "deemed acceptance" language by but its never "immediate" its usually like "if no feedback is provided in 15 days". The alternative is to have a "pause clause" in (if you don't get us feedback in 15 days we have the right to put your project on "pause" until we can get back to it)
Hopka 14y ago
To me, this looks very similar to the waterfall model.
- nahname 14y ago
  Arrows all going in the same direction? Yep, that's waterfall.
  - anandagarwaal 14y ago
    but the steps are repeating..getting feedback from client after every step
twog 14y ago
I have met these guys in Puerto Rico (which has a great emerging startup scene) a few times. They are by far one of the top UI/Django pairs I have ever met, and could give any agency a run for their money. If you're looking for some smart guys, consider them.
cateye 14y ago
It is great how everyone describes their "process". In the end, it doesn't mean a lot because it will all depend on the mentality and knowledge of the people working in that process. At the point where people are using "the process" and not their brains and common sense, it will cause a disaster and you have to re-invent "the process".
- scott_w 14y ago
  There's a difference between "following a process" and "following THE PROCESS". Outlining the working process means that I and my client have an understanding, and that they have less grounds for being surprised about getting a larger than expected bill. It forces the client to be disciplined in their own behaviour, which they wouldn't be without a process. On the flip side, demanding clients fill out Form 27-B for Change Requests every time they want something changing is way, way over the top. In addition, a process can help give a client some confidence that you know what you're doing. This is especially true in the technology business, where clients tend not to really understand what they're working with.
  - cateye 14y ago
    The root cause of all the symptoms that you are describing is that your client hasn't got the proper knowledge, experience and mentality to (co-)develop something innovative. How exactly is "a process" going to change that so rapidly? (I haven't a simple answer and I am also struggling with this problem..)
    - scott_w 14y ago
      I think clients in this area tend to not want "innovative". From my (admittedly limited) experience, most clients want "a website". A process can help the user understand what is needed to go from nothing to a website. It works well when the website is an aside to their goal e.g. selling watches. The website is merely a facilitator to this. By setting a process, you can gauge your client's capacity to work with you on the project. If they don't like how you do things, you can compromise or part ways, amicably. If you are building the product that the client will sell directly (e.g. a web service) then I believe that a process alone isn't going to overcome the fundamental difficulties of the project - namely that your client is probably selling something that they don't fully understand.
cateye 14y ago
It is great how everyone describes their "process". In the end, it doesn't mean a lot because it will all depend on the mentality and knowledge of the people working in that process. At the point where people are using "the process" and not their brains and common sense, it will cause a disaster and you have to re-invent "the process".

64 points by flexterra 14y ago

> We also explain the client that anything that does not get revisions or comments from them is automatically approved. A really good post. I hate it when the clients ask for last minute features (for free) after not saying a thing about this during the development.

jpadilla_ 14y ago
The great thing about this method is that when that happens the client is clear about that, we get to add another whole step, and charge for it.

paulbennett 14y ago

We too employ a 2-iteration process to the design/UI/IA stages, however I don't understand why the client should still have the option to make 2 iterations of changes during the development and especially deployment stages of a project. The elweb illustrated process appears to miss out a key section - functional specification. We derive our func specs from scoping meetings, navigation structure, required content etc. which is then presented to the client along with user journey flow diagrams. This is presented and discussed before the design stage - thus the functionality is agreed upon far before development happens. With this approach we don't run into the situation where the client wants to make changes during development which could potentially greatly extend a project's timescale (cost is less of an issue as it passed onto the client anyway).

jpadilla_ 14y ago
The process shown on elweb is just to illustrated the 2-iteration process, not a concrete example on how to make a website, more like an example of using the 2-iteration process on various steps of a project.

13hours 14y ago

We run an Agile process where the client is involved as Product Owner in the team. The client can add stories at any stage, and set the priority in the backlog at any time. They just can't change the current sprint's stories and priorities. That way they can make as many changes as they want, and the impact of those changes are always visible. Why limit the client to an arbitrary number of changes (like 2 in this example?) The whole idea of Agile development is that we cannot know everything in the beginning, so we spec as much as we can in the beginning, and leave room to change our minds at a later stage. Of course, we explain this way of working up front as well, and we make the benefits clear to the client. They have to buy into this before we start with anything. It works very well when they do buy in though.

gk1 14y ago
I assume you're not charging a flat fee, then? The approach described by OP provides much more certainty in terms of scope and budget, which a lot of clients prefer and allows for easier planning of resources for the managers. How do you deal with resource planning and also billing?
- 13hours 14y ago
  We don't do flat fee no. We convince clients it's not a good idea for them to do flat fee, because it takes longer, and we build in a margin to cover our risk, so they usually pay more with flat fee. By making every step of the process visible to them, and charging them for what we do as we go along, we can save them money and time.
rmrfrmrf 14y ago
I like to feel the sense of completion of a project. When you let clients run amok adding requirements as they see fit, it lowers my morale as the project completion time drags on longer and longer.
- 13hours 14y ago
  We've (almost) never had the feeling of "running amok". Communication is key, and constant feedback from the client helps us to make small adjustments often. That usually keeps them from making large changes at late stages, because we are evolving the project with them. Changes are usually an evolution, not a revolution, if that makes sense. The times where the changes were big and late, it was usually down to bad communication at an earlier stage.

digitalengineer 14y ago

I know the flow, use one myself for one of the biggest corporations out there. But in my experience it's more "This is how we wish to work with clients". I see a lot of "squeezing the agency" going on these days. (As in non-paid extra work and revisions despite agreements on how to work).

msrpotus 14y ago
It's important to set limits and explicitly say that changes made after approval will cost extra. Otherwise, they'lll just push you to do as much for free as they can get.
gk1 14y ago
There's always an "Oh, I thought of one more small thing..."
- jpadilla_ 14y ago
  Indeed, and that usually becomes a problem at any stage of the project, usually converting it into a longer project, and if you're not careful you will surely loose money and precious time.
- digitalengineer 14y ago
  Or the "YOU forgot about my remark 3 weeks ago regarding the -insert little detail that doesn't mean jack sh*t but I want it done anyways- ... (Sorry to rant)
mikeryan 14y ago
Yeah there's some stuff here which we won't see fly with our clients. Every step has at least 2 iterations. Sounds great but whats an "iteration"? Is a design of a whole website? What if they want a few tweaks on the about page after the second iteration because that area wasn't fully fleshed out originally? We also explain the client that anything that does not get revisions or comments from them is automatically approved Never, ever will this language be approved by our larger clients. We can sometimes get "deemed acceptance" language by but its never "immediate" its usually like "if no feedback is provided in 15 days". The alternative is to have a "pause clause" in (if you don't get us feedback in 15 days we have the right to put your project on "pause" until we can get back to it)

Hopka 14y ago

To me, this looks very similar to the waterfall model.

nahname 14y ago
Arrows all going in the same direction? Yep, that's waterfall.
- anandagarwaal 14y ago
  but the steps are repeating..getting feedback from client after every step

twog 14y ago

I have met these guys in Puerto Rico (which has a great emerging startup scene) a few times. They are by far one of the top UI/Django pairs I have ever met, and could give any agency a run for their money. If you're looking for some smart guys, consider them.

cateye 14y ago

It is great how everyone describes their "process". In the end, it doesn't mean a lot because it will all depend on the mentality and knowledge of the people working in that process. At the point where people are using "the process" and not their brains and common sense, it will cause a disaster and you have to re-invent "the process".

scott_w 14y ago
There's a difference between "following a process" and "following THE PROCESS". Outlining the working process means that I and my client have an understanding, and that they have less grounds for being surprised about getting a larger than expected bill. It forces the client to be disciplined in their own behaviour, which they wouldn't be without a process. On the flip side, demanding clients fill out Form 27-B for Change Requests every time they want something changing is way, way over the top. In addition, a process can help give a client some confidence that you know what you're doing. This is especially true in the technology business, where clients tend not to really understand what they're working with.
- cateye 14y ago
  The root cause of all the symptoms that you are describing is that your client hasn't got the proper knowledge, experience and mentality to (co-)develop something innovative. How exactly is "a process" going to change that so rapidly? (I haven't a simple answer and I am also struggling with this problem..)
  - scott_w 14y ago
    I think clients in this area tend to not want "innovative". From my (admittedly limited) experience, most clients want "a website". A process can help the user understand what is needed to go from nothing to a website. It works well when the website is an aside to their goal e.g. selling watches. The website is merely a facilitator to this. By setting a process, you can gauge your client's capacity to work with you on the project. If they don't like how you do things, you can compromise or part ways, amicably. If you are building the product that the client will sell directly (e.g. a web service) then I believe that a process alone isn't going to overcome the fundamental difficulties of the project - namely that your client is probably selling something that they don't fully understand.

cateye 14y ago