Pastwords

A "password reset required" screen from the NSW Government Strata Hub website.
~ Sean McNamara ~ Leave a comment

Expiring passwords. We’ve all been forced to with them. And the annoyance of trying to think up yet another weird combination of characters which will be compliant with whatever other password policies apply is a pain in the 4$$! all too familiar to computer users around the world.

But I have a secret to tell you – expiring passwords are bad security!

Yes, that’s right! Bad security! Expiring passwords were never good security, and they’re being walked back from by serious security and software vendors around the world, including some former heavyweight evangelists.

But first, a history lesson…

Actually, you know what? The history doesn’t matter (I’ll e-mail it to you if you want).

The “short” version is that it goes back to 1985 when the US Department of Defence suggested changing passwords every year (based on crackability), and that timeframe was reduced as computing power which could be applied to cracking increased. So, when the US National Institute for Standards and Technology (NIST) wrote up its recommendations in 2003, a much shorter timeframe was suggested. That got “baked in” to many vendors’ settings and recommendations (including Microsoft’s).

What ultimately does matter is human behaviour.

When faced with the “challenge” of choosing a new password every 30/60/90 days, humans will be lazy. They’ll make simple changes to existing passwords, or repeatedly change them until they’re able to pass a “not the same as the last 𝑥 passwords” test and be back where they started.

They’ll fall for phishing attacks, put passwords on sticky notes, use their kids’ or pets’ names, choose security questions (e.g. “What city were you born in?”) with easily discovered answers (“Hello, Facebook?”) – there are myriad ways password security is compromised by human behaviour.

And security practices have advanced to the point where we can do a lot better, and avoid the false sense of security a periodic password reset instills.

Here are the basics of good security/password practise:

  • Use long random passwords: long passwords with minimal requirements about the types of characters work best, for example “caxsAb-tufjew-qepgy1”
  • Don’t use the same password for multiple sites/services: if one site gets cracked/hacked, you don’t want the attackers trying that password on other sites and getting in
  • Use a password manager: programs which store your myriad random long passwords and are accessed via single strong password you commit to remembering
  • Use multi-factor authentication (MFA): two-factor authentication (2FA) is a form of this, it means in addition to something you know (your password) you use additional information, such something you have (your phone to generate one-time codes or to approve logins) to make cracking the site password alone useless
  • Avoid SMS MFA: SMSes are able to be intercepted by SIMjacking and other means
  • Use incorrect answers to security questions: if you must use these with a site, save the incorrect answers in your password manager because some of that “personal” info is relatively easy to find

Returning to required periodic resets, the US National Institute for Standards and Technology (NIST) dropped that recommendation in 2017, and some big-gun adherents like Microsoft have also dropped it as the default and recommended setting.

If a provider is still requiring it, they are not doing security right, especially if they’re also using 2FA.

This post is brought to you by the security mavens in the NSW Government IT services division who are using 2FA (painfully, through e-mail) for Strata Hub, yet still apparently require expiring passwords.

Strata Hub(bub)…

~ Sean McNamara ~ Leave a comment

If you’re a Strata manager and want to get your heart rate up without visiting the gym, I have two words for you: “Strata Hub”!

Much as I personally find it fascinating, I won’t discuss the rationale behind the Strata Hub and how it has evolved over time in this post – that’s really a discussion for another day.

However, I do want to quickly (or at least, as quickly as possible!) talk about some of the challenges when preparing data for and sending it to the Strata Hub.

I’ll only mention in passing the fact the Strata Hub went live on 1 July 2022 with a promise of bulk upload templates to be available by August/September while noting that, in fact, the upload templates were finalised and available for download on 15 December, only a few working days before most strata firms closed for the year.

I’ll barely even acknowledge the fact plans and managers were told to upload their data by 30 September or face fines, which was then extended to 31 December 2022…which then changed again over time to 30 June 2023 with a very watered-down statement that “fines may apply” after that date (my emphasis).

Is it even worth mentioning the bulk upload files were not insignificantly changed from their draft versions, while the data definition documentation was not updated to reflect those changes? Probably not.

Should anyone have expected instructions that upload files only needed to “match” the format defined in the upload templates actually meant anything but that the data had to be copied into the provided Excel templates or the uploads would fail? Such naiveté!

