Reporting and Performance

Conclusion: Governance committees face a number of challenges that can undermine their effectiveness. These challenges include groupthink, a focus on individual responsibilities rather than organisation-wide benefits, trust issues and a lack of knowledge of emerging issues and opportunities. Appropriately qualified and experienced independent external advisors can play an important role in overcoming these challenges.

IBRSiQ is a database of client inquiries and is designed to get you talking to our advisors about these topics in the context of your organisation in order to provide tailored advice for your needs.

Conclusion: Most organisations across Australia have implemented project management methodologies to support successful project outcomes in a consistent manner. Project boards exist to provide support for project managers and advocate the business change that is being created by the project. An important role of the project board is to have oversight of progress and to ensure execution is advancing as expected. However, many project boards accept project status updates that include only lagging indicators and play a passive role in project oversight. Project indicators should include both lagging and leading indicators and project boards need to actively review and probe these areas to assess progress and identify early indicators that issues are emerging. Project difficulties often start in the blind spots and can be avoided.

Conclusion: Organisations everywhere have been embracing agile as a project delivery approach, agile for creativity and product development and even agile and lean for new business models. Seeking to fast-track their way to value often means embracing the minimum viable product (MVP) method. MVP is often bandied about but rarely is this method being utilised as intended. The reasons are many and varied and understanding what MVP really is and how to leverage the method effectively can provide significant value for teams and organisations alike.

Conclusion: Organisations understand that implementing projects is part of the natural workflow. Delivering projects that meet organisational expectations is expected and demanded. Project management offices (PMOs) have been established to support project management activities and provide some key elements such as project management methodologies, documentation, project manager recruitment and organisational reporting.

While many organisations have implemented a PMO, there are nearly as many organisations that continue to struggle with some key elements such as resourcing, benefits and prioritisation, and the PMO has an opportunity to provide real value to the organisation in addressing these areas.

Conclusion: Agile teams will struggle to deliver a viable solution (or product) unless they can tap into the business knowledge of an astute product owner who can communicate the objectives of the product and work with the scrum to ensure it meets the stakeholder’s requirements. Without a proficient product owner, the Agile team may lack direction which would put successful outcomes at risk.

 IBRSiQ is a database of Client inquiries and is designed to get you talking to our Advisors about these topics in the context of your organisation in order to provide tailored advice for your needs.

Conclusion: Project management principles and frameworks are now implemented in the majority of organisations, including public, commercial and the not-for-profit sectors across Australia. While project delivery metrics indicate an improvement in successful project execution there is still a concerning level of project failure (approximately 35 %). Project failure is extremely costly and while focus is on the project execution elements, many failures can be traced back to poor governance and decision making. Project boards set the tone and show the way forward for projects by helping to resolve challenges or to provide alternative actions. Their behaviour will be reflected whether the tone is positive or negative and has enormous impact.

Conclusion: Benefits management relating to technology investments is widely recognised in importance and is quantified and articulated in business cases but not managed. However, often these benefits are stated as expected by governance groups to gain investment, knowing that they are either aspirational or it is collectively accepted that they will be difficult to harvest and are therefore not pursued. Implementing a more pragmatic approach by project teams up to governance groups will provide an opportunity to improve this key area of IT investment governance.

Conclusion: Organisations everywhere are implementing Agile as a dynamic approach to speed up the creation of value and improve development of new and improved services and products. Adopting a best practice such as Agile is more than learning a new process and skill and then applying it in a project environment. Implementing Agile in an established organisation means that there are often a number of other frameworks, best practices and procedures that will need to co-exist with Agile. It is critical to consider these elements and adjust them to ensure that Agile is effective in delivering the value and benefits expected and is not another “best practice” fad.

Conclusion: Despite repeated audits pointing to failures by IT to deliver expected outcomes, organisations continue to publish IT plans that do not adequately address the fundamental dimensions of IT planning, being the IT Business Plan, IT Strategies and IT Program of Work.

These elements are often developed as a single composite document, but this approach fails to recognise that each dimension:

  • requires a different method of creation
  • is owned by different stakeholder groups
  • has a different purpose and audience
  • requires renewal on different cycles.

Failure to ensure that all dimensions are addressed presents risks to implementation both in terms of effective up-front investment selection as well as ongoing IT governance arising from gaps in critical decision-making information.

To avoid these risks, organisations should maintain the content of each IT planning element as a separate deliverable even if the desire, or requirement, is to regularly produce an “annually” updated composite document.

Conclusion: The current wave of digital transformation will see the retirement of large numbers of legacy systems. Although the cost of operations, including storage of data, in newer Cloud-based solutions is often cheaper, the cost of migration of historical data to new platforms can be significant. IBRS has observed increasing numbers of digital transformation projects where the decision is being made to preserve legacy systems using back-up infrastructure techniques at the application and/or database level without any reference to regulatory records management requirements.

Many legacy systems were not designed with a long-term view of key business records and information they capture and generate, nor are back-up technologies designed for long-term archival and retrieval of individual records. The result of these strategies is the potential for access to official records and chains of evidence to be interrupted – a situation likely to be viewed by regulators and stakeholders as a failure of the organisation’s record-keeping obligations.

IBRS iQ is a database of Client inquiries and is designed to get you talking to our Advisors about these topics in the context of your organisation in order to provide tailored advice for your needs.

Conclusions: Many enterprises are simply not capable of implementing the ICT programs and projects that they attempt because they lack the sophistication, skills and organisation to address these developments adequately.

The ‘fix’ is at governance level. Businesses must assess their native capability to contemplate, manage and complete the IT solutions planned to support their business operations.

Conducting a fundamental high level appraisal of a business’ ability to undertake IT tasks may be the most valuable contribution that most management teams and boards can make for the modern enterprise.

Conclusion: Return on investment is the touchstone of business investment success. Within marketing and in practice its use and definition is imprecise. The lack of precision is a challenge for marketing to the degree that it is difficult to assess its value in various dimensions.

Marketing and IT business case managers need to establish the baseline rules for return on investment and put them into practice for the long term.

Conclusion: Governance committees face a number of challenges that can undermine their effectiveness. These challenges include groupthink, a focus on individual responsibilities rather than organisation-wide benefits and trust issues. Experienced independent external advisors can play an important role in overcoming these challenges.

Conclusion: The full financial maturity model provides more detail which can be applied to organisational requirements.

Conclusion: Proficiency in financial analysis and concepts is critical for management. Assessment of an organisation’s skills establishes the requirements necessary to raise abilities. The financial maturity model can assist with the process of setting those requirements.

Conclusion: all organisations implement some form of ICT governance to determine how IT will operate: they manage demand, reduce waste and overheads, identify and deliver demand, and address risks.

The scope of ICT Governance is broad and the maturity and capability within organisations to manage ICT Governance differs significantly. ICT Governance activities commonly focus on the compliance aspects of the function and miss opportunities to use them more proactively and to develop significantly better partnerships with business areas.

Conclusion: Project Health Checks and Gateway Reviews are an excellent way of assessing the progress of a significant project, identifying issues and taking a corrective action approach that is in the best interests of the organisation. One of the obvious and highest risk periods for projects to go off the rails is the period between when a contract has been signed with a supplier and go-live day. Organisations can ensure that they have all the other elements for a successful project in place such as aligning with the strategic goals of the organisation, a rigorous options assessment resulting in a robust business case, a good governance framework and solid project team, and still have major challenges. There are some softer signs to watch, so that if is action is taken quickly, project failure can be averted.

Conclusion: Many organisations in Australia struggle with accurate prediction of project cost and schedule. There are two steps that organisations can make to address this: the first is reuse of well-defined solution building blocks – the second is repeatable construction of solutions using those building blocks.

Architecture and estimation are closely related functions. Therefore CIOs who struggle with projects that run over-time or over-budget should look to enterprise and solution architecture methods to increase the degree of reuse and repeatability when defining ICT-enabled solutions. This leads to improved accuracy in cost and schedule estimates.

Conclusion: The federal government has undertaken a number of whole-of-government (WofG) application and information services initiatives over the last five years. Now that these programs have mostly reached closure, a second wave is being initiated. At the same time state and territory governments are looking to implement similar programs.

Conclusion: With the increasing focus on governance of ICT investments and successful project delivery there will be an ongoing demand for high quality Project Managers to deliver outcomes for organisations. According to an article in The Australian earlier this year the most in-demand ICT roles are “Project Managers, Business Analysts and .NET professionals1”. CIOs have a number of challenges in recruiting or developing project management capabilities to ensure projects are successfully delivered to the organisation.

Conclusion: Most organisations have more ICT enabled projects and initiatives than they can possibly deliver. A significant number of CIOs report that gaining business consensus to prioritisation of projects can be an extremely difficult and often emotional process.

While availability of budget is a common qualifying criterion for ICT project progression, it is often not the biggest constraint. By applying a relatively simple project prioritisation framework to the list of projects waiting to be undertaken, CIOs can develop a program of work that is achievable and can be agreed across the organisation.

Conclusion: We appear to have reached a period in business management where ICT Governance is part of overall Corporate Governance. Across most organisations, policies and procedures have been implemented to support how ICT decisions are made, who makes them and who is accountable. Yet, there are still too many ICT project failures, a continuing inability to control costs, lack of resource management, and business dissatisfaction with the performance of ICT. In many cases organisations have implemented these measures to ensure compliance, or tick the boxes, and are not achieving the real benefit of Governance – Competitive Advantage. Organisations that move from a compliance-only approach to a Competitive Advantage approach can increase performance and improve the value of ICT investment within their organisation including public sector agencies.

Conclusion: Nobody doubts the need for effective governance of IT. Industry journals and Government Audit (and Ombudsman1) reports2 highlight project cost blowouts and implementation delays when governance is ineffective. Ironically while the reports set out what needs to be fixed, rarely do the authors tell readers how to do it.

Conclusion: It is easy to sheet home the blame for IT project cost overruns to difficulties experienced in estimating work days required. Whilst estimating is difficult it can be converted from an art form into science by identifying the tasks required in detail and estimating the work days required for each one. Include the total in the business case.

Conclusion: The prototyping of user interfaces is moving beyond traditional low-fidelity static wireframes and embracing more sophisticated approaches to simulate the entire application experience. Modern solution visualisation tools can deliver a more accurate and dynamic rendition of complex enterprise applications before a line of code is cut. This can significantly reduce delivery risk and improve development productivity. Beware though the diminishing returns from overly complex solution visualisation tools that absorb the cost and risk that they should be offsetting.

Observations: Prototyping has long been a means to visualise early in the system development lifecycle how a system should look and behave. This has the benefit of allowing a system design to be validated as early as possible by subject matter experts. While textual based requirements remain the primary contractual specification for system development, they are often hard to fully comprehend without the kinesthetic aid of a visual prototype.

A good prototype should put abstract and generalised requirements into the context of real life business processes and user interactions, creating a rich dialogue between system designers and users around the system’s expected behaviour. The use of a prototype to assist in the harvesting of correct, concise and consistent requirements can pay off considerably in the long term. Studies show that addressing defects in the requirements phase can be 100 times cheaper than fixing them as post-implementation defects.

Traditional prototyping: Low tech prototyping tools such as butchers paper, white board markers and post-it notes can be immensely valuable design tools when combined with adept user interaction facilitators and knowledgeable subject matter experts. Rapid storyboarding of anticipated system behaviour from a variety of stakeholder perspectives can generate a robust high-level shared view of system functionality. This can help establish, or challenge, the important assumptions and principles that will guide detailed design work.

The use of productivity applications to generate basic user interface mockups (Powerpoint, Visio, OmniGraffle) or RAD development tools (such as Dreamweaver and Visual Studio) to create HTML or native-app click-models have become common prototyping tools. In the case of RAD development tools the lurking danger is that users or (even more worryingly) executives, begin to see the prototype as almost the finished system. This can lead to pressure to “put the prototype into production” without the required underlying architectural support, or set false expectations about the considerable extra effort required to implement complex integration and business rule support. To avoid this situation a common rule is to implement a “throw away” prototype using a technology that is impossible to deploy into production.

Solution visualisation: New prototyping tools (such as iRise, Axure and SketchFlow) have emerged that support the end-to-end simulation of applications without the overhead of custom development. These “solution visualisation” tools enable the definition of rich visual user interfaces with advanced interactive features such as data entry, simulated business rules and complex navigation logic. Supporting these design elements are collaborative features that enable applications to be reviewed, annotated and critically evaluated in a fashion similar to the “mark-up” features of modern word processors. These prototype applications can often be packaged for easy distribution by email, facilitating analysis and review without the overhead of maintaining access to prototype infrastructure.

While solution visualisation tools can quickly deliver rich prototypes that flesh out high-fidelity representations of desired systems, the cost of purchasing such software and the effort to maintain complex prototype models can undermine the core benefits of prototyping. The benefit of common tools such as HTML editors or office productivity application lies in their ubiquitous availability and universal accessibility. Complex solution visualisation tools may require expensive up front license costs and/or proprietary file formats that require specific reader software to be installed for the viewing of applications. They may also require centralised repositories to be installed into server environments. These tradeoffs need to be carefully considered before embracing a solution visualisation toolset.

