Skip to Content

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.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply