During projects we are all faced with problems and have to find solutions to them, these solutions can range from the very simple to the complex. Quite often though these solutions require some form of compromise, which at the time can be acceptable but later turn into a millstone.
During a recent project I was involved in, the project had many challenges around provision of servers to perform Proof of Concept (PoC) upgrades.
The client was trying to run the project at breakneck speed and the hosting partner was not able keep up, although in my experience this is a function of hosting partners and not any particular individual. Because of this difficulty in providing servers within the hosting partner, the client decided to utilize their internal capability, which on the face of it was a perfect solution. This blog will explain why this was not the solution it appeared to be and why governance around this decision is critical.
The client was undergoing an ECC 6 Upgrade and Unicode conversion from 4.7, they had been on Intel Itanium processors - therefore using IA64 chipsets and binaries. The new environment they were moving to within the hosting partner's data centre was based on the new Intel Nahalem processor - using the X64 chipsets and binaries. As I have blogged before, having a PoC at the beginning of a project is vital, as it validates a number of things which are vital to moving the project into the development phases. But what happens when you are not able to run your PoC in the way you intend to run your later phases.
Obviously it is heavily dependant upon what factors are limiting your ability to run the process you want to. In my case it was a combination of kit availability, processing power in the alternative solution, processor architecture differences.
The table below details these differences more fully
The table above was part of the output in defining our objectives and how these differences would affect our ability to use the results from the PoC.
This analysis yielded the table below, which shows the objective of the PoC, the challenge, the analysis of how useful the outcome would be and the importance of the objective.
The analysis was used to ensure that the solutions we were using did not invalidate the PoC, this subsequent analysis yielded the table below. Using the table the project was able to show how it would mitigate the risks and issues of not executing the exact process planned for Production and also the effect it had later in the project.
As shown above, most of our objectives could be met, but items specific to timings were impossible to validate properly. As a result the project team were not able to properly validate them until the 1st Trial cutover when we were working with Production data volumes and Production hardware.
This ambiguity caused several headaches to the project,
1. We were not able to give the business a full breakdown of the timings to justify our downtime requirement
2. The Steering committee has to 'trust' the project team that downtime had been properly extrapolated
3. The project team had to keep the faith the whole way through the project that we could bring the process in within the agreed window
During projects, clear governance is essential when making decisions like these - it protects people and the project, it should prevent issues descending into a 'blame culture' when previous decisions have negative consequences later.
The project used Sharepoint as a way of providing public access to the Risk and Issue logs, it also instituted a Decision log as a way of keeping track of the multitude of decisions made during the project.Using tools like Sharepoint are a very easy way to provide structure to certain project functions. For this project, using the decision log to record items like1. The stakeholders involved in the decision
2. The decision required
3. What the options are
4. What the decision taken was or the next action to be taken in order to reach a decisionSharepoint enabled a transparency that cannot be achieved with spreadsheets, when updating the decision in the log, the previously defined stakeholders are notified of any changes to a document that they are linked to. This enables them to check and verify any information relating to their work.
Project governance, in my opinion, not fun or sexy, but it is essential to the smooth running of a project. I will also put my own hand up as being a poor practitioner of project governance - better than I used to be for sure, but that's by learning the hard way.
1 Comment