Multiple device simulation. The enterprise application landscape is changing. Touch phones and tablets have established a need for mobile “finger-driven” apps as much as there is a need for “mouse-driven” desktop apps. Corporate applications are demanding dual-mode solutions that support finger operated Android and iOS access just as they do web-based or rich native applications. This need is adding an extra burden on prototyping efforts to support multiple target platforms. Solution visualisation tools can help manage consistent requirements across a multitude of platforms.

ALM tool integration. The key outcome of solution visualisation or prototyping efforts is a consistent and complete set of requirements. In the modern software world applications are often managed by dedicated tools or as part of application lifecycle management (ALM) suites. Effective solution visualisation tools need to be able to integrate into the requirements and design management tools that support the end-to-end development lifecycle. This allows solution visualisation tools to be institutionalised in the core process of application delivery, rather than sidelined as a niche user experience activity.

Next steps:

  1. Organisations should carefully evaluate the use of prototyping in supporting custom application development. Is it effectively contributing to the quality of application design before moving into the development phase?

  2. If basic prototyping tools are not being used effectively start with the low fidelity approach and embed their use into upstream requirements and design activities.

  3. If basic prototyping has reached a ceiling of either design richness or stakeholder reach, consider solution visualisation toolsets. Consider carefully the Total Cost of Ownership of such tools against the anticipated benefits.

McConnell, Steve (2004). Code Complete (2nd ed.). Microsoft Press. ISBN 0-7356-1967-0.


Conclusion: Technical debt is a metaphor for the ongoing cost of bad IT decisions. As with debt in the real world, interest is paid on technical debt in the form of increased cost of operations and maintenance, poor quality solutions and loss of enterprise agility. Prudently managed technical debt can be a useful tactical tool, however uncontrolled technical debt can rapidly become an overwhelming burden and severely reduce the ability to invest in new initiatives. This is toxic technical debt. Crucial to managing technical debt is having an approach to identify and track when and where it is incurred.

Conclusion: During the GFC many organisations lost their innovation mojo. As economic rationalism reigned, organisational cultures became stale, research and development budgets were cut and fresh ideas stopped flowing.

Conclusion: Recent Standish Group research1 has shown that project failure rates for IT-based projects have risen since from 19% in 2006 to 24% in 2009. Running projects successfully has become more challenging in recent times as the lingering effects of the GFC tempt project participants to cut corners. Strengthening methodology observance and project governance arrangements may result in some improvements in success rates. However, IBRS believes that greater benefit can be achieved by transcending such mechanistic approaches. We advise a holistic re-examination of candidate projects using our 6C2 approach, then re-configuring those projects where necessary to improve their chances of success.

Conclusion:An often reported issue with our clients is that they find the process of benchmarking costly and time consuming, while rarely does it provide them with worthwhile information. After discussions with those involved we have found that this dissatisfaction is often due to a small number of issues which could have been resolved prior to undertaking the benchmarking process.

Over the last 2 years I’ve been surprised to find a number of e-mail and file archive projects that had failed very badly. I say surprised because for most of my career I’ve worked on infrastructure implementations, and while they are complex and messy, they generally workout Ok in the end.

After a few discussions with clients it dawned on me that while archiving is generally being implemented as an infrastructure, usually by IT infrastructure staff, it is very, very different from a typical infrastructure project. In particular archiving sits somewhere between a traditional infrastructure, i.e., some hardware and software that is generally very stable and has limited end-user features, and business applications, i.e., large scale software projects with extensive end-user features.

Conclusion: When establishing or enhancing an IT governance framework, one size does not fit all. For full effect, governance practices need to reflect an organisation’s ethos. Time can be the enemy of good governance practice; what works well at the outset may need to be tailored and progressively refined to suit evolving organisational maturity, changes in personnel and the interest of executives in contributing to the IT agenda. In essence, a multi-factorial, time-phased approach is recommended for instilling and maintaining effective IT governance.

Conclusion: Project managers often find management of the change process one of the hardest aspects to deal with in their projects. While they have been trained to deal with facts and figures using templates and other project management aids, rarely do they have the necessary skills and experience to successfully manage the workplace change associated with their projects.


Project managers often find management of the change process one of the hardest aspects to deal with in their projects. While they have been trained to deal with facts and figures using templates and other project management aids, rarely do they have the necessary skills and experience to successfully manage the workplace change associated with their projects.

