Availability is simply the ability to get what you want from the system when you need it. There should not be any barriers outside of the checks and balances that manage the other security perspectives in the CIADA model.

Given that Excel is a fairly robust and prevalent industry application, there are not many software ‘features’ that may deliberately or inadvertently withhold information from its own users; though a side thought would caution against passwords only known by one person which is a simple but important risk.

Beyond this, I am slightly at a loss with regards to the specific availability threats in the context of decision support and reporting with Excel. The threats would be largely similar to any system I think… maybe there is something I am missing under this heading.

Appropriateness and alternatives advice is thin on the ground given that the risks cross solutions. So… um… yeah… (tumbleweed).

Contact me if you think of anything deep and meaningful – tweet me using @stugom or email me using stuart [dot] gomersall at bsguk [dot] co [dot] uk – and we can revise this post with appropriate credits where due.

The post Spreadsheets in the enterprise, considering availability (pt 3/5) appeared first on BSG (UK).

This post looks at the perspective of integrity – defined for this purpose as “concerning the unwanted modification of data.”

Modifying the data in a sensitive data set is a huge risk. Potential ruinous of the result in its entirety and in the context of a decision support system – it is the kind of thing that people lose jobs, homes and businesses over. Shockingly, people may even want to do this for selfish and malevolent reasons… and in an Excel world they can do this without a trace (almost – which is a thought for another post).

The threat is multi-dimensional:
1. Altering a data element directly – like lowering your own sales target in the evaluation sheet
2. Altering referenced data – linking your sales total to salesman of the year Bob’s total
3. Removing key data points – deleting Bob’s biggest sales account entirely
4. the list goes on…

There are complex tools within Excel and, if you speak “formulae” and can trace through multiple sheets simultaneously then you’re all good, you could find the modifications. Which is cool, right? What could possibly go wrong? Well – how do you know you’ve found them all, how long have you got to do the searching and fixing? And most importantly, how do you even know that there is a data integrity problem in the first place? On top of all this, the “business case” for Excel is usually that it is quicker, but by the time you’ve done all of this digging, that business case no longer stacks up.

Of course, even transactional enterprise systems of any type are vulnerable to data threat. The difference is that an enterprise system is layered: the data source and the reporting are separated which is not the case in Excel.

To repeat the rallying cry. Use common sense, think about the data you are handling, analysing, modelling and use the appropriate systems and countermeasures to make your work simple at the same time minimising risk of breaches. Easy, right?

The post Spreadsheets in the enterprise, considering integrity (pt 2/5) appeared first on BSG (UK).

Lack of centralised consumer credit information

Although there are institutions in a few of these countries that are taking steps to consolidate the consumer credit information, centralised credit bureaux similar to the Credit Reference Agency in the UK or the Credit Bureau in SA do not exist. The impact of this is that underwriters are unable to accurately assess the indebtedness of potential borrowers at the time of booking the loans.

Interestingly, collections agencies, that is, companies to whom collections and recoveries are outsourced, often have a richer view of the obligations facing customers as they store this information from their clients in the banking sector as well as mobile phone providers and retailers. Unfortunately this information is only used in the collections activities rather than at the point of underwriting by which time the proverbial horse has long since bolted.

Poor understanding of how loan financing works

Our observation of customer behaviours suggests that they have a poor understanding of the mechanics of loan financing. This leads to an unhealthy appetite for debt which is fuelled by inappropriately incentivised loan underwriters who try to make it as easy as possible for people to take on debt so they can meet their targets. Combine this with the absence of centralised consumer credit ratings and it’s easy to see how many customers’ debt service ratios often exceed the recommended levels of 30% ultimately leading to an inability to service debt and subsequent delinquency.

Lack of national identification schemes

Although many of the countries visited had effective national identity schemes, where these were absent, there were significant challenges. The Ugandan government has ceased issuing national identity cards and Tanzania has only recently introduced a national identity scheme. This makes it very difficult to uniquely identify customers and consolidate their credit information. This not only leads to asymmetric information at the point of underwriting, but also at the point of collections where customer contact information may have changed and it is not possible to link one John Smith to another.

Poor job stability

In many of the countries visited (most notably Zambia and Tanzania), there is poor job stability, particularly in the mining sector where the demand for labour fluctuates. Given the fact that miners are relatively well paid, underwriters are generally willing to grant them loans which would be unserviceable in many roles to which their skills might be transferrable (e.g. construction). This means that when miners find themselves out of employment in the mining industry they face immediate delinquency even if they can find alternative employment in another sector.

Poor quality contact information

