Understand where you are going before you leave.
Sounds simple enough. And yet despite all the theory and experience of decades of software development, it’s amazing how often projects are pursued in a ‘pioneering’ fashion.
An impatience to start build can be overwhelming, but projects routinely fail because insufficient thought and preparation is done before cutting code.
For the project team to work effectively, developers need to know where their work fits into the whole and also what business needs they are aiming to satisfy.
A failure to adequately comprehend and define how the solution will acheive the business objectives and ‘realise the benefits’ is a big risk and can easily mean the project will be late, blow the budget and leave an unhappy customer in it’s wake.
In terms of Project Control Processes, I’ve come to consider Risks and Issues as intrinsically linked, despite that many sources and courses teach these seperately.
Here’s the logic: An Issue is a Risk with a 100% likelyhood.
Issues are problems that need to be managed, in the same way as a risk once a trigger point has been reached.
The procedures for distinct risk registers and issue logs, means that Project managers can at best incur greater administration or at worst they can lose the holistic view that a combined view would give.
Ask yourself how many status meetings have you been to where the majority of the session is spent fire-fighting the issues and zipping through the risk log right at the end – or worst still, suggesting that be looked-at at the next meeting.
If the scoring system were adequately calculated it could be that some HUGE risks should merit higher attention than minor issues and should in truth be prioritised higher up any single list.