Governance

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:

When considering the level of Microsoft/Office and licensing, the biggest conundrum is generally around E3 versus E5 licensing. E3 licensing is closest to the capabilities organisations have had with perpetual licensing for the Office Pro suite. E5 licensing adds a slew of new services, including security, analytics, and advanced e-discovery and enterprise voice.

Conclusion:

Part four in this series of advisories looks at how to improve the disaster recovery (DR) planning maturity of your organisation. The focus of improving maturity in DR planning is to improve your probability of successfully meeting the needs of your business in the event of a disaster. Ensuring your DR plan (DRP) and business continuity planning (BCP) are fully integrated and that all elements of the organisation have a high degree of familiarity with DR processes.

Importantly, your organisation must understand that maturity is both a journey and a target. To maintain the target maturity, your organisation must put in place a number of strategies that will be continually repeated to ensure the target is both met and maintained.

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. It should be noted that despite all the strengths of Agile it is not suited to all projects. 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. Without looking at Agile as part of the whole ecosystem, the results can seem underwhelming or negatively impact on other areas, and can cause a lack of appreciation for Agile and subsequent lack of adoption, or a complete rejection of an approach that has so much to offer.

Conclusion:

Chargeback of enterprise-wide ICT costs were developed to assign ICT costs to the point of usage. The outcome is twofold; it ensures the initial allocation of ICT assets and services are identifiable, and it enables reallocation of underutilised or unnecessary services. This relies on IT creating assets and services which are commodified and transferable.

A chargeback arrangement can increase tension between ICT and the department managers. Allocating all ICT costs to achieve a zero-sum IT department can exacerbate that tension. Making IT fully responsible and accountable for IT costs can create insular behaviours which stifle innovation and investments in new IT services for departments. Departments will feel entitled to explore ICT improvements without an effective relationship with IT. Creating a chargeback governance model that manages disputes and builds trust in the process is preferable.

Conclusion:

Part three of this four part series looks at how the disaster recovery (DR) plan can be verified. The DR plan is in effect a contingency plan to deal with risk of a disaster. The DR test plan is a validation of the preparedness of the organisation to address these risks.

The need to have a DR plan verified is therefore essential if the contingency is to be effective. Just having a plan in place is not enough to mitigate the risk. The plan must be tested and verified as part of business as usual (BAU) to both increase familiarity with the plan, its standard operating procedures (SOPs) and processes, and most importantly, improve the likelihood of success.

The true benefit of digital strategies is in the thinking, reviewing, assessing and critical evaluation of where the current state is and where the target needs to be. Organisations that have commenced digital transformation have recognised that capability development and ownership of the strategy can make or break success. It is critical to be brutally honest about capability and skills to get to the target.

Log in and click the PDF link above to download the IBRS presentation kit to inform your team.

Conclusion:

There is no denying that the incidence and severity of ransomware cyber attacks, both real and fake, are on the rise. Whether the attacks are State-based or purely criminal in nature, organisations need to address their ability to both defend against such attacks and respond appropriately when they occur. The impact of a successful breach can have a high cost in the areas of productivity, reputation and the potential for financial losses. A good defensive posture against cyber attacks will make your organisation a harder nut to crack for the attackers.

Conclusion: 

Project management in organisations is commonplace. Reviews are often undertaken at the end of the project to gain insights 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 need to have a disaster recovery (DR) plan that is understood, agreed, and jointly owned by all elements of the organisation is essential in preparing for a disaster event. An effective DR plan will focus on managing the risk associated with completing a successful restoration and recovery in a time, and to a level of effectiveness, acceptable to business.

To ensure the plan is effective at mitigating the risks associated with completion of restoration and resumption of services after a disaster event; the DR plan must also clearly identify how the plan is to be verified and therefore reduce the risk of not completing a successful disaster recovery.

The key focus of the DR plan must always be about the restoring delivery of business functions. The technical delivery may be from ICT services on-premise, outsourced providers, or Cloud. Regardless of technical delivery to business, the impact of an ICT disaster event needs a verified plan!

We all hear that data is growing at exponential rates, and so too is the demand and complexity of data management practices. But does this mean you need to obtain the highest levels of data management and buy into the most sophisticated tool?

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.

Contract management can be more than just record keeping. When done well, it can enable organisations to explore the best ways to optimise their investments when conditions change.

This capability proved essential for the Australian government when COVID-19 hit, with investments in all manner of services and infrastructure being needed almost overnight.

IBRS interviews ZEN Enterprise, an Australian niche contract management solution vendor, and the contract manager from a large Australian agency to tease out the benefits and challenges of advanced contract management in an age of rapid change.

Conclusion

With the growth of dependence on ICT for business to perform effectively, many organisations have increased risk associated with the ability of ICT to provide service continuity. ICT downtime means business is negatively impacted. Many organisations believe the DRP is a problem that is ICTs to solve. Whilst ICT will lead the planning and do a lot of the heavy lifting when a disaster occurs, it can only be successful with the assistance and collaboration of its business partners. It will be the business that sets the priorities for restoration and accepts the risk.

Both business and ICT need to be comfortable that the disaster recovery (DR) plan has been verified to ensure a reasonable expectation that recovery will be successful.

The Latest

20 March 2021: GorillaStack has released capabilities that allows it to monitor and apply governance rules to any external service that communicates with AWS EventBridge.

Why it’s Important

GorillaStack is one of the earliest vendors to address the complexities of Cloud cost management, having started in Australia in 2015 and moved to having strong growth in the international market. In May 2020, GorillaStack was acquired by the switzerland-based SoftwareOne.

Like its international competitors, GorillaStack moved from helping organisations monitor and optimise their Cloud spend, to monitoring the Cloud ecosystems for performance and security concerns. This recent announcement suggests that the next phase of growth for organisations in the Cloud cost optimisation space is not only to detect events in Cloud infrastructure, but also external services, and then apply rules to perform specific actions on those events. Such rules can not only automatically help reduce Cloud spend by enforcing financial governance directly into the Cloud infrastructure, but also helping to enforce security rules.

Who’s Impacted

• CIO
• Development team leads
• Business analysts

What’s Next?

Cloud cost optimisation is already an important discipline for organisations with mature Cloud teams. Like software asset management (SAM), tools alone will not see organisations optimise their expenditure on Cloud services. An understanding of the disciplines required and setting up appropriate rules is needed. In addition, IBRS notes that many less-mature organisations have a ‘sprawl’ of Cloud services that need to first be identified and then reigned in before cost optimisations products can be fully effective. 

Related IBRS Advisory

1. New Generation IT Service Management Tools Part 2: Multi-Cloud Management
2. How to Get on Top of Cloud Billing
3. Sourcing Monthly April 2020 – May 2020

The Latest

9 March 2021: Dropbox has acquired DocSend for US$165 million. This is a welcome addition to managing the risks associated with information management in a collaborative environment. 

Why it’s Important

Dropbox’s acquisition is not about organic growth, as DocSend’s client base of 17,000 users is dwarfed by Dropbox’s estimated 600 million. The deal is more about positioning Dropbox against the likes of Adobe Document Cloud, by allowing organisations to track what happens to information once it is shared. Being able to manage and track document access is a critical aspect of modern, enterprise-grade file sharing which is needed for secure collaboration. It is a feature missing in most collaborative platforms - at least out of the box. 

Who’s impacted

• CIO
• Development team leads
• Business analysts

What’s Next?

Being able to manage access and track who’s accessed a document is a good start for closing the governance issues of most collaborative platforms (e.g. Teams, Slack, Zoom, Zoho, etc.)  However, organisations should look at adopting a zero trust model for information assets, involving identity management linked to access controls and an ‘encrypt everything by default’ mentality.  

Related IBRS Advisory

1. Did Dropbox just break knowledge management?
2. IBRS survey exposes Teams risk - The Australian - 21 January 2021
3. Microsoft Teams governance: Emerging better practices
4. Data loss by the back door, slipping away unnoticed
5. Workforce transformation Part 2: The evolving role of folders for controlled collaboration

Conclusion:

Involving end-users in the software development cycle isn’t a new concept, yet reportedly, 78 per cent of IT project professionals believe business stakeholders need to be more involved in and engaged with the requirements process¹. Commonly, software development project managers report problems with end-users’ ability to learn and use the new system and/or the end-users’ perceived quality of system functionality. While usability testing is meant to be a safeguard for system ease-of-use, user acceptance testing is designed to be a safeguard for the development of quality functionality. Both play a different role in the software development lifecycle.

This paper covers the differences between usability testing with end-users and user acceptance testing, also conducted with end-users and why both are equally important for the software development success.

Conclusion:

For many years Chief Information Officers (CIOs) have faced endless questions about whether Microsoft (MS) and other suppliers meet the requirements for an enterprise-grade solution. The main components of the office suite (Word, Excel and PowerPoint) and the Windows operating systems for desktops and servers, has been de facto standards for most organisations for many years.

With Microsoft’s success with Azure (Cloud and infrastructure), Dynamics (enterprise resource planning (ERP)), Office 365 (collaborative workplace platform) and the PowerPlatform (analytics and low-code workflow development), MS is now competitive in almost every aspect of the enterprise solution space. Your organisation’s approach to determining the value proposition for any supplier is the same as it has always been – maximum gain with minimum pain. The MS offering in both terms of capabilities, service support and security has matured significantly and now offers a much-improved value proposition that organisations should consider.

Conclusion:

COVID-19 has presented a number of challenges for business and the underlying Information and Communication Technology (ICT) in particular. These challenges have presented both as crisis and opportunity but all have been compelling events. To paraphrase Winston Churchill, ‘never let a good crisis go to waste’. In each case, this will only be possible when the lessons learned are properly investigated and documented, allowing evidence-based decisions to ensure organisations improve the way business is done.

The COVID-19 pandemic has resulted in many changes to the way business is done, how employees contribute, and how customers interact. Taking the time to evaluate performance, document the lessons learned, and to improve your business decision processes is invaluable. Applying the technical and business lessons learned from the period of this pandemic will add value for many years to come. It will allow your organisation to reinforce successes, avoid possible errors, and potentially improve its position in the marketplace.

Future of Work expert and IBRS advisor Dr Joseph Sweeney has made seven recommendations towards good Microsoft Team governance after surveying and speaking to 80 CIOs across Australian organisations. 

Microsoft Teams usage grew to more than 44 million global daily active users during COVID-19 and has still continued to grow. Dr Sweeney's findings discovered a number of concerning issues for organisations with Teams implementation and the risks associated with them. Businesses rushed to deploy Teams in a way that left them at risk of exposing critical data and damaging productivity.

Dr Sweeney emphasised Microsoft hasn't created an insecure environment with Teams. "Out of all the vendors Microsoft actually has a really good security Story" said Dr Sweeney. "The problem is, a lot of organisations in the rush to get people working from home turned Teams on, and they've deployed (it) without full consideration of all of these new risks."

Full story.

Related Articles

Microsoft teams governance: Emerging better practices

Better Practice Special Report: Microsoft Teams Governance

With the rush to deploy Teams to enable remote work in 2020, the majority of organisations have not yet fully considered the highly disruptive nature of deep collaboration. Governance has been largely overlooked in the effort to ‘just get people working’. IBRS outlines the seven critical areas of governance that must be immediately addressed for Teams to be sustainable and to mitigate the new risks (and benefits!) of deep collaboration. Find attached a PDF of the webinar to download for free. Or to view the webinar, click on the video below.

Conclusion: In today’s marketplace, a successful business needs to position itself strategically to be a leader in the market by either delivering services better and cheaper than the competition, or by disrupting the status quo to deliver services in a different way that empowers the consumer. To achieve this, organisations need to ensure their procurement plans are aligned with the business strategy and, where appropriate, identify in the ICT sphere where procurement is important strategically.

Organisations therefore need to identify the value a supply chain delivers to the business strategy. In doing so, the executive needs to understand the procurement activities that provide an advantage to the business in the marketplace, and which procurements may lead to a broader alliance with the supplier where mutual gain is possible to all parties involved.

Conclusion: The true benefit of digital strategies is in the thinking, reviewing, assessing and critical evaluation of where the current state is and where the target needs to be. Organisations that have commenced digital transformation have recognised that capability development and ownership of the strategy can make or break success. It is critical to be brutally honest about capability and skills to get to the target.

IBRS advisor Dr Wissam Raffoul, who specialises in transforming IT groups into service organisations, said legacy tech stacks had a lot of 'single point failures' which could bring whole systems to their knees.

Full story.

Conclusion: Organisations using Microsoft Server licences should consider leveraging the full potential of recent developments in the AWS licence suite. For more than a decade, AWS Cloud services have provided different organisations reliable data servicing and fewer downtime hours. AWS suggests that it offers clients more instances and twice the performance rate on SQL servers compared to other Cloud providers. Clients will need to have a performance rating in mind to validate these services for their own use.

Over the past decade, AWS has sought to innovate its processes and features following customer feedback. For example, the AWS License Manager was developed after customer feedback as a one-stop solution that manages usage limits and enables IT licensing optimisation across a variety of software vendors and across hybrid environments. It is important for customers to compare this licence management solution with other Cloud providers to validate the additional benefits.

Conclusion: All organisations need to identify the value of their procurement portfolio. That is, to document and regularly review the portfolio to understand both the criticality of the contracts to business and the triggers that decide whether the technology is meeting the need and when actions need to be put in place to limit the risk to the business in the acquisition process.

With an improved situational awareness of the procurement portfolio, organisations then need to ensure alignment with the business strategy. The alignment can only be achieved with regular independent reviews, and by effective governance processes to ensure that the risk associated with procurement planning is contained.

Conclusion: At the start of 2020, businesses had carefully-devised strategies in place which had been put together the year before. The onslaught of the global pandemic has either put these strategies to the test or caused them to be scrapped completely. The coronavirus has imposed changes everywhere we look and across different industries. Some businesses were forced to close shop. Others have been on a path of fast-tracked innovation and transformation. Before the pandemic, organisational behaviour had been structured to usher in growth and expansion. Although these are still valid goals, another factor has been added and that is survival.

With an economic crisis looming, consumer behaviour will inevitably change. Building and rebuilding the business requires its executives to be resilient and agile. A change in mindset is key. Alternative perspectives are relevant in pivoting in this new normal. After the period of adjustment has set in, managing IT may look different from how things were previously done.

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.

Conclusion: As-a-Service solutions offer organisations agility, flexibility and scalability but the graveyard of unused software piling up should ring alarm bells. Neglected software utilisation and compliance will be factors that should drive a new Software Asset Management (SAM) investment. The impact of an unmanaged Cloud SaaS or IaaS solution will be quickly revealed during audits. At a time when management is a focus, this should be an easy win.

Organisations will need to quickly identify if they are running single or multi-tenanted instances and whether production and non-production environments are being managed efficiently for the purposes of SAM product selection.

Selecting a SAM tool should be proportionate to the cost of non-compliance. Unmitigated software licence costs can be eye-watering. Consider these factors when selecting your SAM product for Information Technology Asset Management (ITAM):

1. Data points
2. Software overspend
3. Inefficiency
4. Compliance

Conclusion: In the modern world, no organisation has ICT entirely in-sourced. As a result, procurement, contract and vendor management have become strategic processes that allow organisations to align their ICT capability with the business strategy to achieve the desired outcomes, both now and into the future.

