Tag Archives: booz

Do You Have What it Takes to Change Government and Create Gov 2.0?

Image courtesy of O'Reilly Conferences on Flickr

As I’ve said many times before, Government 2.0 isn’t about technology, but what that technology enables. When the TSA rolls out an initiative like the IdeaFactory, developing and implementing the technology is the easy part (disclosure: my company has supported the IdeaFactory project).  When the GSA implements the Better Buy Project, getting UserVoice up and running was probably one of the easiest tasks on the whole project.  No, when a government agency decides to use technology to try to become more transparent, participatory, and/or collaborative, the technology isn’t what’s keeping the project leads up at night.  The hardest part of all of these initiatives is figuring how to change the way the government operates.

Managing change in the government is HARD, much harder than in the private sector. Leadership and, consequently, leadership priorities are constantly changing as administrations change. Because of this, employees suffer from change fatigue (if you don’t like how your department was reorganized, wait a year and it’ll change again), middle managers don’t invest in the change themselves, and leaders all too often push forward with their own agendas and goals, current organizational culture be damned. It’s no wonder we’re still talking about how the best way to create Government 2.0 – we’ve been way too focused on the easy part of this, the technology.

But if changing the government is so difficult, then why have some government leaders succeeded in bringing effective changes while so many others have failed?

To try to answer this question, Booz Allen Hamilton teamed with Harvard University Professor of Public Management, Steven Kelman to identify the common methods—the best “leadership practices”—used by successful government executives to transform their agencies and achieve mission goals. By studying 12 federal cabinet and sub-cabinet level agencies from the administrations of former President Bill Clinton and former President George W. Bush, the study determined which organizational strategies worked best for delivering effective, meaningful change in government—and which did not.  More than 250 interviews were conducted with federal agency leaders and their employees, career executives, congressional staff, unions, media, customers, and interest groups.

So, why are some government leaders able to innovate and reinvent themselves and others stagnate?  At this year’s Gov 2.0 Summit in Washington, DC, some of the findings from this study were discussed at the “Do You Have What It Takes to Change Government?” session. If you’re responsible for a Gov 2.0 initiative, here are some of the key findings that you should keep in mind as you attempt to change government.

  • Use a collaborative strategic planning process – This isn’t going to happen via a memo or directive alone.  If you believe that your employees will become more open or collaborative because the boss said so, think again. Involve your employees in the strategic planning process. Sure, it takes a little longer, but you’ll be surprised at what you’ll learn and your employees will have some ownership in the change instead of feeling like they’re being told what to do.
  • Develop performance measures – what does success look like?  Can you explain how becoming more open and collaborative will help your agency/team/department/group/division better achieve its mission?  Ten thousand Facebook fans isn’t a goal – your goals should be tied to your organization’s goals and objectives, and your employees should be judged on their ability to achieve those goals.
  • Be proactive in building relationships with external groups – Your agency doesn’t exist in a vacuum.  Identify other groups who may be impacted, positively and negatively, and proactively go and meet with them.  Talk with them, listen to them, and involve them wherever and whenever you can.
  • Re-organize if you need to – Assess the current organization and determine if you can achieve your goals within the current structure. Are there impenetrable stovepipes? Are there too many layers of middle management? Are there personality conflicts and “turf-guarding?”  Don’t be afraid to shake things up and move people around.
  • Focus on 2-3 goals – The majority of successful leaders in the study had 2 or 3 goals that were action-oriented and quantifiable. Unsuccessful leaders typically had jargon-filled, tactical, action-based goals that described the effort, rather than the outcome. Gov 2.0 goals should be focused on an outcome – improving customer satisfaction levels or decreasing FOIA requests by making more data available online, etc.  Unsuccessful leaders typically use goals focused on an action – “implement a new knowledge management system” or “use social media more effectively.”

Here’s the full presentation as it was given at the Summit:

 

http://www.whitehouse.gov/open/innovations/IdeaFactory
Continue reading...

Dear IT Guy, Can You Actually Use the Tool You’re Creating?

Do the top developers for Google’s Android operating system use Blackberries?  Do the IT guys developing Windows 7 use Macs?  Do the folks at WordPress use Blogger to host their personal blogs?

