Change Management and the Facebook Development Team
If you, like me, have been “sucked in” to the Facebook craze, you’ve also recently been reading a LOT of posts about the new Facebook interface. Even the tag clouds on Google and Twitter show Facebook complaints as a leading conversation trend.
In fact, I chimed in on the conversation with this post:
“You’re not really ‘there’ until everybody hates you and makes jokes about you. Congratulations Facebook, you’ve joined the ranks of Google, Microsoft, and IBM.”
In perfect new-media form, I’m going to share a secret now with everybody in the world. (Yes, because I’m a Facebook-er, I too have been numbed to the normal trepidations of sharing secrets about myself in public.) So here goes . . . .
I’m sorry, but I happen to like the new Facebook interface. I think it’s more convenient, allows more control over your news feed, gives you the ability to classify posts, and allows you to see real-time commenting more effectively.
Yet, with all the effort Facebook must have put into designing this new interface, they are taking a MAJOR reputational hit.
So being the opportunist that I am, I must take this opportunity to point out that the PRIMARY causes of Facebook’s new release depression is indeed what we in IT Governance like to refer to as “Change Management.”
I know, this is not a very happy subject for many smaller institutions, because to comply with “best practices” you would have to do so much work you’d never be able to accomplish change. But the Facebook incident proves something. And yes, this would indeed be classified as an Information Security Incident if Facebook had adopted some of the incident response policies I’ve been auditing these days. And the post-mortem analysis of this incident would surely lead even the smallest of Incident Response Teams to conclude that there are some simple change management fundamentals that even small businesses should consider:
1) People don’t like change, no matter how good it is for them.
2) Announce the darn change, preferably IN ADVANCE of the change.
3) Heck, try to SELL the change in advance if you can.
4) Try to give people an opportunity, if possible, to opt out of the change, at least at first. If appropriate, establish a timeline for adopting the change.
5) Another way to put item 4: Get approval for the change in advance of making the change. (And yes, at least in banks, sometimes that approval process is going to require a risk assessment.)
6) If you really want to get fancy, try to include some instructions explaining the change, how to use the new features, and perhaps some suggestions on how to make the most of the change.
7) Finally, if the change involves your customers and you have a social media presence (ahem Facebook), monitor the social media comments about the change, and try to respond to them.
And that’s why Facebook should be treating this as an Information Security Incident. Had an Incident Response Team been called once they realized their boneheaded-ness, maybe an opt-out button could have been offered. Then early adopters would eventually bring the late adopters into the mix.
Dan Hadaway CRISC, CISA, CISM
Founder and President, Infotex
“Dan’s New Leaf” is a “fun blog to inspire thought in the area of IT Governance.”
Leave a comment
Show this article to your CFO the next time he or she asks for a budget. Another one Read more
Another awareness poster for YOUR customers (and users). Now that we have our own em Read more
Several New Targets For Ransomware Have Been Identified… An article review. Over the Read more
Incident response testing is the stone that kills many birds… Another one of those Da Read more