It is often the case that effective planning for the procurement of technology capability is compressed or constrained such that procurement is not able to effect ‘big step’ change. Or the commercial approach means the agreement is based on a fixed term, which results in the procurement not being a strategic exercise. More often than not, the procurement delivers constraints that limit the business’s ability to achieve the desired outcomes. These constraints limit the business’s ability to be agile in terms of elasticity, or how well it can respond to disruption in the market.

The technology options to meet business demand are not the same today as they were yesterday, and they will undoubtedly differ tomorrow. The challenge is to ensure ICT procurement is responsive to the business strategy, and that vendors share in the advantage a strategic alliance brings to the business. Procurement needs to be effectively planned and clearly aligned to the business strategy to ensure the strategy is delivered effectively.

This paper is the first in a four-part series on how to ensure procurement meets the business need, gain an understanding of strategic versus tactical procurement, and will define the steps necessary to avoid the pitfalls that cause procurements to under-deliver.

Conclusion: The need to see value from an enterprise architecture (EA) framework is essential, if for no other reason than to justify the cost. However, the business benefit of EA is not just the cost. It will also provide reduced risk and improved agility for the business in its use of ICT.

Many organisations struggle with how success or failure of EA should be measured. This paper provides the reader with guidance and advice on what to measure EA against and how that measurement could be presented as a key performance indicator (KPI).

In establishing KPIs for the EA framework your organisation has adopted, both business and ICT will jointly have a better understanding of the value EA brings to the enterprise, and be able to provide governance on the continuous improvement of your EA framework to achieve even better value.

Conclusion: Many organisations have integrated enterprise architecture (EA) into the business processes, whilst many have not. To some, it is a religious argument as to why the ICT group even needs to have people with ‘architect’ in their name; for others, the EA group is the watchdog of the system, ensuring both new capabilities and changes to existing capabilities will be fit for purpose.

Like most things in business, the cost versus benefit analysis to justify why any activity is a priority is essential before committing effort and resources to it. EA should be no different. Organisations should complete a business case assessment to justify why EA is necessary for their business model, and what form it should take.

In doing so, both business and ICT will jointly have a better understanding of the value EA brings to the enterprise, be able to manage expectations on what EA can deliver and judge its effectiveness.

Conclusion: The COVID-19 pandemic has taken the whole world by storm, shutting down establishments and pushing businesses and public sector agencies towards high levels of uncertainty. It seems it will be a while before this storm lets up.

Regardless of how bleak the effects of the pandemic and ensuing lockdowns are to the economy and the business sector, it can be a platform where leaders and innovators come forth.

Most companies are struggling to determine the next steps and are barely surviving through their business continuity plans. This paper aims to help you pivot towards a different perspective.

Conclusion: To prepare for the inevitable questioning by senior management of whether an expense line item can be reduced, management must review its breakdown and be prepared to justify it to senior management when asked. Responses must highlight the business risks that will ensue should a selected expense line item in the ICT opex (operating) and capex (capital) expense budgets be reduced. Failing to frame the response in business (risks) terms could delay the review and reflect poorly on ICT management.

Conclusion: As a result of COVID-19, has the criticality of web presence for your business changed? Is your organisation now exposed to threats and risks that previously were a lower order concern? Are there advantages to be gained in the realignment of the organisation’s web strategy?

IBRS recommends organisations assess the vision statement for its web presence. Once the vision is clear, review the framework for delivery and sustainment, the processes, and the roles and responsibilities for online web services, as a result of the impact of COVID-19. The purpose of the review is to ensure your organisation leverages the strengths and opportunities of the organisation’s online presence resulting from the impact of COVID-19.

Conclusion: In the current COVID-19-driven environment, video conference calls have become the stuff of life. They are used for school, family, leisure and even work. Numbers of call attendees have jumped from tens of millions to more than 300 million worldwide. As is normal in technology, there are a plethora of options to choose from.

