Posted on

So which is the best analysis method?

Some of us like to do things differently

As the digital space pervades more and more of business, decision makers are taking more of an interest in analysis. There are sufficient battle scars amongst the leaders of today who have suffered from software projects run by developers that they have got over the “do we really need the expense of analysis?” That is the good news.

The next step is of course to ensure that analysis is done correctly, and again there are battle scars from initiatives that have not gone to plan. I worked with a regional Council that was looking for a new IT service management system. They had an analyst develop a large number of requirements from innumerable workshops and put out a tender. Not a single vendor responded!

The key to successful analysis is to align the analysis technique to the specific project. The benchmark international standard for business analysis is managed by the International Institute for Business Analysis. They produce the Business Analysis Body of Knowledge (BABOK) Guide and have further developed a series of approaches in their specialisations – Business data analytics, Cybersecurity, Agile and Product ownership.

Having a global standard to follow and people who are certified certainly improves the chances of success for any initiative. The most critical step however is to document how you will do your analysis – the Requirements Management Plan, sometimes integrated with the overall Project Plan.

The key components of a Requirements Management Plan are:

  • High level approach – this aligns the approach with stakeholder expectations and with good practice. It details how current state will be recorded and analysed and how to go about developing a future state. It needs to align analysis with overall project methods such as agile, waterfall or procurement related.
  • Stakeholder engagement – how does the project engage with stakeholders and what are the expectations on both sides?
  • Process elicitation and documentation – what standards are being used? Do we include user stories and personas? What level of detail is being documented?
  • Requirements lifecycle management – how are the requirements being classified and managed through the lifecycle of the project?

Even with all this in place, getting analysis right is challenging. You need good people who can interact effectively, bring sufficient understanding into the workshops and work efficiently to manage the volume of detail that good analysis inevitably entails.

Have you had good or bad experiences with business analysis?

Posted on

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?

Posted on

Unleash the analyst in you

Flying in to do strategy
Flying in to do strategy

I have recently made a big change in my life, leaving a CIO role to join a top notch consulting firm. My business card calls me a Strategic Analyst, I get half the pay and have twice the fun. So how different are the jobs of an analysts and a CIO?

I have come up with 4 areas that highlight the similarity:

  1. The CIO as a strategist – The heart of any strategy is analysing current state, developing a vision of a future state and working out what is needed to get from one to the other. The future state is developed with the help of research, providing insight into trends in customer, marketplace, regulations and technology.The output from this enterprise analysis work may be a strategy and roadmap or a business case, all of which need to be bread and butter for a CIO
  2. The CIO as a builder – Much of the executive focus goes into the projects that IT are working on. While these typically represent only 30% of IT expenditure, projects are exciting and presage business change. While many see the skills of project managers and business analysts as the key to success, the CIO should be thinking at the program level. A well designed program focuses on how to integrate many initiatives to deliver an outcome that furthers the business strategy.Pulling good programs together needs enterprise analysis. CIOs need to be thinking about how all the moving parts of projects, programs and BAU knit together to deliver an outcome. The more components that are in motion, the greater the risk and the more strategic the analysis needs to be.
  3. The CIO as an operator. IT systems are not much use if they are not working! CIO careers can easily come unstuck when outages and security breaches cause embarrassment to the businesses.
    To operate IT systems well, the analysis effort needs to go into the IT processes up front. With a good service management framework in place, the CIO needs to ensure that operations are adequately resourced with skilled people committed to outcomes
  4. The CIO as a leader. One key skill for CIOs is as a leader of their team and as a networker / leader of stakeholders. Leadership is open to analysis. There are management techniques that are known to succeed and some CIOs develop a formal relationship architecture.In the end, relationships are about people and your personality type has a big impact here. You don’t have to be extrovert to be a CIO, but you do need empathy and excellent communication skills.

For me, CIO as an operator was my Achilles heel. I could never see how fixing the CIO’s phone was more important than keeping a mine site running or ensuring the intensive care ward was operating. I can now focus on what I am really good at – enterprise analysis, strategic thinking, business case development and program formulation.

So how many of the areas above does your CIO tick off?

Posted on

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?

Posted on

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!

Posted on

Excuse me CEO, just one question please?

It's tough at the top
It’s tough at the top

Gartner runs a CEO survey every year and in his blog, Mark Raskino asked what questions we should be asking in these surveys. The focus is on how the CEO sees the current state of IT and how it needs to change to support the business.

