In the blog entry on the Microsoft Government Solutions Forum 2010, I promised some additional content would be made available soon.  This will take the form of a Whitepaper entitled ‘Case Management Using Microsoft Technology - How Singularity Leverages SharePoint, Dynamics/CRM and other Microsoft Products for  Enterprise Case Management Excellence’ . A summary of the content is below. I would be delighted for anyone to visit the Singularity website, read the paper, and let us know your thoughts on the content.

Microsoft technologies provide powerful and valued support for much organizational work today (this paper discusses the relevant capabilities of current Microsoft technology versions, including SharePoint 2010 and Windows WorkflowvFoundation 2008). Yet complementary technology is required to meet the demanding requirements of case management work. Singularity delivers solutions which leverage the strengths of SharePoint, Dynamics CRM and other Microsoft technologies while complementing them with Singularity’s Business Process Management Suite (BPMS) to meet the key challenges of case management. The result is an Enterprise Case Management Platform built on Microsoft-based technologies which delivers on today’s challenges, allows cost effective adaptation to future needs as they arise, and reduces TCO.

 Download the whitepaper at http://www.singularity.co.uk/case-management-using-microsoft-technology.lit 

Author: Manus Savage, Singularity 

‘What about?’. Two little words that can spell the death knell for a project at any time down the line. No-one noticed the possibility of that circumstance occuring until it was to late. Now the blame starts and the expensive rework in terms of time, money, patience and re-thinking.

But it could be so different if you listen out for those two little words right up front. As BA, don’t just rely on the senior management to tell you what the current process is. Talk to the people on the ground, the people that work with the customers, with the process day and daily. They know the ‘quirks’. They know the ‘what abouts’.

There’s probably 1,001 ‘what abouts’ that have cropped up in the past and not everyone knows about them, so listen out for them. It may be that they’re unknown common practice and result in the process being more tricky and expensive to automate. They may even make automation impossible.

It may be that the ‘what about’ is something that you may chose not to do any more in the interest of simplicity, like dropping those installment plans, but that decision needs communicated to customers to ensure a smooth transition. At least you can plan now without it tripping you up further down the line.

And all from listening out for two words. What about it?

Author: Paul Gordon, Singularity

Last week I presented the Singularity ‘Case Management for the Microsoft Enterprise’ to an audience of clients and partners in London. The feedback was very positive, with broad agreement that providing a Case Management solution which works in conjunction with the Microsoft suite of products is a good thing.  We also had some interesting Q&A – one of the interesting topics was how we can use BPM tools to estimate efficiency savings, and help the client build a business case for process improvement.  Talking afterwards,  many of the attendees were looking to the future and the challenges some public sector organisations will be faced with in the coming weeks and months.  We are confident that Singularity and our partners can work with our clients to build confidence in how more efficient process can be built, and how Singularity and our partners are ideally positioned to bring about these savings. If you are interested in working with Singularity, or have a project challenge, we would love to hear from you.

On Nov 25^th we cracked open several bottles of champagne to take the edge off the real pain of bringing a new product to market in 100 days. Back in June we ran a hothouse to come up with a proposal for a BPM as a Service product – effectively a brand new client, delivered across the web, for our existing SPP platform. The hothouse was great fun – 3 days of alternating between staring at the ceiling, brainstorming, and frantically cranking out code or PowerPoint, all in a very competitive environment. The output was the concept of LiveAgility; a Silverlight-based BPM design and run-time environment with a radically different look and feel, and a commitment from the company execs to fund the development and bring it to market by the fall.  Development started for real in August after the holiday season was over, and followed Singularity’s standard agile model:  3×4-week iterations and a 2 week regression, but with an extended alpha trial tacked on the end. The hard part was to ensure a radical break with the past – we’ve built several process design environments over the years and there was a danger we would just build another version of the same thing. We decided to give UI design control to someone who hadn’t worked with the previous process builder. The response to the results suggest we’ve achieved our goal – at Gartner events in the US and London, and in other sessions with analysts and prospects, we’ve had a very positive response and we believe we genuinely have something different to offer.   It’s still early days of course – I’m amazed at how much we’ve been able to deliver in the first release: you really can put useful processes together in minutes and run them. But there is so much more we plan to add: support for persistent data, integration with SharePoint online, tabular and graphical reports,  real-time collaboration, desk-top integration. One of the advantages of the SaaS model is that we can bring these features through very quickly – after all there is only system to update.  Currently the product is completely free – you can sign up for a trial at www.liveagility.com    We’ll introduce charging some time in 2010 but there will still be a 30 day trial period for existing and new customers.  We’re tired but pleased – we hope you like it.

