[astonecipher]

I have an on going project that we now have a push to get done by 7 Jan. We had a meeting with the client this afternoon to go over some minor design and functioning elements. I set the site up on a dedicated IP in advance of installing the SSL and sent out the IP to all parties.

Now for the rant,
I received an email from my non-developer, non-technical, non-project manager boss. Who told me that as a rule of thumb, we should not let clients see work in progress, because it will prolong the project.


Apparently, we should surprise the client with what we have been working on for months. Then, they can say it's crap and we can start over. That will be much more efficient apparently!

[no2pencil]

Well, to be fair, in my experience when I've left a work in progress website up, I would get calls, sometimes daily.
"Why isn't there any progress from yesterday"
"This looks terrible, put it back"
"it would be great if...."

To curb this I would set a 'proof of concept' delivery date, & show them the site when a lot of the contract-written work was done.

[astonecipher]

And I understand that side, I have dealt with that as well. And I could always protect the site and only release it when we need to show the client what has been updated. Currently, the site is more or less a proof of concept. The content write up is falling completely on us, as well as finding the images. I schedules the meeting today to go over some "interpretations" from emails we have had. After the meeting we found out that the client had a completely different design in mind. So, to me it was well worth the meeting to get those assumptions straightened out now, compared to the day we launch and find that out.

[jon.kiparsky]

I'm with you 100% on this one, astonecipher. The client should always be seeing incremental progress, because their feedback is essential. If nothing else, knowing that they've seen what you're doing and it's exactly what they want is great motivation, and conversely knowing that you're not going to spend weeks going down the wrong track before you find out that it's not what they really want is also pretty cool.

The "get the spec right and then hide from the customer until it's done" model is kind of twenty years out of date at this point, isn't it? I mean, isn't that the point of all of the flavors of agile?

[jon.kiparsky]

no2pencil, on 22 December 2014 - 11:33 PM, said:

Well, to be fair, in my experience when I've left a work in progress website up, I would get calls, sometimes daily.
"Why isn't there any progress from yesterday"
"This looks terrible, put it back"
"it would be great if...."

To curb this I would set a 'proof of concept' delivery date, & show them the site when a lot of the contract-written work was done.

You can manage this by keeping the client informed when you check off things, and also telling them when they're not going to see progress for a little while. (either because nothing's going to be happening for some reason, or because you're going to be spending a sprint on back-endy stuff, and there's going to be progress that they won't really see)

Of course, you really need a strong team lead who can say "no" to the customer - or rather "yes, we can do that, but here are the consequences of making that change". (ie, here's how the schedule changes)

[no2pencil]

Saying "no" to the client is not a problem. It's not saying "you are not our only client" that I struggle with.

[jon.kiparsky]

Sometimes that's what you need to say, though. And sometimes it means "you know, you're not our only client, and we had to put some resources on this other project this week, so there's not a lot of progress on your stuff, we're sorry, we'll make it up to you", and other times it means "you know, you're not our only client, and if you're really not happy with what we're doing, maybe we all need to find other walls to bang our heads against"

[Martyr2]

I don't think you have to go as far as ever really telling the customer that "you're not our only client" but I have found that simply doing prototypes of a project at various stages, keeping them informed as to progress and if they want to make changes telling them the impact to the timeline and budget is always enough. Non-tech savvy business people always push the envelope on what they want to see done and what they get for their money. However, just watch how many of those asks disappear when you bring in budget and timeline changes. They always say things are important, but 90% become not important as soon as you say it costs more. If they still push forward despite the change in cost, then you know they are serious and really "need" it.



Edit: Sometimes cost is a good mechanism to keep the client in check as well. Don't make changes cheap!

This post has been edited by Martyr2: 22 December 2014 - 11:05 PM

[depricated]

I've always been a fan of the charge-per-change-after-signing method. There's probably a term for it that's much more apropos. But in short, you both agree to the design, you present a mockup, they give the go ahead. From that point on, any changes have a fee attached.

[depricated]

But I agree with jon, them being able to see the deliverable is good too. It's still a service you're selling in the end, which means some degree of customer service, if just being polite and working with them to demonstrate progress.

[baavgai]

Yep, showing your client your progress WILL slow that progress. You'll have to make early changes. Respond to pesky requests. Probably add stuff that was "out of scope." Bother.

However, the final result will not only make for a happier client, but far fewer change requests. The extra time spent up front in the early stages pays off by dramatically in limiting or removing work done after release. Thus, longer incremental development leads to a more stable future and less time spent overall.

If you want your client to pay you more, in time spent on post release changes, by all means spring it on them. Depending on how trapped they feel, they might even pay you to fix it. They'll also blame you for everything and hate your guts.

The nice thing about showing the client as you go is that time constraints effectively disappear. If you can show, and document, weekly progress, then the client understand what's happening. When they make changes through the development cycle, they see how those changes impact the work getting done. The client will understand, rather than resent, extra time taken to accommodate requests. But, hey, who wants happy clients?

You are correct. Your boss is an idiot. I feel your pain.

[farrell2k]

Any company or person that is willing to tell you "you're not our only client, you know", does not deserve the privilege of receiving your hard-earned money. I can't believe someone would write that. Putting up with customer requests is part of the job. If you can't deal with that, you don't deserve their business, someone else will find a way to earn their money.

[astonecipher]

Flat out saying it is different than, the issue has been added to the queue and will be resolved as quickly as possible, too.

In an interoffice environment, I have told people their stuff will wait because the priority is on so and so's project.

So and so was very demanding

[depricated]

Some clients aren't worth keeping/marketing to. Just like some jobs aren't worth accepting.

Sometimes you have to fire a client. If the client is problematic, to the point that they're demanding work be delayed for other clients so that they can be appeased - by all means yes. Just like a job offer isn't a magical gift from the corporate overlord, a service contract isn't a magical gift either. This isn't McDonalds - you don't get a free Big Mac because the guy in the drive thru in front of you had a large order that made your wait an extra 30 seconds in the drive thru.

[astonecipher]

VERY true!