Ars Technica has a fascinating inside story of how Anonymous hacked security firm HB Gary, after the security firm vaunted that it was about expose members of the group.

It is a tale of wincing humiliation for HB Gary, security experts who allowed themselves to be utterly humiliated by an attack that not only compromised their website, but led to their entire e-mail archive being published online, many of their core company servers being completely compromised and terabytes of backups deleted.

It is a genuine cautionary tale. Their folly was not merely taunting capable and motivated adversaries, but rather of not following security best practices, which as experts, they know well.

Read on…Anonymous speaks: the inside story of the HBGary hack

I am currently crunching through Steve Litt’s brilliant series of books on Troubleshooting. I am hugely into general problem solving frameworks and his Universal Troubleshooting Process (UTP) is one of my favourites.

Today, whilst clearing my backlog on Instapaper I came across this Wired.com piece on legendary design firm IDEO. They use a simply process called “Design Thinking” that they claim is at the heart of their stunning successes:

Practically speaking, the approach isn’t complicated. In stages, it goes like this: firstly, immersion, whereby the designers research the problem by plunging themselves into it – talking to the people they’re trying to help, working with them, interviewing experts. Secondly, synthesis – whereby they gather together their findings and look for patterns. Third, ideation – brainstorming solutions to the real problems identified by stage two. Then comes prototyping, making mock-ups of solutions to try out against the problem. After that comes the product. Only at the end, at the prototyping stage, are judgements made; until then, all ideas are given equal weight.

This methodology is radical in that it differs from traditional approaches to business strategy in two key ways. Whereas in many companies the concept for a new product may have already been based on, say, an idea from the marketing department with a designer later brought in to make it look pretty, design thinking places the designer at the heart of the innovation process. Secondly, the methodology gives a firm framework within which a wider team can work. It takes the cliché of the lone creative mind being struck with genius, and replaces it with a process that a whole team can follow. Creativity, therefore, isn’t a thing that magically appears, but a process you work through.

From: Reinventing British manners the Post-It way – Wired.co.uk

I can see similarities to Ken Watanabe’s simplified problem solving methodology as presented in his best-selling children’s “Problem Solving 101“

1. Understand the current situation current (Immersion)
2. Identify root cause (Sythesis)
3. Develop an effective action plan (Ideation)
4. Execute until solved, making modifications as necessary (Prototyping)

From: http://www.problemsolvingtoolbox.com/

You can also see similarities between IDEO’s framework and Dan Roam’s framework for proble  solving through visual thinking as outlined in “The Back of the Napkin: Solving Problems and Selling Ideas with Pictures“. In the book Roam explores a four stage process for solving any problem with visual thinking:

1. Look (Immerse/ Understand)
2. See (sythesis / Identify patters / root cause)
3. Imagine (Ideation / Plan)
4. Show (Prototype / Execute)

How do these map to the Universal Troubleshooting Process (UTP)?

The UTP shares the core troubleshooting steps with the other three (3, 4,6,7 and 8), but it has some seemingly anachronous and superfluous steps (1,2,5,9 and 10). I say “seemingly” because experience has taught me that the Universal Troubleshooting Process steps are all necessary and in the right order.

It is aimed more at professional, routine troubleshooters and as such addresses the important psychological factors and habits that contribute to long-term effectiveness.

I cannot do this process justice in a few lines, but here is summary:

