Showing posts with label consulting. Show all posts
Showing posts with label consulting. Show all posts

Tuesday, November 25, 2008

Business Survival needs good IT People

What a ridiculous proposition. How could embracing web 2.0 and having a good IT strategy be important for business survival in a recession/depression? Or even anywhere near the top of the list. This sounds like spending money.

Well, yes it is spending money, just like wages. One lesson that is common from all our previous experiences is that strategic shortcomings are punished hard in downturns. When we learn lessons from the Great Depression we have to make sure we adjust for a world that really is different (telephones, TV, internet, for example). How could IT and Web 2.0 be important though, for a washing machine manufacturer for example? How can a web site and good IT affect their sales? Surely only Geek-based businesses have to worry.

Our washing machine broke down two days ago and we rang our trusted repair technician. He won't repair that brand any more. I asked him why not? Reply "their website is crap". In what way? "well, to give you an example, of the last 7 orders we put through it for spare parts, 5 were wrong. It wastes our time, which costs us money, and the customers get annoyed because of the delays and blame us, so we don't touch them anymore". His recommended brand? - Bosch or Miele. Our replacement brand - not the one we have now, even though I was happy with it. Sure it can be fixed by the outfit in town that doesn't care what they fix, but the point is that they don't care. People that don't care usually cost a lot more in the end. I'm not going to drill down to the cause - it's probably a poorly implemented parts catalogue. What I am interested in is that I am lost as a customer through a poor website, and the Company won't even know it has happened. It's not the customer-facing part of the site - it is the maintenance person part. There is no obvious way to measure the loss of my custom, nor how many others are lost as well.

What has fundamentally changed is the way customers interact with businesses and each other. There's good news in this because transforming technology gives us future growth. There's bad news in this because managing by, and measuring the wrong things will kill a business stone dead. The toxic effects of bad measurement have been discussed before. It's affecting the new crop of IT people - the very people that will save their organisations - but the organisations don't even know it.



Business (including Government) is still slow to recognise the importance of web 2.0 to future survival, and to identify their own people that can help them. I recently responded to a Twitter stream from a 'thought leader' - an influential networker, who needed to explain what he does in 'value adding' to his own IT management.


Yeah, how can IT or even HR (who should be making the call on productivity) measure the efficiency and quality of work I perform ..
.. that I've leveraged through my professional social networks such as Twitter, LinkedIn etc?


YOU are 'peer reviewed' as worth following on a daily basis by 573 people (twitter followers) - the peer review bit is key
HR does not measure quality. So give them stats. Training.gov.au has nn unique hits and 17 committed (daily) followers from zero [in just a few days]


So why aren't we asking these questions? These are the very people that will lead our organisations to better efficency and effectiveness. At the very least they will see us through to survival. What do you know of your people -
  • who blogs,
  • how are their blogs rated by peers,
  • who Twitters,
  • how many followers do they have,
  • how many retweets,
  • who is monitoring the twitterspace for mentions of your organisation, service or product?

Right now is the time to update your business and IT strategies for what will be the toughest year we will have ever faced in our working lifetime. Are you ready? Are you measuring the behaviours you need to have a future?

Tuesday, May 20, 2008

Why should I Deal with You?

Staying with the theme of motivating the workforce and keeping your company in business ....


Why Should I Do Business with You? - Harvard Business Online's Bill Taylor
This consultant, whose firm has conducted thousands of “mystery shops” and interviews with front-line employees at retail banks, told the gathering that during their visits, his researchers always ask bank employees a simple question: “As a customer, why should I choose your bank over the competition?” And two-thirds of the time, he said, front-line employees have no answer to that question—they simply “make something up on the fly.”

How can any business expect to outperform the competition when its own employees can’t explain—simply and convincingly— what makes them different from the competition? This question isn’t just for bankers. Gary Hamel, the influential strategy guru at the London Business School, makes the case that most companies, in most industries, suffer from a kind of tunnel vision: They chase the same opportunities that everyone else chases; they miss the same opportunities that everyone else misses.

Saturday, May 17, 2008

Agile techniques - Why User Stories

Extending the discussion of Consulting Techniques and adapting Agile, approaches, this article by Mike Cohn is still relevant today. I've included a snippet from his discussion with a meaningful example. The bottom line is that a clear story line is critical to ensuring a report is effective.


Mountain Goat Software - Advantages of User Stories for Requirements
IEEE 830–style requirements have sent many projects astray because they focus attention on a checklist of requirements rather than on the user᾿s goals. And lists of requirements don't give the reader the same overall understanding of a product that stories do. It's very difficult to read a list of requirements without automatically considering solutions in your head as you read. Carroll, for example, suggests that designers “may produce a solution for only the first few requirements they encounter.”6 For example, consider the following requirements:7

3.4) The product shall have a gasoline-powered engine.

3.5) The product shall have four wheels.

3.5.1) The product shall have a rubber tire mounted to each wheel.

3.6) The product shall have a steering wheel.

3.7) The product shall have a steel body.

By this point, I suppose images of an automobile are floating around your head. Of course, an automobile satisfies all of the requirements listed above. The one in your head may be a bright red convertible, while I might envision a blue pickup. Presumably the differences between your convertible and my pickup are covered in additional requirements statements.

But suppose that instead of writing an IEEE 830–style requirements specification, the customer told us her goals for the product:

* The product makes it easy and fast for me to mow my lawn.
* I am comfortable while using the product.

By looking at goals, we get a completely different view of the product: the customer really wants a riding lawnmower, not an automobile. These goals are not user stories, but where IEEE 830 documents are a list of requirements, stories describe a user’s goals. By focusing on the user’s goals for the new product, rather than a list of attributes of the new product, we can design a better solution to the user’s needs.