What the pandemic can teach Business Analysts

Not an on-line experience
Less close please

I recently managed to score a meeting with the Dean of Business at one of the GR8 Universities in Australia. Given the pandemonium in the University sector (think: no international students, the move to online education, the Government rework of University Course charges and lecturers can’t take their overseas junkets), I was grateful to get the time. Our conversation covered many topics to do with the future of work, but it was an off-hand comment that peaked my interest.

The Dean mentioned the remarkable job done by the University to pivot to on-line learning as large gatherings were prevented by the Covid-19 pandemic. The speed of transformation was breathtaking (a matter of weeks) and it was well supported by all academic and administrative staff. He commented that if the change had been driven as a regular University project it would have cost millions of dollars and taken 3 to 5 years.

I asked him what the key driver of this successful change was. Evidently the remote learning technology is reasonably mature and most staff had some familiarity with the on-line experience. This was not the main thing. “The one thing that made this happen was that everyone absolutely understood the need for change” the Dean stated.

This set me thinking, what can this teach us about business change in general? In this case many hundreds of man-hours of project manager, business analyst, change manager and tester’s time was not needed. Are we fundamentally flawed in our project approach? Is the money spent on these roles wasted, based on a mistaken belief that the only way to implement technology driven business change is through a well-resourced project team?

For me, the answer is yes and yes. Organisations can effect rapid business change effectively if stakeholders fully believe in the change rationale. In circumstances where the driver is less dramatic than a pandemic, we should be investing more effort in the “why” of change. In practice this means more upfront investment in clarifying strategic drivers and building excellent, believable business cases.

The second “yes” is that the project environment is not well suited to technology driven business change. The move to agile over recent years has certainly been an improvement, but ultimately the change capability must be built into the operating departments of every organisation. For technology driven change we need to move away from project managers to product owners and re-empower the people managers who have responsibility for business success.

It’s a hackneyed term “never let a good crisis go to waste”, but in this case we need some introspection and to ask the question – Are we really doing a good job with business change, or is it just fattening our wallets and keeping us employed?

What they don’t know

Birthday cake
Surprise!

Have you ever been to a dinner and known that one of the guests is about to get a surprise? The tingling excitement seeing their normal carry on persona until “it” happens and everyone shrieks in laughter. Well I sometimes feel IT / Business meetings are a bit like that – each side sharing what they think is important and when problems happen they ask “how could they have not known about that?”

The big IT decisions are taken in leadership governance forums, structured to get the right level of input about the opportunities and threats from the business, and likewise from technology. The trouble is that they don’t know everything that we know (on either side of the table). In fact often we don’t think they have sufficient understanding of the realities of the world we live in (again common to both sides).

People have to take decisions based on their understanding of the relevance and quality of the information in front of them. And if you want to get good outcomes, you have to take good decisions. So how do you develop effective governance in the organization. I have a few tips:

  1. The business side needs to see technology literacy as a core development requirement of its leaders. This is not about giving them an i-pad, but teaching them about the value of frameworks, the role of enterprise architecture and service models. Formal courses are required here and an increased technology focus in MBA courses would be a good start.
  2. There just has to be less optimism around IT solutions and more realism. Yes they are the free lunch that accounting firms drool over (while the IT folk work through lunch); but miracles don’t happen, they are dragged out by strong leadership teams steering a steady course and holding to realistic business outcomes – just like the team did with the Collins Class improvements.
  3. The people mix has to be right. You need governance teams with perceptive insight. These may not be the operationally focussed IT staff who have been promoted for brilliantly resolving the ceaseless IT outages. More likely it is the analysts or architects who will develop to GOVN7 competencies.
  4. The information that is shared has to be just right! The governance meetings may take up only a few percentage of the working week. What information to share and what to leave under the covers becomes very important. For project governance, this is reasonably well understood. As you move to programme, portfolio and business process governance, it comes down to having the right leaders with the perceptive insights of what is really important.

