Wednesday, March 31, 2010

When Is It Time To Quit?

Whilst teaching an IT architecture class in Moscow this week I was asked the above question by one of the students. The question was in relation to projects and when you should realise the project is not going to deliver and should therefore be cancelled rather than carrying on regardless. I hate using the phrase “it depends” in answer to a question like this but this was one case when that's all I could think of! However, having had a bit of time to reflect on this (on a long journey back home) here are a few thoughts that I've had since then. This is also related to my previous blog entry.
In some ways working on a software delivery project is a bit like fighting a war (though admittedly you don't usually risk losing your life). In a war you may not win every battle and may sometimes need to retreat and reconfigure however, the important thing is to focus on the strategic battles that will lead you to get to the overall objective (and win the war). In a software delivery project winning the war is to successfully deliver the system or application on time and within budget. The battles are what the architect and project manager must fight every day to address the technical and other issues which arise and must be overcome for fear of letting the project get out of control. So what are the battles, which if not won, are going to cause the project to fail and, more importantly for this topic, will lead to surrender if the cost gets too high? Here's my top five in order of importance:
  1. No, or poor, sponsorship.If there is no clear (and strong) sponsorship from the right level in the enterprise then you may as well pack up and go home immediately. Even if the project does get to the delivery stage the chances are no one will really want or need the system. The job of the sponsor is to evangelise, convince and cajole a sometimes reluctant workforce of the need for the new system and the change that it might bring about. Weak sponsors will be unable or unwilling to do this.
  2. Not having a water tight business case.If the business case for why the new system is needed is not well thought through with a clear cost-benefit analysis then there is a danger that the project could be cancelled at any time. I once worked on a project that was cancelled days before we were due to exit system test because a review of the business case revealed a flaw in the return on investment (ROI) of the new system so the client decided to pull the plug on the project rather than deliver something that would not make the cost savings that were expected of it. Painful but probably the right decision!
  3. Not engaging all stakeholders.Not identifying and engaging (i.e. talking to, convincing, schmoosing, wining and dining or whatever it takes) all the stakeholders is a bit like death by a thousand cuts. Although you will start off well, entropy will gradually set in and and things will start to fall apart. Stakeholders who should have been informed early on will learn about the project through the grapevine and will not only not support it but may actively try to kill it. They may see it as a threat or may treat it as sour grapes, “no one bothered to tell me about it so why should I support this”?
  4. Underestimating the complexity of building interfaces to legacy systems. Very few projects have the luxury of a clean sheet of paper when starting out. There is nearly always some old, creaking legacy system that needs to be interfaced with, even short-term or temporarily. In my experience one should never underestimate the complexity of these legacy system interfaces. And I don't just mean technology interfaces. Many times IT departments will see it as a threat to their existence that what starts out as an interface may ultimately lead to a complete replacement of the system that they run and manage so lovingly and will therefore do whatever they can to derail the project.
  5. Not having regular and viable releases of the system/application.Gone are the days when a project could go off for many years before delivering anything of value to the key stakeholders (or I hope they have). I cannot emphasise enough the importance of delivering something of value that users can get their hands on and starting using that will give them some business benefits. This not only shows them the value of the new application but also gives them a belief that IT can actually deliver stuff and will also get them to “buy-in” to the new system and may well have the useful side-effect that they become sales-people for the new system and will convince colleagues of its benefits.
I believe that if one or more of these issues exist on your project you should either take very serious steps to address them or consider looking for another job because there is a greater than 50% chance everything is going to get very messy and is going to end in tears or much, much worse.

Friday, March 26, 2010

Why Do Complex Systems Projects (Still) Fail?

Depending upon which academic study you read, the failure rate of complex IT projects is reported as being between 50% and 80%! I thought I'd test this against my own experiences and took a look back over my career at the number of complex systems I have worked on and how many could be counted as being successful. Clearly the first thing you need to do here is to define "complex" and also "success" so I'm defining complex as being a system with:
  • Multiple stakeholders involved.
  • Multiple systems interfaces.
  • Challenging or high risk non-functional requirements (including delivery schedule and budget).
and "success" as being:
  • Delivered on time and within budget.
  • Met the stakeholders requirements.
  • Went into production and ran for at least 12 months.
By my count I have worked on 18 projects which meet the first set of criteria and of those I reckon 8 meet the second set of criteria so can be thought of as "successful". So that's a slightly under 50% success rate! Not brilliant but within the industry average (which is of course nothing to brag about).
As you might expect there is a wealth of information out there on the reasons why IT projects fail. Top amongst these are:
  • Lack of agreed measures of success.
  • Lack of clear senior management ownership.
  • Lack of effective stakeholder management.
  • Lack of project/risk management skills.
  • Evaluation of proposals driven by price rather  business benefits.
  • Projects not broken into manageable steps.
These typical failings were highlighted in a joint British Computer Society/Royal Academy of Engineering report from 2004 called The Challenges of Complex IT Projects. That was six years ago and I wonder what has changed since then? Anecdotely I suspect not much. Certainly newspaper headlines about failed government IT projects of late (see, for example The Independent on 9th January 2010: Labour's Computer Blunders Cost £26bn) would seem to indicate we are still not very good at delivering complex systems.

The interesting thing to observe about the above list of course is that none of these problems are technical in nature, not directly anyway. Instead they are to do with governance and process (or lack thereof) and what you might term "soft" aspects of systems delivery, how we manage and understand what people want. One of the right-brain activities which we IT folk sometimes fail to exercise is "empathy". Our capacity for logical thought (i.e. left-brain activity) has gone a long way to creating the technological society we live in today. However in a world of ubiquitous information that is available at the touch of a button logic alone will no longer cut the mustard. In order to thrive we need to understand what makes our fellow humans tick and really get beneath their skin and to forge new relationships.

Happily this is not something that is easily outsourced, at least not yet! There is still something we can do as IT professionals therefore in engaging with stakeholders, understanding there wants and needs and trying to deliver systems that meet their requirements that can only be done with direct, personal contact.

Monday, March 22, 2010

V is for Versatilist

On the IT architecture class that I teach in IBM we have a thing about saying IT architects should be T-shaped. What we mean by this is shown below.
Ideally an architect should have a good range of general skills and at least one deep skill. So an architect might be a good Java programmer for example but also have a broader range of skills including project management, negotiating skills, SOA or whatever.

A Gartner research note I discovered recently called The IT Professional Outlook: Where Will We Go From Here? (from 2005) predicted that by 2011 "70 percent of leading-edge companies will seek and develop “versatilists” while deemphasizing specialists." It defines a versatilist as someone "whose numerous roles, assignments and experiences enable them to synthesize knowledge and context in ways that fuel business value". This diagram better shows the versatilist skills therefore:
 I like this because not only is the versatilist a V-shaped sort of guy, denoting a broad range of skills at a greater depth of understanding and practice, I believe these skills should be cross-discipline and yes, maybe even consist of right-brain as well as left-brain skills.

As mentioned in a previous post I believe that we architects need not only breadth, to quite a level of depth, but also a good range of skills across all disciplines if we are to come up with new ways of thinking to solve some of the wicked problems out there. Architects should therefore by V(ersatilist), not T-shaped.

Friday, March 19, 2010

Skills for Building a Smarter Planet: A Manifesto

IBM is currently doing a big advertising campaign called Smarter Planet. I recently put together a lecture for a group of university students which tried to weave together a number of themes which I am currently interested in:
Here's my manifesto:

In the 21st century IT professionals must adopt more of a systems thinking approach if they are to solve the wicked problems the world faces. If we are truly going to build a smarter planet then we need a new breed of versatilists who are able to solve these problems.

There are a number of themes here I plan to return to in future posts.

Tuesday, March 2, 2010

Architecture Refuseniks

re-fuse-nik (noun) a person who refuses to cooperate with a system or comply with a law because of a moral conviction

Some IT architecture refusenik types who may or may not have moral convictions about this sort of thing:
  1. It's all in the code - Just wants to get on with cranking out what really matters (to them) the code. Thinks that anything to do with architecture is poncey nonsense and that all architects need to "get real" and realise that code is king.
  2. It's all in the process - Can create the worlds most complex process that will deliver, er well nothing actually because no one will ever take any notice of it and just get on with the real work anyway.
  3. It's all in the clouds - Will pontificate endlessly on things like 'governance', 'process', 'reviews' but will never actually deliver anything.
  4. It's all in the model - Opposite of the coder. Thinks the system is completely describable by models and says their work is done, and the system is 'complete' once 35 (or more) UML models have been created.
  5. It's all in the plan - As long as we have a plan that is at least 8 levels deep and has every minute of every day accounted for it'll all just work at the end of it.