Why isn’t Government adopting social software?

15 01 2008

Just quickly picking up on posts from two people who I hold in regard in the matter of social networking.

From my perspective, which I’ll say right now has little to do with social networking applications, but more to do with enabling change to new concepts within the Federal Government…

I both agree and disagree with my brothers in arms Matthew Hodgson and Stephen Collins.

Now I’ve had little to do with social network software other than my own personal tinkering. What I HAVE had a lot of experience in doing is implementation of new concepts within the Federal Government.

One of my own personal trophies, was within an Australian Federal organisation of about 4,500 people, around 3,800 of them customer service officers. The organisation had no concepts of User Centric considerations from any perspective within the organisation. This extended from how processes were created, policy was developed, software designed and delivered let alone maintained, forms design and documentation development, and sadly even marketing campaigns had a lot to be desired. Fundamentally the organisation was failing to provide quality customer service to both it’s internal workers and it’s clients becaue of it. Everything else was blamed, and the dead cat of poor design was simply ignored as the development process just kept running the same way.

It took several years of very strategic proofs of concept activities, done as pet projects where I could bargain my way in but in the end, the concepts were adopted, and it got change beginning to occur. Eventually a critical mass of people became tuned to the concepts, and that was the catalyst it needed to keep on going under it’s own steam.

The story there is the same in my mind, when it comes to instilling that sort of ‘new technology’ concept within the Federal Government. I’m yet to come across someone in the Government who genuinely doesn’t want to do things better, or to make better products. I have come across many people who have been beaten by the ‘system’ and fallen victim to the “I can’t change things” attitude.

The key point for achieving success in getting new concepts in place really falls to a few things in my experience:

1. Not everyone, in fact most people within Government get caught or have been caught out ‘prematurely’ adopting new technology, and therefore have developed a fear based resistance to anything new. This can be overcome, if you as the instigator of the change, can indeed PROVE that what you are suggesting is of worth of some kind. For government, this must be tangible and measurable, so it can withstand the battering it will get from the accountability police.

2. Proof is not what YOU as the instigator think is a good thing, it’s what THEY as the recipient think is a good thing. Things like social networking do have value, and do have many non or hard to measure benefits. But again, to beat the risk beast, you have to provide evidence that the concepts deliver against THEIR values. Sadly “this is the coolest thing on the web right now and is going to provide amazing networking options” simply doesn’t cut it with the accountants.

3. Return on investment. Government is held accountable for every cent it spends. End of story. Therefore the people involved do in my experience make significant effort to ensure that they spend well. Failure is acceptable, but if the risk of failure is increased due to unmeasurable benefits at the end of the day, you won’t find a buyer.

So how do you get around this stuff?

Well to make a long story short, if you have an idea and want to get it in play;

Firstly, remember you are working in or talking to a large organisation. Change takes time, and is not easy. So be “patient, persistent, and positive while maintaining perseverance”. (Thanks Pat)

Secondly,  figure out what is of value to both the person you are talking to, and the organisation on the whole. Your solution has to map to those values, not yours. If you are finding yourself making up values that align to your solution, you may be doing this the wrong way around.

Thirdly, look for opportunities to demonstrate in a controlled and risk free or contained environment what you are thinking. Pictures speak a thousand words… active prototypes being used by real people speak a heck of a lot more.

Fourthly, and this is critical. Figure out how to measure the performance of the idea both for now and over time, and then actually measure or concept clearly in the right language (in terms of values discussed above). If you cannot measure and justify the value of doing something, it’ll never happen, or it’ll get ridiculed and no one will do it.

It’s never easy, and people in my experience can get short sighted in terms of seeing long term benefits of many things. Years of beatings over ‘cowboy applications’ and ‘poor decisions’ can do that to a person, even me. To get a concept over the line, at least to proof of concept stage (which is about as far as you’ll need to get in many cases) you need to be able to prove it’s value, in the same terms as those you are pitching to.

Hold a positive view of the Government, there are many things that can be done better, but without a doubt, there are many things they could do far far worse too.

Please send hate mail to benwintergilesatgmaildotcom



Design Authority – Part two

21 11 2007

Using the Design Authority concept in a large multi team agile environment.

Your Design is AUTHORISED!!!I was speaking with a colleague not long ago. He was asking me about using agile in a large team (50 plus developers, testers and designers), and the kinds of

The challenges as we saw them were;

  • That the software that the floor produced all serviced an internal client (i.e. the organisation).
  • That development efficiency was anecdotally noted as being not where it was desired.
  • That development consistency was also anecdotally not where it was desired.
  • That because of the changing priorities, consistency was a real issue, both in the visual, experience and technical areas, affecting the perceptions of quality, reliability and repeatability.

So I spoke with him about how he could firstly consider using agile methods to enable flexibility in his teams, so they could be configured against the outcomes required of them by the clients. We discussed the use of a configuration manager role, which would effectively marshal those team configurations so that the teams were created and disbanded in an efficient manner. We also discussed how he could still use a predominantly linear management technique to run the floor from an administrative perspective, thus supporting regimented accounting and reporting responsibilities.

Lastly we discussed how he could use a ‘Design Authority Cluster’ to cover off the following key areas:

  • Visual and interaction design
  • Business modeling design
  • Technical or architectural design