And btw, you can pronounce it l-i-veagility or l-ae-veagility as you wish; we don’t care just as long as you give it a go and let us know what you think.

Paul Moorhead
Head of Product Management

Singularity
Nisoft House
Ravenhill Business Park
Ravenhill Road
Belfast BT6 8AW
Northern Ireland

Email: paul.moorhead@singularity.co.uk
Tel: +44 7866 4876 

www.singularity.co.uk

www.profit-thru-process.com

I’m no gardener.  I have trouble remembering to water my houseplants, never mind making informed choices about pest control, soil pH or hydroponics.  My level of expertise is slightly above ‘the green part sticks up, the white part goes in the ground, and if it turns brown, pour water on it’ (this could explain my usual less than stellar results).  But what I do understand is that plants can take heat and light and a bucket of dirt, and in a short amount of time, transform it all into something beautiful; and there’s something a little bit magical and miraculous about that. 

Humankind (being the inveterate tinkerers that we are) has then taken that natural process, and has worked out that if you stick it all under glass in a ‘hothouse’, you’re trapping that solar energy in with the plants where it bounces around the room a bit and transforms into heat, which gives you better results faster.  This deeply scientific description gives some clue as to why the agile community has borrowed the term ‘hothousing’ to describe the sort of competitive workshopping approach that’s making headlines at the minute. 

So what is a hothouse?

If you think of a standard requirements workshop as gardening unaided, the Singularity hothouse version adds three things to intensify this environment to give the group the right atmosphere in which to synthesise innovation, and to accomplish this over an extremely short three day timescale: 

• light (iterative realignment of requirements to the overall strategic vision of the project and the organisation)
• fertiliser (additional skillsets and information not usually brought into the workshop environment)
• heat (two teams of stakeholders  to provide some good old-fashioned competition)

Light

Traditionally, requirements capture starts in a workshop that might involve one or two analysts sitting down with a subset of business users to elicit everything the users can think of during that session. This activity is then repeated across functional areas and product stakeholders, and while there are a lot of techniques that can be used to good effect to coax requirements from end users, the activity is still up front, with the usual goal being to produce a lengthy, comprehensive technical document that will be frozen for change control purposes before anybody writes any code.

Even in the agile world, where requirements are identified using use cases or, even better, business-friendly user stories, requirements workshops produce a product backlog that often isn’t reviewed by the project’s sponsor in any great detail (the attitude is usually, ‘if the users are happy, then I’m happy’).  This can, however, lead to a backlog which is:

• misaligned to other organisational objectives
• delivering value, but in the wrong areas
• missing opportunities to deliver (or prove delivery of) some of the specific benefits promised in the project’s original Business Case

Singularity’s hothouses, on the other hand, aim to get business-friendly requirements in front of the project sponsor and product owner at the end of each d  d ay.  The sponsor and product owner become the hothouse judges, and evaluate each team’s daily presentation.  These detail:

• the problems that the organisation faces
• the benefits to be achieved by solving these issues
• a set of proposed requirements that will deliver a meaningful solution
• high-level evaluation of the cost and time required to deliver the key requirements, and
• prototypes and scenarios to provide visualisation of how the solution could achieve a positive change

This iterative evaluation allows the judges to steer teams toward proposals that complement ongoing organisational strategy, while also allowing the teams to excite the judges with a compelling vision of the future.  In addition, the presentations become key project collateral which can be replayed to wider audiences, to accelerate the process of achieving buy-in across the various user groups.

Fertiliser

Agile requirements workshops are usually run by analysts for end users, and often don’t incorporate development team members to any degree.  Cost is usually prohibitive in the run-up to construction, as developers and testers don’t come cheap, and once an initial backlog is in place, the development team is usually too busy building and testing valuable software to spare the time to sit in on sessions that can easily run to weeks.

Agile theory has documented at length how combining business users, developers and testers in a single co-located team offers communication shortcuts, while also providing cross-fertilisation of ideas and delivery options.  Hothousing therefore aims to include both developers and testers in any team alongside the critical business interests. 

