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).

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).

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).