What to do when insanity reigns. CYA for a reason

Recently I've had one of those experiences where you just have to stand back and think "Either I'm insane or they are". Reviewing the facts its pretty clear that the insanity is on the other side. Slightly worse than that the decision that is about to be made is actually tacitly admitting that its an insane decision.

This is when you need to implement a real CYA policy. CYA is Cover Your Arse this isn't the bad old EA CYA approach, its not even about clear documentation. This is about making sure when the shit inevitably fan that people don't turn round and say "why didn't you say" but also making sure that they don't say "its your fault because you didn't support it".

So the line here on your programme is simple, you know its going to fail, you have to support it through the failure, but when it goes tits up you need to make sure that your well reasoned arguments into the clinically insane decision are well versed.

Stage 1: Store ALL the documents that went into the decision

Stage 2: Write an email saying that you respect the decision and will of course support the approach, but you feel it doesn't address some of the issues that you previously raised

When this email is ignored that is fine, the people making the decision clearly know its insane but have decided that right now insanity is a valid defense. If they reply with "We think it does address those problems" then again don't reply.

Stage 3: Write down a list of the things that are going to go horribly wrong. Get them flagged in the risk register. You don't have a risk register.... holy crap you need more help than I can ever offer, get one in a hurry

Stage 4: It now becomes the PMs job to track against the risks, if you are the PM then make sure you got Amber early, not Red as you will be "obstructive" but go Amber with your concerns. The worst thing in the world is the project that flicks from Green to Red with you saying "told you so".

Stage 5: Its going down hill, your risk report looks like the dance floor in Saturday Night Fever and people have forgotten what colour green actually is. Now is the time to start pushing "resolutions" you really want to be the person who pulls it from the fire, this will involve however Napalming lots of the people who screwed up, you do not want a problem child responsible for clean up as that just means that it will go more wrong.

Stage 6: You are responsible for clean up. The key phrase here is "Drawing a line under what happened before" this means you are going to ignore any previous decisions and base your judgement on what goes forward is what you want. Its the same line as when a failure is put in charge, the difference here is you will be firing people.

Stage 7: Remember that people screwed up against advice. Those people need to find other place to screw up, unless they are in a desperate career saving type place, then they are your perfect allies. Think of reformed smokers or born again Christians... but with a pay cheque.

Stage 8: Do an Obama. The smartest thing Obama has done so far is declare everything screwed. Don't be nice, be ruthless. If there are six months to go live but it will never happen blame it on the prior administration. Then work out what is achievable.

Stage 9: Plan to an end. Don't get caught in fire-fighting, break the current project and start a new plan for a real end game.

Stage 10: Deliver to live. There is nothing that will help you more than meeting the expectations you set in Stages 8 and 9. This makes you a rock star and this gives you the future right to say "this is wrong".

Insanity and stupidity are horrible things, but don't try and ignore them. The worst things I've ever seen are where bright people have dug stupid people out of holes without making that visible. I've seen some really dumb people in roles they couldn't handle as a result and some smart people burnt out because of it.

The Risk Log is your friend. Do your job, do your best. But this isn't the navy. Over throwing the stupid captain is fine, as long as the number back you up.

Technorati Tags: SOA, Service Architecture

User Adoption matters

One of the most annoying things in the WWW and most especially the Web 2.0 world is the Field of Dreams mentality of "build it and they will come". With package projects and business services this is the resort of two groups of people.

1. People who think the technology is the only thing
2. People who are scared of users

Sometimes people fall into both of these groups but the underlying principle is always the same. The technology is enough, its enough to "let people know" and you will then "build a community" which will make it all successful. The problem is that while there are successful internet businesses that were created in part by this approach they also had a couple of other things

1. Marketing
2. A user population the size of the internet

If you are aiming at the mass consumer market on the web then it might be enough to launch it and do some marketing, if however you are doing this internally to your organisation then quite simply it isn't enough.

So how do you drive user adoption? Well the first thing is to find out why users might not use what ever you are proposing. Be negative, get the worst things out there and then one by one mitigate those risks. To do this you've of course got to identify your users and be realistic about them. If you are doing a bug tracking system or a service for fraud analysis its highly unlikely that everyone in the company is going to use it, so set your objectives realistically and see why your user community might not switch.

