Some of these six problems apply to projects other than IT projects.

1

A failure to distinguish between want and need.  At least one person has explicitly stated the supplier has to find out what the client wants and deliver it  No!  That will end in tears.  You have to establish what the client organisation needs (not what the person you’re talking to needs, and certainly not what they want).  It’s no good replying “well, when I wrote ‘want’, I knew I meant ‘need’”.  Sorry, don’t believe you (or, if it really is true, then your (lack of) accuracy with the English language will trip you up badly soon).

2

A failure to recognise that, if you are going to get from the client representative a full and accurate statement of what the client organisation needs, you are going to have to be, foremost, a good coach.  Good, because you’ll have to do the job quickly compared to normal coaching timescales.  There is no reason to suppose that a project manager is a good coach.  When I was doing this stuff, I had a unique position:  I was the intermediary between the client and the development team.  I certainly didn’t interfere with the development.  I was, though I didn’t know it then, using coaching skills I naturally possessed.

3

A failure adequately to define division of duties.  In other words, who is responsible for what.

(a)  It will be helpful of the supplier to brief the client on how the project is best managed;  how communication is to be handled between supplier and client;  who gets to sign off what, and what this means;  and so on.  All this stuff should be documented and signed by both parties.

(b)  The supplier is responsible for defining the needs.  The client is responsible for checking that the defined needs are the actual needs and acknowledges this by signing them off.  If subsequently the delivered software conforms to this definition, but it isn’t what the client now realises it needs, that is the client’s responsibility, however stupid the functionality looks in retrospect.  The correct response from the supplier is, “I am not a bleedin’ mindreader.”

However, the supplier can make a name for his/her business if he/she can develop an avowedly coaching approach which works to help the client work out what the client needs.  (This is what my company did.)

(c)  The supplier is responsible for designing, building and documenting the software, and for testing that it conforms to the previously signed off needs.  The client is responsible for checking the software does indeed do this and does so by testing it and, when appropriate, signing it off.

It’s worth reminding the client (it might be some months later) that it is the client’s job to do this acceptance testing and the supplier isn’t going to help them.

4

A willingness to be seduced by “lean” “technologies”, “rapid development” products and so on.  The fact that these things exist doesn’t suddenly obviate the need to do the job properly.

5

The elevation of the ”prototype” to almost mystic status.  A prototype is great as an aid to the coaching conversations at requirements definition stage, but the idea that it forms the basis of the finished code is dangerous.  Engineering prototypes are thrown away when they have served their purpose;  so should software prototypes.

6

A reluctance to test.  Yes, It can be boring.  My first ever task in my first ever job was to test a data vet program.  Boy was that tedious.  But the idea that you release untested software onto the your client’s clients is simply unprofessional, however prevalent.  No good arguing that everyone else does it, when what you mean is that you didn’t have the guts to tell the client what the cost of doing the job properly would be.

by Jeremy Marchant . image Free images (I don’t know what it means, either)
Please see About this website for guidance on using this material.