I have been a member of a State Government programme board for one of the largest IT projects in the country. We used to receive 300 page board packs, supplemented with consultants’ reports that ran to 100 pages each.  Fortunately we had perspicacious board members who knew where the really important information was – and it was very rarely in the executive summary!

So how do you think we can improve knowledge on both sides of the table?

Invest to succeed

strategic wrapper
strategic wrapper

As I have described many times in this blog, investing in IT solutions is notoriously risky. Just 1 in 5 projects succeeds and failures can bring down companies and governments. How then do enterprises manage this risk?

The answer is challenging to the project sponsors, who just want IT to get on with the job. With other areas of the business they assign accountability and expect the business unit heads to deliver on outcomes. With IT this approach is ineffective given the number of stakeholders and the limited ability to control events.

One example that springs to mind was when I introduced a recruitment and on-boarding system. The project was well run with a solid business case and good governance. Unfortunately the HR staff were too busy to contribute as a result of a high recruitment load from a major mining project. Rather than delivering a poor product, I slowed the project to allow them to engage. The final system was very successful, but the project ran over budget and over time.

To deliver on time, budget, scope and value, you need a strategic approach. The best way to do this is with a strategic wrapper, run by someone who can bridge the business / IT divide. They should by preference be independent from project delivery.

The wrapper has 4 components as per the diagram above:

1. Framing question. This is probably the most important step and is designed to test the business engagement. In an accelerated workshop format, the key senior stakeholders agree to the high level problem statement and commit to change. A great outcome is an email from the CEO to all staff “We are making this change for this reason and expect it to deliver this”.

2. Business case. A well written business case will surface any inconsistencies between the project and the organization’s strategy. It then sets out the options, scope, benefits, costs, risks and timeframe. Once this is agreed by all stakeholders, you can use the document as a bible for all future steps.

3. Project governance. The people delivering the project will put in a governance process. This needs to be made accessible to senior stakeholders and you need a highly experienced individual to ensure that you make the right calls on the difficult decisions.

4. Value delivery. This step is so often missed out on IT projects. Organizations commit to the investment, they should also commit to the return. An independent analysis of returns against the business is guaranteed to focus the efforts of business unit leaders.

The strategic approach will cost money – typically 10% of the cost of a project. The approach is likely to deliver many times this benefit from a focused project that does not spend money on unnecessary features; cost reductions and quality improvements from best practice processes; and more business value delivered at the end of the project.

Does your business approach IT investment this way?

Upgrade or perish

Good old technology
Good old technology

The Voyager 1 spacecraft was launched in 1977 and will continue operating until 2020 (43 years), approximately 18 billion Km from earth. The NASA team built a dedicated control room for this and other deep space missions. This means they can continue to use the original computer and communication systems through the decades without continually upgrading operating systems.

A few years ago I visited the European Space Agency Operations Centre in Darmstadt, Germany where they had developed new approaches to dealing with the technology cycle and were building shared control rooms for their multi year missions like Rosetta and Cluster II. This is a complex challenge as operating systems become unsupported, programming languages change and engineers move on or retire.

Unfortunately most organizations do not have the luxury of ignoring the upgrade requirements from the technology cycle. IT departments put significant resources into continually upgrading products, often for no tangible business improvement. One of the biggest challenges around upgrades is the computer operating system. In April 2014 the XP operating system will no longer be supported by Microsoft and yet 38% of computers worldwide still use XP.