And shouldn’t strata managers understand that phone numbers must start with “02” or “04” to be valid phone numbers for contacts in strata schemes in NSW?! Sorry, schemes with cross-border contacts and “1300” number-bearing strata management and building management companies: those numbers aren’t valid.

And, of course, everyone expected that contacts couldn’t undertake more than one role, surely?! Strata managers as Chair and/or Secretary? Impossible!

Lot count discrepancies between LRS’ data and what strata managers have on record? A minor irritation “easily” sorted by getting the OC to resolve to update LRS.

Undefined limits (say, $1B in insurance building replacement values) couldn’t possibly be due to inadequate planning in relation to future needs of the relevant data fields…could they?

And it goes without saying that such undefined limits would prevent the uploading of the file without explaining why the upload failed (literally – the upload process doesn’t say).

And let’s not quibble about the 20 or so clicks required to verify authority to provide information and acknowledge privacy consents for uploaded details and download invoices and generate BPAY details. For every scheme uploaded. Every year. Group acknowledgements? Pah!

Surely using time-sensitive BPAY details which aren’t included on invoices is only a problem for Accounts, not strata managers…right?

And don’t forget, the initial upload has to be for the 2022 year, and any AGMs held subsequent to 31 December 2023 will trigger the 2023 annual update (and Government per Lot fee), but I’m sure Committees will understand the “double” billing from the Government and for Schedule Bs.

And for a little extra spice on that one, if a new plan has not yet held an AGM, or only held their First AGM in 2023, they won’t be able to be placed on the Strata Hub as there’s no exclusion for this situation available to be applied.

There’s no doubt API access would make providing data more straightforward, but many of the above issues are underlying data definition and process issues which the method of data provision doesn’t change. Additionally, if a file-based bulk upload facility is provided, surely it should be more straightforward than the above.

Then there are the many questions outstanding, not the least of which include:

  • Will the data trigger compliance action by Fair Trading and/or Councils? Think “buildings not currently required to prepare AFSS’s”, or “schemes which have not held an AGM as required”.
  • How will the Government confirm identity of those seeking access to a scheme’s data (owners and tenants), and how will their data sources align to the Strata Rolls we maintain as strata managers and which we have stringent legislative and privacy requirements on access to?
  • How will other community-ownership and management regimes (BMCs, Community, Neighbourhood and Precinct Associations, and Company Title) be incorporated in a way which is consistent given the wildly varying natures of those regimes?

The Strata Hub is obviously a work in progress, the scope has clearly grown significantly since its inception (and will continue to grow), and quite a few design decisions were clearly not thought through from the perspective of day-to-day strata management operations.

On top of this, issues around privacy and access were sometimes dismissed (before some level of accommodation), and in some respects are still to be resolved (for example, tenant access to Committee member contact details).

COVID-19 has seen some important and overdue changes in strata (increased prevalence of electronic meetings and document signing), and some challenges, of which I definitely consider the implementation of Strata Hub and compliance with its requirements examples of.

How strata companies react to these changes at a systems level will define how well they will be able to continue to service the needs of their clients in an ever more complicated market.

And I’m honestly not entirely sure the market considers increasing complications such as these as valid triggers for a sensible approach to strata management fees…but that’s yet another discussion for another day.

Send me your stories of Strata Hub challenges, stresses and wins! I’d love to hear how others have coped with this process, because everyone I’ve spoken to so far seems to have needed several stiff drinks upon completion.

Bad (Data + Systems) = (Staff + Client) Turnover

AI-generated image of two Victorian-era clerks pulling their hair out while holding pieces of paper.
~ Sean McNamara ~ Leave a comment

Staff and client turnover is the bane of every Strata management company and strata manager in the industry.

It’s hard to make such sweeping statements in life generally, and in my days as an IT consultant I needed to constantly avoid such “certainty” in favour of “should bes” and “wait and sees”.

And funnily enough, it’s not just outgoing staff and clients which can cause stress, but also incoming ones (more on that later).

I doubt there’s a strata management firm operating today that hasn’t dealt with one or the other, or quite possibly both, in the last week.

If you’re running a management company and are lucky enough to have gone a month without needing to deal with issues associated with such turnover, please raise your hand, bottle your secret, make a motza, and make everyone happy…please!

For everyone else, let’s look at the impact bad systems, processes, and data can have on staff morale, burnout, and retention, and on client satisfaction and retention.

