Showing posts with label risk management. Show all posts
Showing posts with label risk management. 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.

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.