This can happen because a Singularity hothouse requires only three days from development staff.  The inclusion of technical staff in each team provides the business with a whole new perspective to draw from, which they otherwise might not have access to until later in the agile development cycle.  Developers provide advice on feasibility, reuse and technical risk, and testers help business users to define the acceptable limits of each requirement, and to articulate these in easily testable ways.  In return, developers and testers gain invaluable tacit knowledge, which helps to achieve a deeper understanding of the challenges faced by the business.

Achieving the right mix of people and perspectives in the highly productive environment of the hothouse allows the product backlog to approach construction-readiness after only three days.  The goal is generally to leave the hothouse with only a few days tidy-up and estimate verification required before being able to take the backlog into the first sprint planning meeting.

Heat

It’s hard to imagine any standard requirements workshop, whether agile are not, being allocated enough budget to run parallel streams of analysis over the same exact functional space.  It might be possible for a day or two, but never over the long term.

A Singularity hothouse, being a high profile activity for any organisation, and run over such a short, intensive time period, accepts this cost in exchange for the added benefit of using competition to fuel productivity, and to allow exploration of different facets of the problem area by different groups.  Rather than having one workgroup, a hothouse comprises two teams, equally balanced on grounds of skillset, background and personality types.

This is what really pushes the group achievement into the stratosphere.  However hard a person works, there’s something about human nature that pushes even harder when there’s a high profile backdrop and someone else to beat.  Skeptical about that?  It’s no coincidence that dozens of world records are broken at every Olympic Games, or that Usain Bolt has set his most recent sprint record at the World Championships, rather than in a practice run.

Competition generates the ‘heat’ required to move the team more quickly into a performing state, and then challenges them to experiment with more radical ideas in order to differentiate their vision.  These ideas might be too quickly discarded in a standard requirements workshop as too ‘out there’, too scary, too much.  The advantage in an iterative, judged approach is that there is nothing to lose by proposing radical new ideas during the first two days of the hothouse: judges will steer teams away from genuinely extremist ideas, while encouraging exploration of the sort of innovative thinking and creative problem-solving that can generate unexpected benefits.

If you feel that a Singularity Hothouse might be right for your organisation, please don’t hesitate to contact marketing@singularity.co.uk.

Author: Marion Mcdowell, Singularity

Part1: Case Management white paper – Extract No. 1

Michael White, 23 July 2009

As promised, here’s the second extract from our white paper “Case Management – combining process with knowledge”.  Case management describes how knowledge-centric processes are coordinated.  In this extract we describe the typical characteristics of Case Management. You can download the full white paper from http://www.singularity.co.uk/case-management-whitepaper.lit.  You can also check out our paper on Case Management on BPTrends at http://www.bptrends.com/resources_publications.cfm?publicationtypeID=DFC61D66-1031-D522-3EBDAB1F65A451AA , and we also have a chapter on Case Management in the Public Sector in this year’s BPM Handbook, available at http://www.futstrat.com/books/handbook09.php.  As always, we’d like your constructive feedback on the article and white paper and we’re happy to take any questions.

Case management scenarios share a lot of common characteristics.  Case workers need to manage a complex set of steps from the start of a case through to its completion, usually involving interaction with others in their organization and with external agencies, and requiring the generation of correspondence, documents and records.  The key characteristics of case management include:

• Knowledge-intensive: Typically case management processes require the intervention of skilled and knowledgeable personnel.  Staff acquire their knowledge through their experience of working on similar cases and through collaboration with more experienced colleagues, becoming thoroughly familiar with the tacit and explicit rules governing how cases should be managed.  These members of staff have to deal with issues that can be ambiguous and uncertain and that require judgment and creativity.  Managing knowledge so it stays within the organization and is passed quickly to new members of staff is a challenge.
• Variability: While a particular type of case will share a general structure (e.g. handling benefits applications), it is not possible to predetermine the path that a particular instance of a case will take[see note 1].  A case can change in unpredictable, dynamic and ad-hoc ways as it is progressed through an organization. Certain elements may be fixed (e.g. the end-to-end duration for completing a case may be set to 18 months, or a fixed budget may be allocated to each case) but there can be considerable variation in how steps are executed, based on the particular circumstances of the case.
• Long running: cases can run for months or years, and are generally much longer running than the shorter interaction cycles handled by standard customer relationship management (CRM) systems.  Because a case is long running, it changes hands over time, different people work on different aspects and no single individual has an accurate view of the case as a whole.  This drives the need for a supporting case management system that can provide a single consolidated picture of the case.
• Information Complexity:  Case management almost always entails the collection and presentation of a diverse set of documents and records.  Emails, meeting notes, case documents and correspondence related to a case must be easily accessible to the appropriate case worker at the right time.  This is often difficult for case managers to organize and manage efficiently, with the danger that an important record, note or file will be unavailable, lost or overlooked when it is needed.  Retrieving the correct information required at a particular decision point usually depends on the knowledge of the case worker and an adequate physical filing system.
• Collaboration and coordination: case workers usually need to co-ordinate interviews and meetings among interested parties e.g. scheduling an interview with an applicant, with other staff in the organization, with legal representatives. Many cases require a team-based approach, with different specialists working on different aspects of a case or acting as consultants to their colleagues.  These team members need to be able to access case information and discuss it with each other.  Collaboration is particularly important in knowledge-based case management because workers rely on each other’s advice and experience when making decisions on a case.
• Multiple Participants, Multiple Roles: There are often a range of involved parties, either directly or indirectly related to a case, who play different roles during the lifetime of the case – e.g. applicant, witness, claimant, injured party, appellant etc.  There can also be a large range of staff roles required to complete a case end-to-end.  And case workers can fulfill different roles in different types of cases.
• Cases can be interrelated: the outcome of separate cases may have an impact on each other.  For example, an application for citizenship by an individual may be affected by the success or failure of an application by a spouse or immediate relative.   Cases can be explicitly linked or they may be linked by inference and conducted with this inferred link in mind.
• Critical nature of timescales: while cases may have great variability in how they are completed, very often there are inflexible requirements for end-to-end timescales, driven by legislation or Service Level Agreements.
• External events affect cases: external, out-of-band events and intervention can change the state of a running case e.g. a phone call from a lawyer or the unscheduled arrival of compliance documentation.
• Difficulty in Gaining Visibility of Case Progress: this is a common characteristic of case management as it is implemented today, although it is not an inherent characteristic.  While case workers may have a good understanding of how they are progressing individual cases, it is often difficult to monitor progress when work has been passed to colleagues within their own unit or to an external department.  At a higher level, managers usually have poor visibility of how long it takes to progress a case on average, how much a case costs to process, and what the expected completion time is for a particular case.  It may also be difficult to obtain information on which cases are stalled waiting for an external communication and which steps in a case are repeatedly causing bottlenecks. The result is that processing of cases is often serialized, because to run them in parallel, while more efficient, is just too difficult for many organizations to manage.
• Strong reporting requirements: There is usually a significant requirement to report on and analyze information derived from case handling, both at operational and management levels, for example workload analysis of cases by stage, by individual and by department and case performance versus target.  Managers want gain insight into operational performance and quickly identify exceptions.
• History: every action performed, every decision taken and every piece of correspondence received has to be tracked, not just for audit purposes, but also to provide guidance for future similar cases.  Case workers need access to this history when making decisions, while auditors need the history to ensure policies are being adhered to.  The case history is the organization’s defense mechanism against any allegations of failure to perform, particularly in cases which have high cost or personal impact.
• Security:  there is a requirement to provide fine-grained control over who has access to particular information and functionality.  In certain environments, these security requirements assume particular significance e.g. policing, health care and child protection.
• Isolated pockets of automation: this is a characteristic of case management as it is generally implemented today, rather than an inherent characteristic.  Case management is usually only partly automated and there is disjoint between those pockets of automation.  Legacy systems automate slices of the processes, but the end-to-end management of a case still relies too heavily on paper documentation, physical folders, spreadsheets and email. 

While this list of characteristics is not exhaustive, it captures the essential aspects of managing cases.  But what are the practical implications?  Why should people care about the characteristics of cases or the issues raised when trying to automate them? 

In the next extract, we’re going to look at why Case Management is so important to so many organizations today and why it’s going to become more important to more of us in future.

It’s Tour de France season – which is an exciting time of the year for a man with calves and varicose veins like mine.  Road cycling remains a minority interest in the British Isles but, perhaps stimulated by the UK’s stunning success in track cycling in Beijing, I’m seeing unusually high levels of awareness and enthusiasm for the TdF this year.  This is good – it means I may not have to move to Belgium (although their beer is a compelling proposition).