The versatility of the Design Authority role is such that the key concepts of having a dedicated role to maintain authority and provide that ‘single point of truth’, can easily be carried over consistently to pretty much any discipline. The only example where I can’t see it being applied, is in Project Management where a Centre of Excellence or PMO model is probably more appropriate.

Obviously the key points in actually considering these roles are:

  • Actual benefits of consistency of approach
  • Holistically as a whole does the development floor required to produce visually and technically consistent products?
  • How many people will be needed to fulfil the role of the Design Authority, and will they be full time or part time or just plain over-time!?
  • What is the cost of change to the behaviours and activities for development, planning, testing, release management and so forth to instill this new set of roles?
  • Is it a single point of truth that’s needed or an expertise Centre of Excellence. (hint; one is about guidance and accountability, the other is about capability development and provision, and you may indeed need both.)

In large organsiations, predictability is a big thing. This is because it serves the accountability requirements which is a big deal, particularly in organiations that have public obligations or responsibility to shareholders.

The Design Authority role, engineered and embedded well into an environment can go a long way to supporting those needs.

What if managers thought like designers?

28 10 2006

I was reading this fantastic article the other day from a mag I frequently peruse.

Its called ‘BOSS’ by AFR, but what i read is the actual printed version.

Weird as it is, I actually love flicking through magazines rather than reading things online. (he says bashing keys into a blog.) It’s a tactile thing.

Anyway. I’ve always had this big beef working in the Australian Government. It’s usually about how strategic initiatives are arrived at.

The article I was reading was titled similarly to the title for this post. What the article discussed was the authors view on the same beef, and he drew some very elegant synergies between strategic design and many other design specific behavioural patterns.

The catch line for the article was “What if we tried to think the way designers do? here are 10 things that would happen if we used the design metaphor for planning.”

Probably the best way to get across what I’m thinking here will be to pull some quotes from it.

“We all care about strategy, because we want the future to be different from the present. But powerful futures are rarely discovered primarily through analytics….This doesn’t deny analysis an important role, but it does subordinate analysis to the process of invention”

“Leaders must …persuade others of the compelling wisdom and superiority of the story they have chosen. They must, in fact, make the story seductive; in selling their strategy, they must, to put it bluntly, treat employees like lovers instead of prostitutes.”

“Persuading others to share your vision works best when you issue an invitation instead of a command.”

from the chapter titled The value of simplicity

“Think of an object you love. Chances are that it is complex enough to perform its function well, but no more complex than it needs to be. In other words it’s an elegant solution.

No design is a better exemplar of simplicity and elegance than the little black dress, the LBD….the LBD goes beyond mere functionality to achieve elegance. it lacks nothing essential and contains nothing extraneous. what if we used the LB as a model for business strategy?”

From Aiming for inspiration

“one of the saddest facts about the state of businesss design is the extent to which we settle for mediocrity”

“Design teaches us about the value of including multiple perspectives”

“In business we tend to start strategic conversations with constraints.”

OK OK enough.

There’s a heap more, but those stuck out the most to me. At this point in time anyway. (midnight… yet again.)

The last one I’ll discuss here, it’s highly relevant to my thought at the beginning of this post.

I’ve sat through heaps of strategic direction meetings / workshops / love ins and so on. Many people have.

Often they start off with a bit of an S.W.O.T. Strengths, Weaknesses, Opportunities and Threats analysis.

Terrific stuff.

If you have a clue of what goals you are trying to hit. Otherwise it’s a pretty pointless exercise. How can you provide any relevance context for what you come up with under each of those headings without an actual strategic goal in mind?

If my strengths that I come up with are that I’ve got access to pen and paper, but after I’ve finished the SWOT, I figure out that my strategic goal is to cook dinner, where does my time spent figuring out that I have a pen and paper become well utilised? Would I have answered different strengths if I knew that my goal was to cook dinner?

Continuing, I’ve had heaps of ‘strategic’ conversations that revolved around actions.

“Ben I want you to come up with some strategic initiatives for us that further our capability in web service delivery.”

I wrote a strategic discussion paper for my senior executive once (at a previous department) and it was highly innefective. It discussed what I envisoned for the relationship to effort spent on maintenance vs the effort spent on innovation and improvement and the benefits of various weighting between the two actors.

The feedback I got back was that it was too conceptual, and had no information on implementation or constraints of the environment (budgets, technology and so on).

If I was writing a project management plan then I would have included that detail, becuase that detail is relevant to an activity that is drilled out from having a goal. (Rule 1, get requirement before you write action plan.)

I was writing a strategic discussion paper, ignorant of constraints, ignorant of how to do discussions. Of course, no one was able to work that way, it simply was not how they worked.

What I could have done better though, was frame what I was writing, what purpose it served and how it would benefit our planning.

I should have also made clear what I was NOT doing, and ensure that each person who I was seeking information from was involved in my pre thoughts so that through the virtue of the collaboration in that stage, they would be better placed to input in the way which I needed.

It’s important to work with your team, managers, peers. As a designer I would have done this intuitively, as a manager I didn’t, even though I was thinking like a designer with a clean slate and fresh crayons.

It’s also important to remember the rule, get your requirements first. What the hell are you doing. Then figure out how.

Design first, then figure out how to cut the code.