| Some projects are achieved on-budget/on-schedule, | | | | hunted' look that tells everyone that things are not |
| others are howling successes, some die a slow death, | | | | going well. |
| and others simply implode or explode. Quite the | | | | 4. Changing Scope: Successful - the business |
| spectrum when you look at it. Unfortunately, the last | | | | requirements are fully documented, signed off and |
| two are more common than the first two. So what | | | | base lined at the start of the project, with internal |
| really causes that slow death or that noisy bang? | | | | agreement on how scope changes will be handled, i.e. |
| Well, in order to clearly identify the causes, one first | | | | with proper change control procedures; Unsuccessful |
| has to know what clearly causes the successes. | | | | - business requirements are incomplete, are not base |
| 1. Executive Support: Successful - project support | | | | lined, changes enter in and the PM, wanting to be |
| from executives is visible, strong and CONSTANT; | | | | 'approved' by everyone, lets them happen without |
| Unsuccessful - executive support might appear to be | | | | documenting the impact to cost, time, etc. Changes |
| strong at the beginning but is not maintained and if | | | | to the project scope can cause overruns on cost and |
| the project gets into trouble, the executive starts | | | | schedule, and 9 out of 10 times leads to a bad ending |
| pointing the big gun at the Project Manager. | | | | for everyone. |
| 2. Stakeholder Involvement: Successful - all | | | | 5. Project Resources: Successful - resources are |
| stakeholders are identified, consulted and involved all | | | | available (although they are usually spread out over |
| throughout the project; Unsuccessful - stakeholder | | | | the organization), functional managers of the |
| list is incomplete, they are consulted at the beginning, | | | | resources are aware of the project and are willing to |
| but that slowly fades away, and the project does | | | | help the PM as needed, the resources assigned know |
| not deliver what is really wanted. | | | | they are needed and are ready; Unsuccessful - not |
| 3. Risks: Successful - project risks input is obtained | | | | enough resources at the beginning of the project (or |
| from many sources/stakeholders because the | | | | not fully qualified resources), the PM is stretched thin |
| Project Manager needs different viewpoints and | | | | either fighting to get the right resources or hoping |
| perspectives on what the risks are - could lead to | | | | that the existing resources will be up to the challenge |
| hundreds of risks at first, but is paired down through | | | | and won't run into major issues. |
| the review process; Unsuccessful - only the sponsor | | | | While there are a wide variety of other causes for |
| and the project team are consulted about risks and | | | | success/failure, the five areas listed above should |
| the risk register (list) is small (i.e. 20-30 tops). The | | | | help to flag the potholes along the way. Stay sharp |
| project misses risks, has major issues and the PM | | | | and good hunting! |
| ends up walking around the office with that 'I'm being | | | | |