

This is how we work with clients - flexterra
http://elweb.co/stuff/this-is-how-we-work-with-clients/

======
digitalengineer
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).

~~~
gk1
There's always an "Oh, I thought of one more small thing..."

~~~
digitalengineer
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)

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

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

~~~
nahname
Explaining how you get buy in would be a much more interesting blog post. The
person footing the bill usually wants some plan for reassurance sake.
Something along the lines of, "Aha! Gotcha! You didn't do X! I'm not paying!"

~~~
13hours
I'll try to make the time to write up something. It's really a matter of
explaining to them why our way of working ends up being faster and less
expensive than the flat fee way. With our way of working, there's an
assumption of trust, and we keep that trust through visibility of our
progress. That way we share risk, and if we can share risk with the client, we
can charge less, because we don't have to build in such a big margin in the
price to cover our risks.

~~~
nahname
Couple pain points from experience:

Estimates in $$$ desired before start

-> Leads into defining a complete feature set

-> Desire for all estimates in time for all work (BS number, always)

Guarantees on what will be delivered

-> Getting the client on board with paying for time vs. paying for features

-> Offer minimal feature set + what we can do?

-> Dealing with scope creep

Require clients time

-> Feedback

-> Showcases

-> Many A) or B) given B) is 10 times more expensive

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

~~~
nahname
Arrows all going in the same direction? Yep, that's waterfall.

~~~
anandagarwaal
but the steps are repeating..getting feedback from client after every step

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

