stty consulting › our future
Killing IT Softly cont..
Not Robust Enough
Some IT executives are to blame for not challenging business executives' unrealistic expectations of what can be delivered.
The key distinction between a CIO and an IT Manager is a CIO must always question the value of the project. In fact it shows the maturity of the business when the dividing line of CIO and IT Manager roles becomes blurred and the IT management can directly challenge the relevance of any project. The result of a CIO failing to act as a robust gatekeeper insisting that all projects have a solid business case and have been validated by the appropriate and pertinent people is that IT becomes the scapegoat for the 'canned' projects. IT certainly is the potential scapegoat when the communication breaks down as this is sighted as the department's weakest attribute.
Once the decision has been made to terminate, you need to explain clearly and precisely why it is being done.
In many businesses, especially in the UK, the IT function is controlled directly by the Finance Director thus failing to place anyone in the position of CIO. In this scenario the FD find that they are too distant from the department to clearly act prior to the inception of any project but are quickly dragged into the maelstrom of the failing ones. This again leads to the project team finding themselves in the firing line, sometimes quite literally.
Business Backing
Two methods that are employed to get the buy-in of senior management which work effectively for all business activities not just technology; set up a steering committee and get departmental sponsorship for the project. Both approaches are becoming increasingly popular with many large corporations in the UK.
Many businesses find them in the "tail wagging the dog" type of situation. Neither the business nor the technical teams would clearly and openly define their objectives which would leave the two creating very disparate plans. By implementing a number of steering committees that in turn seeks the advice from every aspect of the corporate entity, the business will more easily avoid the misspend that can have with technology initiatives.
By establishing these committees the CIO, or technology representative, is able to table any proposed strategic changes to the business systems and get a corporate decision or view point on it. Without these the CIO would normally be informed of the project, yet would find that no real discipline exists to ensure that no one would spend a great deal of money on technology initiatives without their prior involvement. The steer groups and project teams also ensure a greater visibility within the company, ensuring that there is a clear process to prioritise change at a strategic level. By developing these new formal lines of communication the projects and initiatives will be notified of planned changes more quickly rather than the delays inherent with the 'grapevine' methods.
Taking Ownership
The CIO will lead certain projects, such as technical infrastructure investments, but the heads of departments will own the projects from which they will derive benefits. Again, the CIO is the gatekeeper who must take the stance on whether the cost justifies the benefits that are expected to be delivered.
Using these methodologies no doubt will help the project, but some projects are inevitability doomed to failure !
Scheduling regular reviews and meetings helps all parties to identify areas of concern and possible pitfalls. If the project team find that they are making good progress, yet in order to meet the delivery targets they expect the cost to increase by x, then you need to sit down with the sponsor. You will have to assess the project as if it now costs this much, is the proposed benefits still justified. This is where the article comes in.
Check Ups
Having regular review is fine, just how often they need to be is the difficult question. Typically people don't know when the actual business case, that had been agreed, is going to change. Obviously there is little point checking the business case every week, but if a project will extend beyond the current quarter then it is advisable to sit down around a table and take stock of the situation.
It is a simple thing, yet far too many businesses fail to keep to the rule that the project should only move on to the next stage when the key deliverable are 'delivered'. Al to often the focus is much on the timeline rather than the overall benefits. Do not move to the next stage of the project unless you are satisfied with the content, quality and diligence has been taken.
There is another trend within the UK and that is to utilise a formal project management methodology, such as PRINCE2. Much of these structured methods do fall under common since but it does formalise the terms of engagement.
Using these methodologies no doubt will help the project, but some projects are inevitability doomed to failure. The onus is on the CIO and the project manager to spot the warning signs and act accordingly. When key deliverables are not achieved and best way to stop this from continuing is to use a 'gatekeeper' process or phased review methods.