Health Checks

Conclusion: A simple Google search can provide access to thousands of change management frameworks, methodologies and theories. Many relate specifically to digital transformation; however, methods such as the Knoster model cover organisational change more broadly across culture, vision, resources and action planning.

The frequency of unsuccessful organisational change or transformation is on the rise1. While there are many organisational change theories, this paper demonstrates the connection between a particular theoretical framework (Knoster model) and how an organisation can translate these theories into successful organisational activities and practice.

This advisory paper will step through the six dimensions of change within the Knoster model for managing complex change and how you can use this to easily investigate and diagnose the overall health of your organisation’s change or transformation agenda, and to identify practical steps to stay on track.

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: Effective project managers prize the importance of capturing lessons learnt during the life of a project, but too often, it is just a necessary task to complete at project closure. By following simple tips and adhering to some techniques, project managers can get increased benefits for themselves and the organisations they work with.

Conclusion: Project management in organisations is commonplace. Reviews are often undertaken at the end of the project to gain learnings for future projects. Project reviews completed during the life of a project need to ensure that they are inclusive of appropriate stakeholder groups and assessment is targeted at the appropriate focus areas. Active and inclusive review and assurance activities need to be well understood and supported within the organisation so that it is not viewed as an exam that needs to be prepared for and passed. Applying reviews and assurance as a process checkpoint only is ineffective and will not ensure quality project delivery.

Conclusion: The PMO role has many manifestations. It is also rarely static. When the organisation is in transformation mode the PMO must ensure project managers work as a team and deliver results. It is analogous to the role of an orchestra conductor who must get the musicians to rehearse so they know their roles and work together to make their opening concert a success.

Post transformation, one of the PMO’s roles is to get business operatives to assimilate the system’s functions so the benefits expected are realised. Similarly, the conductor’s role is to get the orchestra to perform so well there is a full house at every performance and the producer gets a satisfactory payback from the production.

Conclusion: Deciding to stop investing in a business system is a decision no manager likes to make as it could have an adverse impact on staff, suppliers, clients, stakeholders and the Board. Before making the decision, management must assess all options and conclude they have no alternative but to act now and stop wasting scarce resources.

Conclusion: To grow their business and deliver sought after online services, organisations must provide error free systems supported by robust IT infrastructure. When unable to deliver one or both of these consumers will seek other suppliers that provide better online services.

To meet consumer expectations online systems must be comprehensively tested and error free before making them publicly available, and operated on IT infrastructure that can be ramped-up when needed to meet consumer demands. The inability to provide quality services when required could put the organisation’s reputation at risk.

Conclusion: Businesses with an interest in becoming ‘digitally transformed’ need to take stock of their current status and preparedness. Systematic as well as creative approaches can be taken to discover ways to radically upgrade the business’ operations as shown in a self-assessment.

Use this checklist showing five stages of maturity in preparing for a digitally based transformation of the business.

Take the necessary actions in a graduated approach to make the required transitions endure.

Conclusion: When business critical systems have ‘passed their use-by-date’ or maintenance costs are excessive there is a temptation to fast-track the approval of the replacement systems and underestimate the cost and complexity of doing so. Avoid the temptation by thoroughly defining the scope of the project and include contingencies in the cost estimates to cater for the unexpected. When this is done, start lobbying management so they approve the project first time.

Conclusion: Project Management in organisations is commonplace. Reviews are essential, but often overlooked. Project reviews completed during the life of a project should include appropriate stakeholder groups and focus areas. Reviews that are inclusive of the groups not directly involved in the delivery of project activities and objectives can assist in identifying communication and brand perception issues. A clear and concise review program applied to projects can increase the likelihood of project success and improve the organisation’s brand image.

Conclusion: Organisations, large and small, have invested time and money over the past 5-10 years in improving ICT project success. Skilled project managers, governance groups, increased executive awareness and improved processes have all combined to improve the probability of a successful project. However, recognising when to cut the losses of a failing project is still a problem for many organisations. Either they never terminate a failing project or they delay in making the decision to terminate it. Either way the consequences can be devastating.

Conclusion: Many organisations have implemented frameworks and methodologies, increased internal project management and improved project governance in an effort to improve IT project success. The Standish Group reports project success has shown considerable improvement over the last 15 years. However, projects can still fail and organisations can improve their preparedness for projects and change programs by spending time undertaking a Business Readiness Assessment (BRA) before they begin any new change initiative.

