This is related to Perl only in that I finally decided to write this down after people have been using one of my more inflammatory business web apps (it forces people to do work and communicate with each other). Note, I have used the *royal we* below. If your company isn't like this tell me where to send my CV ;).
I'm about to go on even more project management and my pre-activity questionnaire made me mull over something I have been wishing for a while.
The original question - what would you like your clients to be saying about you if you accidentally overheard them talking about you to one of their co-workers?
My answer? How about:
How can I better act as a client to Simon and his colleagues?
Ok, probably a little wet behind the ears at first reading but I feel quite serious about this. We spend time and money on choosing from a variety of management processes, tools and learning ways to communicate. Often through roleplay, discussion groups and generally anything to get us out of the office.
We do our utmost to get some kind of spec and (if lucky) a budget and business case. We fight against an overwhelming tide of politics, empire building, fixed timescales and infighting - sometimes within the team. We go to meetings with members of the client group and patiently sit through the usual run of character assinations and territorial markings.
Etc ... etc ... etc.
What we don't learn is how to be a good client.
So, in discussion with some work friends, at the gym and online, we started to come up with a list of things that would make a good client. Feel free to comment, add or ridicule any.
- If the spec changes, the project time goes UP.
- If you have a fixed timescale you have a reduced feature list
- Cutting documentation to save time means only one person understands the application so pray they don't leave or die
- If you don't say you what you really want then you cannot complain when it doesn't do what you wanted it to
- Looking pretty and actually working are two different things
- Any time quoted is always wrong - more time is always needed
- Ringing the developer twice a day will not make them work faster. Nor will asking them to report via email, spreadsheet or other communication format.
- Never say how something should be implemented. You are not the expert.
- Only you understand your requirements, state them as fully and completely as possible. Write them down. Get other people to read them.
- You are an expert in your chosen field - your service provider (developer or whatever) most likely is not. Always remember this in answering any question or in providing any information of any sort
- If there is a business case for the project and the requirements of that are met in full then the project is a complete. It is also a success.
- Always remember to say thank you - someone has worked hard for you
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.