Showing posts with label risk assessment. Show all posts
Showing posts with label risk assessment. Show all posts

Monday, 29 September 2014

Risk management - a conflict for iMedia companies

Trying to get a snapshot of risk management in digital development proved difficult and confusing. I was looking to find information about specific risks in project development but they didn’t surface; what did is actually more strategic and thought-provoking.

There is a complete spectrum of risks for tech companies ranging from lack of innovation to the higher risk of insolvency because of not managing financial risks. It’s a minefield. You find examples of larger companies valuing the smaller entrepreneurial risk-taking tech companies because they themselves are too big and slow to evolve business solutions that suit the fast-changing consumer environment. They appreciate the iterative progress/test cycle and user-lead style projects that give faster results. Hence the Accelerator Centre in West London where 11 tech companies have been selected by Barclays Bank and Techstars to invent future financial services. Another such partnership is Centrica and Hive where ‘normal management structures don’t apply’. General Electric (GE) outsource innovation including offering open competitions for ways to improve their products. Get more information on these from the BBC Business News (9 September 2014).

So from risk takers and their culture to the more traditional ‘control risks or else’ cultures. R3 – an insolvency trade body – has reported that tech firms are at higher risk of insolvency because of their failure to ‘factor in the full costs of development or assess the competition’. Apparently tech firms in the North-East are most vulnerable which explains the news item in the Lancashire Evening Post, Tech Sector has high number of firms at risk (29 September 2014).

The key word from the last paragraph was ‘cultures’. The ‘soft risks’ or ‘culture’ of a company are beginning to get serious recognition as a possible financial drain – a hard risk factor! The Dialogue blog (16 September 2014) Soft risk: how culture can fail business, by Richard Finn, gives interesting examples of where a culture misaligned with business purpose has had serious consequences. This is BIG, since he calls for senior management to create a new senior management position (non-executive director) and committee to manage soft risks! How does your company’s culture line up? Richard cites six consequences of a ‘bad’ culture as: business under-achievement, poor products, poor service, damaged investor sentiment, reputation destruction, and talent flight. Well, I’m sure no company wants those.

We’ll end with a conundrum. As I said, this risk assessment seems to follow a circular path. Enter the larger tech company that is targeting bespoke development companies in the government sector: KnowledgeKube from Mercato Solutions. They cite bespoke solutions as costing more and taking more time to develop. They offer a platform and services approach that will drive down costs and give government departments more control. It sells itself on being able to ‘remove the risk associated with bespoke development.’

So you see the conflict between the start of this blog where innovation and risk-taking are valued and this last example where bespoke development is itself risky and to be avoided.

Friday, 13 June 2014

Assessing risks in digital projects - sort-after skill but elusive

If you look at the job adverts for any Project Manager/Team Leader in digital companies then one of the top ‘wants’ is assessment / mitigation / avoidance of project risks. Once you try to find a definition of such risks to check if your experience meets the need, you get unstuck. A definition seems to be the ‘holy grail’ for iMedia!

The problem at one level is that there is a school of thought that wants to define and control risks while the other approach appears to accept that risks are necessary and that without them you’re not innovating, not moving forward, not succeeding in digital. Where does your company sit on this fence? How do they define the skills they want for a Project Manager? Can you do both – control and innovate?

Naturally, you don’t want your projects to fail, so you need to define and control or avoid as many lurking pitfalls as possible. But each digital project will throw up some variations in delivering the solution and these need the innovation/creativity to provide the workable answers. It’s true that the greater the innovation the greater the risks all round. Others may well learn from your mistakes and reap the rewards on your innovatory shoulders – but can you afford this? Can you afford to take the hit from an innovatory project on the premise that you’ll reap rewards later? It’s a business conundrum. Most businesses take the view that primarily you have to meet your clients’ needs and your budget. If there are risks, your clients have to know them and accept them. Many clients don’t want you learning on-the-job at their expense. Research - well isn’t that innovation - is a costly item.

The UK government’s Major Projects Authority has estimated an increase of over 15% in projects at risk between 20012 and 2013. This is billions of pounds. It doesn’t define which of these projects have a digital component but you can be sure that many do. It’s a sobering thought.

The Technology Strategy Board have defined a need for an innovator centre that is meant to help digital companies experiment in an attempt to get ideas to market more quickly and cheaply because this will contribute to the UK’s economy. You may be able to take advantage of this. The centre is due to open later this year.

Risks in projects can come from a variety of sources, including the diverse number of people involved across clients and developer teams as well as the actual software and hardware components and processes involved. So it might well be that a Project Manager should coordinate risk assessments across the expertise sectors involved in the project. This might include a risk assessment from the clients as to how the project might be received by their company and end users.

Why should the expertise for risk assessment reside with one person when a digital project crosses so many functions? If any marketing personnel are involved, they should be made aware of the very high threat of risk as perceived in their area. 58% of European marketeers, in a recent survey about their fast-changing role in the digital environment, foresaw risks in success for them caused by lack of skills, confusion over roles and responsibilities in their company and resistance to new programs. See the ‘key findings’ section in Discerning Digital’s summary of the Five most interesting takeaways from the Adobe summit (21.5.2014).

Perhaps the most down-to-earth recent account of risks in digital projects that should help you define the areas you might need to include in Risk Assessment is at Simpleweb in their blog Risk Assessment: How to avoid a disaster when you’re growing rapidly (29.5.2014).