Conclusion: Two-thirds of all ICT projects fail to deliver all of their intended benefits on schedule and within budget1. This results in ICT Executives spending a lot of time explaining why project schedules have slipped, why projects have been abandoned, or why goals and requirements have changed.

The Gateway Review Process(GRP) provides a well-proven and recognised approach to project assurance. Increasingly the process is being used as a basis for developing customised assurance processes in organisations across Australia.

Knowing when and how to customise the process is non-trivial andmust be based on lessons learned from application of the GRP. Many aspects of the GRP have been based on careful design and research – changing those aspects unwittingly will greatly reduce the effectiveness of the custom process created.

Conclusion: CIOs today are often faced with deciding whether to buy integrated systems solutions and services from major vendors or buy best of breed solutions from multiple vendors and manage the integration project in-house.

Organisations that have engaged external services providers on a major scale and eroded their IT skills base typically find they have no option but to buy the integrated solution. Conversely those with specialist skills in-house and the need to develop their people, often find in-house systems integration solutions more attractive.


Conclusion: They usually begin with starry-eyed stakeholders. Too often they end in tears. After several years of fiscal restraint, blockbuster projects are back on the agenda. Many will fail. Others will fall well short of organisational expectations.

Conclusion: IT Strategic Plans typically include a long term application pathway for offering enhanced services to clients, and better management information. In reality this is just the beginning of the journey from concept to benefits realisation. To succeed, project sponsors need to take the initiative and gather arguments that will ensure funds are allocated to their projects by the governance group as soon practicable.

To minimise management tension the governance group has to create a level playing field and equitably allocate resources to sponsors whose projects best contribute to meeting business objectives.

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: Organisations aiming to improve the effectiveness of their EGIT (Enterprise Governance of IT) initiatives must ensure they apply best practices in relationship management with all stakeholders. This is because effective governance is dependent not only on having the right framework in place, but also people skilled in stakeholder relationship management positions to implement them.

Conclusion: Failed projects are newsworthy again. The most recent report from the Standish Group, which has studied over 70,000 IT-based projects since 1985, indicates that project failure levels reached new heights during the GFC. Prima facie, this is counterintuitive. Additional controls (such as closer scrutiny and reduced tolerance levels on spending) and cautionary approaches have typified executive responses to the GFC. However, cost-cutting to meet agreed targets and attempting to hasten project delivery in an already resource-lean environment will have contributed to this result.

Conclusion:The need for an overarching framework to drive business value from IT through value management processes, supported by mature delivery service processes has prompted the need for an enterprise-wide approach to IT governance1

Conclusion: Enterprise governance of IT (EGIT), the objective of which is to drive business value from IT, is a new concept. It also goes beyond traditional IT governance, which focuses on effective delivery of services, by seeking to transform IT so it can meet the current and future demands of all clients.

CIOs who can drive the transformation of IT and help drive business value through their leadership role with the senior management team will always find their services in demand.1Conversely those who do not take up the dual challenges run the risk of being perceived as operational managers only, and potentially limit their career advancement options.

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:Knowledge workers – and people in general – commonly overestimate their ability to convey information in documents, diagrams, and in discussions. To make matters worse, they typically have too much faith in the validity of their personal mental models to frame the problems that need to be solved. As a result, misinterpretations often remain undetected for months, milestones are missed, and deliverables don’t meet expectations. There is no antidote against project failure in terms of a universally applicable methodology, but many failures are avoidable by recognising that communication and collaboration is fraught with difficulties.

Conclusion: As discussed in “Backup is not Archive!1 all IT organisations should evaluate deployment of an archival platform. However, based on numerous client conversations and a recent survey, it is clear there are significant project risks in implementing archiving. One-quarter of archiving projects take more than two years to implement and nearly half of IT managers state that they would not recommend the archiving product they had selected!

Conclusion: Stakeholder management is a critical, but often overlooked aspect of project management. Insufficient attention to the needs and attitudes of project stakeholders can lead to project failure even when the more well known components of project management have been addressed.