1. Prepare - This is about having the right attitude and mindset for troubleshooting as well as the required tools, skills and information. For professional troubleshooters (like Technical Support agents) attitude is one of the most important elements in their professional quality and success.
2. Make damage control plan – This is iatrogenic prevention i.e. do not make things worse. If forces you to think of consequences before trying pot luck fixes.
3. Get a complete and accurate symptom description - Here the UTP shares a step with the first principle of the other three (i.e. Look / Immerse/ Understand). In the UTP thi9s is usually achieved by creating a simple block diagram off the problem system so as to understand elements and relationships.
4. Reproduce the symptom - This is part of fully understanding and verifying the current situation. You verify the symptoms and measure them.
5. Do the appropriate corrective maintenance - This step is again targeted at professional troubleshooters. So many problems are caused by bad maintenance and fixed by routine maintenance, that often it is worth running the standard best practice maintenance procedures over the system and seeing of that fixes the issue.
6. Narrow it down to the root cause - This is the core step. Often it is a process in itself as you look from problem patterns, isolate elements of the system and systematically disqualify them as candidates for root cause. Eventually you generate a most likely root cause hypothesis and proceed to step 7.
7. Repair or replace the defective component - Here you generate a plan to test the hypothesis by fixing, replacing or implementing a work-around for the root cause.
8. Test - You now apply your fix and test to ensure the problem is indeed solved. 
9. Take pride in your solution – This is another psychologically important steps to help prevent burn-out and boost morale.
10. Prevent future occurrence of this problem – This is simple operational best practice. You learn from your problems, document your solutions and new knowledge, you modify systems and procedures to ensure the problem does not reoccur, or you can respond quickly and effectively.

This universal troubleshooting procedure has been a vital tool for my team and I in beating some extremely tough problems, sometimes involving desperate customers begging us to fix badly broken massively complex undocumented systems and us successfully finding and fixing the root cause problems in 24 hours where the system designers could not succeed for months.

I also heartily recommend the Dan Roam and Ken Watanabe books referred to above. They are both brilliant and accessible.

Master consultant and all round business genius Gerald Wienberg has sorted the best of Jerry Weinberg’s (no relation) “50 things to improve business”:

2. back up everything

4. Rule: do nothing, revised with 3 caveats: a) don’t do it if there’s someone that can do it better; b) don’t do it if there’s someone that can do it adequately; c) if it makes me really happy, do it anyway; d) if someone can do it 85% as well as I do, let them do it; e) anything not worth doing is not worth doing right; f) if in doubt charge for sales trips

6. make them pay something, with their time, their money — if they don’t pay for it they don’t value it

8. if it’s not on paper, don’t do it

9. listen to what other people are telling you

10. don’t communicate to somebody, but communicate with somebody

11. always have an exit strategy

12. make them feel like your client has a part in the final outcome; make sure they have their fingerprints on it

13. listen for what they’re not saying

14. listen to the “music”, body language, intonation

15. always be ready to sell your product

16. if you find yourself reluctant to sell your product, there’s something wrong with it

17. any successful services company has some fixed priced product to sell

18. given them entry points that they can buy

19. recurring revenue model, e.g. via contract maintenance plans, or follow-through

20. have a follow-through clause in contract so you can know how you’re doing

21. charge more money if they don’t want you to come back after some time, e.g. 3 months

22. if you just build it they probably won’t come

23. manage expectations, book: Managing Expectations, by Naomi Karten

24. Time spent in reconnaissance is time well spent

25. You can observe a whole lot just by watching (Yogi Berra)

26. Go hard or go home; fully commit all resources needed, or kill it mercilessly

27. Commit enough to learn what you have to learn to find out whether it’s worth pursuing or killing

28. People who work in an Agile/iterative way often fail to do the discovery

29. Ideas by themselves aren’t as valuable as you think they are; don’t guard them too closely

30. Nothing is as dangerous as an idea, esp. if it’s the only idea you have

31. Never rest on your past successes; there is always something more you could be doing; if you’re not learning, you’re dead

32. Sharing competitive advantages brings 10-fold rewards; give it away, it comes back

33. Being able to say ‘no’

34. Research clients as if you were hiring them

35. Recognize that every client is unique.

36. You don’t have to remember everything to succeed.

37. It’s ok to let a client go if it’s not the right fit; you should organize your business such that it’s ok to let a client go, i.e. don’t be over-dependent on any single client

38. The best way to build a business is to stay in business; stay around, build a reputation and credibility