These are purposely ridiculous questions – wouldn’t the best developers use the actual tools they’re responsible for building?  Wouldn’t they do their job more effectively if they were actually a user of the product they’re developing? Doesn’t the product have more credibility if the people behind it are believers in the product’s features?  Out of everyone, shouldn’t the development team, at least, be the biggest advocates of the very software they’re implementing?  Shouldn’t they be the ones drinking the Kool-Aid?

Unfortunately, IT departments at large companies and government agencies are too often doing the equivalent of developing Android apps at work and using the iPhone at home. Sharepoint developers implement Sharepoint, yet they don’t use it to manage the implementation. The guys installing your organization’s blogging software don’t realize that the “Add a Picture” button doesn’t work because they don’t have blogs.  The team responsible for increasing awareness of your Enterprise 2.0 platform haven’t even created profiles of themselves.

Now, take a look at the official support areas for WordPress, Telligent, MindTouch, Jive or any of the dozens of social software vendor sites.  Notice anything? The developers are often the most active members of their respective communities and they’re using their own software day after day in the course of doing their jobs. If there’s a glitch involved with posting a new comment to a forum, they’re going to be the first ones to see it, diagnose the problem and fix it.

Sadly, I’ve been seeing these situations increase with the emergence of the Enterprise 2.0 and Government 2.0 initiatives. IT departments are increasingly being asked to implement wikis, blogs, social bookmarking, video-sharing, and dozens of other varieties of collaboration software – software they may know how to code, but often have no idea how to actually use.  They’re just told to “give us a wiki” or “develop a blog for me.”  Actually using the blog or wiki isn’t a requirement.  As as I was told by one programmer a year or so ago when I recommended he start a blog to inform the rest of the community about the latest enhancements and maintenance activities,

“Every hour I spend playing around on a blog post is an hour I spend away from coding!”

Well, that was helpful – thanks! Instead of getting frustrated and ending the conversation, I should have instead elaborated on the benefits that a developer enjoys when he becomes a user instead of just a developer.

  • Higher quality product – you can identify bugs and feature improvements before they become problems for other users.
  • Increased credibility – If, as a user,  I ask how to upload my photo, guess whose response I’m going to be believe – the guy with an empty profile or the guy who’s been active on the community for the last year?
  • Increased “forgive-ability” – Look, we know that these sites will go down occasionally, especially when they’re first being developed.  We can deal with that…if we’ve been reading your blog and know that it’s down this Saturday night because you’re installing the new widget we’ve been asking for. If the site goes down and all we get is a 404 error page stating that the site is down for maintenance…again, we’re going to be less than pleased.
  • Content Seeding – Clients are always asking,  “how are we going to get people to actually work on this site and add content?”  Well, before you even launch, if your project team (including developers, community managers, comms people, etc.) actually use the site you’re building, you’ll create a solid base of content before you even start to open it up to more people.  Adding to existing content (even if it’s not related) is always easier than creating something new.
  • Common Ground – you become a member of the community instead of the guy behind the curtain making changes willy-nilly. You gain trust and respect because they know that you’re dealing with the same issues they are.  You’re struggling to access the site on your phone too.  You’re not getting the alerts you signed up for either.  You’re not able to embed videos correctly.  You go through what they go through.
  • Greater ownership in the final product – The community becomes YOUR community, not something you’re just developing for a bunch of “users.”  You become invested in it and want to make it faster, add new features, win awards, etc. because you’re a part of it.

For all you non-developers out there, would you like your IT staff to be more visible?  Would you be interested in learning more about what’s happening under the hood of your Intranet/Enterprise 2.0 platform?  What other benefits do you see to getting them more involved?

For you developers, what’s preventing you from getting this involved in the communities/platforms that you’re responsible for creating?

Continue reading...

I Started a Blog But No One Cared

 

Image Courtesy of Flickr user cogdogblog

As many of you know, here at Booz Allen, we’ve got an internal suite of social media tools available on our Intranet – hello.bah.com. While it’s garnered a lot of publicity, won awards, and really changed the way we think about virtual collaboration here, I get asked this question and others like it (e.g., why isn’t anyone asking questions? How do I get people to read the blog? Why isn’t anyone editing the wiki pages?) at least once a week.

