In my opinion businesses, rather than dragging their feet are, all too often, wrestling with ill-defined, ill thought out and very badly communicated regulation.  

In order to succeed the Prudential Regulation Authority (PRA) and Financial Conduct Authority (FCA) will need to be far more prescriptive and much clearer in what is and is not permissible under the new regime if the spectre of financial meltdown is to be confined to history.

The crux of the problem is that recent regulation in the UK has all too often been open to interpretation, too ambiguous and especially poorly communicated. This has made it difficult for a typical Compliance team to clearly articulate to its ‘Business’ what has to be done to achieve Compliance, by whom and by when.

Regulation is all too often drafted with too many ‘shoulds’, ‘coulds’ and ‘mays’ in the specific detail. This means interpretation is left to individual organisations’ Compliance Teams who are regularly seen as ‘harbingers of doom’ and are constantly asking their ‘Businesses’ to give up valuable profits to implement expensive Regulatory Programmes that have no discernible benefit, other than the measures being implemented ‘may’ ensure regulatory scrutiny is averted.

Since its inception the FSA has failed to properly articulate what measures must be undertaken to achieve full Compliance. Perhaps the introduction of a formal ISO type standard might be a way in which Compliance standards can be evidenced and approved but that requires unprecedented decisive and definitive action on behalf of the Regulator.

In the end Businesses will do as they’re told with regard to Compliance but that telling has to replace the ‘shoulds’, ‘coulds’ and ‘mays’ with ‘musts’ and ‘wills’.

Sitting on the fence (and more specifically the glib use of ‘Risk Based Approach’ in practically every communication), did nothing to protect financial institutions, their shareholders, their customers, their employees or the wider population from the events and fallout of the Financial Crisis of 2008 (and beyond).

These lessons must be learned in the new world.

• Vendors tend to modify and customise the handsets so emulator testing does not represent actual behaviour
• Location based testing and network environment cannot be tested in an emulator
• Interoperability with other functions happening in parallel such as a phone call and how it affects the application under test and behaviour cannot be done in an emulator.
• Behaviour of the software on the device under different cellular network is also difficult to test in emulators. Some networks may have restrictions, while others might not. This is particularly true when the device is used in different countries.
• Multilingual software requires testing by changing the locale, which may or may not be possible in emulators.
• Security testing is even more of a concern amongst mobile users. Sensitive data must be protected and each device may have different security holes, which must be tested for. Also Cellular networks are know to be less secure and prone to hacking so extra testing in this area is required to make sure that data is secured appropriately.

Other functional validation such making sure that application is usable with devices of different screen sizes is also extra requirement in mobile application testing. This is because sometimes there is requirement for the software to work on a particular operating system for example Android, which supports tablets of varying screen sizes and different sized mobile phones. Although this is a very high level run through the issues I hope I have highlighted the need for some careful up front test planning and design before embarking on the testing of mobile applications.

As a direct result mobile applications become more and more attractive to companies as a means of 24/7 connectivity and information access especially with technological innovation in superfast 4G networks, NFC (Near Field Communication) devices, and availability of augmented reality and bar codes scanning. Mobiles devices using these technologies are revolutionising ways in which companies are conducting their business and spending in this area is increasing substantially.

Given the appetite for mobile devices from all sectors, there seems to be a rapid growth in different types of such devices coupled with a number of different operating systems to support them. We believe that testing these new applications is going to be a critical factor in making them successful and ensuring that companies do not suffer brand damage from releasing them in an unstable state.

So what are the challenges in testing applications on mobiles devices? First of all they don’t simply imitate Desktop environments but have their own user interfaces, business workflows and infrastructure dependencies. There is a choice of thin and thick clients and they must operate on a 24/7 basis, so businesses need to build new services and infrastructure separate from those servicing their normal applications. All this of course increases the risk of quality and performance problems occurring. Hence not only functional but performance validation of these applications is very important to mitigate the risks. Over the next few weeks I will be covering the various challenges in testing these applications.