One of those, Zoom, has made the news repeatedly over the period of April-May, initially because of its popularity but then because security flaws were being discovered. With the flaws seemingly serious, commentators were recommending organisations abandon Zoom. Many organisations did so, given the amount of coverage the flaws received.

But the product was and is popular. It is one of the easiest video conferencing products to use. It works well and is simple to deploy. A valid question to ask is whether Zoom is safe to use for business purposes. Taking a realistic view of the flaws combined with efforts Zoom has made to correct some of them leads to the conclusion that Zoom is safe for general business usage.

Conclusion: The phrase ‘People, Process and Technology’ describes the three key elements of a successful business. Business is the why, People the who, Process the what, and Technology the how. No single element of the trilogy can be seen as more important than the others. However, in the post-COVID-19 world, successful businesses will see that the focus of People has changed – they no longer go to work, work goes to them.

In technology terms, this effectively means that everyone is now the core of the system; the old concept of a core that is controlled from a central hub is now questionable. Post-COVID-19 technology design must allow for each worker to be able to work from any location, able to access information, services and data when necessary, and for each location to have surge capability.

Conclusion: Projects in trouble or failing need to be assessed with two main possible outcomes: rescue or discontinue. Organisations should carefully consider whether shutting down a project is a better outcome. If the decision is to discontinue then it should be done in a careful and controlled manner which considers the impact on stakeholders, team members and any residual value that can be extracted.

Conclusion: Organisations that are nearing the end of life for their current voice platforms or have a compelling event to hinge the replacement of their voice service, need to review their use of voice before replacing the technology. IBRS recommends organisations look to leverage voice as an application to operationalise the processes within the organisation, and improve customer satisfaction.

Today the newer technology offerings allow your organisation to get a better return from voice. However, the use of these new technologies will impact business processes and offer greater innovation for your customer interaction. It will not be a simple replacement of boxes.

The key is understanding the power of voice. It is now an application driven by smart software. Businesses need to assess their use of voice to determine the cost benefit of the changes in the technology stack now on offer.

Conclusion: Once a project is in trouble and the first response of escalation of commitment in terms of allocating time, budget and resources in an attempt to recover the project has not been successful, the project can be considered as not just troubled but in real crisis. Recognition of a project in crisis is the first step to recovery and often the most difficult. Next steps involve putting the project into triage and preparing the project for the detailed assessment phase which provides critical information, options and the potential important decision to kill the project or recover.

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: When projects start to show early signs that they may be in trouble, it is easy to have a knee-jerk reaction and address the most visible symptom. However, it is critical that CIOs and business executives (project board chairs and project sponsors) understand that early recognition and intervention is often less painful, less costly and less damaging for the organisation.

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: Not knowing where an organisation’s business-critical data is located, and its quality, can lead to many frustrating efforts to respond to management queries. When the converse is true and IT management can respond quickly to queries, say, at a board meeting or in an FOI (freedom of information) request, it enhances confidence in the quality of management of IT generally.

Conclusion: Deterministic¹ project budgets do not convey any information about the range of possible outcomes for a project, or the associated risk factors driving the range. The ability to communicate the risk-weighted range of possible project outcomes can lead to much clearer expectations and understanding of project outcomes, especially for project sponsors. Modelling these ranges can be performed with relative ease, using basic Excel add-ins and high-level estimates of risk applied to the components that make up a project².

Conclusion: The notifiable data breach regulations have had an impact on business priorities. For any organisation subject to the regulations, protection of personal information should have become a priority. One security technology, data loss prevention, could have offered some assistance. But it has had a mixed reception in the past due to many issues in both implementing and operating the service.

The continued move to SaaS for office systems such as document creation and email is also changing the market. Many capabilities that have been previously offered as standalone products are now being subsumed into the SaaS offerings as just adjunct functions. 

This simplifies the selection of the products and their ongoing management. A prime example of this is data loss prevention which is now being offered as a check-box selected capability in several SaaS offerings.

