Mate of mine's small project

[suityou01]

At a guess, I'd say it's the ability to read what you've written and understand why it might not be right. To "tow the line", would involve putting the line on some kind of rope, and tugging it along behind you. That would imply it's some kind of activity, rather than a behaviour.

"toe the line" clear indicates the behaviour of keeping your toes on the line and not straying.

What you also lack is authority. If you haven't got natural authority, then you need to learn to fake it.

Yes, yes, yes. It burns so it must be true.

Is it Jedi mind tricks I need?

[d000hg]

Dressing it up in fancy words is intimidating though, is my point.

You don't need daily meetings to do an agile project for a client who doesn't really know what they want, in fact they are perfect for it. Get a rough idea of the purpose of the app and the core things they need to do, create something usable and then get them to review this. Being able to use it and see it working takes away the problem of having to imagine how it should work and how they will use it.

I would probably just say "can you show me how you use the current version?" when dealing with a small company/project.

[NotAllThere]

Yes, yes, yes. It burns so it must be true.

Is it Jedi mind tricks I need?

In your case, I'd suggest (seriously) that you'd gain authority by being prepared to walk away. You have a job to do. If the client is actively disrupting your ability to do that job, then tell them to either start doing things your way, or you will simply quit. Do this a few times and you'll find your confidence increases. With confidence comes an aura of authority.

Alternatively, agree to everything, put your integrity to one side, smile pleasantly and keep billing. Some clients just will not be taught.

[suityou01]

Dressing it up in fancy words is intimidating though, is my point.

You don't need daily meetings to do an agile project for a client who doesn't really know what they want, in fact they are perfect for it. Get a rough idea of the purpose of the app and the core things they need to do, create something usable and then get them to review this. Being able to use it and see it working takes away the problem of having to imagine how it should work and how they will use it.

I would probably just say "can you show me how you use the current version?" when dealing with a small company/project.

Good point, noted.

The big problem here is that it's an excel app. So when porting to a web app, if column a, multiplies column b to give column c my mate is trying to replicate this behaviour.

Then he gets phone calls at 10 O'Clock at night saying "In Excel, if I right click I get a copy and paste menu, and I can format the cells etc etc". So this is where things fall down.

He has made the point that an excel version in the cloud exists and they can use that for £6 a month or whatever.

Documented requirements give you the ability to push back on change, and prove it's change. Two points make a line. His failing was thinking that ClientCo would still be just as amicable 6 months down the line when it was all beer and skittles. Now the first part is in test, things are getting ugly, uber ******* picky and it's doing his brain in.

Yes you can point out failings, but in my mind Client is behaving badly and needs put back in his pram.

[d000hg]

With small clients not au fait with software, I would assume from the outset that no matter what you do it's going to be an iterative process because no matter how detailed you can document requirements, this won't be what they actually want or need. Formal documentation means you can say "we agreed this" but it's unrealistic to expect they won't want changes, to me this comes with the territory and is just part of creating software for less technical clients. You cannot apply enterprise process/methodology with the expectation it will go smoothly

[DirtyDog]

The big problem here is that it's an excel app. So when porting to a web app, if column a, multiplies column b to give column c my mate is trying to replicate this behaviour.

All you can do is to keep explaining that if they want to use a web-based version of Excel then there are tools to do that - there's no way that you can replicate Excel completely. When you did the work, did you document what you were doing and why? A functional / technical design document - even if you can't get them to input to the requirements gathering process, you need to document what you think you are meant to be doing.

Then he gets phone calls at 10 O'Clock at night saying "In Excel, if I right click I get a copy and paste menu, and I can format the cells etc etc". So this is where things fall down.

Stop answering the phone at that time. This is beyond ridiculous, so put your foot down and stop being available at that hour.

Yes you can point out failings, but in my mind Client is behaving badly and needs put back in his pram.

If they will not listen to you while you are there, then you have two choices. Either you stay and suck it up, or you leave and hope they realise the error of their ways. Unless you need the work, then I would walk - you are a professional being treated like a bitch by the client, and you deserve better.

[MicrosoftBob]

With small clients not au fait with software, I would assume from the outset that no matter what you do it's going to be an iterative process because no matter how detailed you can document requirements, this won't be what they actually want or need. Formal documentation means you can say "we agreed this" but it's unrealistic to expect they won't want changes, to me this comes with the territory and is just part of creating software for less technical clients. You cannot apply enterprise process/methodology with the expectation it will go smoothly

Wise words and it's only ever really a problem if it's a fixed price contract otherwise toot toot!

[eek]

Good point, noted.

The big problem here is that it's an excel app. So when porting to a web app, if column a, multiplies column b to give column c my mate is trying to replicate this behaviour.

Then he gets phone calls at 10 O'Clock at night saying "In Excel, if I right click I get a copy and paste menu, and I can format the cells etc etc". So this is where things fall down.

He has made the point that an excel version in the cloud exists and they can use that for £6 a month or whatever.

And for that reason alone I would be politely running away from the client as soon as f*** possible. You are on a hiding to nothing mate....

[cojak]

Dressing it up in fancy words is intimidating though, is my point.

You don't need daily meetings to do an agile project for a client who doesn't really know what they want, in fact they are perfect for it. Get a rough idea of the purpose of the app and the core things they need to do, create something usable and then get them to review this. Being able to use it and see it working takes away the problem of having to imagine how it should work and how they will use it.

I would probably just say "can you show me how you use the current version?" when dealing with a small company/project.

Wd000hgyS.

As a process BA, I see too many process specialists up their own egos getting kicked off projects while I stay.

And the title I give them is 'Princess' - they are too precious about 'their way'. Their way is best and no other way is good enough.

You get your deliverables by working around the client - don't batter them over the head with what 'should' be done.

If the client are 'too busy' to want requirements don't call it a requirements workshop. Buy the head honcho a coffee and get him to talk about himself and his project for half an hour (they love doing that). You'll get high level requirements out of that.

In the time you've spent arguing about definitions you could have a good idea of what is needed by ferreting around the as-is stuff and talking to the people who use/will use the new stuff.

And as for the processes themselves - yes, there is 'best practice' and you should incorporate it (I use best practice processes as my 'strawmen'), but if the client doesn't want something, don't put it in. They'll come around to it later when they realise that they've missed something. Just treat that version of the process as the baseline for CSI.

As for backstops - I always do a Process Architecture document. Every time. When they say they don't need it I say not to worry, creating it won't affect my other deliverables and they don't need to use it if they don't want to.

It has ALWAYS ended up as core documentation.

[vetran]

tell em Microsoft spent £X billion writing Excel, your chap is happy to rewrite it as a web version at their cost but he is pretty sure they will run out of money before he gets bored.

get a private phone & divert the work phone to voice mail. 10pm is a call out and they get charged accordingly.