Those of us involved in evaluating the General Data Protection Regulation (aka GDPR) and advising on how to implement it for different scenarios are well aware of the distinction between “Personal Data” and “Special Category” data and we know that our Clients need to pay special attention to “Special Category” data. However, I have been thinking more and more about scenarios where I might consider recommending Clients treat routine “Personal Data” as if it was “Special Category” data.
Read on for an example to illustrate the point, although there are more examples (and I expect there are many that I haven’t thought of). Dissenting and assenting opinions are welcome so feel free to chime in with your views.
The number of Blog posts, articles and discussions that ask or attempt to explain “How to be a BA” is a good indication that nobody really knows the ‘silver bullet’ answer. If you think you’ll find the perfect answer here…. don’t waste any more time reading on: I don’t have a ‘one size fits all’ answer either!
This is not because nobody actually knows what a Business Analyst is or does (although there are many Recruiters and Hiring Managers who obviously don’t!). It is perhaps because there are so many different types of BA, who do different things, in different roles, for different Projects and in different Organisations.
What makes an MVP an MVP…? Do you prioritize the ‘M’, the ‘V’ or the ‘P’…? Who should be the final judge of what an acceptable MVP looks like?
These might seem like strange questions but, like most things a Business Analyst has to consider, each is a simple question behind which lies a very complicated and very, very important relationship between all Stakeholders on a given Project.
For the record, and to prevent Sports fans having to read any further, MVP in this context stands for Minimum Viable Product, rather than Most Valuable Player!
NB: additional paragraph below marked with * added as a result of feedback.
So, which is more important in a software product development environment: Minimum, Viable or Product…?
The Agile Manifesto is 15 years old now. That’s 15 years… No matter how you look at it, 15 years is a hell of a long time, especially in technology. A lot has happened over the last 15 years in the world of Software, Technology, Information Systems and the Disciplines that support (or supported) these areas.
In February, 2001 (when the Agile Manifesto was published), Google was barely a baby, Windows XP was the new OS kid on the block, Industry had just been through the Y2K hype (look it up), the Dot.Com crash had just happened (look that up, too!), MySpace – the first real, modern, Social Network) was barely an idea, FaceBook and BeBo (don’t bother looking that up) were far in the distant future, as was YouTube and Skype. Twitter, Instagram, SnapChat, Pinterest and WhatsApp were so far into the future of mankind’s imagination that they might as well have been time travel, nanobots or cheap 3D Printing.
It doesn’t matter what your view on the Agile Manifesto actually is and it doesn’t matter whether you think Agile is the solution to all our IT and Software Dev problems (which it isn’t), Agile is – by technology standards – very, very ancient.
Last year, I flew to NYC on business over the 4th July weekend. I rented a car from Dollar (@DollarCars / http://www.dollar.com) well in advance. Literally from the moment of arrival, it was a very frustrating experience, including
a long, long wait for a vehicle (couple of hours, with about 15 people waiting ahead of me when I arrived and no available vehicles);
a demand by the Dollar counter staff to prepay for a full tank of fuel, even though I had Originally made the booking with an agreement to return the vehicle full of fuel;
a vehicle – eventually provided – that was not quite as clean inside as it might have been (probably because of the quick turnaround required);
You know the horror of having to change your password for your email address or some other login…? It is a nightmare to come up with a new password that you’ll remember and that will be strong enough to resist all of the hundreds (thousands?) of different hacks, exploits and attacks happening seemingly every week… So, when you painstakingly choose a new password, it’s only natural that you’ll use the same password (or a minor variant of it) when you later have to reset some other password.
Increasingly, workplace systems that require passwords are set up to force-reset passwords every 30 or 45 days (or whatever). This, of course, means you have to reinvent your password – and it has to be easy to remember yet hard to ‘break’ – every month or two.
Naturally, you don’t write down your passwords. That would be stupid. Instead, you save them in a note or an email, on your phone or on your PC or laptop, maybe synchronised to some public cloud storage provider… After all, who could know that your file call ‘blah.doc‘ contains potentially useful information, and how would they even know where to look…?
As a Business Analyst, Technology Consultant or in any role where you need to identify suitable Applications, when trying to find a Solution or Product to meet your Requirements, particularly a Customised Off-The-Shelf (COTS) Product, you will no doubt come across blog posts, updates and group comments purporting to give you access to a ‘white paper’, ‘product review’ or ‘industry overview’…
These often turn out, frustratingly, to be nothing but a mechanism for gathering email addresses for the Sales & Marketing departments of various Vendors.
What’s worse is when you’re trickled into giving your contact details to gain some insight, only to discover all you’ve got access to is a product brochure.
One of the most common things I have to do on software development or Application selection projects, at one point or another, is to define a series of potential features or functions. They can range from obvious and nearly mandatory (e.g. ‘reset password’) to the more ‘out there’ features. Often, trying to get stakeholders to contribute to the production of these feature sets (note: they are not requirements yet!) is a pain in the proverbial backside. Everyone is too busy to tell you what they want their shiny new toy to do – although they’ll be quick enough to tell you if you get it wrong!
So, over many years & many projects, I have developed (and continue to develop) a quick and easy process to get the obvious features into a list early in the engagement _ but in a way that cries out for stakeholders to get stuck in and evolve it. Feel free to adapt it to your needs – you can use it to impress stakeholders with your speed of delivery!
I’m often asked to recommend simple tools for aspiring BAs to use and I can’t think of anything more simple – or more useful – than pen & paper or, where available, a whiteboard.
For those of you who like to work with pen & paper or with whiteboard & marker, here’s a simple tip: Get a sheet of A4 paper & laminate it. Then get some fine-tip whiteboard markers. You now have a portablewhiteboard.
Make an A3 version too, if you wish. Don’t roll them up, though… it’s a nightmare to unroll them when needed. If you want something a bit more robust, laminate a piece of white card instead of paper. Read More »
Although it’s now been quite a while since I was involved in Corporate SEPA migration and SEPA has now bedded in for most Organizations, I still occasionally get involved in discussions about specific issues that don’t seem to be as clear cut as others, more-so now that there is another SEPA deadline looming. These deadlines focus the mind and this is when – during implementation rather than theoretical analysis – outlier issues tend to arise.
One such ‘outlier’ is the issue of what happens when a Creditor collects a SEPA DD from a Debtor who is in a non-Eurozone country (or who has a bank account that is in another currency) and where the Debtor initiates a refund 12 months after the original Transaction. Logically, and according to the SEPA rules, it won’t matter. The Creditor simply refunds the Euro amount, regardless of what the customer’s “home” currency is.