I have just joined a new project and yet again it seems to be a failure waiting to be rescued, what can I learn for ones in the future?
This project is like many others, developers have been doing one thing, huge amounts more have been promised, analysts doing another, management thinking something else, most of them seem quite competent, so what has gone wrong?
There are hundreds, if not thousands, of attempts to work this out so I may as well throw my ideas into the mix.
The biggest most obvious reason is over promise by the technical group. No one in the IT management area really gave them a strong direction either – so they chose to develop an outdated perl solution. The Analyst has been superb and has documented most business processes in a good level of detail. Development will now not be that hard.
So how to avoid the same traps the original developers fell into in future projects…..
- Don’t go for in house developers. Developing is just too hard to do without a decent core of people around to bounce ideas of, check each others code etc. In the past I have never been a fan of outsourcing, but I have turned fully around now.. but only for part of the team.
- Do have an analyst embedded with the client. The knowledge that can be gained by sitting with an organisation for a few months cannot be matched, no matter how skilled the interviewer. Once change management for implementation begins, they will be invaluable.
- Make sure the communication channels are there right from the beginning. Everyone should know the expectations. This does not mean a Prince project kick off or landscape document which will be ignored by everyone as soon as they are signed off, but a really easy way for everyone involved to see it, in detail, as often as they want.
- Documents should all be built in a living environment, sure there is a need for sign off at times, but a signed-off document, is a dead one and is meaningless the second it has been approved. If you try to repurpose your documentation content from one group to another, as often as possible, by default you become more aware of what each other is actually doing; or at least what questions to ask.
- A big one, make sure the project manager (or program manager) doesn’t just report what people want to hear. So many try to hide problems from the stakeholders, funders, senior managers, other project members , everyone!
- Overall it has to be a non-blame environment, get the communication happening in any form possible. Tools like Wikis and Blogs can assist with this, particularly if a common taxonomy for tagging has been established so that it is easy to view information applicable. Of course, if there is any form of blame comes down from these forums, openness will disapear. Establishing the rules before opening access, and keeping them brief, should help.