For the sake of this post, I’ll define confidentiality as “concerns regarding the unwanted disclosure of information.”

Confidentiality is complex as it is both role-driven and time-driven, i.e. sensitive data may only be applicable to me in my current role and for a specific timeframe after which it may become stale and elicit invalid results.

Without deploying additional layers (e.g. using the file system layer to assign access via login to specific roles) neither angle is covered by Excel (or any Office-style application). Access is blanket applied – you are in or out of the loop. Hidden sheets help, but security by obscurity is never a great design choice and is not sustainable. And let’s not get started on the concept of using a tool designed for collaboration with others as a store of sensitive and/or confidential information – it is certainly paradoxical!

All of the above really depends on the inherent “value” of the data (or asset) you are trying to secure, if it is public information then, by all means, use Excel. For example, the Guardian makes chart data available via Excel for further analysis. Sensitive financial or people data is another matter. It is crucial to apply a set of reasonable countermeasures to data and systems based on the valuation of the asset from each perspective of the CIADA model.

Assessing the alternatives available to maintain data confidentiality may be simple. If the alternatives are very obscure, very expensive or a change management bridge too far then go back to your valuation of the asset. You may be inflating the valuation based on an incorrect view from the relevant stakeholders. Or maybe rudimentary controls are appropriate as countermeasures.

My rallying cry is simple. Excel is fine, in context. Be sure to complete the valuation of the information asset as well assessment and deployment of appropriate countermeasures over the blind use of a collaboration tool.

The post Spreadsheets in the enterprise, considering confidentiality (pt 1/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).

Challenges are just opportunities to think differently

Offshoring has its horror stories. Many of them resulting from putting the desire to drive cost down ahead of the desire to deliver against business benefit. Throwing specs “over the fence” may be cheap, but there is often significant business upheaval in the wake of a poorly built software system. The cost of correction (in the software) and disruption (in the business) is often significantly greater than would’ve been incurred had a smarter approach to working as a team been pursued from the outset. Effective collaboration within distributed development teams is thus becoming increasingly important.

We recently conducted a lessons learned exercise on a project in which we built a reporting tool for a London based insurance market corporation. The team was split across London (business design) and Cape Town (software development). The system, which has approximately 100 users, extracts, collates and submits data from multiple sources to a regulatory authority. Inspired by the lessons learned exercise, and building on our collective experience across a number of distributed projects, we want to share our reflections which all sit in the realm of collaboration.

Teamwork begins best in person

It would be naive to ignore that the best way to cultivate effective working relationships is face-to-face. Ideally, the delivery team should meet in person at the outset. Sometimes it’s not possible for the business users to be involved in this. On this project, the business analysts, after having spent time understanding the business’ ambition, hopped a plane and spent some time with the development team with the aim of clarifying the requirements. I hear Cape Town in March is spectacular.

Collaborate on estimating and planning

No matter how experienced the Project Manager, there is no point in planning without the involvement of the team responsible for delivering the product. Expecting team members to take accountability for their delivery requires suspension of a degree of control in setting the estimates.

We found that delegating estimation at a task level to those responsible for task delivery helps to create ownership and accountability. It also creates a feedback loop: plan the work, do the work, reflect on the plan and improve planning capability. The best estimates are sense-checked by peers to ensure that the team are not setting themselves up for failure.

Share the plan

It almost goes without saying that once the plan has been compiled, it should be shared with the entire team. We recommend that this take place in a forum where people are encouraged to raise concerns such that they can be understood, addressed and either dealt with up front or influence the subsequent planning. This will ensure that the team is committed to achieving the objectives of the project.

Adjust working hours

So as it turns out, offices on either sides of the planet often exist in different time zones. Go figure. A simple way of resolving this is to align working hours across the team in a reasonable fashion (i.e. create a set of core hours when everyone on the team is working). That way when Sarah identifies a bug during system testing at 15h00 in London, John can be reasonably expected to respond, even though his local time in Bangalore is 20h30. The key here is to set expectations across the team (including external stakeholders) upfront.

Stand up

Make sure the team keeps talking. One of the most effective ways to keep one’s finger on the pulse is to meet at the start or end of each day for 15 minutes. The purpose of this is to provide an overview of what was completed the previous day, what will be tackled the next day and to raise any burning issues which are holding team members back from progressing. It’s a well known practice across agile delivery methodologies and our experience reiterates its importance.

Talk more

Despite the natural gravitation towards email and/or instant messaging, we found that the best way to avoid ambiguity was to pick up the phone. A message sent is not necessarily a message understood, but a message discussed is far more likely to be. Better yet, we used video conferencing to discuss product features and ensure that the development team understood exactly what was meant by each requirement. There is significant richness in real-time personal conversations.