Next up think about how you are going to market it to the users, yes that's right market it. Again its not enough just to lob an article on your intranet, think about how you are going to communicate what is coming before it is there. Create a comms plan and work out what you are going to tell them when. Maybe even create an internal buzz campaign to make people interested.

Next up look at how you transition users to your system gradually (if you can). If it is a green field system then this is easier as you don't have the data migration challenge. The point of a gradual migration is to start building a reputation for success that can then be used to go after the more challenging groups. If you have to go big bang then make sure it works on day 1. If this means delaying the launch a couple of weeks then try and do that because if you bugger up the launch day they'll remember for a long time, no matter how good it is a few weeks later (look at Heathrow T5 for an example of that).

Finally, and most importantly, don't stop on go-live day. Track usage and adoption and look at who is, and isn't, using the service/package/solution/etc go out and find out what has worked and then have a follow up campaign to get people more engaged. Keep doing this as a core part of the run for the system to make sure that the system is successful in 24 months time, not just 24 minutes after being turned on.

Technorati Tags: SOA, Service Architecture

If you get made redundant

As someone who has been made redundant twice (startups that didn't) and fired once (saying that a company would go bust in 12 months if it didn't change its approach, I was wrong.... it took 18 months) and who graduated during the last downturn I thought I'd give some advice to anyone who finds themselves in IT without a job in the next year, and a few things to do while you are in work to make sure you either keep your job or are better prepared for what ever comes next.

First off lets be clear, being made redundant sucks, its a crappy feeling and it will hit your self-esteem, so the first point is

It sucks, it sucks for everyone, its not just you

You are entitled to mope around for a bit, hell the first time I was made redundant was six months into my first job, my uni girlfriend dumped me and Wolves went out the FA Cup with a dreadful performance... trust me it sucked. The key point however is that you need to drag yourself and realise a few key points

1. No-one owes you a job - you have to go and get it
   
2. You will be competing for your next job - its not an end of year promotion round
3. Your skills need to be marketed

The first two are pretty obvious but its the later where I've seen people struggle. Your internal profile at your company that lists out your skills is completely different to the CV that your competitors for the job are putting in. Its not a question of lying its a question of putting it the right perspective for the job you are going for. If you are after a Java developer job then your CV needs to reek of Java, don't lob in the fact that you did VB for six months on a nightmare project as most Java guys will turn their nose up at that. If you are after an architect job and your last project was on time and budget... don't expect people to know that.

Its really worth spending time crafting your CV and making it something that markets yourself. When you review CVs how often do you look at page 2? How often do you look behind the first half of the first page (especially when reviewing electronically)? Well that is how most other people review as well.

The other piece that some people have to face up to as well is that maybe IT isn't he best area for them to be in. Lots of people have fallen into IT because there were lots of jobs and will struggle when it gets more competitive. Sometimes its worth taking advantage of redundancy to recognise that your career lies elsewhere.

Key things to do while you are at work is get your Google score for work up if you can. Nothing says "different" like being able to find relevant stuff to your job on Google and someone thinking "hey, this guy knows his stuff". I've had people say they are "world class" in a given subject but I've given the job to the person who the world actually knew about.

Another key thing to do at work is start profiling your work for your career. This doesn't mean turning down work it means thinking about how it best reflects what you want to do. If you are managing a team of offshore developers, but you want to be an architect, then make sure you are also doing the governance and oversight stuff.

If the worst does happen and you are made redundant make sure you don't dress like it at interviews, a new suit and shiny shoes (like when you went for your first graduate job) are a must at many companies.

Being made redundant can also open up new doors, I was lucky. My first taste of redundancy got me into Air Traffic Control which ended up with me meeting my wife in Paris. My second led to be working in Denmark which led to my third (getting fired) which led to a solution architect role that got me to where I am now. If I'd been in the same job since university then I wouldn't have done half the things I've done to date.

So start planning now because you aren't just planning for redundancy you are planning for your career, and its that focus that will make sure you aren't out of a job for long.

Being made redundant sucks but not having a plan for your career sucks even worse and is especially critical at a time like this.

Technorati Tags: SOA, Service Architecture