This could put data loss prevention within reach of small to medium businesses as a component of their personal information protection strategy.

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

Conclusion: Every dollar spent in supporting legacy systems or BAU (business as usual) represents a dollar that cannot be allocated to digital transformation initiatives. Conversely, organisations without legacy systems (digital natives) can be quicker to market with innovative solutions supporting the digital strategy, as there is no residual debt to repay.

Compounding the problem for organisations with legacy systems is that skilled IT professionals supporting them are likely to be fewer each year, as they leave for greener pastures or retire. To back fill, management must pay a premium to engage skilled contractors who will need time to understand the nuances of the legacy systems and become productive.

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: Managers need to pay attention to ensure effective project governance, or risk joining the already long list of ICT project failures in Australia, aided by weak or ineffective project governance.

Conclusion: Project management in organisations is commonplace. Organisations then seek to establish a Project Management Office (PMO) as a more permanent centre for project coordination. PMOs may start in the technology division and expand or may be established outside the ICT area. Knowing what the various models and structures are is important. Knowing how to assess the maturity and environment within the organisation and selecting the appropriate approach with empathy and common sense is critical to success.

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: 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: Most organisations today understand that business change requires the effective management of stakeholders. Whether they be internal or external, the inclusion of their opinions, needs and concerns is critical to the success of the initiative. However, too many projects and change programs still struggle to be completed successfully or to achieve desired outcomes. Change management and stakeholder engagement is too often handled as a linear process and many are under the assumption that working through the activities in sequence will be sufficient. Stakeholders are complex to identify and to assess as their relative power and influence often go beyond the obvious. Effective stakeholder engagement absolutely requires a full and frank appreciation of the power and influence of each stakeholder.

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.

Conclusion: Many municipalities and civic enterprises contemplating Smart City initiatives are simply not capable of implementing them because they lack the leadership, partnering skills, corporate experience, skills, sophistication and organisation required to address these global urban planning and ICT developments locally¹.

The remedy is at Governance level.

Municipalities must assess their own native capability to contemplate, evaluate, manage and complete Smart City business and ICT solutions according to global best practices.

Conducting a fundamental high level appraisal of a city’s ability to undertake Smart City tasks and programs may be the most valuable contribution that most mayors and civic management teams can make for the modern municipality.

Only municipalities working through a broad Digital Transformation strategy can truly expect to be in strategic control of Smart City initiatives as part of that framework. 'Smart’ initiatives are a critical element in fulfilling Digital Transformation for cities. 

For many civic organisations, the Mayor, Councillors, City Planners and Administrative Staff react to Smart City opportunities as if they sit outside their traditional local government role. However, the first principles of Digital Transformation require that a logical baseline of current capabilities should be established so that any initiatives are grounded in an understanding of the city’s ability to effectively evaluate them and deliver reliable solutions. 

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.

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.

Many enterprises are simply not capable of implementing the ICT programs and projects that they attempt because they lack the experience, skills, sophistication and organisation required 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.

This MAP addresses the need to identify an organisation's level of IT Maturity and outlines the steps that should be followed to improve on that level. 

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.

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: Most organisations have some form of central approval process (Governance) based around agreed artefacts – few organisations have a built-in evergreening process to ensure governance controls are in line with emerging technology and business trends.

Conclusion: The high-risk and high-reward Agile approach for systems development enabled many organisations to respond quickly to changing management strategies and yielded significant productivity benefits, according to a 2015 survey1.

However the same survey found not everyone has been so successful, as lack of experience in using the Agile approach, and organisation resistance to change, have frustrated almost the same number of organisations.

Once IT and business management have decided that Agile is the right approach they must:

• Champion and defend its use
• Actively track progress and allocate extra resources to the project if justified
• Provide a safe environment in which a retrospective review can be conducted
• Widely disseminate the lessons learned from the review, including strategies that succeeded and failed, without attributing blame

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: 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: 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: The full financial maturity model provides more detail which can be applied to organisational requirements.

