And now for something completely different... (Actually this can't possibly be an original idea. Can it?)
140 characters sometimes just isn't enough to adequately express why people should care about your Follow Friday tweet. The idea of Follow Friday Director's Cut (or #FFDC) is to give your followers a bit more of an idea of why you follow somebody and why they might want to as well.
I know that part of Follow Friday's charm is its relative ease. I also know that I follow a lot of bloggers, many of whom revel in finding les mots justes, ease be damned. Follow Friday is fundamentally about providing positive feedback, and G215 taught me that feedback is more meaningful when it's specific.
So without further ado...
My first #FFDC is @georgewenzel. George is a federal public servant from Edmonton and a very active member of the #GoC community on Twitter. One of the things I like best about George is that he often posts great links that I don't see anywhere else. The first post of George's that I retweeted was an article about prioritizing fatherhood and rejecting lifestyle inflation. He's a tech geek but he comes up with stuff like 7 High-leverage life skills they should teach in grade school and 10 Things You Should Be Able To Say Before You Die. Interesting, thought-provoking stuff that otherwise doesn't usually show up in my tweet stream, which skews fairly techie. George would also be a good "gateway" follow if you're in the GoC, new to Twitter, and interested in finding other actively engaged public servants.
I'd love for this idea to catch on, and if you think it's cool, I'd appreciate a retweet, or better yet, an #FFDC of your own. I'm planning to do more of them regardless, and any feedback would be welcome!
Friday, October 28, 2011
Sunday, May 29, 2011
on IT systems vs. people (or, too much to tweet, volume one)
I've got a thought which I can't adequately express in 140 characters, in response to a couple of tweets I just read:
@thomkearney: IMO we should spend less on IT systems per se and more on making sure those systems actually contribute to org objectives
@scilib: @thomkearney we need to stop thinking IT systems can solve problems. People solve problems. $ on systems without $ on people = #fail
I look at it this way. You never want to build a solution that doesn't solve a problem, or that solves the wrong problem. Your IM/IT unit is there to serve your business, and business problems require business solutions. Any business solution has to start with a requirements analysis that depends on the subject matter experts (SMEs) in the problem area. Developing business solutions is new ground for a lot of SMEs and other business partners, ground that we have walked many times before. We are (or we should be) there to help you solve the problem effectively and efficiently, using our knowledge of IM/IT capacity, policy and regulatory considerations (particularly with respect to IM), lessons learned from past projects, and our often-overlooked knowledge of the whole business.
We shouldn't be driving "IT projects", we should be advising on and contributing to "business projects" where IM/IT is just one part of the puzzle.
You mean that's not the way everyone does it? :)
@thomkearney: IMO we should spend less on IT systems per se and more on making sure those systems actually contribute to org objectives
@scilib: @thomkearney we need to stop thinking IT systems can solve problems. People solve problems. $ on systems without $ on people = #fail
I look at it this way. You never want to build a solution that doesn't solve a problem, or that solves the wrong problem. Your IM/IT unit is there to serve your business, and business problems require business solutions. Any business solution has to start with a requirements analysis that depends on the subject matter experts (SMEs) in the problem area. Developing business solutions is new ground for a lot of SMEs and other business partners, ground that we have walked many times before. We are (or we should be) there to help you solve the problem effectively and efficiently, using our knowledge of IM/IT capacity, policy and regulatory considerations (particularly with respect to IM), lessons learned from past projects, and our often-overlooked knowledge of the whole business.
We shouldn't be driving "IT projects", we should be advising on and contributing to "business projects" where IM/IT is just one part of the puzzle.
You mean that's not the way everyone does it? :)
Subscribe to:
Posts (Atom)