How is work planned/done at your place?

antijoke

antijoke

antijoke

Caporegime
Joined
28 Jan 2003
Posts
39,925
Location
England
Just after some feedback from other web devs/freelancers about how a project is handled once you've won the tender?

Do you draw up contracts? Do you insist on a spec/brief for what the client wants? Do you just start knocking up visuals?

Seems an odd question but I need get a feel for how the rest of the industry goes about planning projects.
 
1) NDA
2) Receive brief
3) Write up black and white spec, no cutting corners
4) Get documented approval of spec
5) Design phase if appropriate... mockups, iterations & sign-off
6) Build phase
7) Present on dev site
8) Iterations if necessary, charging where outside of agreed spec
9) Training if necessary
10) Go live
11) Paid ongoing support and evolution, gone are the days of doing a site and then leaving it alone for 3 years ;)
 
Interesting, so you write the spec based on the brief that you receive from the client?

That makes sense. I also like the sound of point 11. Is that done via an ongoing SLA/whatever you would call it?
 
Of course, the spec is our thorough interpretation of the customers' brief, all t's crossed, i's dotted and opportunities identified.

Ongoing support is a quarterly reviewed contract whereby x amount of hours per month is allocated to improvements based on customer feedback, performance results and technological opportunities.
 
1)lets do this
2)cool
3)work
4)done
5)drink
(How 99% of my own projects go)

As for clients;

1)initial contact. Agree ballpark figure.
2) recieve final specs of what they want done/offer the price we will do.
3) create concept and arrange contract holding them to specs from point 2.
4) take first half payment
5)alpha/test inhouse
6) beta/test with client
7)finalise designs and get feedback from client.
8)set work live and take final payment.
9) drink.

The last steps are the most important I feel. Bear in mind I've only had 22 clients and the business is me and a partner.
 
Writing the spec based on a brief makes no sense. Whatever is documented is never right. Get an overview of what functionality is needed, only needs to be generic and just enough to give an estimate to complete the work. Literally an hour or less discussion. Don't bother aiming for accuracy, you'll never, ever get it right. Start building the site immediately after you've got a "Go!". All that time drafting documents for specs is waste. Get rid. Have regular demos with the client and let them see what you're building as you're building it. The more frequent you have these interactions the better.
 
Last edited:
Dj_Jestar said:
Get an overview of what functionality is needed, only needs to be generic and just enough to give an estimate to complete the work. Literally an hour or less discussion. Don't bother aiming for accuracy, you'll never, ever get it right. Start building the site immediately after you've got a "Go!". All that time drafting documents for specs is waste. Get rid. Have regular demos with the client and let them see what you're building as you're building it. The more frequent you have these interactions the better.
Click to expand...

We'll only do this on an hourly-rate project.
If the client wants a fixed price, the spec needs to be nailed down.
 
"nailed down" never happens. At least not in the right place. Result? Unhappy client bad mouthing your work. Next.
 
Dj_Jestar said:
"nailed down" never happens. At least not in the right place. Result? Unhappy client bad mouthing your work. Next.
Click to expand...

So how do you give fixed price contracts with vague specs?
Do you overestimate it to account for unknowns?
 
I dissuade them from fixed priced, for a start. Fixed spec + fixed cost + fixed timescale = destined to fail. Either too expensive due to overrun and T&M or overcompensation at the start, not finished due to budget overblow or time overrun, and the inevitable scope changes. That and the late nights because fixed contracts are just crap and everyone has to cram. Just doesn't work, ever. Always leaves a bitter taste in the clients and workers mouth whatever happens.

Else I just tell them that my current estimate range is for x-y (say 3-5 months for a figurative example) and that that will cost them a-b (i.e. 3 months rate to 5 months rate)

If it goes over, then the work either stops or they continue to pay more. They will have a working product, just whether it'll be as feature rich and polished as they want is up to them.
 
Last edited:
I don't work with web design but do freelance (primarily industrial and 3d design) so I'll give my approach as well.

Bearing in mind I have an automatic nda for all work I undertake.

1) Meeting to discuss brief, break down requirements with client while there. Say I'll get a quote out for them by end of next day.
2) go home and work out quote and proposal (in simple/plain english), time frames for meetings if needed etc, send to client via email (passworded pdf) with a phone call follow up to check it's all ok on their end. This states that once agreed any changes may incur additional charges (there's another stage which has this too for me personally).
3) They say yes via email and/or signed contract.
4) Wait on initial payment towards work.
5) I start working on required work.