Conclusion:The recession has brought the prophets of gloom out in force, all predicting massive cuts in the IT budget, with many of them also telling us how to address this. Their solutions are often facile and naïve, most boiling down to “do this to be more efficient”, ignoring the fact that most good IT shops have already made themselves highly cost-effective and have little room to move to reduce costs. Other commentators have recognised this and are predicting that the major savings in many IT shops will be by stopping or deferring projects.

Most IT shops have a range of projects on the go at any time, all with committed teams and management support. Determining which projects should be stopped or deferred may require the judgement of Solomon, and like Solomon, the IT manager should not be the one to make the decision. The projects are all, presumably, business focussed and the business should make the decisions.

Conclusion: The ability of organisations to implement major strategic business initiatives is to a large degree dependent on their ability to successfully execute the program of projects on which these strategies are reliant. Despite the importance of such programs most organisations, while accustomed to the demands of managing individual projects, often lack the skills and experience required to manage the complexity of such programs. The recruitment of an experienced program manager to lead the program and an integrated approach to program governance and planning can go a long way to ensuring a successful outcome.

Conclusion: Unless an organisation consistently conducts project PIRs (Post Implementation Reviews) for business systems (IS development, staff training and business process redesign) and IT Infrastructure projects it cannot claim to be learning organisation.

Done well the reviews can help avoid mistakes of the past, sustain the project’s benefits and aid staff development.

Organisations that do not review outcomes from business systems and IT Infrastructure projects, or do review them but pay little attention to the lessons learned, will probably continue to make unwise business systems investment decisions and fail to develop their people. 

Conclusion: Many organisations continue to have trouble having projects complete within budget, on time, and meeting user requirements. This is in spite of a plethora of project monitoring metrics and methodologies designed to prevent this happening.

Conclusion: One widely used mechanism for identifying project issues and assessing the overall status of projects is the concept of the project Health Check. The concept of an independent review, generally of high risk projects, has proven useful in providing guidance to management as to where corrective action needs to be applied in order to improve the prospects of project success. 

Conclusion: The application of a project management methodology to an organisation’s project work can be the cornerstone for consistent project success. It can assist, among other things, in allocating resources, managing the project schedule and controlling project costs. Most importantly it provides a consistent approach to managing projects across the organisation so that project personnel don’t waste time learning multiple approaches to the management of projects and executive management only have to deal with one approach to project governance and reporting. 

Conclusion: Risk management for IT projects or services that involve suppliers e.g. software and hardware suppliers or system integrators, is a more complex activity than the risk management of a project when there is no supplier involvement. There are not only additional considerations that must be addressed in the risk management process; there are also additional risks that will have been introduced through the involvement of supplier(s) of IT products, services or other resources.

Conclusion: Weaknesses in the approach to risk management, when applied to IT projects, can lead to poor project outcomes. A holistic approach that encompasses people, structure and organisational culture, as well as tools and process, is needed for the successful management of project risk.

Conclusion: For a project to be judged a success it must not only provide its deliverables on-time and within budget, it must also deliver the benefits that were outlined in its Business Case. These benefits will normally not be achieved unless there is a successful outcome to the process of change. The change may impact the organisation in a variety of ways, for example through changes to business processes, procedures, products or technology.

Conclusion: A number of recent high profile IT project failures have involved issues with external suppliers of services. Despite this, the increasing complexity of IT projects and the need to minimise on-going costs of in-house IT resources will necessitate the continued use of external suppliers. The effective management of such suppliers requires project management staff with skills that cover not just project management but also a high level of commercial, contractual, leadership and interpersonal skills.

Conclusion: An ongoing process of Project Portfolio Management, managed by a Project Management Office (PMO), can lead to significant improvements in the returns achieved on funds being invested in your IT projects.

Impressive ROI reports based on nebulous benefit predictions often slip through the approval process at big organisations. The numbers presented are often so impressive, or so difficult to understand, that no one bothers to question them. Organisations launch big software projects such as enterprise resource planning (ERP) and customer relationship management (CRM) - which can easily cost $50 million apiece at a large organisation - with a completely false sense of whether the project will pay off. For anything but minor projects, the ROI analysis is essential to the business case. But with the CIO responsible for delivery of the IT component of the project within budget, and a business manager responsible for the realisation of the benefits for the project, finalising the ROI analysis is often difficult.

Impressive ROI reports based on nebulous benefit predictions often slip through the approval process at big companies. The numbers presented are often so impressive, or so difficult to understand, that no one bothers to question them. Companies launch big software projects such as enterprise resource planning (ERP) and customer relationship management (CRM) - which can easily cost $50 million apiece at a large company - with a completely false sense of whether the project will pay off.