Use the right tools

Finally it’s important to use the right tools which enhance a collaborative working environment. We’ve already touched on the use of video messaging (we used Google+ Hangouts) and instant messengers, but there are a plethora of online project management tools becoming available. These allow users to allocate tasks to individuals, ensuring there is transparency (i.e. everybody knows what has been assigned to whom) and task ownership (i.e. the person to whom a task has been assigned is responsible for its completion). We’re currently experimenting with Asana, but different teams will find different tools are productive for their working practices.

These ideas and techniques allow the whole team to have early sight of any potential problems which can then be addressed proactively. The approaches also engender a culture of sharing where team members are encouraged to speak up sooner rather than later. The simple things are often the most constructive.

What practices have you found helped you to overcome the challenges of working in teams spread across distributed geographies? We’d love to hear from your comments.

The post Collaboration: The key to successful distributed development appeared first on BSG (UK).

At the outset of every engagement, we spend time architecting the project to ensure that there is alignment between the organisation’s strategy, the proposed deliverable of the project and the approach to be adopted. Over the years, we’ve seen many, uhm, less than optimal practices across the industry. We decided to write them up in a “cheat sheet” for project architects.

Project architecting for anti-progress

Make roles and responsibilities unclear. In fact, why even consider them at all? Just assign people to the project and hope that they will get on with it. This way, the real “diamonds in the rough” will get a chance to shine. It’s Darwinism, project style.

Make your documentation as long as possible. Long documents are proof that you’ve consulted widely and thought hard. Stakeholders really appreciate them because they get a chance to be sure that every single conceivable exception, no matter how unlikely, has been considered. They also look really impressive on the desk. Aim for at least 250 pages (excluding models, these should be in a separate appendix).

Ensure that there are dozens of people engaged in review cycles. Surely it is better to get insight from everybody in the organisation? And customers. Not to mention suppliers and regulators. If you research and review requirements with a massive stakeholder group then you’re sure to be able to deliver a fantastically thick requirements document.

Everyone needs to agree on everything before progressing any single decision. This is a project, not an autocratic government. It needs to be setup so that every decision is consensus driven across a wide stakeholder group. Especially the little decisions, those are most important. Documenting the never-ending email chains as decisions progress provides great content for your appendices.

Encourage teams to operate as functional silos during delivery. Talking to each other only slows things down and gives people the illusion of being involved. It’s much better to ensure that different parts of the project team are minutely focused on their own work at the expense of anything else. This will allow you to write documentation much more quickly.

Waterfall. Only. Forever. Thinking through different delivery approaches will only slow down the project. Why waste time planning how to do something when you could be having meetings and writing documents? Those new fangled approaches are only a fad anyway, everyone knows the space programme / banking platform / other important thing was built using a waterfall approach.

Keep it big. Breaking up the scope into small manageable chunks only demonstrates an inability to be a big picture thinker. Also, you never know whether you’ll get budget again so be sure to use it all in design and delivery. With all the analysis you’re doing, it’s almost certain that your design will be totally accurate.

Make change within the project complex. Don’t let stakeholders fool you with changes to business priority and process. The point of the waterfall approach is to draw a line in the sand. There’s no point in a line if you don’t police it. Make it exceptionally difficult to cross that line. This will demonstrate how serious you are about meeting the project ambitions and win you respect across your stakeholder community.

Paper, paper and more paper. Don’t be fooled by tools that allow either better management of requirements throughout the project or collaborative working environments. These too are a fad. There are many detailed spreadsheet templates that will allow you to track traceability across a complex design making for value-adding work on the project team. Paper will never go out of fashion.

Make workshops cover as much ground as possible. Your stakeholders are busy. And they need some time to be available to review your thoroughly written documents. Be sure to make workshops cover every angle – the more you can cram into a single whiteboard session, the better. Don’t worry about focusing on the details, stakeholders often get this type of stuff confused anyway. It’s your job to address this as you write out an activity diagram, use case and associated notation for every single process.

Measuring benefits is like counting up your old Italian Lira. Benefits only begin accruing after the project is complete. By then, you should be focused on some other important project or change. You want to be a forward thinker, not stuck in the past.

Do you have any more rules to architect projects for anti-progress? Let us know in the comments.

The post Project architecting for anti-progress appeared first on BSG (UK).

The post Project reviews using De Bono’s 6 hats appeared first on BSG (UK).

In this episode, you will get to hear from a top-notch BA in UK, creating ‘Aha’ moments for his clients in every engagement. His passion for doing work that can goes beyond just being a ‘project’ can serve as a great example for us to learn from.He shares many insights and tips that can help practitioners understand that our profession is a social profession and that collaboration is at the heart of a project well done.

