ben.eficium is the blog of Ben Slack, citizen and principal consultant at Systems Xpert.
All posts are Copyright © Ben Slack on the date of publishing.


12 August 2014

Why I will no longer visit certain churches

My decision to not attend the christening of our nephew Fergal on the weekend has attracted some attention from friends and family. For anyone interested, this post attempts to spell out my reasoning.

For many years I have been uncomfortable attending ceremonies in churches where doctrine holds contraception sinful. I can honestly say I feel ashamed whenever I walk through the door.

The reason for my discomfort is that in the past three decades millions of children in Christian majority developing nations and other Christian communities have been born with HIV - the Philippines and Nigeria being notable examples. Many, perhaps most of the HIV positive parents had no education or access to contraceptives due to policies of churches and the state foreign policy they successfully influence.

The effect of HIV and AIDS in developing nations is catastrophic. Apart from the deplorable human misery, coping with with so many sick people weakens and destabilises governments, diverts untold resources from economic development, increases a state's reliance on charity and foreign aid and demoralises whole communities. If the active suppression of family planning activities and contraception methods and devices were brought to an end in these communities, the number of people contracting HIV and babies being born HIV-positive would rapidly decline.

I believe that by stepping inside a church you are implicitly stating your approval of the institution. I do not approve of the actions of the relevant churches and am boycotting ceremonies in any institution which does any one or more of the following:
  • actively preaches against contraception in developing nations;
  • provides "independent" (i.e. non-missionary) medical aid which does not include family planning and contraception;
  • lobbies developed world governments to discontinue provision of family planning and contraceptives in their national aid programs; or
  • accepts taxpayer funds to deliver aid programs which do not include family planning and contraception.
The Roman Catholic Church is the largest congregation that meets these requirements, but there are many others. I will apply the rule to all sects of all faiths equally. The philosopher Nassim Nicholas Taleb said that if you see a fraud and say nothing, then you are a fraud. I have said nothing for far too long.

I have asked myself how this boycott compares with others preaching their own religion or beliefs. Am I not as bad as Nicole's aunt, who not only declined the invitation to our civil wedding ceremony, but insulted our choice and my beliefs in writing and actively proselytized her own version of Catholicism?

I came to the conclusion that my decision is not in the same category. My aim is not to insult anyone, deride their faith or preach my version of agnosticism. My hope is simply that people who are interested in hearing my point of view will examine their own views on this topic. If they find my reasoning unconvincing or my morality faulty, then I will respect that. If they find my argument valid, then it is my hope that they might work within their church organisation and take reasonable steps to change attitudes and behavior.

I don't want to see the end of organised religion or religion itself. I don't want anyone to give up a faith that provides them with fulfillment. I don't want anyone to change their mind on any matter but church doctrine on contraception. The irony being surveys consistently find a majority of Catholics in Australia neither believe or practice church doctrine on contraception anyway.

08 August 2014

I never hire the university medalist

I've hired a lot of business analysts and developers over the years and one thing I've learned is the university medalist or academic high achiever is almost never the right person for the job. An aptitude for academic excellence primarily means that someone is very talented at completing university courses. The degree to which this talent indicates an excellent worker is not as clear as most people think.

