Reply to: Read boss's mind?

[tractor]

....

True, and for much more than just computer programs.

In my personal case right now, my problems are that the PM doesn't know what is needed (neither does the user probably but I don't get to interact with them at all and anyway the project is at an advanced stage allegedly), can't tell me what is needed, leaves out bits even of what he does know, won't put it in writing or even discuss it, needs it this afternoon WITHOUT FAIL, and will tell me afterwards if I didn't get it right. How to feed back is irrelevant, need to feed back is already a "fail".

I started off feeling that that situation was the all-too-common one of an almost impossible project, bid low on price by a desperate small software house, with a PM under the gun and over his head, an angry client and a sinking project plan, with a contractor brought in to be a wizard and make everything all right. But I am beginning to feel that it might be the not unknown case of a project already sunk, with a contractor brought in with the job description (supposed to be unknown to him) of "scapegoat". I have been that contractor before and I don't intend to be again.

So far I think it may be just that the project and the PM are crap and the PM has an attitude problem.

Confirmation in the lift going down: a distant colleague said, you're a new contractor? Yes. Which project are you on, XXXX I suppose? Yes. Tough luck, it's a tulip project. Demanding client, impossible deadlines.

Contrary to what agents and clients think, the purpose of an interview is for the contractor to determine how tulip a project/PM/Client is before you commit to it.

[yasockie]

1. shut up and keep invoicing.

Make it's handling exceptions quietly.
It's a bank - they'll cover it up when the hit fists the fan or sth like that

[expat]

You have to remember this simple fact. That most people are incapable of imagining how a computer program should work.

Therefore the only way they can progress a software development is to give you some inaccurate requirements. See the results, then iterate towards the solution.

This is why Agile is better than waterfall. Because it recognises this intrinsic truth and shortens the cycle between "DO" and "CHECK".

The problem comes because they do not know they are incapable of imagining how a computer program should work and don't appreciate the skill and time required to build a sophisticated piece of software.

True, and for much more than just computer programs.

In my personal case right now, my problems are that the PM doesn't know what is needed (neither does the user probably but I don't get to interact with them at all and anyway the project is at an advanced stage allegedly), can't tell me what is needed, leaves out bits even of what he does know, won't put it in writing or even discuss it, needs it this afternoon WITHOUT FAIL, and will tell me afterwards if I didn't get it right. How to feed back is irrelevant, need to feed back is already a "fail".

I started off feeling that that situation was the all-too-common one of an almost impossible project, bid low on price by a desperate small software house, with a PM under the gun and over his head, an angry client and a sinking project plan, with a contractor brought in to be a wizard and make everything all right. But I am beginning to feel that it might be the not unknown case of a project already sunk, with a contractor brought in with the job description (supposed to be unknown to him) of "scapegoat". I have been that contractor before and I don't intend to be again.

So far I think it may be just that the project and the PM are crap and the PM has an attitude problem.

Confirmation in the lift going down: a distant colleague said, you're a new contractor? Yes. Which project are you on, XXXX I suppose? Yes. Tough luck, it's a tulip project. Demanding client, impossible deadlines.

[tomtomagain]

You have to remember this simple fact. That most people are incapable of imagining how a computer program should work.

Therefore the only way they can progress a software development is to give you some inaccurate requirements. See the results, then iterate towards the solution.

This is why Agile is better than waterfall. Because it recognises this intrinsic truth and shortens the cycle between "DO" and "CHECK".

The problem comes because they do not know they are incapable of imagining how a computer program should work and don't appreciate the skill and time required to build a sophisticated piece of software.

[bintang]

Your expertise inside application progress is not html coding up what many people tell you to perform. It truly is html coding up what needed.

[expat]

I wouldn't sweat it, it will be going to India soon I suspect.

So will I, on a long holiday, if I can stick out this contract and don't get canned from it.

[DimPrawn]

I take everybody's point about D&C but in this case I'm OK with that because I'm outside the UK (yes yes I know) and acting in an IR35-avoiding way anyway.

Actually tomtomagain got it, indirectly: do what they need, not what they say they want. But I am actually looking for an easy bum-on-seat techie contract with oodles of D&C and no thought needed, and my real complaint is that the D&C are crap!

