Wednesday, June 08, 2005

Common Sense is the best tool for a project manager, and for a process.

Experience with a wide range of customers, and with teams with varying degrees of leadership skills, management skills and process control (and I mean varying - from none, to too much) has given me great exposure to a number of techniques to use, in the software development project lifecycle.

The overriding aspect of this process for me though, is common sense.

You have to know your team and your audience. The level of documentation and the contents of those documents, the number and formality of meetings etc, then becomes common sense. Do enough process to get the job done. Sometimes, too much is conterproductive, it won't get the job done because, forcing users - particularly inexperienced (in terms of IT) users - to read and sign off large documents will only alienate you and your team.

This was driven home to me recently when a senior manager in our company was commenting, unprompted on how he enjoyed reading the (one page) user stories we circulate (accompanied by more lengthy . I've managed to pick the most appropriate documents and techniques out of many processes to get the job done here. And it varies based on what we are producing too, somethings naturally need more detailed explanations first, so they get it. Other things need high level explanations, but detailed technical designs which end users don't, can't and shouldn't have to care about - so they get produced for development purposes only - anyway I digress - The manager in this case, finds it great to know exactly what we are doing, and appreciates the chance to change it before it;s too late.

This boiled done to common sense! It is just so easy, it astounds me how many project leads / managers don't insist on a bit of process up front to make sure all issues are out in the open.
Too many IT people seem to want to "get on with the real work". Well good luck to you, you will certainly be doing plenty of it. Some even manage to force customers to pay for all this work, and re-work. While that is happening there is no chance of any improvement to this situation.
So, use common sense in developing processes. Treat most projects differently, but draw on common techniques and approaches. This makes process repeatable, but repeatable in terms of your current environment. Remember, what should be repeatable are the results, well communicated requirements, soundly developed solutions and happy customers, not necessarily Product Requirements documents signed off, Use Cases signed off, technical design signed off, unit tests signed off etc.