While it might seem a trite to say “happy workers are productive workers”, there’s research to back this up (by Oxford University academics, no less!). And happy workers are much more likely to hang around, even if worse workplaces offer better financial inducements.

Conversely, frustration with tech is a major driver of employee dissatisfaction at work.

And while you’d be hard-pressed to say that such tech-frustration is the primary reason for staff turnover, any dissatisfaction or frustration with tech and systems is bound to play some part in an employee’s decision to leave.

On top of this “personal” frustration of team members, if an inability to quickly locate accurate information on behalf of clients leads to them being frustrated, they tend to take it out on the most available team member – usually the strata manager or their assistant. This, of course, feeds further into team member frustration.

Burnout and rapid-fire staff movements are both features of the wider strata industry and clients are faced with a carousel of strata managers, assistants, or admin and ops staff. Burnout sees potentially valuable employees flee the management company (or the industry all together), certainly not an ideal experience for other staff or clients as schemes are juggled around the team.

So how to clients fit into this equation – their experiences inform how they view your company and their decisions on renewals and management changes.

Once again, bad systems or processes are rarely a primary driver of this, but I’ve known it to be mentioned when discussing changing companies, and consideration of the prospective management companies’ systems and processes invariably forms part of the selection process.

It’s also not uncommon for bad systems at the outgoing company or even a bad induction process at the new management company to further cause issues for schemes and managers.

While I would in no way endorse a scheme remaining in a bad strata management situation just to avoid changeover issues, any management change is bound to be disruptive to some degree from the point of view of, for example, invoice payments, induction of historical data, bedding the scheme into new processes, etc.

Stress during handover can be high as staff attempt to get up to speed, the day-to-day needs of owners and committees need to continue to be met, records are delayed in being input to a new system, etc.

The format of handover documents often leaves a lot to be desired. If your strata management software exports to a proprietary format which requires a specific “reader” application and export of individual files, uses non-obvious filenames, dumps everything into a folder or series of folders with no logical connection to the individual items and categories, or commits more than one of those sins (or various others which frustrate the induction process), you are simply causing further general dissatisfaction and adding to strata owners’ often already dim view of strata managers and management companies.

Suggesting it’s “no longer our problem, let the new company deal with it” is puerile and counter to basic customer service tenets. It’s not unheard of for schemes to return if a change doesn’t work out for them, but they’re much less likely to do so if they’ve been hung out to dry by such an attitude.

A drive to professionalism in the industry and legislative requirements dictate acting in the best interests of schemes at all times, and I personally believe this includes the provision of usable, clear, logically arranged records when handing over books and records, whether paper or electronic.

As an industry I believe strata can do better, and it needs to start at the top, and be better informed by the daily experience of team members and clients.

Listening to staff about systems issues, providing an easy path to report issues, regular audits of systems and processes (and that the latter are being followed), and a willingness to correct problems or try new things are all going to be critical for management companies to “up their game”.

And when it comes to clients, six-monthly NPS ratings and a robust complaints management process do not directly address systems issues from a client perspective. Listen to their complaints and how they relate to your systems, and look for patterns where systems and processes are consistently failing or disappointing.

Undertake meaningful investigations of where your systems are falling down, and, where feasible, liaise with team members and software providers to undertake changes which improve the experience of all involved in the day-to-day running of schemes. Everyone will thank you for it.

We have a rich vein of experiences and suggestions in our staff and clients – let’s tap it to all stakeholders’ benefit.

Send me your stories of your biggest strata software, process, and systems frustrations – I’ll collate them into a future “best of” post (or should that be “worst of” post?). All submissions will remain anonymous, and product names excluded where appropriate.

And yes, those slightly weird pictures at the top of this post are AI generated – thanks, DALL·E!

Garbage In, Garbage Out

~ Sean McNamara ~ Leave a comment

The title of this post is a very old adage used in computer circles, often abbreviated as “GIGO”.

It’s a pretty straightforward concept – you can’t expect computers to return meaningful or useful results if their inputs are flawed.

Two recent issues have really made me think long and hard about the data we rely on in Strata – the rise of AIs, and the NSW Government’s Strata Hub.