39. Actively solicit feedback from clients; actively extract the feedback, e.g. watch the audience

40. Don’t be alone in your work; have someone to talk to

41. Honor the people who are your sounding board and bring feedback, e.g. life partners, friends, …

42. Anything that’s annoying or repetitive should be automated or stopped

43. Track your budget & cost every month

44. Don’t make mistakes over your budget or your cost.

45. Don’t spend your money on office decoration, esp. if your clients don’t come to your office

46. Always try someone out before you hire them

47. Don’t fall for the big lies: “we’re just about to get funding” “our data is clean” “your check is in the mail” “we’re going to sign it next month, just keep working” “don’t worry about the contract” …

48. Preventing any one of these mistakes will pay for this conference

49. Double your reading speed

50. Choose not to read a lot; don’t read stuff that’s not worth reading

51. Stay off Facebook & Twitter

52. Sometimes you can save money by spending money; and sometimes the reverse. Learn to tell the difference

via 50 more ways to improve your business.

Also see the original 50 ways to improve your business .

There is a good article in Projects@Work about what to do when a risk you chose not to mitigate materialises, and how to handle it.

From Projects@Work – A Guy Named Murphy:

Widely accepted risk management theory says that doing nothing is an appropriate response to some risks. But what happens on a project when you’ve done no risk mitigation and then the risk materializes?

“When you are running a large project and have already passed the project planning phase, the project manager’s core role is managing the performance of people, meeting plan expectations, and assessing the threats to project success,” say Tim Pare and John Kirkwood, managing consultants at PA Consulting Group. “From a practical point of view, there are always a ton of these threats and there is seldom time available to spend on things that have a low likelihood. It is probably more often the case that risk mitigation activities are curtailed, or not enacted at all, rather than pursued for too long.”

Lisa Anderson, president of LMA Consulting Group, also believes that there’s a natural stop to risk management activity. “I’ve led project teams, it is common to have unexpected events and challenges arise. [But] once you have established an effective project team and defined a critical path, stop risk mitigation activity, as it will be a waste of time and resources,” she says.

In fact, these unexpected events are par for the course in project management. “If you have been a PM for any length of time you have run into problems on your projects — especially if they are IT or technology related,” says Bruce McGraw, CEO of Cognitive Technologies, a professional services firm delivering project and program management services, products and PMO tool implementation to commercial and government clients. “In fact, we blame these problems on a guy named ‘Murphy’ which has led to the whole field of risk management, where we try to think of all the things that can go wrong before a project starts. The first step in addressing the worst case is to determine that you have a problem. That is not always as simple as it seems.”

Johanna Rothman, author of Manage It! Your Guide to Modern, Pragmatic Project Management, agrees. As a consultant, she was brought in to help resolve a crisis on a development project where nothing was working and everything had been tried. “[The] project was slipping a week every week,” Rothman says. “The PM had no idea what to do. The project team had no idea. They were trying to integrate a piece of hardware and software, and it wasn’t working.”

Rothman established that the problem they thought they had — no more options — wasn’t actually the real problem. “The developers had been saying ‘We’ve tried everything’ but they hadn’t. The testers were saying ‘We’ve tested everything’ but they hadn’t. I had them build a matrix of everything they’d tried and the results they’d gotten. Once they realized there were holes in the matrix where things hadn’t been tried, they knew how long those tasks would take and we would have another chance to reassess after those tasks were done.”

From the Economist’s Guru section article on Elliott Jaques:

Jaques (1917-2003) decided that jobs could be defined in terms of their time horizon. For example, a director of marketing might be worried about marketing campaigns for next year, while a salesman on the road is worried about reaching his targets for the week. Jaques also believed that people had a “boss” and a “real boss”. The boss was the person to whom they were nominally responsible, while the real boss was the person to whom they turned to get decisions crucial to the continuation of their work.

