Governance

Conclusion: Standards Australia has developed and published the Australian Information and Communication Technology (ICT) Governance Standard1, the first government driven ICT Governance Standard in the world. This provides an opportunity for ICT dependent organisations to revisit their ICT governance and confirm it meets agreed good practice. It is also a useful template for any organisation that is setting up or re-examining its ICT governance, policies, and procedures. It should be used by company directors, owners of small businesses, and other organisations to recognise and accept their ICT responsibilities and to set in place processes that ensure that ICT meets these obligations.

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: In March 2001 the Organisation for Economic Cooperation and Development (OECD) published a management brief1 addressing problems in implementing large IT projects in the public and private sectors. Observations in this report included “...budgets are exceeded, deadlines are over-run and often the quality of the new system is far below the standard agreed when the project was undertaken”.

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: Project Portfolio Management (PPM) is now viewed as a necessary pre-condition for maximising the contribution of an organisation’s IT projects to the achievement of corporate goals. Unfortunately many Small to Medium Size Enterprises (SMEs) have made the decision not to implement the process due to its cost. The guidelines provided in this paper have been found to be effective in allowing a scaled down version of PPM to be implemented in a cost effective fashion within SMEs.

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.

With increasing use of external service providers CIOs and IT managers find themselves having to prepare an increasing number of RFPs (Requests for Proposals) to select the right provider at the right price.

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: 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: Public sector IT projects have been found to have similar rates of failure to their counterparts in the private sector, however they also have a number of characteristics that are different to private sector projects. Project related issues that arise from these characteristics have been found to be the drivers for the majority of public sector project failures.

Conclusion: Through the 1990s many organisations established Project Management Offices (PMOs). Also known as Project Offices and sometimes as Strategic Project Offices, these were generally set up within the IT organisation and were driven by the desire to take a more focused, financially responsible and standardised (read template-driven) approach to project delivery.

Conclusion: Many organisations have IT steering committees that are considered to be ineffective due to a combination of poorly defined committee charters and ineffective leadership. Restructuring of the committees and resourcing them with appropriately skilled business executives can result in IT Steering Committees that add significant strategic value to their organisations e.g. by prioritising IT projects based on business need and risk.

Conclusion: Portfolio Management is a process that allows management to prioritise and manage its portfolio of projects. The more progressive organisations within IT are finding that this approach needs to be modified in order to manage the different project types that are associated with competitive edge and strategic advantage business initiatives.

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: 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’.

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: One of the more difficult aspects of the management of projects is the decision making process associated with shutting down troubled projects. There are a range of factors that can influence decision makers and prevent them from making a rational decision to close down a troubled project. These include project related influences, psychological and social factors as well as organisational pressures.

Conclusion: The continuing widening of the span of control of application systems managers is a major management concern. Unless the span is reduced by initiatives such as replacing systems with marginal value and rationalising the number of application software vendors, organisations will see their systems maintenance costs rising higher than other support costs and the time from program fault to fix blowing out.

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: 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: Benefit management should be an integral part of every organisation’s project management methodology. Its application provides organisations with a clear view of the benefits being realised by their IT projects. It also ensures there is a continuing focus on benefit realisation during the project lifecycle and issues that arise are highlighted and addressed.

Conclusion: A Project Management Office (PMO) built to a model that is in sync with the organisation’s culture can, over time, have a major impact on project outcomes. To achieve this, the role and responsibilities of the PMO must be defined so that it addresses priority project related issues within the organisation. The office must then be resourced with personnel who have the skills and experience capable of undertaking the role allocated to the PMO.

Conclusion: Providing it has strong management support and is resourced with the right mix of personnel, a project management office can produce major benefits around:

  1. management of your organisations IT project portfolio; and

  2. the outcomes from these projects.

Conclusion:A prerequisite of a business case is that all the variables are covered; the forecasts of likely outcomes along with the returns on investment and the processes to manage the venture are classified and described. In so doing, risk is averted or minimised, although there may be occasions when a proposed venture is so large a degree of faith in a business forecast is just as influential as the logic or rationale contained in the business case.

As News Corporation emerged became the third largest digital media player in the US in 2005, its approach to managing online strategic investments offer an interesting insight into its strategic direction. For instance the corporation is now committed to digital media to produce a new growth channel as its newspaper businesses suffer decline.

Few mangers will face the scale of what News has done but two useful messages emerge. Firstly, catching up with the early movers is prudent because the risks associated with catching up with them decrease over time. Secondly, management needs to take steps to ensure that a new initiative works across the entire organisation, that is, it produces benefits for most operating divisions. In the case of News, to take a military analogy: they have boosted their right flank and hoped the left can survive – for the time being.

Conclusion: For CIOs sustaining effective IT Governance in an organisation is hard work, principally because most senior managers are preoccupied with meeting their performance targets and have little time to come to grips with the nuances of IT Governance. Helping these managers understand their role so they become informed participants in governance matters is an ongoing challenge.

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.

