UniPhi's version 12 release saw the demise of the lonely change request system. This system was created in UniPhi's second release back in 2005. Since then, the documents, costs, issues and risks modules have evolved to a point where all the functions contained in change requests were better managed via these other modules.
How is this so? Well, we realised that managing change is significantly more than document the description and reason why change occurred and then analysing the impacts. If you want manage change rather than react to it then it needs to be incorporated into the day to day management process of which, the first element is capturing the risk of change. By better identifying the risks of (or opportunities for) change to your project, you can then create specific tasks in UniPhi to mitigate the chances of the risk occurring and preparing for if it does.
As projects evolve, these risks sadly sometimes eventuate and other issues crop up that weren't identified in the risk analysis. By triggering contingency plans or logging, managing and if necessary escalating issues in a transparent and collaborative fashion through a web based tool that pulls in emails and allows for commentary with file sharing, these changes can be effectively closed out without impacting on budgets or delivery dates.
Of course, some issues morph into events that do requiring further funds and/or delay delivery of the project outputs (we won't even touch benefits as who manages these anyway). When this occurs, new budgets can be created in UniPhi's cost module, time delays via the project schedule function and then presented to management in accordance with the relevant delegation of authority via the the documents system. Once approved, this then becomes the new baseline to compare commitments and forecasts to complete.
And that is the interactive, evolutionary way we support managing change.
How is this so? Well, we realised that managing change is significantly more than document the description and reason why change occurred and then analysing the impacts. If you want manage change rather than react to it then it needs to be incorporated into the day to day management process of which, the first element is capturing the risk of change. By better identifying the risks of (or opportunities for) change to your project, you can then create specific tasks in UniPhi to mitigate the chances of the risk occurring and preparing for if it does.
 |
| Risk register across a portfolio of projects |
Of course, some issues morph into events that do requiring further funds and/or delay delivery of the project outputs (we won't even touch benefits as who manages these anyway). When this occurs, new budgets can be created in UniPhi's cost module, time delays via the project schedule function and then presented to management in accordance with the relevant delegation of authority via the the documents system. Once approved, this then becomes the new baseline to compare commitments and forecasts to complete.
And that is the interactive, evolutionary way we support managing change.