KYC (Know Your Customer) regulation requires institutions to consolidate and maintain accuracy and currency of their customer contact information. Unfortunately, this is far from the reality in Africa. In Ghana for example, the growth of housing developments has outstripped the ability of local governments to create an address system (see here for details). In other countries, some customers provide addresses of empty plots and given the lack of a proof of address requirement, there is no way of validating this information. The end result is that bankers are often unable to locate their customers once their obligations are past due and the loans ultimately get written off.

When it comes to phone numbers, the increasing prevalence of mobile phones and the disposability of pay -as-you-go numbers mean that as soon as customers become delinquent, they discard their lines and obtain new ones to thwart the debt collectors’ efforts.

Prevalence of predatory short-term lending

If you take all of the above and add to the mix the rise and rise of microfinance institutions in the African market, you get a worsening situation. Unscrupulous short term lenders often prey on individuals who are unable to pay back debts to other institutions like banks or retailers. These individuals will use the short term loans to finance their longer term obligations and get stung with astronomical interest rates for their troubles, only to re-enter delinquency the following month.

Limited focus on customer lifetime value

Customers who have been poorly treated by collections agencies associate that experience with the lending institution and invariably will move to another bank once they become rehabilitated. As a result, the potential future earnings from these customers are lost. There is an increasing focus by global market-leading lenders on viewing their collections efforts as more of a customer debt rehabilitation exercise, rather than an effort to reduce distressed debt. This distinction is important because the difference is in the treatment of the customer, the ultimate source of profitability.

So what’s the answer?

From what I observed, the operations with the healthiest portfolios were those with the most conservative credit risk strategies, loaning only to those with the utmost likelihood of repaying their debts. But as we all know, risk and reward are inextricably linked and for those wishing to profit in this new world, addressing these issues is going to be the battlefield on which the fight for supremacy in the African retail credit space is won.

Are these challenges in line with your experience? We’d love to get your take in the comments below.

The post Insights from the African retail credit market appeared first on BSG (UK).

In our experience helping clients with compliance projects, we’ve noticed some fundamental aspects in which these regulatory change initiatives are different from other business-driven change initiatives. We thought we’d share 5 of the most distinctive differences, which you might have already considered in Eva’s struggle.

Drop dead dates

Deadlines are fixed and set externally.

In regulatory projects the deadline is fixed by the regulator and individual firms have little influence on implementation dates. There have been instances when the initial deadline has been so tight that no market participants could meet them. In these situations the regulators may be forced to re-consider, but this isn’t commonplace and generally organisations have far less room to manoeuvre timelines in regulatory projects than in business-driven projects.

Poorly-defined requirements

Requirements remain uncertain until late in the game.

The winds of a change in regulation are often felt well before the deadline. But unfortunately the devil lies in the details. After high level drafts, there are consultation periods and it can take years to produce the detailed technical standards. Meanwhile the implementation deadlines remain fixed. Firms can start projects to implement the changes, but until the final text of the regulation is produced the industry can only make assumptions about what the final guidance will state. This is contrary to an ordinary business project where the traceability of requirements is carefully managed and all changes go through an acceptance process before being applied.

Everything is “must-have”

There’s a fixed list of requirements to implement.

Regulatory requirements define a mandatory set of functions. Everything is must-have and this could be a serious hindrance in any project methodology.

But how does it affect the iron triangle of project management? We’ve already spoken about the time and features elements, which are fixed to some extent and this is different from the traditional methodologies.

Figure 2 The regulatory shift in the iron triangle

You might already be familiar with the waterfall and agile versions of the triangle. The regulatory one is probably a blend of the two as you can see from the third picture. The only factors you can really influence are cost and quality. Everyone would like to decrease the former while increasing the latter. But the elements move together, they are inter-dependent. Assuming that the planned solution is optimal, if you reduce the budget, some of the other elements will have to move down with it. Create a partial solution or run out of time and you’ll surely face huge fines. The only viable choice for reducing costs seems to be reducing quality. But whose choice is it?

Who is the business owner?

When no one wants to be.

By interpreting the legal text, Legal or Compliance becomes the “source” of requirements in regulatory projects. But, not every organisation is prepared for that when it comes to project governance. After identifying the affected systems and processes, the impacted department becomes the official owner of the project. But are they truly engaged in this mediator role?

If you think about how regulatory changes usually take the resources from business initiatives, it must be hard for the owners of those shelved business projects to wholeheartedly support the unexpected guests. But these projects desperately need the engagement of business, because compliance can only advise of the final state, but not how to get there. That capability lies in the hands of the business users.