Almost every time I have hired an academic high achiever (I'm talking distinction+ average marks), that person has proved disappointing and I think I know the reason why.

A lot of people who earn those marks do it through the kind of time consuming rote learning perseverance that is not desirable or sustainable in full-time employment. A lot of these kids were doing assignments on Friday and Saturday night after having studied for 55 hours during the week. Sure, sometimes corporate work requires these kinds of hours but everyone knows it is not sustainable week-in-week-out. Someone who required that kind of time to get those marks is not going to deliver the same quality in the time available for corporate work.

What you really want is the girl who cruised through the course with as little study as possible, read the textbook a couple of days before the exam and walked away with a credit to distinction average having put in about 20% of the work of the university medalist. That's the person who's going to deliver good consistent work in the kind of turn-around modern business requires. The kind of mind who will find the easiest way of achieving a goal. And they're not going to burn out after 2 or 3 years.

There is always the chance that a high achiever is an exceptionally talented "cruiser". So you have to develop the interview questions and testing that identify quick original thinking. But you should be doing this anyway. My advice - don't look at or ask for an academic transcript and don't assume a good student makes for a good worker.

21 July 2014

Uncertainty, randomness and risk

In the past few years I have taken a keen interest in the literature of uncertainty and randomness. James Gleick's classic Chaos sparked the interest 20 years ago but the work of philosopher and polymath Nassim Nicholas Taleb has re-kindled my curiosity in recent years. The popular books of mathematician Leonard Mlodinow, gambler and political forecaster Nate Silver and behavioral psychologist Philip Tetlock have also proved fascinating.

Once you start to understand uncertainty and randomness you begin to see its effects everywhere in every aspect of life. We each play a role in so many complex systems we are often blind to the effects of random chance. But it is constantly present.

The crux of what I've learned and how it relates to work life is that humans are terrible at predicting and anticipating how complex systems will behave in the future. This is a huge problem, given we constantly rely on predictions and expectations of what the future holds. It also means what I had long suspected, that our ability to evaluate and manage risk is fundamentally compromised.

The concept of risk management has a long history in many industries and professions. Even if it is not specifically identified and documented in risk management plans, we all spend time managing risk.

I've been involved in creating, maintaining and managing project risk for most of my career. I've had many opportunities to see others performing these tasks also. And my observation and reflection lead me to agree with the literary evidence. We are hopeless at it.  I'm not saying our efforts are totally in vain. However, when I consider the wildly inaccurate probabilities assigned to identified risks, the risks we missed that seem obvious in retrospect and the problems that weren't and couldn't be anticipated, I think we need to throw out current methods and start again.

Taleb offers a new way, one that seems simple at first but will be difficult to implement. Essentially, instead of concentrating on identifying, evaluating, anticipating and mitigating specific risks, we should concentrate our efforts on making business systems "antifragile". He divides the world into three simple categories, fragile, robust and antifragile.

Fragile systems are those that are vulnerable to widely unanticipated events. The vulnerability of Wall Street to bundled mortgage securities erroneously rated AAA is an important example.

Then there are robust systems which successfully mitigate identifiable risk and are robust or resilient to shocks, but are still vulnerable to Taleb's "black swan" events. Those are events entirely unexpected due to confidence in the continuation of patterns and behavior that have always proved true in the past. His example is the Christmas turkey. The farmer houses and feeds the turkey from its birth. They turkey thinks, "This is great, everything is provided for me for no work. I'm on easy street."

The turkey relies on its expectation that every day will be like the one before. The day the butcher arrives is the turkey's black swan. Nothing in its previous life had prepared it for this possibility.

Antifragile systems are designed to benefit from unlikely, uncertain or unpredictable "black swan" events. An example is his investment portfolio strategy where he holds options that mitigate the effects of economic crises. These options are undervalued by the market due to those factors that cause humans to massively over or underestimate risk. Holding the options does not greatly effect the normal returns of the orthodox investments. However, if a disaster occurs, the portfolio actually benefits from uncertainty. Returns are larger.

Taleb identifies real-world examples of "optionality", actions that strengthen systems in an analogous way to his use of financial derivative options. Over the coming months it is my intention to identify some of the ways we can apply this thinking to business projects and systems.

08 July 2014

Plain English please (First part of many)


Using buzz-words appropriated from other domains incorrectly is about the worst thing that a manager or public figure can do. This is guaranteed to make smart people think you are stupid. Two examples I often hear are the word “quantum” and the phrase “sovereign risk”.
“Quantum” does not mean “total”. It is the plural of “quanta”, meaning the most basic unit a thing consists of. Outside physics, it most common use is in law, applied to compensation amounts derived from the application of several different legal axioms. In context, the word's subject is some or all of the multiple amounts, not their total amount. This is an important distinction.
When a CEO stands up at an AGM and starts their address with, “We confidently forecast the quantum of revenue next year will be 20% higher than this year”, without any context of the units that make up the revenue, that man or woman is using a big word to try and impress people. And failing dismally.
“Sovereign risk” is appropriated from the finance industry where it means the probability of a state defaulting on interest payments on its treasury bonds. The phrase entered common parlance in the 2011 European debt crisis where Greece and a few other nations came close to default. How many Australian pundits, politicians and executives now use the phrase to mean any uncertainty in proposed government action or to simply criticise a policy they don't like? I've heard lots of 'em on ABC's “The Business” alone. And either consciously or unconsciously the purpose is to allude to the chaos in the streets of Athens we all witnessed on TV.
How does this sound to people where this phrase still has its specific finance domain meaning? I think its likely to lower confidence in Australian economic stability. That can't be a good thing.
When you use technical words incorrectly and appropriate phrases out of context, you can do a lot of damage to your own reputation and produce all sorts of unintended and unpredictable effects. And smart people will think you're an idiot.

20 June 2014

Can you hire a "change agent"?

A lot of people seem to think you can. There are always ads on SEEK for an experienced "change agent". Often they are for 3-6 month contracts.

I know it's nearly a decade since I took the "Managing Change" elective in my MBA study, but introducing new work systems hasn't changed that much. All the literature at that time, which was around the beginning of the movement, made absolutely clear that a "change agent" is someone who has been in the orgainsation a long time, has the respect and admiration of colleagues and the political clout to influence and coerce decision makers. If you think a new contractor who'll be there for 6 months can do that, then you are out of your tiny mind.

You can hire a change manager. A change agent needs to be found inside the organisation.

18 June 2014

Abstract your requirements up-front (Part 2)


Due to a host of reasons including politics, budget, time or project owners' lack of experience, creating an abstract Use Case Survey (or other expression of abstract requirements) as a first step may not be possible

Every requirements analyst has been in a situation where before or during a meeting a stakeholder gives you, in the example of software, a detailed user journey and even screen mock-ups of how they want the software to work. They think they've done the work for you. An abstracted view of the requirements and use case development is not required. I say this is fine and useful in situations where the following conditions are met.

  1. The stakeholder owns the use case or is the authorised proxy of the owner.
  2. The use case is relatively atomic.
  3. The work provided is obviously correct or mostly correct. (If it's only mostly correct, you need to weight the cost/benefit of the battle to improve it.)
  4. The inputs and outputs are controlled by the owner or the owner has the authority to speak for those who supply the inputs and rely on the outputs.
  5. At the time you cannot identify any duplicated effort in producing the requirements.
  6. Delivering the product is cost-effective.

I'd encourage you to make these points a checklist and mark against it when the situation arises.

Mostly these conditions are not met. You are presented with the “customer is always right” problem. Many experts say you need to follow the dictum to the letter. I've heard an academic say (to paraphrase), “Deliver the request, regardless of the consequences”. This doesn't work in the real world.

The needs of the project stakeholders are your primary concern. However, remember you are a professional. This stakeholder wouldn't give detailed instructions to a lawyer on submitting a statement of claim or instruct their accountant on the method of depreciation to use.

Business analysts may not have a state sanctioned professional organisation like the Bar or Institute of Chartered Accountants; however, you still have similar ethical obligations to your project stakeholders. If you receive a request which is unrealistic, inefficient, impossible or just plain stupid, you have a professional obligation to inform the stakeholders of this fact and recommend an alternative course of action (in writing if at all possible). Otherwise you are not a business analyst, you are a clerk.

In my opinion you are also under an ethical obligation to explain why the first step of system creation needs to be producing abstract requirements, use cases or any other method you prefer. Doing this in writing is important, if only to cover your own arse.

There will always be people who will ignore your advice, cut you off during an explanation, treat you like a clerk and demand the project be performed in a wrongheaded manner. If these are your clear instructions after performing your ethical duties to your best effort, then go ahead and do what's requested. When it all goes pear-shaped, don't be afraid to say “I told you so”.

10 June 2014

Abstract your requirements up-front (Part 1)


In my experience the best systems are created with methodologies that include the “use case”. In the Unified Processes, the central tenet of the use case method is recording an abstract description of the use case scenarios. In one pithy aphorism this means:
“A Use Case scenario must describe the interaction between a user and a system in terms of inputs and outputs only.”
There must be no detail of the exact physical actions required to enter inputs and receive outputs. In a software project, no descriptions of GUI elements; clicking on buttons, typing in text boxes, no dialog windows appearing, etc. In a purely human process, nothing as detailed as “wrap a product in bubble-wrap”, “give a PowerPoint presentation”, etc.
How many use cases have you seen that steps out scenarios that concentrate on physical actions? E.g.
  1. The User opens the “Hello World” program from the Start Menu.
  2. The System displays the introduction screen with a menu listing “X”, “Y” and “Z”.
These are not abstracted requirements. This is a written GUI design, which is pretty redundant, you may as well just do the screen mock-ups or workflows in Visio. A better use case example would be:
  1. The User initiates interaction with the System from an entry point.
  2. The System provides the User with options to continue with this Use Case (go to step 3) or perform other Use Cases (initiate new Use Case).
The point of this abstraction? Who's to say up-front that presenting a menu is the best way to do things? You haven't yet thought about: how this affects other related use cases; if it's consistent with presenting options in the other use cases; whether users will find this approach intuitive; if it's appropriate for every class of user, etc. The problems are multiplied in a large project with a team of analysts producing the Use Case Survey.
Producing an abstracted Use Case Survey for a project iteration allows designers to:
  • better avoid duplicated effort by identifying common aspects of system parts;
  • up-front identify the high-level duties of required actors, allowing managers to earlier prepare personnel (and unions) for changes in roles, responsibilities and job descriptions; and
  • most importantly, forces concentration on the purpose of the system as a whole; the “why and what” rather than the less important “how”.
The project as a whole will save time as producing workflow diagrams and screen mock-ups is more intensive work than writing a few simple use case documents. If you've planned better up-front, less tweaks and changes are going to be required for those graphical tools.
And these are just the benefits I can think of in the time it takes to write a blog post. Abstracting requirements up-front is well worthwhile. Do it every time you can.