Conclusion:The analysis and discussion in the paper, The Role of Productivity (July05), examined how the productivity equation measures economic output. This paper extends that analysis to examine how productivity can and should be utilised in a business case.

Managers who use productivity as an objective in a business case would be advised to measure the current operational situation within their organisation. At first glance this may appear a difficult task but the reason is straightforward: any claim for a productivity gain will not mean what it declares unless an established benchmark is categorically defined. Moreover it will be useful in dealing with the aggressive productivity claims by vendors for their products when they can be judged in the context of an organisation’s operations.

In so doing managers who define their terms and the input criteria for productivity will be in a stronger position to make business cases and advocate investments in place of assertions.

In his excellent book on workplace change management titled, ‘Managing Transitions’, William Bridges focuses on the need for change agents to get the 4 Ps right when promoting their program.

Conclusion: Most senior managers are unclear whether their organisation is investing too much or too little in Information Management (IM) (IT plus business solutions with redesigned business processes). For some managers who cannot get resources to automate a process or get extra information on their desk tops, too little is being invested. Conversely, other business managers claim IT gets more than its share of resources and they are starved.

A common response when requests for extra investment in IT are made is, “How much are our competitors investing and are we at a competitive advantage or disadvantage?”

These are difficult questions to answer because I have observed:

  • It is hard to get sound and comparable IT related investment data from competitors

  • Published reports provide few performance metrics facilitating comparison

  • Although organisations may be in the same industry, differences in their management priorities and use of unorthodox accounting practices frustrate comparison.

Conclusion: Customer relationship management, business rules, and portals are typical examples of expensive technical solutions that require strong business leadership to deliver their promises of return on investment. Many IT executives have become aware of such solutions and seen their potential well ahead of their operational counterparts. However, many of these innovations have failed to achieve traction in the first instance as a result of poor socialisation prior to project initiation. Often, organisations shelve these projects for several years after initial failure and kick-starting them again is difficult.

Conclusion: Company reports used for planning and discussion are not always as clear as they might be. There are a few basic rules which can clarify what is required to be an effective report writer.

Firstly, ensure the argument and the structure is clear; that there is a beginning, middle and end to the flow of ideas to make the report cohesive. Secondly, use short sentences to make the argument unambiguous. Do not rely too much on bullet points in spite of the fact that they are widely used. A sentence argues a case and guides the reader through a thought. On the other hand, a bullet point asserts a point but may not convey an argument satisfactorily.

Most reports will have executive summaries or recommendations. To make the recommendations convincing it is essential that the arguments throughout the body of the report connect with each other. Structure will aid clarity, and these elements are the two hallmarks of good writing.

Conclusion: Effectiveness is, along with efficiency, the aim of many projects and investments. It is commonly expressed as a ratio, outputs minus inputs. Measuring effectiveness is however a more delicate process of evaluation than employing the blunt, and occasionally, imprecise ratio method, described above.

Comparing effectiveness with other measures of a company’s performance, such as revenue, demonstrates how well a department or a firm is working. It is more valuable than simply comparing a ‘before and after’ financial scenario.

In adopting this type of approach two factors to consider are:

  1. Adequate ‘before” the event data, showing levels of performance is required to assess effectiveness. (Sound after the event data is necessary too.) Measurement of performance and function must use all key variables. These variables may include financial items, benchmarked service levels, and people performance measures such as e.g. job, morale index or similar;

  2. Make any analysis comparative, with the purpose of showing what has been achieved. Grey, and or, so-called mixed results from an effectiveness assessment arise from weak analysis.

Implementing the techniques above should improve the quality of effectiveness metrics and thereby raise the standard of business planning outcomes.

Conclusion: CIOs who sit back and wait for their executive teams to implement ICT governance are putting their own careers at risk. While business leaders continue to misunderstand measures of ICT performance CIOs face two perennial problems: good performance may go completely unrecognised while CIOs may be blamed for failures that are totally outside their control.

More than half of all IT projects do not deliver the expected benefits. This is a metric that CEOs do not want to hear in these days of executive dissatisfaction with IT investment performance, and it is the CIO that is called to explain.

Conclusion: CIOs, because they have a cross enterprise perspective, are ideally positioned to champion the institutionalising of benefits management practices and demonstrate how to do it by corroborating the benefits from IT Infrastructure investment.