I ticked the wrong box

On client sites I don’t get a desk phone. I like desk phones.

In newbury Waitrose has a poor selection of sushi. In Canary Wharf there is an itsu. I like sushi.

Old news, but new for me today.

LinkedIn have released an iPhone app.  I’m a big fan and user of their app, and I think keeping up to date has just become a lot easier with this iPhone app.

http://blog.linkedin.com/2008/09/16/post-2-2/

(and if you’re interested - http://www.linkedin.com/in/hamishrickerby)

Carling has a campaign here - “probably the best beer in the world”. I found tonight they have been beaten in terms of finding marketing phrases that suck.

Companies here seem to resign themselves to positions in the marketplace that may or may not be all they can acheive. Seems to me to be wrong that a company has an attitude that being inferior is OK.

Air New Zealand has recently launched a new campaign. What makes me chuckle, and angry is the folllowing ad:

My response: If you say I can demand it during take-off and landing, why did I have to fly for around 26 hours with you people and have no on-demand service, after the flight was delayed for around 13 hours?

I guess that’s what you get when your national operator turns into a what is effectively a budget airline. Never flying Air New Zealand again.

I was sitting at a desk last week and overheard a man yelling down a phone to someone else that “People aren’t an asset. They don’t appear on a balance sheet”. I agree with that view - not because of the strict accounting definition of an asset, but because of what I believe people in companies should mean (either consciously or subconsciously) when humans are called assets.

Companies refer to humans as assets for 2 reasons. (1) To make employees feel good and (2) because of the value they create for and contribute to the business.

I believe humans are assets to companies, but they are not assets of the companies. The actual asset belongs to the individual - their time - and they trade it for money. The company gets the output of that trade, but the value of the asset remains in the power of the individual.

They won’t appear on a balance sheet, but the work they do with their time that they have swapped for money is the “asset” in the eyes of the business. That appears on the books in the form of IP, physical goods, inventions, patents, or money received for the company on-selling that time (like the work I do).

Opening hours. I want them on every physical stores, restaurants, and bars website. They do good store locators in the UK, I guess it’s because postcodes are everywhere, everyone knows them and they identify a very small area (a street, or part of a street). How come stores, when thinking about the data on their store locator, don’t include opening hours. Address and phone are always there, but when I’m going home on the train I want to know if my local stores will still be open when I get there.

Oh well, no spending at that particular store tonight.

Recent blog post from 37 signals - What you expect from clients is what you get

It’s interesting - I see exactly the same thing in organisations I’ve worked for and with (I mainly deal with very large multi-national companies).  One organisation in particular has a long history of process, and gates, and hoops, and requirements, and documentation, and review periods, and signoffs.  Those things aren’t necessarily bad, but this organisation also has a long history of burning money, and not delivering anything.

Organisations often try to become more agile, deliver more, and promote efficiency through introduction of more management, more process, more rigor.  The core of the process remains the same.  The fundamental problem doesn’t go away.  And these extra layers add overhead; time in meetings, time writing status reports, time appeasing everyone, and building consensus - which will dilute of solutions, rather than making concrete decisions and promoting original vision.

Part of my job now is to help these companies break out of this mold, advise them on how things can be done better, show them a better way.  I do expect that certain companies I work with can’t be altered, and that people won’t understand advantages to the different options out there - perhaps it’s time to change that perspective of mine - give it a shot.  The worse that can happen is that they do what they’ve always done…

The types of companies I (used to) work for and (now) consult to,  love release management.  At least their IT people do.

For those who are not in the know, check out the following 2 resources for a bit of background

• http://en.wikipedia.org/wiki/Software_release_life_cycle
• http://en.wikipedia.org/wiki/Release_Management

When companies often start out, they focus on getting IT systems enhanced as soon as possible.  A simplified, but common cycle is design (maybe), build (definitely), test (should) and deploy (definitely).  Steps in this process may be skipped when an organisation is small, and the side-effects of getting something wrong in build or deploy can be handled on-the-fly.  As companies mature and grow (in both size, application complexity, and IT landscape complexity), they often wish to have more control over the processes that manages software design, development and deployment.  As enhancements start to involve distributed application development (eg, introducing a new feature on a customer care system, that requires a service on a billing system, and have that exposed by an integration bus, and that integrated with from a web or IVR channel), the process and dependencies involved with deploying that application become more complex.

To ensure that the cross system (and often) cross department, company or country design, development, test and deploy process, companies introduce Release Management Processes.  Different application development projects are collected together, and managed from a central point - who is unimaginatively known as the Release Manager.  The release manager usually has responsibility for delivery and deployment of all the changes requried within a system, and across systems for a particular instance of deployment activities (that’s a wordy way of saying that a whole load of stuff gets developed, tested, and then deployed together).

So, to recap - early days - applications designed, developed, tested and deployed whenever people want.  More mature business - applications designed, developed, tested and deployed under a managed process, with defined implementation dates.  In principle, that sounds fine.  In fact, it sounds like a sensible way to manage development and deployment.  Software can be complex, and complexity grows as you have more systems involved, different parties, different skills, and in some extreme cases, different countries and cultures.

Business users (ie, the people paying for the development, and specifying the functionality) rarely like release management.  It’s costly.  It’s slow.  It’s inflexible.  And this is more true if the business users know a little bit about software development, and especially if it involves the web.

The web is known for being an inherently agile environment.  Web applications are usually self-contained and loosely coupled, and can be easily and quickly altered.  There are other types of applications that exist in enterprises that do not have the same inherent agility.  Customer Management Systems, Billing Systems, Banking Systems, ERP systems.  All of these systems usually have long lead time on changes, strict testing requirements, are have historically been designed and developed in a different (monolithic) manner to web systems.   The requirements on them are often different too - they often aren’t about exposing new “services” to the public, but more about internal services, bug fixes, operational fixes, or enhancements to allow new products to be offered.  However, they don’t interface with the external customer and often aren’t driven by the same requirement for agility - it’s often easier in business (for your brand, and bottom line) to deploy something that is a bit crappy internally (manual processes, double-keying data etc) if you can get the message out to the customer.

Business users want the ability to alter the messages and functions that are delivered to their customers on their terms - when they want - not bound to some (in their eyes) arbitrary release schedule.  They don’t understand why their functionality must be deployed with another, completely unrelated, system or process.  They want to get their product to market.

I feel strongly that certain types of systems fall nicely in a “release managed” category, and others fall into a “system owner” managed category.  (sidenote: I feel that for a platform that supports as much functionality as “the web” that often The System is too coarse a unit for splitting - it could be taken down to business process, journey, or user type).  For me, I believe that systems that have a requirement to be highly agile, provide a high level of flexibility (configuration/scripting, as opposed to packaging and release of compiled code), and support essentially decoupled functions and flows, should not necessarily form part of conventional release management processes.  The “release early, release often” convention can be followed on these systems.  Obviously, a business must be made aware of the risks with this approach (e.g., more defects are likely to arise), and they should also be made aware of some of the sensible processes and changes in methodology to make this approach work (e.g., agile development methodologies).  In my mind, integration and web implementations fall into this category.

Integration systems enhance the ability for each system to remain decoupled from it’s peers - and this in turn means the systems are more modular, and should be able to support development and implementation (outside of a monster sized release), even when all of the required functions are not implemented.  Integration systems can provide stubs that indicate a service is unavailable, and when each system is finally ready, then the processes can be turned on in each.  Integration systems are inherently cross application, yet system independent at once.  This paradoxical view on integration is what makes them great candidates for exclusion from release cycles - they are self contained, but support both the situations where external systems are present, as well as when they aren’t.  This level of resilience and flexibility means that they are a core enabler to allow other systems to deploy functions, and still work when the up/downstream systems they are reliant on do not exist.

I have a couple of recommendations if your organization is considering looking to migrate to a release management style approach for application development and deployment:

1. Applying release management only to systems where it makes sense to do so, will allow a business to maintain the necessary rigour required for financial, legal, regulatory, professional and moral obligations.  Release management should not be a one-size-fits-all approach.
2. Shielding systems with integration and process configuration flexibility (on/off switch for process/service enabling) will reduce the dependency of each system on it’s peers to be launched - and this in turn increases the flexibility to make changes to an individual system without them having a downstream impact, and increases the ability to more quickly make changes.
3. Applying a finer-grained design, build, test and deploy scope (i.e., not cross-system) to customer facing systems will give businesses the agility they desire to get their messages to market.  This in turn will allow businesses to try more products and services in the market, and respond to competition in a more timely manner.

I believe following an approach that ensures that your systems are shielded from changes in each other, and promotes flexibility and agility in the customer facing systems is key to delivering true value to the business in terms of both responsiveness, and reliability.

I’ve been struggling to find podcasts that I really dig. Redmonk radio lost me as a listener. I thought their early episodes (up to around 40 or so) were great. A good mix of strategy, business, and IT - in a general sense. I’m quite an enterprise focussed generalist, so that really appealed to me. However, recently they have released the RIA and IT Management podcasts, and they are not for me at all - so I unsubscribed.

I went looking last night for some new podcasts in iTunes that might appeal to me. I found a couple, but am still left unimpressed.

What I found was…

• Deloitte UK Insights - Interesting analysis from Deloitte UK - based around their recent releases of sector based 2008 predictions. I liked this, but I’d like it to be more frequent than yearly
• boagworld.com - not listened yet
• Enterprise Architecture with Jan Popkin and Enterprise Architecture: Lessons Learned - thinly veiled sales podcasts from Telelogic - authors of the Popkin System Architect tool (which I personally like as a tool, but not as much as Metis Architect)
• Manager Tools - not listened yet
• Pragmatic Programmers - not listened yet
• TelcoTalk - product reviews, US based, but features some international news. I think this has promise, but needs to leave just reporting about device press releases and features, and start to comment more on how the devices are unique in the market, their competitors, business value they create etc…
• The Web 2.0 Show - not listened yet

What I’m actually looking for is IT / Telecommunications / Enterprise / business / strategy / analysis style talking. I’m not after development podcasts (although the Ruby On Rails podcast is good, and I’m expecting PragProg, boagworld and web2.0 show to be similar), but I do enjoy the style of them - talking about new ways of working, the business value of agile methods, interviews with startups and businesses on introduction of new technology into the enterprise etc.

Does anyone know of anything that will fit the bill?

Well, last friday (29th) was my last day at Vodafone Group Services. It feels a bit weird not working there anymore, although I don’t even know if it’s really hit me. After 8+ years in the same group of companies it’s just a bit strange to be out.

I’ve got a new role at a consultancy based in London, starting with some intensive training on the 10th March. Should be very interesting to start working on the other side of the consultant/customer relationship. I’m really looking forward to it - it’ll be great to be able to interact with a wider range of companies, industries and perform a much more cross-functional role. It should be great! And finally being able to feel like I’m delivering value to people and organisations again - that will be the most rewarding part of the move (of course, I have been delivering value for the past 8 years, it’s just in the last 2 it’s been in a very different way - all advice and recommendations, rather than something tangible).

The biggest thing that I think I’m going to struggle with though is having to pay for phone calls! Spending a long time with free wireless voice and data services builds up some bad habits (from my bank balances point of view!)