The sales manager in charge of a salesforce would not have a longer time horizon than the people in his salesforce. So when a salesman wanted a decision on something affecting his ability to deliver to his clients, he would go over the head of the sales manager for that decision. Jaques called this “level skipping”, and identified it as a dangerous pathology in any hierarchy.

He then looked at the time horizons of people, their bosses and their real bosses, and he found that people with a time horizon of less than three months treated those with a horizon of 3–12 months as their real bosses, and so on up the scale. He identified seven different time horizons, from three months to 20 years, and argued that organisations, no matter how complex, should have seven levels of hierarchy, each corresponding to a different managerial time horizon. Jaques’s theory has come to be known as RO (requisite organisation).

This reminds me of the Tolstoy quotation from C.S. Lewis’s “The Inner Ring”:

“When Boris entered the room, Prince Andrey was listening to an old general, wearing his decorations, who was reporting something to Prince Andrey, with an expression of soldierly servility on his purple face. “Alright. Please wait!” he said to the general, speaking in Russian with the French accent, which he used when he spoke with contempt. The moment he noticed Boris he stopped listening to the general who trotted imploringly after him and begged to be heard, while Prince Andrey turned to Boris with a cheerful smile and a nod of the head. Boris now clearly understood-what he had already guessed-that side by side with the system of discipline and subordination which were laid down in the Army Regulations, there existed a different and a more real system-the system which compelled a tightly laced general with a purple face to wait respectfully for his turn while a mere captain like Prince Andrey chatted with a mere second lieutenant like Boris, Boris decided at once that he would be guided not by the official system but by this other unwritten system.”

A new working paper from the Harvard Business School debunks the long-standing myth that setting goals promotes improved performance and employee motivation.

From the summary:

For decades, goal setting has been promoted as a halcyon pill for improving employee motivation and performance in organizations. Advocates of goal setting argue that for goals to be successful, they should be specific and challenging, and countless studies find that specific, challenging goals motivate performance far better than “do your best” exhortations. The authors of this article, however, argue that it is often these same characteristics of goals that cause them to “go wild.” Key concepts include:

• The harmful side effects of goal setting are far more serious and systematic than prior work has acknowledged.
• Goal setting harms organizations in systematic and predictable ways.
• The use of goal setting can degrade employee performance, shift focus away from important but non-specified goals, harm interpersonal relationships, corrode organizational culture, and motivate risky and unethical behaviors.
• In many situations, the damaging effects of goal setting outweigh its benefits.
• Managers should ask specific questions to ascertain whether the harmful effects of goal setting outweigh the potential benefits.

Read on here: http://hbswk.hbs.edu/item/6114.html

In an recent article for Future Changes, Bill Arconati – Confluence Product Marketing Manager at Atlassian – argues that Enterprise Wikis are much better than contemporary e-mail culture , creating what he calls an opt-in culture:

“In an opt-in culture, employees contribute to conversations where they gain the most satisfaction and have the largest impact. They look beyond their tiny fiefdoms and seek out situations where they can add value and offer their expertise.” – Wikis, “Opt-in Culture” Contribute to a Healthy Organization

Her contrast opt-in culture with its opposite – the opt-out e-mail culture – that completely dominates the business world:

Perhaps the best way to understand and appreciate an opt-in culture is by contrasting it to an opt-OUT culture like email. Have you ever left work at the end of the day and thought to yourself, “All I did today was respond to emails?” In email-based companies you frequently spend your days knocking down emails like a bad game of Whac-A-Mole.

The main problem with email is that you have little control over what lands in your inbox. Most emails are either (i) people asking you to do something or (ii) conversations between two or three people (frequently executives) with a dozen innocent bystanders in the cc line. The only way to shut out the noise in an email culture is to opt-out and say “Take me off this thread!”