Now how does this affect our project planning triangle? Resources are scarce; the cost has to be minimized. This seems to be reasonable for a project which does not bring direct benefits for the organisation or the investor.

The argument is questionable on two fronts. When we speak about direct benefits, have we considered the fines which we don’t have to pay if the project is successful? This might not be a strategic benefit and as a best result we just maintain the status quo. But avoiding costs is as important as reducing them, not to speak about the reduced risk brought by the regulation. On the other side, with respect to minimising costs, which costs are we talking about? The immediate costs of executing a project until the deadline or the total cost of the change, which potentially includes years of manual work instead of automation? Additionally, what about the costs associated with the maintenance and operation of new systems as well as future changes? And the list continues with the financial consequences of being shut down by the regulators.

If we blindly minimize immediate costs, we’re risking the reduced quality of the solution which will increase costs in the long run.

Quality is the fourth perspective from which the legislation usually doesn’t define how the change should be implemented. Should you use automation or manual processes, develop an in-house solution or integrate a boxed product? There are lots of decisions about quality which can be and must be made carefully in a regulatory project.

Everyone is equally affected 

You might be fooled into thinking that the same regulation affects everyone in the marketplace equally. But are all participants equally impacted? In our experience the depth of the effect on resources and the business can be vastly different. An organisation which has its compliance eye on its processes may be better prepared and can therefore focus more on advantageous projects. Therefore it’s important to watch the regulatory horizon with eyes wide open and to be willing to adopt a culture which supports proactive thinking about the possibilities. Meeting the regulatory requirements should be the consequence, not the driver of a thorough organisational risk culture. Look behind the tickboxes.

The post Regulatory projects are commonplace, but should we give them special treatment? appeared first on BSG (UK).

21^st century London. Seagulls fly around the Shard, light drizzle dampens the pavement and the Waterloo and City line still resembles a tin of sardines more than a tube.

Eva, is a business unit leader at the retail arm of First Compliant Bank (FCB). Her team uses an internal system for tracking customer interactions in the loan collection and recovery process. The software is a bit slow and tedious to use. Eva is eager to change it to more recent technology, so she initiated a project at the last budget planning meeting. The preparation should start next month and Eva is excited because she’s imagining a much better service. The upgrade, if successful, will enable the team to follow customer interactions more easily and the new electronic reports will please management as it will eliminate the need for manual calculations and lots of paper. Relieving pain by improving efficiency and decision making and becoming green at the same time – it would be a shame to miss this.

Black clouds are gathering on the banking skyline

Have you ever heard of the Central Regulatory Authority? Not yet? Don’t worry, it’s fictional anyway. But imagine that it’s responsible for the regulation and enforcement in our fictional financial sector. These guys are serious; when they say something, it has to be that way. And now they say that the way banks handle the regulatory reporting of retail loans must be changed.

Unfortunately the reporting system in FCB also belongs to Eva’s department and it was developed by the same team as the collections and recovery system. This change clearly interferes with any plans she had. Neither the team members nor the department’s budget can sustain two such projects simultaneously. Not even her McDonald’s smile training during high school summers can help Eva to hide her disappointment. More so that she knows this project is going to give neither her team, nor FCB any advantages over their competitors.

As soon as the first draft of the new regulation came out, Group Legal and the Compliance Officer started identify the effects on FCB. By the time Eva had sight of it, they’ve already submitted the high level plans to the project governance committee. The deadline is fixed in about 8 months from today. This binds the bank legally, whereas her improvement project can be delayed; so you can imagine the committee’s decision. The bank is going to start a project to respond to the new legislation as soon as possible. What about the system refresh? Well, that might fit in next year’s budget.

Who’s going to deliver this?

Tim is the only project manager available from the pool. He’s got 8 years of experience in delivery, including 3 years in agile methodologies. The team can start the preparation this month; the problem is that the source of the requirements is only a draft regulation under consultation and so many details might change over the coming months. It is likely that the requirements will be fixed just before the deadline. This is not new to Tim, but in this case it can’t delay the deadline or reduce the scope. The scope is another painful point because every feature derived from it is a must-have requirement. This defines the so-called “minimum viable product” for the project. Tim’s concern is that this could change significantly before the deadline.

 Figure 1 The time – cost – quality triangle of the new project

So the minimal scope and the deadline are fixed, and Eva probably wants to minimize the costs, so that she can hopefully spare some budget for the other project to commence. With both scope and time fixed, a decreased budget will surely have a negative impact on quality.

What can they do to save the situation?