The Oxford University research on big IT projects is timely given the increasing financial constraints on UK business. Businesses need to grow but are becoming more and more scared of engaging in large business change projects, fearing the worst outcomes we become less competitive, preferring the status quo, than the career limiting step towards business transformation we so dearly need to compete in the world market.

So, what is the answer? Some of it addressed in the article, over sized and over complex, over ambitious use of new technology are a few of the issues. When technology is changing so rapidly it is no surprise that projects as big and as complex as the NHS National Programme for IT had to be curtailed. It is clear that the big outsourcers and consultancies do not have the answer as they are often in the middle of the mess that ensues from a badly structured project. Despite the fact that the study highlights that the use of new technology introduces more risk. Many other sectors seem to manage this risk competently. In Grand Designs the use of new and exciting building technology rarely causes project failure. As my father used to say ‘a bad workman blames his tools’!

The fact is we need to adopt some of the rigorous control we employ in the more successful sectors such as construction. At Certeco we have adopted a planning method that encompasses the approach taken in constuction projects, this provides more rigorous programme office functions, ensuring governance and change control through the programme. Importantly, and this has started to happen in recent projects, the business users must provide more than sponsorship. They must be actively engaged in the process with a team that translates IT speak into business language so that the project is a Business venture NOT and IT Venture.

The early part of a relationship, during the period in which the transition away from the existing testing resource models to the new one led by the chosen testing supplier takes place, provides a number of risk areas. If not controlled properly, these can manifest into issues long into the ‘business as usual’ work.

During this early period, the real working practices begin to embed, including staff integration and  how much knowledge transfer is expected to “push” or “pull” and staff quality. The more formal or contractual aspects are tested for their validity here , including ramp up time and consistency, onshore /offshore ratio and dependencies expected from the supplier (such as quality documentation).

The risks around how the transition itself is performed need to be controlled. The supplier transition methodology may tend to the generic, not allowing for the state of a project through its lifecycle, or the peculiarities of technology, working practice or specific project issues.  The tension between project and its desire for continuity and organisation and the desire for early transition (and consequent economies) must be managed, so as to maximise benefits and early “buy-in”.

Once the model is in place and in the ‘business as usual’ state, the focus is on achieving the benefits whilst reducing the risks. Key ones to mitigate throughout the engagement are

• Late or cumbersome engagement with projects, leading to delay
• Overly narrow view of testing scope, leading to testing gaps
• Inaccurate estimates (too low leads to gaps or reduction in quality, too high leads to poor value).

If the supplier is offshore there are typically risks around the availability and support for test environments, time differences and cultural differences.

For the benefits of outsourcing to be achieved, it is vital that the service and quality do not suffer. Identifying and managing risks is a pre-requisite to achieving these benefits.

Risk Management – A risk management solution can provide not only documentation but workflow, evaluation, analysis, simulation, visualisation, reporting and remediation. That way the risk owner can identify and create appropriate controls to track and manage risks. Considering cost, quantifying losses and savings is important. Features such as centralised controls, cost-benefit analysis and the linking of regulatory requirements may be valuable in an enterpise solution.

Performance Management – I guess whereas risk management and audit are areas we take for granted, performance management is the holy grail. This is the point where it really is imperative that we architect a solution that integrates information from many silos and provides feedback on how performance of the organisation is affected by the risks indicated. Ideally the GRC framework will unify and link strategic objectives, KPI’s, targets, resources, Key Risk Indicators amongst other critical information to enable the strategic and operational plans to be monitored and adjusted as the business executes.

As you may be picking up, the linking up of information and making it visible across the business is a key theme. In our next review we will identify some other critical factors in designing a GRC solution.

Audit Capabilities
A key aspect of any solution will be how it support audit. Getting the data out quickly and having the flexibility to drill down when certain parties are focusing on a specific area will be critical. Obviously a key factor is identifying risk and then being able to manage it through visibility of the information relating to risk. But this no longer has to be constant review process within a business area and it can be made to be always visible at certain points in the business cycle. When you are building a solution think about lightening the burden that audit has on the business. Plan a solution that can support a collaborative view giving the audit team the information, whilst minimising the impact on a specific business area, allowing them to get on with their day job.

