Does any one find that the government offices they work in have a hard time accepting Atlassian products such as Confluence? If not, what strategies have you used to make them more accepting?
Yep, quite familiar with that. At least at the Federal level, there is a level of security certification called FedRAMP (https://www.fedramp.gov) that is required (or perceived to be required...). To the best of my knowledge, Atlassian is working on that certification but not there yet. For that reason, government organizations typically go with an on-premise installation which means they have to jump to the Data Center version. That is a bigger bite than the Server version, so there may be a bit of a hurdle.
If you can get the operations folks to help you out and secure a VM for you, you may be able to quickly standup an evaluation version. I have also used the official Atlassian Docker images from www.dockerhub.com which could be ok for a trial. At Ariel, we use the Atlassian Docker images for our Confluence and Jira training. We basically load in a backup of a fully populated demo environment we constructed that includes tons of examples, both of good practices and bad practices to compare and contrast for learning.
hope this helps
Unless we're talking about a tiny agency, I think that getting it installed wouldn't be the biggest hurdle. There's a lot of stuff that isn't FedRamped, so on-premise installations of systems are common. At least that's been my experience with the agencies I've worked for.
Yes! I'm going through this right now. It's not really about Atlassian products, though, it's understanding what an easy-to-use corporate wiki brings to the table over a document-centric system like SharePoint.
When explaining the value of having informal, living documents in confluence (e.g. procedures, knowledgebases, etc) one example I use is this: Say you have a system recovery procedure (I'm in IT) and it's well documented with diagrams, etc. As you are following this procedure, you notice something wrong with the diagram, maybe a server name is out of date. In confluence it would be a web based drawing (e.g. Gliffy or Draw.io) that you could click on and fix on the spot. In a SharePoint environment, assuming you can even find the document (hah), the chance you can edit it is lower as permissions are more restrictive, but even if you can edit it you may find that the diagram is an embedded Visio document and you don't have it installed. Or maybe it's a PDF and you don't even know the authoring tool that was used or who has the source document. Now which procedure is more likely to get updated? Rinse and repeat over time and you'll find that the SharePoint documents get all out of date and people have lost trust that they are current and accurate. At this point you're more likely to make mistakes, fail audits, etc. SharePoint has its uses, but for informal day-to-day reference documentation, the lower the "barrier to entry" the better. And Confluence has one of the lowest.
I also have come across this hurdle in working for multiple government entities. Security aside as mentioned in previous replies I find education is the key to overcoming that obstacle--when the client is researching to buy or new government staff needs to be oriented into the tool.
Create a demonstration space with as much content applicable to your government audience and at the correct security level for that client.
Make it relatable to them. I have done demos now and in the past where I specified at beginning that all content was fake but the function and capability of the tool shined.