define "finished" ....
- Started
- Last post
- 13 Responses
- vaxorcist
Reading the longest project page I remember some "when will it be done" projects.... and I am seeing a chronic problem in web/dev biz....
When a client asks "when will it be done?!?" there's a messy situation.... Unless we define "done" they are asking "when will I finally be satisfied" and since they, not us are the ones who decide that, we have no control over "when it will be done"
Keeping people happy replaces any other method of measuring success unless we are able to define things and control expectations well....
So this is a business model risk for a flat bid project, and a relationship risk for an hourly bid project unless we define "done" in our first few meetings...
How do people here define "done" and/or how do you deal with this?
We tried at one place to have an "exploratory" phase of each project, but many clients kept rescheduling meetings and it seemed they were irritated by "all the mumbo jumbo, why don't you just get started" ... so how we sold our process wasn't effective in these cases...
- airey0
surely a list of projected milestones and deliverables would answer it. lay out the key dates / timeframes and what will be delivered at those marker points, then reiterate to the client when they are reached. a final 'live' date applied and final invoice sent. anything beyond the scope of agreed content/work can be addressed as either delivered by then or give a 2nd delivery date.
i know i keep fucking this up but on projects i've done this it worked really well. it defined to the client exactly what to expect and what they get or don't for the spend.
the real issue is expectations, yours and the clients. they usually don't equal to the same thing so the paperwork has to stipulate what these are.
- vaxorcist0
hmm...
I do think that projects that could have a clear list of projected milestones and deliverables did work out well.... especially as the client would have confidence in those cases, and therefore second-guess random little things less....
When projects either needed an exploratory phase in order to define clear milestones, but that phase was cut short due to client feeling like we were "wasting our time" then this was a red flag we missed.....
the expectations difference is something so rarely spelled out, that may be a big key....
now actually doing these things requires the guts and panache to risk worrying client just a bit early in the project in order to avoid bigger mess later...
In the past, I think I've had issues with just feeling messed with...and it's hard to make one project not pollute your mind on annother....
- airey0
i'll just add that things like 'exploration phase' seem like tosh to me. they sound a tad wankerish and to a client who isn't in a creative filed would sound very openeded and wankerish also. not in all cases but certainly in my experience with clients it would be the majority.
things like that are generally considered something like masterbation, you should do that in your own time. generally the client comes to you for the confidence you show in a solution. is it the best solution? possibly not but like most things in reality it's a solution and a solution done well is better than the greatest solution not done properly.
- Amicus0
This problem exists in any large (or small) scale creative endeavour – publishing, branding, architecture etc. etc.
Placing some urgency and responsibility back on the client will ultimately resolve many issues, but you'll always have clients who say they want a brochure, or social media site, or new interior design – "you know what I want, just get on with it, 'cause we need it urgently" – without even having thought about what they want to achieve with the design.
9 times out of 10 it's the communication between client and creative that makes or breaks projects – creatively or timewise.
A well-defined brief needs to be in clear, concise plain english. If the client can manage that, then chances are the feedback process will also be relatively smooth.
When I've been able to push back on the client about feedback responsibilities projects have always been the better for it.
You have to define key feedback turnarounds so that the schedule is met. If you don't get any feedback for a couple of weeks you probably lose the focus on key issues no matter how well things are documented which costs you and, ultimately, the client money.
- d_rek0
Working in a small studio that has a large number of glaring inefficiencies, I am constantly confronted with this very issue. Actually having seen some of the documents our clients sign off on (and agree to budget-wise) it really is no wonder that they would ask, "when will it be done?" Part of the problem is that there is no creative personell involved in any up-front client meetings. It is simply our salesman bullshitting his way into the client's pockets.
Huge problem.
For example, when he sells 'brand identity' he has, not once in my experience, brought back a list of items that he has 'sold'. It is simply a document with some numbers and a rough timeline. No deliverables, very little scope and a whole lot of guesswork.
For my freelance clients I have taken the completely opposite approach and I think airey is spot on. Defining expectations, defining deliverables, setting a schedule with milestones, delivery and/or launch dates, is all crucial to 'finishing' a project. My freelance clients get a well-itemized document that lets them understand exactly what they are spending their money on.
Without defining the goals, expectations and deliverables for a project we simply set ourselves to be stuck in a cycle of design perpetuity.
- vaxorcist0
airey, you're right about it sounding like a waste...
Amicus, you're right about the 9/10 thing and timing note a the end... and the "just get on with it" mindset....My worry is more for things more like a new idea web app than just a plaintext site, blog or similar things that can be cranked out.....
I'm coming to realize my personality is better suited to definable projects than many of the large, unclear, invent-it-all-here-or-die projects we worked on at a couple of agencies I used to work at....
One idea that did work even with large projects was to keep the business objective and target market and stakeholder lists at the bottom of every email, so that we could point to them whenever random offshoot distraction ideas came up....
- monospaced0
I guess it's all in the process, setting expectations and most importantly, project milestones.. Having them sign off on concepts, then approve and finalize a direction...these are steps toward completion. If at the end they are unhappy with the finished product, you can remind them that in fact you executed to their approved specifications at each milestone. The project is done at this point. It's good to anticipate more than one "final" because, the fact is, most projects end up doing this and experience helps you incorporate it into the overall expected workflow. That's all I've got to say on the matter (for now).
- I actually wrote this without reading the above in detail. Glad to see we're all on the same page.monospaced
- doesn't hurt to reinforce with better writing!airey
- monospaced0
Oh, and for the vague projects, these milestones apply to building project scope and timelines, strategies and even coordinating multiple teams. Once everyone is agreed at a certain point (every milestone, infact), the project must keep moving forward.
- In my experience, this kind of stuff doesn't happen automatically, it's usually one person who is just amazing at organizing and planning.monospaced
- organizing and management and then everyone relies on them. It's tough.monospaced
- airey0
get an online or similar system in place that helps you do these things. even a basic basecamp account and a list of what you need to create per-project (milestones, deadlines, content, whatever) can help a lot. if you need that regimented framework in place to help you then you can easily do it yourself with very little outlay short of a basecamp monthly account and a procedure list you can find online or get off somebody here.
- vaxorcist0
yes... and I'm reminded of an idea I had a while ago....
projects are like playing baseball
-if you're at bat, you can strike out now and then if you are known to hit home runs
- if you're in the field, success is defined as no unforced errors
so, in the case of being at bat, things can be more nebulous if you've got the reputation of very successful projects that took creative risks.... but more projects seem to be the "in the field" kind....
- maikel0
I guess that a crash course in project management won't hurt.
If you make your client aware of the impact in cost and schedule of delays and changes WHEN those occur, they would try to stick to the original plan to avoid delays and extra payments.
Usually linking your milestones to client-related events (like delivering ALL information or formal approval of a UI) give the client a clear idea of where things stand.
A shared Project file, or a web-based solution with a dumb-proof Gantt chart (and a person to guide a client through it) make clients happy and agencies profitable.
You cannot really get into a large scale project without this... Or yes you can and your project will end up tits up...
- this works for known process projects, not so much for inventing something really new...vaxorcist
- monospaced0
This thread is complete. Sign here _________________
- vaxorcist0
bye...