As countries struggle to improve their populations’ dietary habits, now may be the right time to borrow an idea from the ICT industry: just claim it, whatever it might be, leads to higher productivity. The argument seems to work because products that linger on shelves start to move with this simple but effective message. It also motivates policymakers to design grand projects on the basis of productivity gains; it is at the centre of how business is done and it provides an unassailable argument. No one would deny the benefits of productivity.

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: A frequently reported cause of IT project failure is a lack of senior management ownership and leadership.1 This often first manifests itself in problems in the deliberations of the project’s steering committee. Measures that can reduce the likelihood of such problems occurring include the selection of committee members who meet the criteria given in this paper and the use of a Kick Off session to gain agreement on roles and expectations of both the committee members and the project manager.

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: Public sector IT projects can often have a range of characteristics different to their counterparts in the private sector. These can lead to project failure if the issues relating to them they are not appropriately addressed. The adoption of the following set of best practice principles can significant reduce the risk of project failure.

Conclusion: Organisations, especially in the public sector, are increasingly sensitive to the possible, potentially visible and embarrassing, failure of large IT projects. It is now customary to include independent quality assurance (IQA) of the project management for such projects as an added insurance to prevent failure. Lesser projects may not be able to justify such IQA and the PMO may be too involved with the projects to be able to give an objective view.

Conclusion: Deciding whether major business solutions, or ICT enabled projects, should proceed to the next stage during a review is pivotal for sound governance.

When lip service is paid to the review process project failure may just be around the corner. This view was put forward by the UK National Audit Office, and was endorsed in the November 2006 Review of ICT Governance by Queensland Government, which stated that one of the three prerequisites to project success is ‘rigorous challenge and scrutiny of projects and programs at each stage of the life cycle’.

Why do many IT projects that are obviously in serious trouble go well past the point where they should have been shutdown? We can all give examples of where money and resources have continued to be invested in such projects, but do we understand the factors that can impact on decision makers and unduly influence what would appear to be the rational decision to close down a troubled project?

Conclusion: An often reported reason behind failures in complex IT projects has been poor communications between the project team, the decision makers and other parties who were impacted by the project.

To address this project sponsors and project managers should ensure that communication strategies and associated communications plans are developed for all projects that are seen to be complex or have long lifecycles.

Conclusion: Stories of late and failed projects are legion within information technology. Whilst there are may be many reasons for project failure, a key root cause, largely overlooked in the literature, is failure to correctly enunciate user requirements. A less than satisfactory outcome at the requirements definition stage can only become magnified as the project proceeds.

Conclusion: Immediately after the project Kick Off meetings, project managers find it tempting to hit the ground running and tackle tasks identified straight away to communicate a sense of urgency. However, without a comprehensive statement of requirements and having got consensus to them from stakeholders, the probability of design or programming rework is high.

Set out below is a process for capturing requirements and getting consensus to them from business managers. I have used the process successfully many times. It precedes, and must not be confused with, the JAD (Joint Application Design) activity.

Conclusion: Managers that fail to identify the benefits accruing from implementing an ERP will find it difficult to get senior managers to approve investment to upgrade to the next major release of the software.

Conclusion: The quality and precision of variables used in a plan will decide the fate of any plan. Variables come in many forms: sales, market trends, technological enhancements and so on.

Practical issues, such as the size of any given budget in a plan, may also influence and qualify the variables. Limitations on available resources may influence decisions to account for all relevant variables.

For example, the existing status of technology, or if a competitor has succeeded to your cost, could yield more realistic and sharper variables for planning.

All variables must be included in a general or master, plan, or in the appendix to it. The reason is straightforward, as it will indicate the thought process used to develop the plan and why. This level of information will also assist in subsequent iterations because the elements are discernible.

Two straightforward techniques can improve planning:

  • 1. Review past plans and the logic that gave those plans coherence.
  • 2. Cluster the variables of your current planning so that the relationship between them and net effect of one versus the other is clear.

By doing so the thought processes within the plan should be focused to everyone involved in the process.

Usage patterns will be different in every organisation, but the number and size of messages will continue to increase. It is important to watch for shifts in the technology that will help an organisation absorb more data with greater ease. Most of all, it is critical to understand how changes in the business, the technical capabilities of users or their correspondents, marketing plans or external events might create growth spurts or spikes in message size or volume.

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: Successful projects are analogous to freshly cooked puddings in that they not only have to smell nice when taken out of the oven but also excel when tasted to earn the praise of the client. Or to put it in simple terms a successful project is one that has helped the firm to realise the expected business outcomes.

To increase the probability of firms implementing successful projects senior managers must, at a minimum:

  • Identify staff with potential to handle the political as well as the technical arena of projects and a) give them training in project management disciplines as well as b) negotiation and influencing techniques

  • Implement the initiatives described below, monitor their outcomes and ensure the lessons learned in both technical and political arena are widely disseminated