Integrated Management
Avoiding information silos will always be difficult but an ability of integrate/join data to provide a holistic view of the enterprise is essential. We have already discussed audit, highlighting that if risk management and audit can access an integrated view we get a focus on tracking risk in our audit process, if we can integrate policy management with compliance then we can monitor compliance on our policy portfolio. To achieve this the way we extract data from underlying systems will be critical, don’t be misled by ERP integration claims, take a closer look at how data can be combined to provide the most flexible solution.

Stay tuned for some more tips in my next blog where I will be considering compliance functionality and performance management amongst other topics.

Occupational psychology studies suggest that people are actually more social when using computer mediated communication, in certain situations it can often be a more productive environment for generating ideas but, identity theory research has evidenced that people will be discriminative even on a superficial level, which can cause “them and us” challenges for teams working in different locations.

While there is no silver bullet to help overcome these challenges, there are small measures which can help. In the past, I have created a virtual team table, where team members provide a photo (or image they feel represents them if they are uncomfortable sharing photos) to be used when having teleconferences. Managing communication is key, make use of mailing lists and wikis to ensure that information is communicated at the same time, ensuring that no-one feels left out. Ensuring that ownership of tasks is evenly spread across the different teams can help to minimise the feeling that one location has all the knowledge and power, creating harmony across the various locations.

 The test team set itself up as the communicators of information, relaying the state of the software to all the interested parties. The rest of the project team often say that testers should be objective and calm, making choices for the good of the project, avoiding politics because it jeopardizes this neutrality. Or at least that’s what they say.

But life is more complicated than this. We are human beings, with our own desires, hopes, fears and emotions. Like any others we make choices we later regret or that we worry are wrong. Sometimes we behave in one way and then, faced with a similar situation, behave in the opposite way.  We promise to better ourselves next time and for a while we do before slipping back into previous habits.

In my next few blog articles I hope to put some of these behaviours into context, and suggest a framework for ethical behaviour in a testing team. At the very least, I hope to get you thinking about how your test team might behave in certain situations so that you can make the “right” choice more often.

However, it requires a commitment by the organisation to a common approach to enterprise/strategic risk management, ultimately to build and protect shareholder value. After the last few years we all understand the importance of that cause.

The Lehman Brothers collapse highlighted that even with relatively sophisticated data management, with many stakeholders and transactions it can take months to unpick a complex situation. When a situation like Lehman’s must be analysed the statistical information normally associated with GRC is of very little use, the data behind the information must enable you to identify true business risks, exposure against counterparties in the marketplace,  identifying liabilities and relating them to time and events. The deeper and broader reach required by increasing regulation will of course establish this, but of course, not without a cost.

Of course if ‘more information’ is required… then the answer is more data! To enable this a strong foundation is required in designing and developing the enterprise wide GRC database, identifying and proving the analytical tools to transform the data into information, then establishing a reporting framework suitable to support all stakeholders. Surprisingly (or maybe not!) the many vendors we see in this sector focus heavily on the functionality of the GRC reporting capability and give little attention to the complexities of building, managing and reporting on the high volumes of transactional data involved.

The need for the analytical software to calculate risk is a given. The three pillars of Basel II. Minimum capital requirements, establishing a supervisory framework and ensuring market discipline must be supported. But the tools and resulting information and reports are really only half the requirement. Just as important will be the IT and Programme Governance, the structure and foundation of the business systems enterprise that creates the basis of the GRC system. Without the infrastructure in place to make sure the data is managed properly, testing is undertaken, projects are managed properly and the technology is correctly implemented the GRC platform may not be trustworthy and resilient.  When the foundation is set and the data is in place increased sophistication will follow in a controlled way. In this way we see IT Governance as a key foundation to enable enterprise wide business governance.

With the many software vendors with custom solutions and the various database technologies in place already it is clear that every organisation will have their own challenges in reaching their goals for GRC.