On AIs, I’ll just add one problem out of many I’ve not already covered: investigations of the source data for LLM chatbots are exposing biases and omissions which can seriously impact the outputs users receive. If the source data includes discriminatory text regarding, say, gender or race, so will the output. Certainly not a good look to rely on such potentially tainted output for business communications. This is only made worse by the widespread secrecy surrounding source data sets, preventing suitable oversight of these chatbots and their output.

Onto more directly strata-related issues, when reviewing required information and how to collate it for the Strata Hub, the challenges facing the industry regarding records management was brought prominently to my mind.

I was always aware that the information which needs to be handled, processed, and stored in the strata industry had grown exponentially since strata’s introduction in NSW in 1961.

Not only are we more connected and generating a monumental amount of correspondence in our day-to-day strata dealings, but additional compliance and regulatory regimes are accelerants for this trend.

But I’ve seen firsthand that even at its most basic level, the data we have regarding the schemes we work on is often incorrect, missing, or so badly maintained as to be effectively useless.

A simple case in point is the quality of graphical data such as strata plans and drawings for by-laws.

I’m sure we’re all familiar with the gradual degradation which occurs when images are duplicated, then those duplicates are duplicated, and so on, until the details within the image become lost in a sea of noise.

I’ve seen strata plans where the Lot numbers were unable to be distinguished from each other in parking or storage areas, and an exclusive use by-law drawing for an “open plan” garage area which was so degraded after 30+ years that the Lot numbers were literally just blobs. In that case, we had to rely on recollections of the allocations, but we could not independently confirm these by reference to the by-laws.

I had previously become very familiar with this degradation when I was a desktop publisher, as customer artwork and logos were often copies of copies of copies, and suffered visible degradation each generation from the old analog reproduction technologies.

One method to avoid this was to digitise the logos as “vector” art, but that takes time, and not everything needing to be reproduced warranted such conversion.

And while digital scanning technologies have allayed this degradation to some degree by allowing the “tidying up” of noise, tech can only do so much, and some inherent scanning and compression features may even change the content of images scanned!

And that’s just one aspect of how we store important data and documents in strata which can seriously impede the productive management of schemes. Some others are:

  • Poor file naming practices: This is a real bugbear for me. I’ve been in the habit for a couple of decades now of having a stringent naming convention, and it has translated pretty well to strata. The elements are:
    • Correspondent’s name – always preceded by the SP number
    • Subject – short, descriptive, and consistent
    • Date – choose appropriate date formats for all uses (including filenames) and stick to them
  • People seeing the filename should be able to quickly determine what the file is to a pretty high degree of confidence without needing to open the file.
  • Transcription errors: We all make mistakes when transcribing – repeated transcription (say, between systems) leads to degradation of the data further and further away from the original.
    I’ve seen several instances of recorded insurance replacement values being inflated a hundredfold by a team member simply omitting the decimal point but including the cents! Verifying data before Strata Hub upload found those errors pretty quickly.
  • Discarding old records: We are only required in strata to keep records for 7 years – any discarded records may hold vital information regarding approvals of renovations, agreements between parties, the rationale for decisions, etc.
    In this day and age, I think it’s much less onerous to just keep strata records forever.
  • Non-entry (or misallocation) of information or records: if the records can’t be found, they may as well have been discarded. Just like transcription, humans make errors when storing records.
  • Not updating incorrect information: The old “I’ll get back to that later” problem. We’re all busy in strata, but if you see something is incorrect, fix it immediately if at all possible.
  • Owner or committee ignorance: How many of us can say that their Strata Roll is 100% up-to-date? Or that all committee decisions are properly recorded in the books and records
    Many owners aren’t aware or can’t be bother to fulfil their obligations to provide updates, and committee decisions and approvals are not always captured in meeting minutes.
  • Flood of data or communications: The amount of information falling across a manager’s “desk” these days is staggering. Are all relevant e-mails being filed? How is the relevance of such communications being assessed against the record-keeping requirements under the Act?
  • Data type or quantity mismatches: Another one I picked up when verifying information for the Strata Hub. Strata Hub has information pre-populated from Land Registry Services for each strata plan, but that didn’t always match the strata plan drawings or Certificate of Title on record.
  • Inter-system Incompatibilities: A superset of the preceding item – if the data doesn’t match between systems, how do you correct for or manage that difference? If your records can’t help you resolve the issue, you could have a problem on your hands.
  • Handover of books and records: a classic point where things can go awry. Incompatible file formats, clunky (or outdated) viewing applications, useless filenames or file formats, forgotten or mis-stored records not being handed over. A superset of “transcription”, and often featuring actual data transcription and its attendant errors.
  • No effective audits of record management and storage: If no-one ever checks that the above are being adhered to, and that errors are being picked up, it will lead to bad and lost records, an inability over time to correct mistakes (turnover loses so much institutional memory and context), and reduction in effective management of schemes.