One possibility is for Eva to fight against this project. This would make Tim’s work harder, probably resulting in a low quality solution only finalised after the mandatory deadline. It will probably leave a fair amount of work to be done manually and lots of changes to be developed later. But is there another possible future?

Theoretically there are an infinite number of other possibilities. One of them is that Eva pushes through her project, which in turn frees some of the team members by increasing efficiency. They can create the required new reports manually. Even this option might be feasible if the automation involves high costs.

Another possibility is that Eva and Tim, together with Group Compliance, identify the required functions and the possible changes which could come from the regulator before the deadline. The business team, when familiar with the problem, should be able to prioritize the functions. Consider what would be the easiest to do manually in the short-term if the software was not ready to perform at the deadline. The IT team can implement a model based solution which can later be configured according to the changes. That reduces the running cost and can save some work for Eva’s team to focus on other duties. But with limited resources it is unlikely that the team will be able to address many of Eva’s original concerns in the scope of the new project.

Can you imagine other solutions? Have you ever been in a similar situation? What did you do? Tell us in the comments.

The post Regulatory changes, not for the faint of heart appeared first on BSG (UK).

The post Tackling the fallacy of agile appeared first on BSG (UK).

The post Getting ready for regulatory changes in the payday loans industry appeared first on BSG (UK).

The post Stop guessing! appeared first on BSG (UK).

BSG (UK) Business Analysts recently attended the Business Analysis Conference Europe 2013. Shortly after the conference, the BSG delegates collectively identified a number of trends which cropped up across the conference topics.

BAs and leadership

There were a number of talks focused on the BAs role in organisational leadership and / or how leadership skills can improve the capability of BAs to influence change. Naturally, these positions go hand-in-hand because they, in effect, a virtuous cycle.

Although – BAs and project practitioners – we’ve instinctively known this for some time, we take the view that this is really a brave step for business analysis as a profession. We’re collectively standing up and saying (1) we have a broad contribution to change in the enterprise supported by (2) a skillset influenced by, and in turn influencing, leadership within our organisations.

Which is a great segue to …

BAs need not be stuck in a traditional “requirements jockey” box

The BA discipline continues to equip BAs with a wide range of multi-disciplinary skills that can be applied across the entire change delivery cycle. As BAs continue to deliver meaningful change, our credibility as change agents becomes well established and so the opportunity for involvement becomes broader and more impactful.

BAs should be very comfortable taking up these new challenges in shaping of strategic initiatives and getting involved through to delivery. This may involve moving beyond the traditional BA role of bridging the gap between business and IT and playing more of a challenger of status quo and advisory role in delivering high impact strategic outcomes.

To illustrate this point, it was argued that perhaps the BA role (as it is typically imagined) is an anachronism and we should be looking to create a more meaningful, broadly impactful role that draws on our BA skills. The BA is dead. Long live the BA.

This is supported by a worldview which says …

BAs can should be on the forefront of innovation

There is a traditional perception that innovation is conceived and developed in some laboratory or that it involves assembling a number of creative people into a room and being left to generate new awesome ideas. Thankfully, this world view is changing.

Innovation is not necessarily about the next Facebook, Square or well known, publically facing website. Innovation is a mindset: a discipline of changing the way something is currently done in a way that brings about competitive advantage or drives impactful change.

BAs should be playing pivotal roles in driving impactful change in organisations; either through introducing ways of doing things quicker and cheaper, or identifying better ways of exploring existing solutions to make them less complicated and more targeted at real customer problems and needs.

BAs need to shape a role / voice that is positioned to play a bigger part in the entire innovation ecosystem as we can be involved from idea generation through to solution delivery and embedding the change.

Which requires us to be mindful of …

Solving the real problem or any old problem?

It would be very interesting to see how many projects still fail because a solution has been designed for the wrong problem. If we had a penny for every time our business stakeholders propose “solutions” to “problem(s)” that haven’t been identified or clearly defined, we wouldn’t need to raise an expense form for next year’s conference.

We also recognise that it is very easy for BAs to be blinded by attractive and elegant solutions. Of more concern, there are times when BAs somehow limit their own perceptions of their role in revisiting a problem statement (especially when they get involved at a slightly later stage on a project).

The conference advocated for a world where during the initial stages of any project some time is set aside to put together a problem definition mechanism: something which (1) clearly articulates the real essence of the problem(s) (i.e. the “WHY”) that a project is planning to solve and (2) also manages any changes as a result of the evolving business conditions.