What has this to do with BPM?  Bear with me…  one of the unusual aspects of this year’s tour is that the Astana team (banned last year because of a historical association with performance enhancing substances) is back, and with at least three cyclists capable of winning the Tour.  Lance Armstrong has won seven times, and looks sharp enough to make it eight. Alberto Contador was the 2007 winner, and, but for the ban, might be shooting for 3 titles, and Levi Leipheimer has been a top flight rider for several years with a wicked time-trial performance. Most teams would be happy to have any one of them, but here they all are simultaneously trying to win the tournament themselves, ensure that someone from the Astana team wins the individual event, and ensure that Astana wins the team trophy.

The press are falling over themselves trying to stoke up the internal rivalry and generate as much excitement, controversy and debate as they can.  But, hang on, isn’t this just another day at the office? In any organisation today people are balancing their own personal craving for success, their desire to be a team player, and their (enlightened self-interested) wish to see the team/dept/company succeed. It’s not an odd thing – it’s the norm, or at least it should be unless you’ve been crazy enough to hire one good guy and a bunch of lazy and indifferent people.

How far should the business enable or encourage this complicated dynamic? Is it actually a really positive thing rather than a problem? Every business should want the strongest team they can afford; but this only makes sense if they can actually unleash the full potential of those people, and reward them accordingly,  and that requires certain criteria to be fulfilled:

            1. Each player’s overall contribution is fully recognised and rewarded
            2. Each player’s particular strengths are identified, exploited and celebrated
            3. If there a single outstanding performer, it should be possible to identify them quickly and align
                the whole team behind them

Ok, I asked for your forbearance… for many of you, this team dynamic is perhaps not an issue – you work in small fluid teams and you have the chance to shine, or support,  with visibility. But this is not so for the vast majority of people in work today. Their issue closure rate, their customer satisfaction rating, their low defect rates, their creativity, are all invisible, uncelebrated, unsupported.  Not only are we not encouraging healthy competition between them to be the best individual and/or team performers, we may well be encouraging them to coast.  So this is a plea for Business Activity Monitoring – knowing enough about your teams and who is delivering value and in what ways so that you can do what Astana need to do today.   Establishing and enabling processes is good – but make sure as you do it, that you’re getting the data back out of the processes , not just about the overall result, but also about the Contadors, Armstrongs and Leipheimers, to drive up the performance of the entire team… er business.

About the Author: Paul Moorhead is the Product Manager at Singularity.

Part2: Case Management white paper – Extract No. 2

Michael White, 29 June 2009

A little later than promised, here’s the first extract from our white paper “Case Management – combining process with knowledge”,.  You can also download the full white paper from  http://www.singularity.co.uk/case-management-whitepaper.lit.  In the white paper we explain what case management is, relate it to the broader subject of how knowledge workers do their jobs, and identify the characteristics that have made knowledge intensive processes difficult to automate in the past. We show how a Business Process Management approach with specific support for knowledge intensive processes provides the most appropriate solution to Case Management.

Part 1:  What is Case Management?

“For about fifteen years I’ve been doing research on business processes and how they can be improved.  I’ve come to the conclusion that the most important processes for organizations today involve knowledge work.  In the past, these haven’t really been the focus of most organizations – improving administrative and operational processes has been easier – but they must be in the future.”

Tom Davenport, “Thinking for a Living” Harvard Business School Press, 2005

Case Management is critical to the work of many organizations, and is a common approach to supporting knowledge intensive process.  Case management, also known as case handling, describes the way organizations such as government agencies, banks, big legal firms and insurance providers handle complex customer and service interactions. 

In collaborative environments, where knowledge workers work together on a process deliverable, the case management representation is the predominant process representation. 
Marc Kerremans, Gartner, “Case management is a Challenging BPMS Use Case”, 8 Dec 2008

A ‘case’ refers to the set of interactions with a customer and other relevant participants, from initiation to completion, to fulfill some service request.  An  example might be “apply for an immigration visa” or “resolve my complaint about being billed too much”.

Examples of Case Management