If any or all of these impact the ability to effectively manage the scheme or provide clear records when requested, this might be an element of a decision to change management companies – if a change is resolved, think of all the above problems happening again. And again. And again.

And I’m not even sure that’s an exhaustive list!

I believe we can all do better, and that you’d be hard pressed to find a strata management company that could guarantee that the data they hold in relation to their portfolio is even 90% correct.

While perhaps 100% correct is always going to be unrealistic, I think we all should be aiming to improve the records we hold and the processes we use to store them to get as close to that goal as possible.

Do you think I’m being pessimistic with the above 90% ceiling of certainty? Comment below or on LinkedIn with your thoughts and strategies for more effective records management in strata – I’d love to hear your thoughts.

I’d Like a Chat…

Screenshot of a basic interaction with Eliza, a chatbot created in the 1960s.
~ Sean McNamara ~ 2 Comments

What a six months it’s been – AIs and chatbots have hit the headlines and hijacked the zeitgeist!

It’s hard to go a week without seeing a spruiker or a detractor (or several of each) claiming everything is about to change for the absolute best or the absolute worst.

And the “silicon entities of the hour” seem to be ChatGPT and Bard, Large Language Model (LLM) AIs which are causing quite a stir with their convincing responses to plain English prompts.

I’ve been around IT long enough to be able to say with certainty that AIs are nothing new.

While my exceptionally switched on IT teacher in the 80’s was focussed on the integration of various devices such as phones, computers, cameras, TVs/VHSs, etc. into multi-purpose devices (which we now carry in our pockets), AIs were already a “buzzy” topic of conversation in IT circles.

But the running joke has been that “true AI is only five years away” – no matter when you ask.

Now, between image generators like DALL·E (which came to prominence in 2021), website and call centre chatbots, and now LLMs, it seems like the five years is up, and the “Age of True AI” is upon us…

Or is it?

OK, I admit it – I’m one of the skeptics…at least in relation to the utility in Strata (and many other technical fields) of currently available LLMs. But let’s step back a little.

AI, “Artificial Intelligence”, is a loaded term – the first part is really easy, but just what are we going to claim or accept as an “intelligence” born not of flesh.

Personally, I prefer AGI: “Artificial General Intelligence”, which, according to Wikipedia, is “a hypothetical intelligent agent which can understand or learn any intellectual task that human beings or other animals can” (my emphasis). I can live with that definition.

And, based on that definition, what we’re seeing with DALL·E, ChatGPT and Bard is anything but such an “artificial general intelligence” – it’s not even a semblance of a basic intelligence!

These latest chatbots seem convincing, sure – but all they’re really doing is providing something that looks like the right answer. Sometimes the similarity to the right answer is striking and you’d be hard pressed to notice a difference. Sometimes…not so much.

Here’s an exercise I’d like you to try:

  • Think of a subject matter you have a large amount of technical knowledge in (it doesn’t have to be strata);
  • Think of one of the most technical aspects you’re familiar with in this subject matter;
  • Think of a question regarding this particular technical aspect that you’d like to ask another expert in the field to compare notes with;
  • Go to chat.openai.com and login (or sign up if you don’t already have an account);
  • Paste or type your question into the prompt field; and
  • Review the result.

What you’re going to see is one of three things:

  • An impressively correct exposition on the question – “top of class” stuff you can’t fault;
  • Something which is close (for various values of “close”), but “no cigar” territory for those in the know;
  • Something which is so wildly stupid, you can’t understand how this thing was ever considered “intelligent”. You want your money back! (I hope you signed up for the free version.)

Part of the problem is that for the second and third cases, these LLMs will rarely say “I don’t know”, or “maybe” – they will usually give just as convincing sounding an answer as what they provide in the first grade of response. And, for reasons I touch on below, the first type of response is just a fluke!