The ability of BAs to discern and callout such moments where there is a need to take a step back to understand the essence of a problem can prove to be crucial in the success of projects. At times, it might call for recommending that a project is halted – this might not be the most popular recommendation, but, if it is the right choice for the organisation, this will definitely raise the credibility of the BA role.

Once we know what we’re solving, we need to be sure we choose a smart way to solve it …

The BA skillset is as important in the agile world as it was in the waterfall world

As agile becomes increasingly pervasive, there has been a lot of questioning about the role of a BA in delivery. There is no doubt that (where context is suitable) agile practices have come to stay, but it is very important that BAs understand how transferable and applicable their acquired skills are in this space.

The key message for BAs is that their roles within an agile team should be very much about scaling their existing toolset to meet the rather flexible and adaptive-learning approach. The business and / or the customer still need a voice in the design of the solution and the delivery of the change. BAs need to focus on applying their skills to extract key business benefit drivers and ensure that the changes with the highest impact are rollout out first to maximise value creation.

For most of the agile related presentations shared during the conference, the key theme was that the BA role is still very relevant in the agile team structure.

To reference the conference material, please visit http://www.irmuk.co.uk/ba2013/

We published a similar reflections paper last year – BSG (UK)’s reflections on the BA Conference Europe 2012.

The post BSG (UK) reflections on the IRM Business Analysis Conference Europe 2013 appeared first on BSG (UK).

Talk to the customer

Our world is shifting and decisions are no longer made behind closed doors between Business and IT. At least they shouldn’t be. Customers are increasingly using online channels and leaving their footsteps in the front-end systems of every organisation. If IT people can observe these steps they’ll get a better understanding of the customers.

Profiles, personas and behavioural pattern data is growing, ready for analysis. If we ask the right questions, we can validate customer need for almost every improvement. Moreover, customers demand the online presence of the companies who should take advantage of this. Social channels create context for cheap two-way communication and you can easily hear the voice of the customer directly.

BAs are well positioned to champion these. Let go of the traditional gap between Business and IT and open the bridge to the customer. Emerging methods, like User Experience Design and the influence of lean startup principles, provide direction on how to do that. With the new insights gained, BAs will have more opportunity to influence strategy as well and guide the organisation on a customer facing journey.

BAs and agile delivery

Agile: a word shaking the world within IT circles. As a “new” philosophy which has been here for more than a decade, it still causes controversy. While some praise it and others fear it, the agile way of working is leaving an indelible mark on the software industry. Recently it has a huge influence on the business side too. We hear corporate sponsors asking their projects to be agile, because it’s “better by definition” (a turn of phrase which, itself, demonstrates a lack of understanding).

Although the agile methodologies were created to be more adaptive, a poorly designed agile project will underperform a well-managed waterfall type delivery. Projects are delivered in context and agile is a way of configuring resources to meet the business need. The agile approach calls for greater collaboration between between business and IT, and, we would argue that the voice of the customer needs to be directly represented as part of business.

So, do BAs have a role in the agile world at all? Surely business folk can simply meet with developers and spitball requirements? Thankfully (for us BAs), it’s not that simple. Projects still need to be shaped, benefits cases created, requirements sought from wide stakeholder groups (including the customer) and documentation created (to an appropriate level of detail).

BAs need to step up from being merely authors of requirements to being agents of change. As the agile methodologies require much more trust and collaboration, BAs could and should be the glue which holds the whole system together. But because every environment is different, BAs have to fully understand their responsibilities to be able to bring value for the organisation.

On the edge of business analysis

In this profession we can’t simply restrict ourselves to a thin slice of the business we work for. We are responsible for understanding the operation of the whole mechanism, time to put our systems thinking hat on. The conference included some topics that, on the surface, wouldn’t typically be considered in the BA’s area of responsibility however, as they were discussed further, the links became clearer.

One such topic is reputational risk management. Customers are increasingly using online channels for communication and expect their beloved brand to use them too. The most important aspect of reputational risk is how your actions appear in the eyes of the clients and this is central to how you communicate with them. Customers ideally expect you to be online when they are, or, as second best, at least manage their expectations about your online availability. These expectations need to be built into the enterprise’s process as central to their customer relationships.

Notes

David Reinhardt, a BSG (UK) principal consultant, delivered a presentation titled “Did BAs become irrelevant when business learned to code?”. The talk focuses on the evolving role of the BA in response to a narrowing business-IT gap (including the “introduction” of the customer into this gap). The presentation material can be found here.

BSG has previously published a paper on the role of BAs on agile delivery teams. Read it here.

The post BSG (UK) reflections on the UNICOM Business Analysis Conference 2013 appeared first on BSG (UK).