They cite:
  1.  Look for changes (including indirect risks)
  2. Avoid if you can, mitigate if you can’t
  3. Know your strengths and weaknesses (lead the tech, don’t let it lead you)
A good start, but not the whole answer. Anyone got any risk assessment forms/templates for iMedia?

Thursday, 6 September 2012

Assessing risks in iMedia projects and lessons learnt

We've met some thorny problems recently over the maintenance of a long standing project that has been ticking over happily for six years. The design had been done by one company, the server hosting by another and the database processing back-end was done by us. The client managed the three companies in their separate roles. All has not gone smoothly just recently and it provides a salient trigger for a few points to bear in mind if you have long-running projects that just ... work.

Lesson 1 Don't get complacent. Re-assess the risks even on stable projects. There were several signs of risks in hindsight. Key players left two companies and the tacit intelligence they had built up about the nuances of the project left with them. The new staff struggled to catch up. On our side we will be providing detailed briefing documents to help new hosting staff understand how the database fits together, as it isn't obvious. We are also improving our 'disaster recovery' at our client's insistence (quite right too).

Lesson 2 Check the level of experience of the newcomers and point out to the companies that it is their responsibility to manage the changeover of staff successfully with enough back-up of the right level of experience to be mentors.

It is hard to meddle in other companies, of course, but in the end you can voice your concerns about the risks to the client and it is up to them to manage the companies. They pay them. But you should also be aware that you can help cover this risk by briefing people fully about how things work.

Lesson 3 The unforeseen consequences of a tiny bit extra.

When you get that niggling feeling, it probably means there's a risk that needs to be covered! We had that niggling feeling when the design company needed to insert a tiny extra database to log accesses to the public end of the system to make sure that people were limited on the amount of data they could download from the web site. This appears a sound bit of security for the whole database system, we'd all agree. So, what happened?

The system as a whole gets around a million hits a week and the new tiny database was actually being continuously updated. So the server logging increased dramatically and when this was coupled with the logging done as the database was rebuilt the server just ran out of disc space; very suddenly. Knowing what could be deleted without affecting the ongoing rebuild was not straightforward.

Lesson 4 Even back-up systems fail.

Yes, although everyone thought there was the emergency backup system if the database failed, the back-up failed too! There was the strangest set of circumstances, naturally. The server company physically moved the servers which lead to cascading set of failures. (See Andy's blog of two weeks ago Escape to the country, 27th August.) The emergency fallover backup wasn't quite isolated enough as its database was automatically following changes from the server it was mirroring and it mirrored the failure too.

Lesson 5 If one thing goes wrong, other things are more likely to as well! It's that tip of Murphy's (Law) iceberg. These things in isolation wouldn’t have been so bad, but they all happened in quick succession. Maybe too, this was because all had run so smoothly for years.

A long- and smooth-running project should be praised constantly for its stability and the people concerned need praise too. We are all guilty of only noticing the errors and moaning about them. Give credit to the old, forgotten but smooth-running projects. But keep an eye on them.

Thursday, 1 September 2011

Are website gremlins ‘black swans’?

Well, no they aren’t strictly – but what are black swans? Now, this is an interesting project management concept from IT. Black swans in project management terms are catastrophic risks that happen rarely but when they do, they have dire consequences.

We have used IT project management concepts of risk management in the past as the closest to our field of developing iMedia. The classic risk management assessment asks you to assess the risks to your project, starting with the most frequent and important, so that you control these away in the course of the project by various means. But, black swans would appear low on the traditional assessment, if at all. They are low probability but high impact. They are rare in threatening the business and if and when they do occur, humans have tended to sorted them out onerously. However if the technical system is not designed to deal with them and people come to rely on the systems, it can be too late once someone recognises what is going on. Also, the consequences to the business can be compounded by other factors happening at the same time that have nothing to do with the software.

Take a good look at the BBC Technology article on Black Swans earlier this week, where Auto Windscreens is cited as having been the second largest company of its type in the UK but after trying to implement a new IT system, it went into administration in February.

We have the Boo.com story and the dot.com bubble as salient lessons in our sector – hope you’re all old enough to know about those! The article centres on research from Oxford Uni investigating massive IT project budget over-runs and the causes. Perhaps we should be thinking black swans too? Upgrades (for example) can be a big problem for shared hosting, since updating a web or database server on a system where they are shared by hundreds of different web sites risks some of them being broken by the changes. Unfortunately this results in shared hosting continuing to run using out-of-date software, including missing out of security patches.

And the website gremlins? This is a common concept where small changes to a site can have radical and unforeseen consequences. We’re quite used to the idea that any change must be checked out thoroughly and that it can have unforeseen impacts. Most of us rely on systematic testing to check out any changes, I imagine. But where non-professionals are building and repairing sites often for themselves, these gremlins cause lots of angst and can affect business badly too. Here are some examples to bring a smile to your faces – unless you recognise some of the consequences!
  • P9 forum has a classic rant – a bit old, but amusing nevertheless (I like the boffinus notaclueii).
  • Cast Fireplaces saw a change in customer behaviour when their website developed gremlins.
  • Smart Telecom aren’t immune either as a rant on their Broadband Customer Support thread shows
Look out for ‘Black Swans’ now!