And even on the odd occasion ChatGPT says it can’t answer a question, it can often be tricked into doing so, and once again, the result of that tricking will fall into one of the three categories above.

When I was first of companies considering ChatGPT use in strata, I asked it “What is the process for getting renovations approved in a strata building in NSW?” – this was, I expected, a straightforward prompt given we’re over 7 years into the new regulatory regime in NSW.

I won’t quote the whole answer on this page (you can find it here), but my rough assessment at the time was that it was about 10-20% right. Pretty atrocious, frankly. I’d be embarrassed if anyone I managed sent that response to a client.

The next day, after mulling on it further and wondering just where it all went wrong (I sorta suspected, actually), I amended the prompt with a simple tail-end addition (highlighted): “What is the process for getting renovations approved in a strata building in NSW, with reference to the Act?”. The first paragraph of the new response was telling:

“In New South Wales, the process for getting renovations approved in a strata building is regulated by the strata schemes Management Act 1996 (NSW) and its associated regulations.”

Bingo!

No wonder it was up to 90% wrong: It was referencing 27 year old legislation! But when you sign up or login it says its knowledgebase stops late 2021 – how could it be so wrong/out of date?!

This is where modelling, prediction and weighting come in. What ChatGPT did, based on the information it was trained on, was provide what it calculated/predicted was the most likely/suitable response from weighted information sources. My amendment just got it to admit where that weighting lay – on information sources tipped towards the 1996 Act.

And the prompt can actually affect the weighted selection of sources, so framing my question differently may well have resulted in the 2015 Act being used, with its “cosmetic”, “minor” and “all other” (aka major) renovation definitions. Maybe. This is why I said above that these systems may fluke the right answer.

I tried again by asking for a letter to an owner regarding the major renovation approval process, and, to “force its hand”, my prompt referenced the 2015 Act explicitly, but it still took several refinements to get to the point of being (maybe generously) 75% acceptable (you decide) and ready for me to consider editing and sending it to someone…perhaps. It might have been quicker for me to just type something up myself.

Don’t get me wrong – these models will have continuing improvements (the above examples used ChatGPT-3.5, ChatGPT-4 has since been rolled out), and these sorts of “gotchas” will become less and less prominent, even in deeply technical fields such as strata. If I started these tests in five years’ time, the results would be very, very different.

Additionally, it may be possible to train the systems now by providing a body of knowledge before you ask your “real question”, but you’d have to know the right type of training material to provide, then find or write it in a way the AI can ingest it. At that stage I’d have to ask, “Just what are you really gaining?”

But what I’m really trying to get across is that we’re nowhere near the stage where we can rely on these bots in strata (and other deeply niche technical fields), and in addition to that, there are several other important issues with using these AIs to keep in mind:

  • Where is your data going?
    Your prompts are almost certainly going overseas – does this match your business’ data sovereignty policies? Or government requirements? Beware of including personally identifiable information (PII).
  • How will your data be used?
    “In the AIs’ training data” is the short answer. Will the information you provide to these AIs end up forming part of future knowledge bases that answer prompts from your competitors? Maybe? Probably?
    And what are the privacy implications of sharing customer data with external parties in this way? Scary, if you ask me.
    How will you ask your clients for permission to use their data in this way?
  • Whose base data are you relying on to answer your prompts? Do you get to see what data the LLM was trained on?
    I’ll save you Googling that one – the answers are “We don’t know” and a resounding “No”, respectively.
    All the developers of these AI systems closely guard their LLMs’ training sets as proprietary information. And sometimes, they have don’t even have a licensed right to use that information in the way they have in the first place!
    Would you be happy basing business decisions or drafting customer responses on such potentially spuriously-sourced information?
  • How is the information weighted to appropriately form answers? Who chooses the weighting?
    Like the last last question – we just don’t know. Maybe an algorithm (that we don’t get to see)? Maybe guided by humans. Maybe by providing additional material…maybe not.
  • Do you trust beta software?
    All of these systems are under active development, are early stage versions (think “proof of concept”), and may (as shown above) generate dubious content you cannot base responses to customers on. When will they be ready for “prime time”? And who decides when they are? Another set of “We don’t know” questions.

So, after all that, do actually I see any utility here? Sure – but you just need to assess these systems’ suitability for your use cases.

For generalist writing tasks, these bots may provide better output than some people can provide. Great, I say go for it for such non-technical use cases.