Even if you successfully filter out mail you don’t want, there’s little you can do about the email you’re NOT receiving. Important management decisions are made every day on your corporate email server without the input of your company’s most interested and qualified employees. For example, I’m in marketing but I’ve worked in product development and corporate finance in past roles. I’d like to think I have something to offer to conversations about product development and financial analysis even though they’re technically outside of my designated role. But in an email culture, I wouldn’t be cc’d on those emails and hence not part of the conversation simply because I’m a marketing guy. Much of the knowledge and experience that I bring to the organization would be completely wasted in an email-based culture.

He is right, there is terrible waste in the fire-and-forget e-mail culture, with massive numbers of hours lost to simply cheking that mails can be safely discarded.

Bill ends by explaining how to use wiki’s to develop an opt-in culture:

1. Communities of interest – deploy a wiki that lets you create a separate space for every area of interest.
2. Comments and Discussions – deploy a wiki where conversations can naturally evolve out of content.
3. Subscriptions – deploy a wiki where users can opt-in to conversations happening in the wiki either by subscribing via email or via RSS. With email and RSS notifications, users can actually monitor and participate in conversations happening all across the company.
4. Openness – Consider a wiki where openness is the default.

Read on: http://www.ikiw.org/2009/03/04/wikis-opt-in-culture-contribute-to-a-healthy-organization/

Jason Scott savages Cloud Computing in an entertaining if an little bit angry rant/manifesto

ASCII by Jason Scott / FUCK THE CLOUD

Taylor Davidson has put together a lovely list of “25 Secrets Learned through Failure“. It is definitely worth a read. Here is the intro…

I started to write about the keys of success for entrepreneurs and startups, but as I wrote I realized that while I’ve seen companies fail, projects flounder and ideas die, I’ve had little first-hand experience with success. My ideas on the keys to success remain just that: ideas.

But I’ve learned a lot through failure. Close observation and unfortunate first-hand personal experiences have taught me many lessons about why companies fail.

Let’s be clear: this is intended to be an assessment of the 25 most important lessons I have learned through failure, not a comprehensive analysis of all the reasons entrepreneurs and startups fail (and trust me, this is the shortened version: I’ve learned more than 25).

The first sixteen primarily address strategic and operational issues while the last nine deal more with management and organizational issues. Since I believe the three most important factors for any company are people, product and market, I’m not sure that I’ve come up with the “appropriate” ratio of ways to fail, but perhaps you’ll have ideas that will bring the ratio more in line. I’m looking forward to hearing about the secrets you’ve learned through failure.

Here are a few of my faves…

1. Dither, dither, dither; plan, plan, plan.
Instead: Fail fast. Fire, aim, repeat.6. Focus on the long-term.
Instead: Focus on the short-term.

7. Build prototypes, mockups and samples.
Instead: Start building in a format and medium as close to the finished product as possible, and iterate, iterate, iterate.

9. Give customers everything they want.
Instead: Listen to customers, then throw (almost) all of it away.

10. “New, New, New!”
Instead: F*** new. What’s different? What’s better?

15. “We can build a successful business by capturing just X% of the market.”
Instead: Sell to one customer. Repeat. Repeat. Repeat.

22. Meet to discuss.
Instead: Meet to decide.

Read on here.

Geek.com have updated their classic tutorial on how to set up your own PBX (Private Branch Exchange) or switchboard phone system.

This article demonstrates how easy it is to roll your own PBX in about an hour or two. Provided that the instructions herein are followed carefully, you too should be able to set up your very own switchboard/PBX system and all for the cost of the target hardware of your choice.

[From Feature: How to build and customize your own PBX with Asterisk - UPDATED | Geek.com]

We have just fully virtualized our office using PBX in a Flash . Customers call local numbers and are routed invisibly to wherever our operation is awake at that time. We have every feature one would expect from a top of the range Switchboard system, but it is completely free.

We use Gradwell.com and Voipfone.co.uk as VoIP trunking providers that terminate calls to the PSTN (allow us to call and receive calls form ordinary phones).

Everything is hosted on one of our tiny and inexpensive Virtual Grid Servers (VGS) .