In the past, cases would have been managed using a manila folder of documents and records, with the folder moving through a department or organization from one in-tray to the next while the case was evaluated and progressed.  Evaluation of the case would involve correspondence, phone calls, meetings and notes being appended to provide a record of the progress of the case.  The staff working on the case, known as ‘case workers’, would be knowledgeable about their organization and how previous cases had been progressed, and would be empowered to use their judgment and discretion when deciding how some part of the current case should be handled.  Cases might follow a general pattern, but each particular case would take its own unique path from initiation to resolution depending on the circumstances of the individual whose case was being handled.

Case management is often intensely manual, paper-driven, plagued by delay and poor visibility, with isolated parts of the process automated by legacy systems or spreadsheets.  There are two main reasons why case management is so poorly supported.  Firstly, it is inherently more difficult to automate than other processes because of the extent to which case processes must support human knowledge, judgment and discretion to determine their outcome.  It is harder to manage the complexity and unpredictability of a case than, say, automating payroll processing or credit card transaction processing.  Secondly, the available technology simply hasn’t been able to support the requirements for dynamic-user driven changes to cases as they progress. 

Defining Case Management

There are no universally accepted definitions available for case management.  We define it as follows:

Case Management is the management of long-lived collaborative processes that coordinate knowledge, content, correspondence and resources to progress a case to achieve a particular goal; where the path of execution cannot be predetermined in advance of execution; where human judgment is required to determine how the end goal can be achieved; and where the state of a case can be altered by external out-of-band events. 

In the next extract, we’ll look at the characteristics of case management a little more closely before considering how it can be properly supported by technology.

At the start of this month we shipped a major version of the Singularity Process Platform.  The focus of 4.0  has been on support for Software as a Service,  Agile Business Rules,  and eDRMS integration (SharePoint and HP TRIM).   It’s a busy, exciting and tense time for a Product Manager coming up to a major release.  The key responsibility of the job is, after all, to ensure that the company delivers the best possible product at the time, given all the constraints.  Singularity is the first company I’ve worked for which has fully embraced agile development as the approach when working with customers and for delivering product releases.  I’ve plenty of experience in the past with companies who used iterative approaches, time-boxes, MoSCoW and the like, but it was new and invigorating to go the whole hog (or should that be pig? – agile in-joke, sorry).  It works too; not flawless -  my mantra is that “you’re always doing it wrong” so the improvement process never ends, but once product management and development ironed out the wrinkles in the mechanisms for managing the user stories and iteration planning, it flowed very smoothly.   And we’re now on a quarterly release train – and I’ve always liked release trains because of the way they turn the painful and endless “date versus scope” argument into a much simpler “which train will this feature leave on” discussion.

So did Product Management get it right?  Early days, but the SaaS content of the release has been quickly picked up on by the analysts and we’ve had enquiries from several existing and new customers, so it would seem that our belief that SaaS was maturing rapidly, and the economic advantages of a rental model, was well founded.  As we anticipated the interest is primarily from companies who wish to build out their own SaaS offerings and appreciate that a SaaS enabled and scalable workflow engine is a key enabler.

The SharePoint and HP TRIM integration is also arousing interest.   Microsoft are hugely committed to the success of SharePoint and it’s rapidly becoming the centre of the universe for many businesses. We’re using SharePoint internally as the core of our requirements management and iteration planning process (along with SPP of course) and it just works really well. It’s a great product for collaboration and content management, and the OOTB fit with our Case Management capabilities is a powerful story.

I’ll be talking some more about SharePoint Case Manager (as I would like to call it) in future blogs.

Did we get anything wrong?  Well hard to say; I’m personally very pleased with our new business rules and business parameters support, I think the current economic turmoil has underlined how essential it is to be agile, and using rules and parameters to separate policy and external determinants from the business processes gives you that in spades, but the response from customers has been more “that’s nice” rather than “wow”.  Maybe it’s a grower.

On the other hand, some smaller features which we hadn’t really played up very much, excited  customers more than anticipated. For example the integration with the Outlook Task list -  allowing users to view, take and complete activities from within Outlook, resonated very well.

So at this point, while I give the developers 10 out of 10 for the development, I’ll give Product Management 8 or 9 out of 10 for reading the market right.

Back to my user stories now, not long until 4.1.

Wittgenstein’s Tractatus Logico-Philosophicus starts with the statement “The world is everything that is the case”. I’ve never got far past that sentence, being diverted into pondering whether it’s a synthetic or analytic a-priori truth and crashing my operating system. Anyway, it serves to highlight the difficulty with the meaning of the word “case”.

(more…)