The post Help your stakeholders to get better ‘aha!’ moments – interview with David Reinhardt appeared first on BSG (UK).

• Three orders of business analysis: bridging the gap, introducing innovation and facilitating change
• Understand the notion of “Analyst” as a language with tools, techniques and constructs
• Appreciating dialects of “Analyst”
• Recognising the need to be unconsciously competent at speaking “analyst”

This presentation is about the mindset of analysis, it is not about specific methodologies or approaches. I will reflect on “speaking analyst” in the context of our experience as consultant practitioners at our clients.

Presented by BSG UK’s David Reinhardt at IRM UK’s Business Analysis Conference Europe 2012.

The post Learn to speak analyst appeared first on BSG (UK).

So there are 5 special senses, we all know that. There are more subtle ‘senses’ like a sense of fear amongst others. But what are the senses of a Business Analyst? Someone who makes letters and numbers in a spreadsheet into a successful system or change initiative. Someone who makes the impossible possible. Someone who tames the wilderness.

Here are some thoughts on the emergent senses of the evolving BA.

> Common sense
Several of my contemporaries, notably @ukadrianreed, have highlighted how common sense is a thing missing from many BA’s armoury at the moment. I fear that BA’s get carried away in seeking to please and getting the validation of that coveted ‘sign-off’ which so blinds us all to the reality and practicality of making commitments on speculative requirements. I wholeheartedly believe that this is a key sensory talent that BA’s need more than ever and it will ensure their survival out in the project wilderness. And it is an unforgiving wilderness at the moment in the change space!

> Sense of clarity
Engaging with people of all kinds is complicated. When developers say the only problem with their system is the user, the BA should take heed. Users are the source of our requirements, they will make all requirements high priority (or Must Have – if you are a Muscovite) and they will bamboozle you with complex rules, spreadsheet models and bizarre user interface needs. It takes a smart BA to sense ambiguity, dissonance and omission of requirements from the user community. Ever had scope creep? Users are wild creatures, unpredictable. Never smile at a crocodile; and never forget a senior user’s requirement to login “just like Facebook”

> Sense of proportion of things
As I noted earlier, users tend to get requirements trigger happy – and all requirements tend to be must have’s. I guess it’s natural, if I ask you what you want tomorrow, it is unlikely you will settle for less than you have today will you? This is where the relative priority of requirements or features is a much better method than absolute requirement prioritisation. It forces users to rank requirements. No two requirements are equal, the jungle has a natural order and so do requirements.

> Sense of connectedness
As a caveat to the relative prioritisation of requirements above, I believe it is incredibly important to note that sometimes – depending on how you have completed your requirements, some requirements may be inextricably linked to one another. It means that a simple ranking process helps, but has exceptions. But where would we be without the odd exception to the rule?

Further to this, but linked to the sense of clarity, it is important to realise connectedness in relation to dissonance and omission. Dissonance may occur (and often does) where requirements contradict each other and sadly, yet predictably, we never notice this in the sessions when the users are relaying their needs and neither do they! But sometimes, things are not connected on the surface. A keen and experienced BA will sense the dissonance; gurus may even do so in the middle of a workshop. Omission is to requirements as the platypus is to land mammals – an entirely unexpected cousin.

> Sense of perspective
As an agent of change, BAs realise that sometimes it is more important to know enough to move ahead, than to know everything right now. The BA profession is not a career stepping stone to being psychic; requirements change over time, they evolve. Much like any king of the jungle, projects and requirements are emergent and as much as we try to manage change – the state of flux is natural. From change control to Agile, all we are try to do is manage the inevitable. It is perhaps better to have a strong sense of perspective, what do we need to know to move ahead: does this validate or invalidate the perceived project benefits? Am I comfortable living on the edge of certainty and uncertainty?

> Sense of style
A business analyst should be creative, imaginative and innovative. Your delivery should have a sense of style that inspires others, wants them to engage with you, your work and be energised by engaging the change that the BA is representing in the project. There is nothing less engaging that boring workshops, black and white models and lots of text. In order to get ahead in the jungle, fauna and flora need to attract others to their wares. Like bright flowers for pollination, BA’s need to attract stakeholders and users to their artefacts to improve the probability of project success through engagement and buy-in.

Looking back on my starting question: I think yes. There are ‘senses’ to a BA. Furthermore, we might even have specialised sensory tools to receive the stimuli that drive those senses…

But for now, as BA’s evolve, the project wilderness is what it is. Happy evolving.

The post Are there senses of a BA? – Stuart Gomersall appeared first on BSG (UK).