I recently posted the following comment on Facebook in regard to Russell Brown’s post on the apparent lack of good process in the procurement of IT systems for the now fnot-so-new Auckland super-city.

The primary reason these systems keep being selected is that managers are unwilling and/or unable to manage the risks associated with large invasive infrastructure/change projects so they choose to outsource that (the risk management). That large company must have deep pockets and that is confused with ‘can manage risk’. Problem is its *your money* they keep throwing at the project to ‘avoid failure’ – which is what ‘manage risk’ looks like from the vendor side.

I thought I’d take a little extra time and expand on a few of the thoughts contained therein.

While I have Government (and local Government) in mind while writing this, I have no doubt that same issues exist in the private sector too.

As I see it, the big problems that plague most IT projects is lack of information and a lack of process. Those running the projects simply do not have enough information, do not know how to get it, and do not have a way to determine what is important and what is not.

They also do not follow a process that’ll the project stay on track.

In order to run a large IT project two things need to be known and well-understood.

The first is an understanding of the current business processes, and the second is an understanding of the tools available to support that, or a new, business process.

(I have included an example of this approach from a project I managed at the end of this post.)

I’ll divide this discourse into four sections. Process, tools, risk and politics. In a few places I’ll include examples of what best practice looks like.

Process Knowledge

Peter Drucker once wrote that only those working in a process have the intimate knowledge that is needed to make improvements to that process. Managers ignore that at their peril.

A CIO, IT Manager, or Project Manager has to somehow tap into this knowledge.

Staff who work in processes know how those processes work, and very often what is broken or inefficient. They do not always (and most do not) have the skill or authority to change or fix broken processes. That is the responsibility of management, to work with staff to improve the process, or replace the process if the work changes.

As you go higher up the org chart, there is less knowledge of the inner workings of the critical business processes. The CEO should not, of course, need to know much of the fine detail. But at some point, someone has to be responsible. It is no longer enough to ‘run to budget’.

Every business process in an organisation is linked in some way to every other process. It is a System; all parts interact with all the other parts, often in ways that few people in an organisation understand.

W. Edwards Deming defined a System as “a network of interdependent components that work together to try to accomplish the aim of the system.” His books are still well worth reading.

A project that involves process change and new tools, even in an apparently isolated part of an organisation, will have an impact on the whole.

Inability to understand these processes, to improve them or design new ones, and to recognise you cannot do so in isolation, is the basis of many project failures.

Generally speaking, information technology should be used to support an existing business process, or should be used to aid migration from or replacement of an existing process. You cannot fix anything by just investing in IT (or technology). Paul Strassmann’s The Squandered Computer should be required reading for anyone involved it IT.

Tool Knowledge

To succeed, you must also have knowledge of the available tools. This can be obtained in several ways.

The first is a market survey. Contacting other similar organisations and finding out what tools they use is a good start, but be aware that there is no such thing as ‘instant pudding’. You cannot transplant tools and processes from another company into your own. It never works.

The second is calling for expressions of interest. The EOI document should request information about similar use-cases as your own. Don’t send out an EOI that says ‘we need an HR system’, or ‘ we are streamlining our customer relationship management’. Give the potential vendor some business context, and request that they demonstrate some understanding of the problems you are trying to solve.

Neither are hard to do.

There are some common traps in tool selection.

The first is using a tool you already know. Sadly, this is all too common. “I used this tool in my last job” is the single most dangerous philosophy to creep into any project.

The second is basing the selection of the product on relationships. “We got on really well with the implementation team”, or “the sales guys took us to some really nice restaurants”.

Relationships are important, but being able to to sustain a good working relationship with the company over the long term is more important than hitting it off with an employee who may not even be with the company in 12 months.

How many people have quickly changed their opinion of a supplier of services when there is a personnel change?

A third is, “our current vendor is good.” Good for what? What you currently do, your current processes? This does not mean they will be able to provide tools or expertise in the future. They may have a product roadmap that diverges from the path you want to take. Choosing that vendor may force you to follow their roadmap, or worse still, you will need to increasingly customise the solution to fit.

On the subject of customisation, that is also a huge trap. “We always buy off-the-shelf” is a common refrain. Yeah right. Customisations to a product generally add a lot of overhead during future upgrades because the customisations have to be tested and updated, usually at the customer’s expense.

Risk Management

Every projects has risks. The biggest is that the tools don’t fit the business process when the project is completed. Business processes might change during the course of the project, requiring changes to the scope of the project. This should be a warning signal. If processes changes that occur are being allowed to drive arbitrary changes to a running project, that is a major failure – it indicates a lack of actual process design, or the need for it.

Because there is a lack of understanding about business process or tools, it is now becoming increasingly common to outsource the risk management. “I don’t know enough about the business so I will pay someone else to take the risk for me.” The chosen vendor runs the whole project, and is responsible for most or all operational aspects of the solution once it is in use.

Frequently this is NOT explicitly stated in the project plan or in any written contract.