But if I were running a strata management or other technical field company/consultancy, I’d be testing a heap of prompts to see what sort of responses I might expect before going anywhere near a general rollout, and I’d certainly want my staff to be protecting the company by:

  • Carefully reviewing responses before sending them to any external parties – this review is best carried out by someone knowledgeable in the field, who may or may not feel the bot-generated content has saved time over creating the response themselves;
  • Assessing the business risk of relying on such external “(fake) expert systems” we have no ability to review the inputs of – what are you prepared to stake your business’s reputation (and liability!) on?;
  • Ensuring personally identifying information (or information about strata schemes) is removed from prompts – but this means such information needs to be stripped out or obfuscated in prompts, then placed back into responses;

And that’s after giving all team members prompt generation training (including assessments), determining best use cases (and use cases to avoid), and creating an auditing framework to allow periodic review of usage and suitability.

We are going through a time of rapid awareness and uptake of these technologies, and they’re being applied in new and interesting ways (e.g., meeting summaries in Microsoft Teams, aiding internet search engines to generate responses, automating computer programming) – but all of these uses come with caveats similar to the above, and we are about to see a wave of partially (or completely) incorrect information flooding our infosphere.

I believe our organisations and management teams have a lot of “checking sources” and “trust assessments” ahead of us externally, and a lot of “use case soul searching” internally.

Despite the length of this post, this is all just the tip of the iceberg, both in the use of these “AIs”, and in the critical assessment of them. I would love to hear your thoughts – what are you using these AIs for, and where have you seen things gone off the rails?

Please comment below, comment or message me on on LinkedIn, or reach out directly if you’d like to…well…chat. I promise it won’t be a chatbot replying!

And don’t forget to check out my introduction and About page!

An Introduction

A section of a Strata Plan showing part of Lot 3 and Common Property.
~ Sean McNamara ~ 1 Comment

Well, here we are…Welcome to my new blog!

I’ve recently finished up a role in systems/data/process analysis for a mid-sized Strata management company in Sydney, so have a little time on my hands. I’ve decided to do what I’ve been wanting to do for over five years and put some thoughts on strata title, the strata industry, IT systems, and data in strata “out there”.

IT systems are critical not only in the handling of books and records (i.e. the grunt work), but also in the very experience strata managers and strata owners have when navigating this deeply technical, but often very grey, area.

My time as an IT consultant, has often led my thoughts to improving systems to drive efficiency for customers my strata peers. An inefficient strata manager is an unhappy one, and inefficiencies drive client discontent and manager burnout in the industry.

So, of course I have sought out new processes and systems ever since I became a strata manager and have learned a lot about how IT works (and doesn’t work) in strata.

But, before I start posting, a little background is in order – my first career was in desktop publishing (1987-1997), and during that time I started writing as a freelance computer journalist (1990-2009). In 1997, I started an Apple-focussed computer consultancy, MacAssist, which was in operation until 2018.

My strata career started in 2018 after being involved deeply in the issues my wife and I (and our fellow owners) faced when buying into a refurbished building that had then been converted to strata.

Strata, strata legislation and policy, and community living in general absolutely grabbed my attention and interest.

While I “only” spent three years as a strata manager, I’ve maintained my licence and interest in the field, and was heavily involved in SCA (NSW) Committees. I also represented that body and the wider industry in several working groups across strata, sustainability, and building industry reform.

In 2021, I moved directly into working on policy and compliance with SCA (NSW) – a role which also ended up including a lot of work in systems and IT while I wrangled a CRM system which was not well-aligned with managing the (then new) Professional Standards Scheme which binds SCA (NSW) members.

In 2022 I started a role at a medium-sized strata management company explicitly bringing together systems and IT with strata, and very much enjoyed that combination of my two loves, and helping my strata colleagues in their use of systems.

The completion of that role and the successful initial upload of that company’s portfolio to the NSW Strata Hub, sees me with a small amount of time in which I can start this blog while I look for my next opportunity combining the fields that I love.

While much of any technical strata content here will be in the context of NSW, I am fascinated with how strata differs between States in Australia, as well as in its implementation internationally.

Please feel free to suggest topics, see if we can catch up for a chat (virtual or over coffee), comment on the topics I write about, or just say “Hi!” via the contact form.