In my time as CIO, I have often wanted to ask my CEO that killer question that reframes his view of IT. I am not sure that I ever quite succeeded, but the accelerating pace of change driven by technology is probably making some CEOs nervous. Time to hit them with the big one ….

But first I need to frame the state of play as I see it.

The executive and senior management in many organizations are disappointed with IT and do not trust the IT department to deliver the technology that they need for transformation. IT departments provide solutions too slowly; they are too expensive and overly restrictive. The existing solutions are often not fit for purpose. CEOs don’t want to restrict innovation and profit by forcing all technology solutions through IT, so they are allowing the business to buy their own cloud solutions.

The IT departments are frustrated by the way that the business engages with IT issues. Best practice approaches to architecture, IT governance or security are only paid lip service by business leaders. I hear comments like “the business really needs to improve its maturity to be successful with IT”. Furthermore IT budget are constantly under pressure and IT management is having to focus increased effort on supporting products that they had no part in procuring.

A classic Mexican standoff, with the majority of guns pointing at the unlucky CIO!

So how does the CEO think IT should be run in their organization?

Do you believe that following IT best practices would deliver the right IT solutions for your business?

The best practices are there to ensure agility, quality, alignment, risk management and costs control – exactly the problems that organizations are experiencing. IT best practices stretch well beyond the IT department and can only work when the CEO is committed to them. The nexus of the question is who the CEO trusts to fix IT.

If the CEO does not trust the CIO, do they trust ISACA, ITSMF, or PMI (the best practice organizations)? If they don’t trust these industry groups who do they trust? Please let me know your thoughts

Posted on

How do CIOs befriend the miners?

Hole in the glacier
Undermined

I have worked as a CIO in a number of industries and each has their peculiarities. One segment where the CIO has to be particularly nimble is in the mining sector. There are a few top tips that I have learned from working for a contract miner, producing ore from working mines.

I’ll try to frame up the key requirements in this industry

1. The mining industry is cyclical and when it is hot, it is hot. They need solutions quickly and run high profit margins in the good times. As the cycle turns there is a focus on cost control. In many cases IT is delivering projects late in the cycle and appears out of step with reality.

2. The equipment used in the mines has become technologically complex. There are management systems on the trucks, the crushers have IT components and there are a myriad of complex systems such as slope stability monitoring. The vast majority of this equipment is purchased without IT involvement, but these days most of the systems connect to the internet via the corporate LAN.

3. Many in the mining workforce are engineers or technicians and technologically literate. They often source their own technology solutions and have the skills to make them effective in the workplace. Examples are collaboration systems and mobile enabled ordering systems. These are nearly always disconnected from the corporate IT systems.

As CIO, I was keen to get onto the front foot with these issues. I wanted to understand why the IT department could not deliver the solutions as quickly and cheaply as business units buying it themselves. I succeeded in providing solutions quickly, cheaply and properly supported (my perspective), but I don’t think I won the business over for the following reasons:

1. Acceptance of risk. The business had a higher tolerance of risk than that practiced in IT. When the business implemented their own technology there was no business continuity planning, security was dealt with in a superficial manner and there was often a complete loss of capability when a key staff member left (key man risk). The truth was that these systems would fail, but as different systems were used on different sites the impact would not be catastrophic.

2. Opaque costing. The actual costs of these systems were not well understood. There was no aggregated cost (as you would find in an IT budget) and the costs were often wrapped into other high value contracts. The costs benefits were calculated simplistically by referring to the punitive expenses of having plant not working.

3. Inconsistent expectations. Business provided solutions would fail and they often had poor maintenance arrangements. The business was surprisingly accepting of these issues (given the costs of down time) and much more accepting than for corporate provided IT systems. I put the inconsistency down to the extra control that the business had over the issue. They would deal directly with the supplier and often leverage a relationship to accelerate resolution.

So here are my 3 top tips for success (or at least avoiding disaster)

1. Know when to get out of the way – you may not have the capability or resources to deliver. Ensure that you engage the key stakeholders in this decision.

2. Map the risk – ensure that you have a holistic view of technology risk, not just IT risk. The Audit and Risk committee should be thankful for such a perspective.

3. Be excellent at project management – if you are providing solutions apply a professional, agile project management technique. Good people, a strong methodology and business involvement is a recipe for success.

What are your experiences with IT and the mining industry?