It is very easy to outsource your IT to a large company with deep pockets; once the contract (for a fixed price, one hopes) is signed, you are off-the-hook. As I alluded to in my comment above, what you see as ‘managing risk’ looks like ‘avoiding failure’ on the vendor side. There is a very, very simple reason for this: the vendor does not know as much about your business as you do. They don’t ever tell you this though, and the less they know about your business, the greater the cost of the contract because they have to be able to cover eventualities that are unknown to them.

Ahh, I here you cry, some vendors have a fix for this, they have their staff on-site, full time.

What’s happening there is that you are paying an external vendor’s staff to accumulate critical knowledge capital about your business processes and how they interact with the vendor’s tools. This ensures that they become the ‘expert’ about running your business, and makes it much harder to switch vendors later – one of the very reasons given for out-sourcing in the first place: “this gives us much more choice in the selection of services and vendors.” Bullshit.

Politics

Organisations are complex places to work. Sometimes decisions are made because it is politically expedient to do so. The phrase “no one ever got fired for buying IBM*” is an illustration of the problem. Let’s go with the known rather than the unknown. Lets go with the company that has a good reputation. If you want to look good to your boss then deal only with companies that ‘manage risk’, that can take that stuff off your hands. If it goes wrong, it’s not your fault, it’s the vendor’s. Your job is safe.

* The is nothing wrong with IBM, per se.

A comment on solution presentations

It is quite common for vendors to present their solution to prospective clients. These presentations – unless they have done a lot of research – are based on the vendor’s assumptions about your business operations. Because managers frequently do not know much operational detail the average presentation can be quite convincing.

It is possible you’ll see the solution they present as the answer to the company’s problems. It is only a solution to the problems you know about, and those are probably the top of the iceberg.

A comment on very large projects

It is quite common to for companies to look towards a single all-of-business solution. These monolithic solutions are almost certainly doomed to failure, or high costs, or both.

A project manager should be aware of how the market typically successfully handles large projects. Good examples are search engines, social networks, and video streaming services.

Take a look at how Netflix built their architecture, or Google or Twitter. All of these are built on open source, their infrastructures built around many smaller services. These can be updated, replicated for resilience, added or removed without major disruptions (usually!). I think there is a lesson in that.

Conclusions

Many IT projects are at risk before they begin because those in charge do not have enough information to make good decisions, or believe that they are imbued with special powers that come with their job title. Yes, that is harsh.

Accountability for the project outcomes are frequently contractually delegated to outsiders, removing any incentive for staff to understand or take control of what is going on. Yes, also harsh.

Yet time and time again we see reports in the press that illustrate many of the shortcomings I have described above.

The key to success is hiring people who understand the complexities outlined above and who can manage them. There also needs to be public transparency and accountability.

(To be clear, I am not saying don’t outsource, or do an all-of-business project, just understand what the drivers of this are, and the consequences of going down that path. It may still be the right course.)

======

Project example

I’ll use a very narrow example, from my own experience, to illustrate how an understanding of business processes, process improvement, and the available tools, can improve the chances of success.

About 15 years ago I ran a project at RNZ to find a digital replacement for our ageing analogue tape recorders. Most companies had stopped making analogue recorders, and there was a desire to provide better production tools, and streamline the way programmes were made.

The old process generally looked like this:

A producer would record an interview in the studio directly to tape. The producer would take the tape away, listen to it at their desk, and create a ‘paper edit’ – a list of the edits required. That tape and the edit list would be taken to the studio where an operator would dub edit the tape to a new master, editing as required. We did not do a lot of splicing of tape due to the cost. The other advantage of dub-editing is that you can redo edits if they don’t work the first time you execute them.

With an understanding of the process, I started researching the tools used by other broadcasters, and made contact to find out how they were transitioning from analogue. I was very fortunate to get a report from the BBC about their digital editor trial. Their project manager provided a number of very valuable insights, the primary one was that you cannot just treat a digital editor as a direct replacement for an analogue tape recorder – business process change is required to extract the most value from the tool change. Or put another way, the features provided by the new tool enabled changes in the production process.

The key message was don’t try to fit new tools into the current business process.

Once I had a sense of process and the tools, this was discussed with the project team. These folk were given the challenge of building a new production process, based on blue-sky thinking, and then we’d see which of the known tools might support that.

From that point I wrote a generic RFP outlining the function requirements of the system we wanted to support the new process.

Note that I said generic RFP. Even though we’d looked at some tools to get a sense of what was possible, you simply cannot allow yourself to form any views until the RFP responses are in.

For example, in our case, one of the RFP respondents disclosed that they we changing the focus of the product away form audio (they are now out of business). Another had very poor financials (they are also out of business now). One of these was a serious contender up to that point.

Information is king, and the more, the better.

This was, in IT terms, and relatively contained project.

We designed a new production process, based on digital field recording (still in its infancy at the point), desktop editing by producers, final production my producers and operators in the studio (where they final polish is done in ideal conditions), and then digital transfer to a play-out system.

While some of the other tools we needed were not available,  we designed the process to allow for them, ensured that when the technology was mature it could be used immediately. The outcome of the project was a much more flexible and higher capacity production process.

The chosen system has been flexible enough to allow us to move from DAT recording and CD playout and archiving, to flash card field recorders, digital archiving playout.

The project was delivered 5% over the $1.2 million budget, slightly late, but achieved all its objectives. It can be done!