Conclusion: At the big end of town some remarkable process improvement breakthroughs are being achieved with a combination of Lean Manufacturing and Six Sigma philosophies. However, the benefits that can be realised from these techniques can also be enjoyed by medium sized enterprises. Using recent work carried out by the Commonwealth Bank of Australia (CBA) through its Commway initiative, this article briefly charts their journey to date and provides advice for those who wish to embark on similar journeys.

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: When executive decision makers review business cases and observe a ‘J' curve investment pattern, it generates immediate doubts regarding the project's value. On the other hand, ‘S' curves, which represent competitive advantage or increasing profit, generate enthusiastic responses. Unfortunately, too many IT infrastructure business cases are presented with ‘J' curve profiles due to high initial investment costs. In many cases projects with high initial costs and delayed profits can be legitimately restructured to reflect a better commercial outcome with forethought and strategy. Not every project can be transformed, but two methods of cost structuring and ROI analysis have demonstrated successful results.

Conclusion: IT executives are often held accountable for the non-delivery of business benefits when in most cases they are not in a position to ensure the appropriate business process and behavioural changes are made to realise the benefits. To avoid being blamed for someone else’s non-delivery IT executives need to have the governance owners in their organisations introduce a benefits management regime. One useful approach was developed by Cranfield University in the late 1990s.

Conclusion: It is unwise to initiate a requirements workshop with the view that participants will co-operate, work in harmony and not engage in organisational politics. In reality, the sponsor and the facilitator must assume organisational politics will play an important role and participants will use every opportunity to sell their ideas to their peers and as a last resort negotiate a win / win solution. Sponsors and facilitators of requirements workshop ignore organisational politics at their peril!

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: Too often project managers embark on programs of work without sufficient analysis on whether the organisation has the capability or capacity to implement the initiatives. When initiatives inevitably run late most internal observers cite poor project management as the cause of the problem.

Some programs cannot be implemented on time no matter how well they are project managed. These programs go wrong at the planning stage when people fail to identify the work that needs to be done before the proposed project can actually begin.

To avoid inevitable project management failures strategic planners must firstly determine what can actually be achieved in year 1, year 2 and year 3 of the ICT strategic plan. When implementation constraints are known planners can develop a base program of work that is achievable. Once this is done planners should then fine tune the priority of each initiative based on its contribution to business value.

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: 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.

In The Economist’s most recent IT quarterly (September 2003) survey there is a scathing piece about the implementation of CRM in banking, and financial institutions generally. Australia is not mentioned in the analysis, but the point is clear – that as many as 80% of CRM projects fail – which is not news to anyone with experience of CRM projects. There is a gulf between the promise and delivery of CRM.

Conclusion: Inability to manage the plethora of projects cutting across most organisations can lead to failed initiatives, an inability to align ICT and business investments, a lack of confidence in the organisation's ability to innovate and even substandard operational performance - quite simply operational performance can fall because renewal projects become late or are ineffective.

The main reason that these problems occur is that business initiatives are spawned within functional hierarchies and these hierarchies tend to act like silos. Organisations that are looking to effectively balance goal based and role based work need another structure to support the governance process so that resources and initiatives can become visible to the entire organisation. This paper recommends that a project office correctly implemented can play a key role in supporting the governance of goal based activities.

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.

Conclusion: Business managers, who sponsor major Business Solutions implementations, need to be identifying what they have to do to succeed and develop plans that will make success a reality. Focusing on the Right Things Starts with Astute Planning

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

Conclusion: It is no longer viable for telecommunication providers to simply offer Session Initiation Protocol (SIP) trunks for voice connectivity or Multi-Protocol Label Switching (MPLS) links to connect office and data centre locations. Nor does it make good business sense for the telco or for the customer.

The modern architectures of Cloud and Software-as-a-Service (SaaS), mixed with the need to maintain on-premise for critical elements are key components that support most digital strategies. Using older telecommunications architectures with fixed connections and physical infrastructure for routing and switching can be costly, and can stifle agility and therefore productivity.

However, modern telecommunication architectures bring an ability to virtualise connections and network switching. The abstraction of these capabilities allows dynamic management of the services providing substantial agility, as well as potential productivity gains and cost savings to the customer.

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 report on project success has shown considerable improvement over the last 18 years. However, projects still do 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

Traditionally, vendor lock-in was associated with deliberate vendor-driven outcomes, where software and hardware forced the client to align their business processes to those offered by a specific software or ICT platform. Vendor lock-in often limited the flexibility of organisations to meet business needs as well as increasing costs. As a result, information and communication technology (ICT) was often seen as a limiting factor for business success when agility was needed. Historically, vendor lock-in was therefore seen as a negative. Poor timing, bad decisions and clumsy procurement practices may still see organisations fall into unwanted vendor lock-in situations. But is vendor lock-in always a negative?