The PM is stressed and can't stop taking it out on others. I have realised that he is a blame-meister, his whole attitude and speech is slanted towards everything being someone's fault (not his). Presumably any logical arguments to the effect that it was actually his fault will lead to a demonstration of power.

You know what? I don't want this tulip any more.

I wouldn't sweat it, it will be going to India soon I suspect.

[expat]

I take everybody's point about D&C but in this case I'm OK with that because I'm outside the UK (yes yes I know) and acting in an IR35-avoiding way anyway.

Actually tomtomagain got it, indirectly: do what they need, not what they say they want. But I am actually looking for an easy bum-on-seat techie contract with oodles of D&C and no thought needed, and my real complaint is that the D&C are crap!

The PM is stressed and can't stop taking it out on others. I have realised that he is a blame-meister, his whole attitude and speech is slanted towards everything being someone's fault (not his). Presumably any logical arguments to the effect that it was actually his fault will lead to a demonstration of power.

You know what? I don't want this tulip any more.

[SunnyInHades]

Haven't seen anything remotely looking like requirements or documents since it all became user stories, epics and 3 days sprints with retrospectives.

Fortanesque pseudocode..

BEGIN_AgileProject:
  REPEAT UNTIL eveyone 'appyish   // sprint, every 2 weeks
      Decide what doin';
      Design it;
      REPEAT UNTIL working
        Code it;
        Compile'n'test it;
      END REPEAT
  END REPEAT
END_AgileProject: 

[tractor]

....

Wow, the good old day right there, when clients had money and time to spend on such things.

Usually, by the time the bottom line is affected adversely, the suspect is long gone esp in the public sector.

[DimPrawn]

I love how everyone on these threads has all the answers. The process for me normally goes (and bear in mind I'm an infrastructure consultant, not a coder):

1. Sales and pre-sales do their thing
2. I host workshops etc to capture the requirements to shoehorn into whatever has been sold
3. Produce a high level design
4. High level design goes through iterations with my client and their customer
5. Produce detailed low level design
6. Low level design goes through iterations with customer and their customer
7. Build solution
8. Internal Testing
9. Client Testing
10. Client Signoff
11. Go-Live
12. Oh, can we have this? Can we do this differently? The users don't like x? Can you add z?
13. I keep drinking

There's normally a proof of concept in there somewhere, but to be honest I don't know why anybody bothers. The client has already made up their mind and they save all the really difficult questions until later anyway.

Wow, the good old day right there, when clients had money and time to spend on such things.

[vwdan]

I love how everyone on these threads has all the answers. The process for me normally goes (and bear in mind I'm an infrastructure consultant, not a coder):

1. Sales and pre-sales do their thing
2. I host workshops etc to capture the requirements to shoehorn into whatever has been sold
3. Produce a high level design
4. High level design goes through iterations with my client and their customer
5. Produce detailed low level design
6. Low level design goes through iterations with customer and their customer
7. Build solution
8. Internal Testing
9. Client Testing
10. Client Signoff
11. Go-Live
12. Oh, can we have this? Can we do this differently? The users don't like x? Can you add z?
13. I keep drinking

There's normally a proof of concept in there somewhere, but to be honest I don't know why anybody bothers. The client has already made up their mind and they save all the really difficult questions until later anyway.

[tractor]

....

Haven't seen anything remotely looking like requirements or documents since it all became user stories, epics and 3 days sprints with retrospectives.

Yes, for anyone who has been around long enough, it's amazing how we went from fag packets to proper standards and then back to fag packets so quickly!

[DimPrawn]

3. Get proper requirements documented

Haven't seen anything remotely looking like requirements or documents since it all became user stories, epics and 3 days sprints with retrospectives.

[Project Monkey]

Boss tells me to do something one way. I do it exactly the way he says. Then he tests it in different situations unavailable to me, and it has a flaw. This is a mess, he says. That's because you did it this way.
That's how you told me to do it.
But you also have to do this other thing, in case of..

Thinks:
1. shut up and keep invoicing.
2. bring CV up to date.

Am I assessing this correctly?

In bold, too much D&C. Move on.