So how should organizations still running XP approach the end of support milestone. I believe that there are 3 items to discuss at the very highest level in the organization:

  1. The Risk. The primary risk is that when XP stops being supported, Microsoft will no longer issue security patches for discovered vulnerabilities. So how many vulnerabilities remain in XP and how serious is it when they are exploited? The Stuxnet worm (used to destroy uranium enriching centrifuges) used 4 previously undiscovered vulnerabilities. It is a fair bet that someone out there has discovered more vulnerabilities and is waiting until end of support to deploy them and maximize return on investment.The end of support for XP is particularly attractive to hackers. You could end up with malware that is almost undetectable and provides hackers access to systems long after XP has disappeared from your network.
  2. The resources required. There are 3 areas that will cost (and often dearly) – new licenses (either for the operating system or to update old software that does not run on 7); – testing for all the existing applications (almost guaranteed that some will not work first time); and the change project (including designing and deploying the new components and training). $1200 to $2000 per computer is the Gartner estimate, and I ran a project for 900 seats at $1.2M.
  3. The technology options. It is really too late to start an enterprise upgrade project and have it completed inside a year. Even if you get organized internally, the integrators have their resources fully committed to enterprises that have started before you. The situation is particularly serious if your desktop management systems are not up to date.I suggest that you need to look at procuring a cloud based managed desktop. Talk to a few vendors to get a pilot up and running while you develop your procurement documents. Identify and prioritize application testing and ensure that there are nominated business reps to own the test outcomes. Start working with the HR department on a bring your own computer strategy. Most importantly, write a business case that frames exactly what you are trying to achieve and minimize the scope to tackle the core issues, leaving the “nice to haves” until the new technology is bedded in.

One last piece of advice – if your organization “simply does not have the money” for an upgrade, secure your superannuation and check out Seek.com. In the end, upgrades are non-negotiable for anyone except NASA!

Is technology too expensive?

Leap of faith
Leap of faith

Successful business leaders ensure that the scarce resources available to them are best used. They focus on all aspects of spending and ask is it absolutely necessary? Is there a cheaper way of doing this? Can we squeeze out more for the same cost?

Given the challenges of the last few years, most of the low hanging fruit has already been harvested. The competitive pressure has not come off and CEOs are looking to balance an increased demand for services with a reduced ability to attract income. There are 3 main options to achieve this:

1. Transformational change. Radically changing the operating model through acquisition, amalgamation or strategic repositioning is an option. James Carlopio from the World Future Society suggests that these efforts fail 50-80% of the time.

2. Intermediation. This is where the relationships between suppliers and consumers is modified and may be as simple as consolidating suppliers to achieve discounts. This strategy can sometimes be affected with little of the risk associated with business change.

3. Incremental. Typically this involves turning the handle on business processes to make them more effective, reducing cost and improving quality. Technology is likely to be a core component and the biggest risks are around organizational change.

As a CIO I have been involved in a number of successful incremental change projects. One example was the introduction of a logistics management application in a large not for profit organization.

The new application had many technology challenges causing delays and frustration amongst the users. The business processes were standardized and simplified, which made some users feel disempowered. Fortunately there was a clear vision from senior management on what they wanted to achieve. The turning point came when a major disaster struck, requiring a highly complex logistics operation.

The simplified processes improved productivity of staff who were working 18 hours per day. The on line nature of the application meant that geographically dispersed stakeholders collaborated effectively. The biggest impact came from being able to analyse the supply chain and optimize ordering, reducing delivery time by a factor of 6 and costs by 80%.

Of course for every success story, there are litanies of disasters where IT investments have soaked up huge amounts of money. I have a few tips for making sure that you get value if you are investing scarce resources:

1. Create a business case. This clearly states the expectations behind business drivers, strategic outcomes, options, scope, benefits, costs, risks and timeframe. If the costs and risks outweigh the benefits, cancel the initiative early.

2. Assign accountability. You need to have individuals who are fully accountable for the business case and in particular the delivery of business benefits. The expectations should be clearly stated in the individual’s personal performance objectives

3. Excellence in delivery. Running IT projects is risky. The concensus from a number of surveys on IT projects is that just 1 in 5 are fully successful. A solid project methodology, experienced project managers and executive support focused on delivering the promised benefits will increase your chance of success

4. Connect initiatives. Running a series of disconnected IT initiatives will lead to lower agility and higher costs in the long run. Plan your IT like you would plan a city to make sure that your roads connect and you don’t build an abattoir in a residential area.

How confident are you about investing in organizational change?