Conclusion: Poor planning is frequently cited in surveys as a major reason an ICT project has failed. A major element in the planning process is the preparation of the business case setting out why the project is needed and must be approved.

Management is remiss when it approves a poorly developed business case as it sends the wrong message to developers and sponsors – that if the project fails to deliver they are not to blame.

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: ITIL Change Management is insufficient for CRM Governance – an organisational change is needed. As with all complex management jobs, governance for CRM projects should be divided into sets and subsets. By dividing the tasks it is easier to view each set or phase. By combining them into larger groups and modules it is feasible to gain an overview of how the parts fit together.

Conclusion: A product line engineering approach to digital service development and operation can unlock significant value if due diligence is applied when identifying product line stakeholders and product line scope. A successful product line is one that enables all stakeholders to apply their unique expertise within the context of the product line at exactly those points in time when their knowledge and insights are required as part of the organisational decision making process. Good product line architectures align human expertise, organisational structure, business processes, software system capabilities, and value chain integration¹ with customers and suppliers.

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: To provide easy to use online client services, organisations must create cross functional teams with people who can work together to implement solutions which can be tightly integrated with back office systems, and work first time. Failure to assign the right people first time will, until it is fixed, cause tension and stifle innovation.

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

Project directors and SROs¹ are still falling for the same mistakes that Brooks explained so elegantly in 1972².In large government environments where project scope and deadlines are dictated years in advance by election promises and new policy initiatives, many aspects of ‘agile’ can’t be adopted: BDUF (Big Design Up Front) is alive and well.

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: 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: 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: All organisations are multilingual, and most, more so than may seem apparent on the surface. A systematic effort to minimise the likelihood and impact of communication problems can lead to significant cost savings, productivity improvements, and improvement of staff morale. Data quality, the quality of system integration, and the quality of product or system specifications often turn out to be the Achilles’ heel. It is a mistake to assume that the biggest potential for misunderstandings is confined to the communication between business units and the internal IT department. Whilst some IT departments could certainly benefit from learning to speak the language used by the rest of the business, the same conclusion applies to all other business units.

Conclusion: Nobody doubts the need for effective governance of IT. Industry journals and Government Audit (and Ombudsman¹) reports² 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 steering committees and project managers must ‘keep their eye on the ball’ and remain alert for indicators that a project under their remit might fail. Avoiding corrective action will impact on morale and increase costs and potentially delay the project’s implementation. By taking immediate corrective action the project might be saved, or if it is to be stopped, minimise losses.

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

Conclusion: Establishing, or re-launching, a Program Management Office (PMO) using a text-book driven, ‘cookie cutter’ approach is not likely to bring about improvements in the performance of individual projects, IT programs or even a portfolio of projects. While some initial improvements may be observed as a consequence of closer management scrutiny, it is rare for formula-based approaches to work effectively on a sustained basis.

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: 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: 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: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 governance¹

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.¹Conversely 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.

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:It is tempting to seek out easy solutions for hard problems. Many others must have had similar problems, and a large part of the solution development effort can be short-circuited by selecting an appropriate productised solution – that’s hope. But similarities between problems in different organisations are easily over-estimated – that’s uncertainty. Business cases are strengthened by highlighting key differences to other organisations, and by proposing a path that incrementally removes uncertainty.

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: Organisations with immature IT governance processes push many of the decisions that need to be made by the business, back to IT. This creates a downward spiral, often characterised by IT making poor decisions about business/IT investments (due to insufficient business context), consequential failure by IT to deliver business value, then loss of confidence in the IT function, sometimes resulting in the CIO losing his or her job.

Conclusion: The terms “IT” and “governance” are frequently coupled, sometimes glibly and often inappropriately. Indeed, IT governance seems to have a multiplicity of meanings but is generally seen by IT people as a “white knight” in which business user engagement, properly executed, will overcome a troubled IT situation.