All Models are wrong, but some are useful. (George Box) …and some are measurably better than others. (Douglas Hubbard). Such is the premise of the book How to Measure Anything in Cybersecurity Risk, in which Douglas Hubbard and Richard Seiersen take a critical look at conventional methods of assessing Cybersecurity risk, and offer an alternative. A continuation of Hubbard’s series on business statistics and quantitative decision analysis, this book dives deep into the problem of how to inform business decisions in complex situations when data is scarce. While business statistics may not be everyone’s favourite topic, it is a remarkably engaging overview, and it can equally serve as a desk reference for anyone whose work involves helping organizations make informed[…]
Category: Business Analysis
A useful, but often overlooked Excel feature is the Analysis ToolPak. It’s useful because it packages about 20 commonly used statistical functions in a format that is very easy to use. It gets overlooked because it has to be activated through the Excel Options dialog before it even becomes visible. If the Analysis ToolPak is new to you you will find it in the Data segment of the Excel Tool Ribbon. If you already use it and you are In the process of extending your analysis repertoire to include R, you may just be looking for a guide that shows how to do ToolPak tasks in R. Either way, this post fills a gap with a quick mapping from Excel to[…]
Excel is such a handy tool for data discovery and analysis that it’s fair to ask, “Why bother with anything else, especially an arcane scripting environment like R?” The truth is that the transition from Excel to R is very much a green eggs and ham experience: decidedly unappealing at the outset, even for adventurous folk, but rewarding in the long run. This post takes another look at the Titanic data set, this time using R to do the same analysis done last time in Excel. As before, the starting point is making readable text from the raw, coded data shown above on the left. R provides a simple substitution function that simply specifies the filter conditions for the variable[…]
The client wanted 30 minutes. More precisely, they needed to eliminate a 30-minute delay between completing a finished product test in a manufacturing quality control lab and communicating the result back to the operators on the production line. By making data more available to inform decisions about process equipment settings, simply automating that reporting step led to lower scrap rates and higher throughput – a win for everyone. Another client, also a manufacturer, needed to optimize finished goods inventory and production scheduling for a line of consumer electrical products that had 20 or so discrete models. A statistical model used a rolling 3 years of order data in order to predict optimum monthly production volumes for each product. Reviewing the model[…]
My last post was about why Use Cases should still be considered alive and well as an analysis technique in Agile projects. That begs the question: if people can dismiss Use Cases as old fashioned and a waste of time, is there any place left for traditional Requirements documents? I am not a fan of Big Requirements Up-Front. Fat requirements documents based on the premise that if you don’t ask, you don’t get, tend to accumulate very long feature lists. Crafted early in a project, they risk becoming disconnected from what the front line users will actually use. We try to mitigate this risk by prioritizing the features. But anyone who has been through the exercise of separating a few hundred features into[…]
A few weeks ago a discussion popped up on LinkedIn titled “Use Cases are old-fashioned and a waste of time and money“. Provocative, to be sure, the debate that followed (at last count 88 comments and building) was an entertaining romp through the personal biases of a number of experienced practitioners. There were two distinct camps. Arguing against use cases was a group that liked pictures better than words for displaying the sequence of events to fulfill a user goal. For them, taking the time to write use cases is an unnecessary formalism that is too slow to keep pace with the needs of an Agile team. On the other side was more reflective group who viewed use cases as just[…]
Life is messy. Those of us who work as business analysts see it in the myriad of ways in which people create, store and retrieve information in order to do their work. Called upon to help improve a situation, we often reach for help in the form of a methodology. The trouble with most system design methodologies is that they are made for giving structure to the process of building a solution, not for helping people living in a messy situation decide what would actually make things better. It is all too easy, particularly with larger projects, to get to design without fully understanding the context in which people will use the solution. What’s missing is an explicit way of[…]