These aren’t trivial questions – people take the time to create a blog post or add content to a wiki because of the promise of emergent collaboration. They hear stories about people getting entire white papers written by people they don’t even know because it was posted to an open wiki; they see blog posts with dozens of comments that lead to new initiatives; they read forum threads dozens of pages long with input from people across the organization and they want to realize those benefits too. Against everything they’ve learned over the years, they post some content to this open and transparent platform with the hopes that people will flock to it, adding comments, having discussions, linking to additional resources, and interacting with their information. When that collaboration and interaction doesn’t happen, they quickly get turned off and will either A) assume they did something wrong and not go back or B) believe that they’ve been sold a lot of snake oil and this social media stuff isn’t all it’s cracked up to be.

As you might imagine, neither of these conclusions bode well for the long-term health of a virtual community behind the firewall. So, what do I tell these folks when they ask me why no one is reading their forum posts, commenting on their blogs, or editing their wiki pages?  I start by sending them these eight bullets –

  • Write interesting content. You’d be surprised at some of the mind-numbingly boring stuff government consultants blog about. Realistically, out of the 20,000+ people at the firm, how many of them are really going to be interested in your jargon and acronym-filled blog post about the latest developments in IT Service Management? Write something that more than the 20 people on your team will be interested in if you’re looking to get greater engagement.
  • Email is still king. Despite all its successes to date, hello.bah.com isn’t a daily, in the workflow destination for most of our staff. They see the potential of it, and use it occasionally, but visiting the hello homepage to check out the latest blog posts and wiki changes isn’t exactly at the top of mind for most people yet. Post your blog entry, wiki content, forum thread, etc. and then send out an email with a link to it.
  • Cross-promote. Include the link to your content in your team newsletters, meeting agendas/minutes, email signatures, briefings, Yammer messages, and any other communications vehicles you use. Just because you’re the boss/team lead/project manager doesn’t mean people have automatically subscribed to everything you do and are waiting with bated breath for your next post. When our senior VP started blogging internally, we sent out a mass email with each post that included a link to the post, a short blurb on what it was about, and directions for how to subscribe for future posts. We did this for the first five posts or so until people were aware that the blog was out there.
  • The world doesn’t revolve around you. Don’t just post and then whine about people not commenting on your content. Ask yourself if you’ve gone out and commented on anyone else’s blogs. No? Then why are you surprised that no one is commenting on yours. Go find other posts and wiki pages related to your topic and engage there. Include links back to your content as “additional information you might find useful.”
  • Give people an action. Why are you posting in the first place? Do you want to get people’s opinions on some new initiative? Do you want cross-team collaboration on a white paper? Are you asking your team if they have questions about the new reorganization? Be clear about what you want from your readers.
  • Tell them what’s in it for them. Tell me what benefit I get from taking time out of my day to click over to your blog/wiki page/forum and read it. Will I get an opportunity to influence future policy? Will this be the new location where all of our meeting agendas and minutes will be kept? Is creating my profile required for my performance assessment? Will I get to get answers directly from a VP instead of some anonymous email address? Don’t just tell me that it’s there and to click the link because that’s not enough. Entice me. Whet my appetite for what I’m going to get for my time.
  • Do some internal “pitching.” I’ve had colleagues reach out to me and ask me if I’d blog about their programs on my blog. People have asked me to go out to Yammer and link back to their wiki pages. I’ve received internal emails from people pitching me on their project and asking me to “get my team to engage with their content.” This isn’t because I’m some subject matter expert, it’s because I happen to have a popular internal blog and my readers and friends tend to read what I write and click over to things I link to. Find people like me and make them aware of your content and ask them to get involved. No one wants to be the first person to respond – they want to see that other people have read it and commented on it too.  Aren’t you more likely to read a blog post that has 20 comments than one that has none?
  • Lastly, be a community manager.  When the comments on our VP’s blog all started to skew toward the “thanks for posting – great job” variety, the value of those comments went way down (our VPs don’t need any more self-esteem:).  That’s when I started to post some more contradictory/controversial comments and posts.  I wanted to model the behavior that people could/should take when participating in that online community. Other people needed to see how to interact in this new environment.
Continue reading...