My work process usually goes something like this.
1) break down of project into sections
2) work out what's needed for each section
3) work on concepts
4) show concepts to client for feedback
5) develop concepts
6) show final concept(s) to client - repeat 3-6 if needed.
7) develop final concept(s) in 3D
8) Show 'clay render' to client if necessary (some clients just leave me to it)
8) apply materials, lighting etc for rendering
9) do smaller low quality render for 'material/colour approval' -
10) show to client - get them to sign off on it - includes a clause that any changes after this point may incur additional charges.
10) render image(s)
11) present to client

12) send final invoice and wait on payment

Rinse and repeat with the next client :)
 
DJ_Hester is trying to advocate an Agile approach. The problem is in the real world Agile is useless because it isn't what clients want most of the time. They have a fixed. Us get, a fixed deadlines and propose fixed requirements even if in actual fact their requirement vary or change. Agile tries to deal with the latter, and if you are dealing with a client with unlimited money and unlimited time then Agile works a treat. If you deal with a client that understands Agile then Agile works. But in the real world most client just don't work that way, they want something specific delivered at a specific deadline and they believe their specifications are correct.

Sure, their specifications will be wrong and they will change their mind but as long as your contract is B&W then all that that means is future profits.
If you tried any Agile malarkey on any of the clients the parent company I work for deal with they would walk away and you would loose multi-million dollar contracts overnight.
 
Agile doesn't have to be all or nothing. I haven't done any project either as a freelancer or as part of a major multinational in over 6 years that has had a 'signed off' spec before development starts.

Being able to work agile comes from your ability to effectively communicate with stakeholders and critically, end users of the software. Big multinationals usually have years of entrenched PMO bs and self important 'analysts' getting in the way....you just gotta make the poor dears feel useful and get them involved instead of making them an enemy :)
 
Dj_Jestar said:
"nailed down" never happens. At least not in the right place. Result? Unhappy client bad mouthing your work. Next.
Click to expand...
This is so far off the mark mate, we nail everything down and charge for over and above, and unless you're dealing with Mickey Mouse clients this is fully understood and respected way to work.

Very few companies want to pay by the day and open ended, there is no way for the customer to budget and plan, and from our point of view how would we have accurate lead times for future projects?
 
Last edited:
BS you nail "everything" down, else you'd never need to go over. Plus you are just wasting so much time nailing it down when you could just be getting on with it.

I've not advocated open ended (well, not solely). I've advocated that you can't nail down fixed price, cost and timescale. It always fails and leaves a bad taste with everyone. Everytime.

I'm advocating flexibility.
 
Dj_Jestar said:
BS you nail "everything" down, else you'd never need to go over. Plus you are just wasting so much time nailing it down when you could just be getting on with it.

I've not advocated open ended (well, not solely). I've advocated that you can't nail down fixed price, cost and timescale. It always fails and leaves a bad taste with everyone. Everytime.

I'm advocating flexibility.
Click to expand...
I'm not going to argue with you about it, we do nail everything down, and only build what is agreed (they have agreed it after all!).

Additional work = additional money, although our initial stages leave nothing to the imagination and no grey areas.

In the last year, we have worked like this for VW, Continental Tyres, HTC, Britvic and The Economist and it is seen as a positive, not a negative. They know what they are getting, no BS in sight.
 
Additonal work == not nailed everything down. It's obvious.

All I'm saying is accept that, embrace it.. there are better ways to maintain a relationship with your client. Certainly less wasteful than demanding a contract be drafted for everything.
 
D.P. said:
DJ_Hester is trying to advocate an Agile approach. The problem is in the real world Agile is useless because it isn't what clients want most of the time. They have a fixed. Us get, a fixed deadlines and propose fixed requirements even if in actual fact their requirement vary or change. Agile tries to deal with the latter, and if you are dealing with a client with unlimited money and unlimited time then Agile works a treat. If you deal with a client that understands Agile then Agile works. But in the real world most client just don't work that way, they want something specific delivered at a specific deadline and they believe their specifications are correct.

Sure, their specifications will be wrong and they will change their mind but as long as your contract is B&W then all that that means is future profits.
If you tried any Agile malarkey on any of the clients the parent company I work for deal with they would walk away and you would loose multi-million dollar contracts overnight.
Click to expand...
Oh look, the resident dinosaur has shown up. "The Real World" now use Agile more than not.

Ps. please, please learn to use a keyboard. For someone who spends all day with one you have terrible typing skills.
 
You must log in or register to reply here.
Back
Top Bottom