Outcomes – do your projects keep their promises?

* No.6 in a series of articles I wrote in Dec 2010

Several comments on my last post about flabby project methodologies focused on “outcomes”, particluarly from the public sector. The rationale is pretty straightforward:

  • As the client, we know what we want to get out of the project (a more efficient call-centre, faster turnaround time on website changes, instant access to documents from wherever I’m working, etc.)
  • As our IT partner, you will know how best to use the technology available to achieve these outcomes.
  • Therefore we won’t prescribe how we want the systems to work, but we will prescribe what we need them to do for us. You will compete with other candidate IT partners and we’ll pick the one that on balance offers us the best value, which may not be the cheapest.

This is great – the board can focus on outcomes and not get bogged down in detail. Of course, somebody has to deal with the detail don’t they – and this falls to the project team.

Project managers tend to be task focused and they love sequences of activities that add up to completing a deliverable, and sequences of deliverables that add up to completing a project. Everybody understands nice, clear, concrete activities and deliverables, and when they are put in a Gantt chart and ticked off on a regular basis it becomes competitive and the plan seems to hold hypnotic powers over the PM, and even more so over the PMO and other assurance folk!

The great danger is that all focus shifts towards completing activities and deliverables, and away from the expected outcomes of the project. Who cares if you delivered your new call-centre system on time and within budget? What matters is whether it has given you the 20% staff reduction, or the 10% more sales, or the 15% fewer complaints …whatever was promised in order to get the project approved!

Deliverables must achieve the promised outcomes Cartoon @Giggle

Tricky eh? Project teams do need to focus on tasks and deliverables – after all there’s a deadline and budget to meet! Similarly the project board needs to maintain its own discipline of focusing on outcomes – only delving into the detail by exception.

It is the project sponsor’s job to set the context within which the project team can focus on its tasks. To be fair, most kick-off meetings do talk about the outcomes – or at least the outcomes that aren’t too sensitive. But the memory of the tub-thumping sponsor evangelising about the joy of multiskilled homeworking staff quickly fades and newcomers to the project get (at best) a look at the kickoff slides on day 1 while they are waiting for their user account to be set up.

It falls to the PM to reinforce the project context by constantly reminding the current team why they are producing the deliverables. The PM must set the focus of the project plan and the project meetings not on “go live”, but on delivering the promised outcomes.

Take a back seat at your next project progress meeting – does the dialogue show a good balance between understanding what needs to be delivered and how it contributes to the promised outcomes?

Your methodology or mine?

* No.5 in a series of articles I wrote in Dec 2010

You have a strategic project coming up…

…and you have flirted with several consultancies now to see who you might invite to the ball. Some you connect with, some you don’t, but there is this one firm that really gets where you are coming from, and you both want to take the relationship seriously.

But how to take it forward – your methodology or theirs?

What you and the consultant both really want is to build a lasting relationship with your business, but the business probably doesn’t come to your parties! After all you’ll just nag them to sign off those hefty volumes of “as is” and “to be” statements, Use Cases, user stories, whatever. Why do we make it so hard on the business? Nearly all the business managers I speak to express dismay at the size of the documents, their hard to understand structure, and the ridiculous notion that once they have signed-off the document the business world plays “statues” until the system turns up a year later …and a year out of date.

A good follow up question is “does it really matter which methodology we use, if it gets the job done?” Getting the job done means:

The project delivers the benefits that have been promised to the Board, within the time scales, budget and risk profile agreed.

Is your project methodology designed with this in mind? …is your consultant’s?

I would argue that unless you are buying a turnkey project from a consultant then you should stick with your own methodology. It is much easier for a consultant to learn your way of working than it is for your organisation to change its governance processes.

If there is huge advantage to using the consultant’s methodology then make everybody use it for this project and get agreement that your governance processes can be bent a bit to fit, as an exception.

Please bear in mind that a consultant’s methodology exists for only two purposes:

  1. It’s the nearest thing to a tangible product that consultants have, and it allows them to differentiate themselves from their competitors; and
  2. It is designed to protect the consultant and their reputation. It fundamentally is not designed with efficient delivery of your project as the #1 priority.

If the last point sounds harsh, take a look at your own methodology. The bulk of it is there to protect your organisation on one hand; and the people delivering the project on the other. Sign-off is all about protecting the people delivering the project.

Project delivery methodologies have been around since Roman times, and no doubt there were different consulting architects all claiming that their approach to designing a spa was superior to their competitors. I’m no historian but I’m pretty sure that as well as the aquaduct, sanitaton, roads, medicine, education, wine… the Romans gave us the PID.

The problem is that although project methodologies have been modified and updated over the centuries, very little has been taken away from them! Be honest now – how many of you, when faced with the “your methodology or mine” question opted for some kind of amalgamation of the two? You probably rationalised it as taking the best bits of both. Did it get the job done?

…or did it cause a bit of confusion amongst your project team, anger among your enterprise architects, and bafflement in the business?

To answer my own question then – in many ways it doesn’t matter which methodology you use if both of them are bloated and cumbersome and result in slow delivery of a system designed a year earlier. What is interesting to me is how little of any methodology is focused on making sure:

the project delivers the benefits that have been promised to the Board, within the time scales, budget and risk profile agreed.

As a CIO, isn’t it time you sent your project methodology to Weight-Watchers to lose a bit of the flab? Can you get it more nimble and focused on getting the job done? If you do you might find it is the business who is flirting with you, and lets face it – they are much more attractive than well-lunched consultants!

If you struggle with your IT dept, you’ll *love* consultants

* No.4 in a series of articles I wrote in Dec 2010

So far in this blog we’ve had a quick look at what the Business can do to get a better relationship with its IT dept, and we’ve looked at what the CIO can do to get the IT dept more focused on the business.

What about those lovely 3rd parties – IT service providers, consultants and contractors – surely as specialists plying their trade in a variety of businesses they have all the best answers, right?

I need to declare an interest: I have been a freelance consultant for nearly 20 years. I have worked on projects with many 3rd parties: Accenture, Anite, CapGemini, CSC, Fujitsu, IBM, Mouchel, Northgate, Open Text, PriceWaterhouse… and as you can imagine I have seen some good and bad engagements along the way.

It’s easy as an outsider to take pot-shots at the in house IT department. What I want to do in the next few posts is turn the tables and look for a few skeletons in the consultant’s closet. After all, if we want the consultancy business to thrive it too has to stay relevant to today and tomorrow’s business demands.

I believe consultancy is generally falling short of business demands in a number of key areas:

  1. The “day rate” is fundamentally at odds with business demands.
  2. The big “methodology” days are over.
  3. We cannot claim to offer the perfect individuals for the job, and later claim that “all our resource is interchangeable”

There’s a good chance I am blind to many of the failings of consultants so I welcome all discussion on this blog, and I expect the list to change as a result. This week I am going to look at a huge bone of contention – the day rate.

Day rate

I don’t think this is controversial – we all agree that aligning everybody’s interests with the project aims is a good thing. So if your project is about delivering efficiency, you want your project team focused on delivering efficiency, and if you can offer financial incentives then you would make payments based on the amount of efficiency delivered.

Perhaps your project has to be delivered in time for a fixed date – maybe you are building a train station for the London 2012 Olympic Games, or launching a re-branded website to coincide with a Christmas TV advert campaign. In this case you would want your project team focused on timely delivery, and may offer a bonus for early delivery, with a much reduced or no payment for late delivery.

Of course most of the fun projects are more complex and can have some conflicting aims. Invariably there is a limit to the extent you are prepared to compromise on quality to hit a deadline or achieve an efficiency goal.

I am not saying that getting everybody 100% aligned is easy or even achievable. But I do believe that consultants charging you a hefty day rate is almost always in conflict with the aims of your project.

In the current full-fat day rate world consultants profit from good attendance, not for being super-efficient, not for quality, not for speed. Your fixed end date means no more income, so how sad are the consultants going to be if it slips and they get paid for another month?

Arguments for sticking to a day rate: “We’d love to offer you a fixed price but…”

  • You need to define your requirements before we can give you a price.

In plain English: we can’t tell you how much “it” will cost until you tell us what “it” is.

  • We would need a critical mass of our consultants so we have enough control of the project to be confident we can deliver it for a fixed price.

In plain English: you need to buy a lot more of our consultants before we are prepared to make any promises about delivering it on time or on budget.

  • Frankly there’s a lot of risk in this project and we’d have to build so much contingency into a fixed price that it wouldn’t be competitive. It makes more sense for you to own the contingency and manage the risk.

In plain English: this project has DOOM written all over it, but we’ll bill you on T&M until you eventually sweep the project under the carpet.

So what’s the answer?

With all the talk of partnership that goes on, maybe it is time for consultants to step up and take a bit more risk. I propose a model where day rates are charged at a reasonable figure that covers cost only. All the profit from the engagement is skimmed off the day rate and attached to meeting the project aims and objectives.

This will focus the minds of both parties on two things: how to quantify and place a value on the benefits the project is expected to deliver; and how to design the project to succeed. A painful, but I would argue immensely valuable side-effect is that consultants would be compelled to speak up about poorly conceived and badly structured projects, and be prepared to walk away from the opportunity.

I think it is essential for consultants to be more open about their views on the project opportunities they are given. I think it is equally essential for both parties to stop negotiating on day rates, and start negotiating on the value of the benefits to be delivered by the project.

Next week I plan to talk about Methodology but that might change depending on your feedback.

CIOs: step up and rattle the walls of the IT department!

* No.3 in a series of articles I wrote in Dec 2010

Last week I gave a few suggestions for business people to get a better understanding of what makes their IT colleagues tick, and how to get along better. This week I want to tackle the IT department.

Business and IT - friends on Facebook?
Can the Business and IT be friends?

I have worked with a dozen or more IT departments (for a decent period of time) over the last 20 years:

  • IT companies, big, medium and tiny
  • Utilities
  • Universities
  • Local Government
  • Government agencies
  • Logistics
  • Financial services
  • Insurance

As you can imagine, some have been more effective than others. Out of the dozen, I would class three of them as being well-integrated and aligned with the aims of their organisation. The other 75% are doing ok, I don’t think any have been a total disaster. They deliver complex projects with moderate success and just one or two skeletons in the cupboard. They do “good enough”.

And that’s a problem for the CIO, because as I outlined in an earlier post, it is becoming increasingly easy for business people to find their own IT solutions that are “good enough” …and they can do it quicker and cheaper than through a formal IT project and all its baggage. If an enthusiastic graduate in a marketing team can knock-up a salesforce.com CRM system in a few weeks for a fairly small monthly fee, no commitment and no capital outlay, why do they need an IT project that will deliver something a bit better but 2 years and £3m later?

Unless CIOs start swiftly delivering IT projects that glitter with value to the business then the IT department will become the business world’s new dinosaur.

Easy eh? …so how?

We need to review why a business has got an IT department – what is it’s purpose in today’s world?

  • Should it keep the business at the leading edge of technology, or in the mainstream?
  • Is it here to enforce standards, or support the business needs?
  • Should it actively seek and promote ways in which technology can give the business a competitive advantage, or simply respond to requests from the business?
  • Should it own and host the servers and IT infrastructure, or should it manage the infrastructure through specialist partners?
  • Should it manage and deliver all projects that involve technology, or is the business better placed to take responsibility?

Answers to these questions (and others) will vary between organisations of course. Is the purpose of your IT department the same as it was a few years ago, or have things evolved?

Then we can ask (for starters):

  • Does the business agree with this purpose?
  • How well it is fulfilling that purpose today – does the business agree?
  • What mindset and skills do the IT staff need to fulfill that purpose – what is the gap?
  • What barriers exist between IT and the business, and how can they be removed?

So how does your IT department measure up …and what are you doing about it?

The most common shortcoming

There is something that every CIO needs to drive into the mindsets of the staff in the IT dept. Something that will help the IT staff be much more productive and projects much more successful. Something that will massively improve the reputation of the IT dept.

It is simple. It outstrips all project methodologies I know and increases staff value many times over. And it is FREE!

…but of course there is a catch, and it’s one that can vex those CIOs who have become disproportionately fixated on their CMMI levels. So I’m sorry, but the catch is there is no certificate to give your staff. They’ll just have to make do with becoming really good at their job.

Here it is:

  • If you work for an insurance company – you are not in IT. Learn about insurance and what innovations your competitors are introducing.
  • If you work for a local authority – you are not in IT. Learn about the services your council provides and how councils are changing.
  • If you work for Tesco – you are not in IT. Learn about retail.
  • If you work for an IT company – ok, you are in IT! Learn about your customers and how they use technology.

…then figure out how your IT skills can help your company do its business (that you now understand) better.

This may seem unfair on the IT community. As pointed out in a comment on an earlier post, the business expects IT to understand everything it does. Can you imagine in a Local Authority what this must be like – IT needs to know about social care, planning regulations, streetlights, parking tickets, council tax, housing, education, etc. We would not expect social care staff to know about parking tickets, or an insurance underwriter to understand online marketing strategy, or a supermarket fishmonger to know the ins and outs of baking.

It is unfair – but it’s real, it is necessary, so let’s deal with it. Lets not pretend that our IT guys are doing the very best they can to understand the business – they need CIO leadership to shift their focus and start valuing the gaining of business knowledge as much as they do the accumulation of IT certificates (honestly the Scouts/Guides have tougher criteria for awarding badges.)

Businesses need IT, but they need IT staff that talk their language and understand their challenges. This cannot be done from within the walls of a central IT dept. IT staff have to live and work amongst the business to appreciate their problems, and they should specialise in a business area or two rather than trying to understand everything.

Face it – if the internal IT staff don’t understand the business challenges and work hand-in-hand with the business to solve them, then a third party specialist will be only too happy to step in. So why does your business have an IT department?

Next week: What will be left for the IT dept to do?

Getting a better relationship with IT

* No.2 in a series of articles I wrote back in Dec 2010

Last week’s post got some brilliant responses on LinkedIn. Particular thanks to Keith, Kevin, Phil, and Fran who raised many interesting points, which I will be covering in future posts. There is definitely common ground on some of the problem areas:

  • Getting IT and the business to talk to each other and respect each other’s point of view;
  • Does the tail wag the dog – when IT has too much power/control;
  • Duality – why is there an IT/business divide – aren’t we all working for the same business;
  • Unrealistic expectations of the business on IT;

I am going to come back to these problems in next week’s post when I’ll suggest how the IT dept can step up and get closer to meeting the needs of the business.

If you are in the business

Here are a few things I have noticed through working in variety of public and private sector organisations that might help business people get a better relationship with their IT colleagues:

If you aren’t getting the help you need from IT: Generally speaking IT folk value being smarter than the average bear and enjoy solving problems that other people have struggled with. If you want to get their attention on your particular challenge – make it attractive. Tell them that you are struggling with it – you’ve spoken to a few people and they’re stumped too …how would you approach it?

Sign-off of requirements documents: Please understand that IT doesn’t insist on this to annoy you: they need a stable base on which to start building. To an IT person your sign-off means they have finally nailed down exactly what you want and you are 100% certain that it entirely captures what it is you want them to do for you. Believe it or not they really want to do a great job for you. It means they can now throw themselves headlong into solving this tricky problem you have described, safe in the knowledge that you won’t turn up next week and shatter their masterpiece into 1000 pieces with the dreadful words “I’ve been thinking…”

Dilbert.com

If the IT guy seems blunt, rude and full of themself: I’d love to see an anthropological study on this. I think IT has something in common with the academic world in the way solutions, ideas etc are open to scrutiny through robust and often aggressive questioning. Richard Sennett talks about this in regard to the Linux community in his brilliant book “The Craftsman“. To an outsider it can be rather a shock – but the purpose is to validate that the idea has been well though through. Unfortunately some IT folk seem to think that every idea is up for interrogation, and meeting with them can feel like an ordeal for less combative people from the business. Pull them up on it – chances are they aren’t aware they are being so aggressive. Remember, IT folk want to deliver great work. If you can get one to tone-down and thereby get a more open dialogue going that results in a better solution then you will have a friend for life!

Of course, they might just be rude. It happens.

What are your experiences of working with IT ….or working with the business if you are in IT? What have you found that helps bridge the gap? Please leave a comment and I’ll put together a “top 10” list.

Next week: CIOs – time to step up and rattle the walls of the IT dept.

If men are from Mars and women are from Venus, what planet is the IT department on?

* No.1 in a series of articles I wrote back in Dec 2010

…in other words, why don’t the business and IT get along better? The next few blog posts will explore this topic and offer some suggestions for improving the relationship.

dilbert.com

In the late 1980’s when I started working many large organisations had a team of specialists that vanished in the space of just a couple of years. They did word-processing: now *everybody* does word-processing. I think there’s an argument that says that the quality of the output has dropped as a result, because any chimp with a keyboard can produce a document …and they do.

This trend is occurring in photography – the cost of the equipment and the level of skill needed to get “reasonable” results has shrunk to a point that if you can use a mobile phone then congratulations! – you can take your photo and get it published to a mass online audience in under a minute. Again the quality of output has dropped.

…and again with publishing. The stereotype has always been the struggling writer sending their manuscript off to be scrutinized by eagle-eyed publishers for months – years even, in the hope that one of them will pick out their work and judge it worthy of print, thereby validating a life’s work as having *meaning*. What kind of mug does that these days when you can produce and market an e-book, or go to a print-on-demand company and get professional looking physical books on sale at Amazon in a few minutes? As for quality…

In all cases the cost and skill of producing acceptable results is dropping, which opens up a specialism to the masses. Ansel Adams became world famous for his iconic photographs of Yosemite National Park in California. If you use Flickr.com you can see 1,032,710 photos of the same park by the many thousands of peaople who try to emulate his work.

Clearly there is still room for the specialists – I don’t think the photos for the National Geographic calendar are going to be crowdsourced any time soon, but it does mean that the “experts” have to work harder to justify their existence and their right to command large fees. However, at the “good enough” level, the experts aren’t required because people will do it themselves.

It seems plausible to me that in the next decade IT departments will go the same way as the typing pool. Business will just “do IT” – they won’t have servers to manage because their systems will live in The Cloud (or its future offspring), and they’ll be able to set up their own filing systems for documents, or configure their own CRM or ERP system using one of a dozen or so templates as a starting point. Sure, their systems won’t be finely tailored to their specific needs – but so what? They’ll be good enough, and crucially they’ll be live in 2 weeks instead of 2 years. Their investment will be a monthly subscription fee rather than a huge upfront payment, so if it turns out to be wrong they just throw it away and try again. No biggie.

I am not saying that the IT staff will be cast onto the scrapheap – but they will need to change their ways, and so will the business people and their attitude towards the IT guys. How many times have you heard things like this:

The busines - IT gap

I am keen to hear your views – are the days of the IT department numbered? Are people in your business beginning to “do IT” for themselves and bypass the IT dept? What areas of IT do you think still require the specialists, and what can be done to a “good enough” standard by the business?

Five years ago the CIO and the IT department wielded considerable power with specialist staff working with kit that took years of experience to master. That power is fading along with the mystique surrounding IT systems. We are all becoming IT people now, in the same way we are all photographers and writers.

Next week: how to improve the relationship between the business and IT.

Donkeys!

A couple of weekends ago Felix and I returned to the New Forest in search of donkeys. You will of course know all about New Forest ponies, and they ARE brilliant, but my heart is with their sturdier cousins who are just as keen to share your lunch, but not as jittery.

Felix meets eeyore
Felix meets eeyore

I last met the donkeys earlier this summer on the opening walk of The Games Way. I was marching along quietly munching an apple, when I suddenly got mobbed.

Consequences of trying to eat an apple outdoors - August 2012
Consequences of trying to eat an apple outdoors – August 2012

This time we came fully prepared with apples and a bunch of old carrots. All we had to do was find the donkeys…

What, no donkeys?
“Hmm, I’m sure they were somewhere around here…”

As you can tell from the photos it was a beautiful autumn day so walking across Plaitford Common with my favourite partner in crime was a joy. A couple of months ago the ground was bone dry and dusty, but now there were small streams all over the place and the odd boggy bit in the woods, as well as some amazing fungi:

Fungi in Deazle woods
Fungi in Deazle woods

On the far side of the common we found the donkeys, stoically munching the gorse and doing their bit to keep the landscape so open and gorgeous. We waited at a respectful distance, and after a few minutes curiosity got the better of them and they came over for a friendly sniff.

Is that a carrot in your pocket, or are you just pleased to see me?
Is that a carrot in your pocket, or are you just pleased to see me?

It didn’t take long for us to get surrounded, and even a couple of young foals joined in the fun. Everything got tasted – trousers, bags, camera, fingers, bootlaces, but all very social and friendly from these inquisitive beasts. Eventually they realised they had cleaned us out so they bade us farewell and we parted company, all happier for the encounter.

Do u haz noms? - LOLdonkey
Do u haz noms? – LOLdonkey

One last photo – on the way back to the car we found this extraordinary creature trying to cross the road. Google tells us it is the caterpillar of the Pale Tussock Moth.

Caterpillar of the Pale Tussock Moth
Caterpillar of the Pale Tussock Moth, aka “look at the FUZZY”

Even with this otherworldly looking beast there is some common ground – we both love the Hop Leaf!!

A return to programming

Up until August this year, the last time I did any programming was in the late ’90s. Web apps didn’t really exist and smart phones weren’t even a twinkle in Steve Jobs’ eye. I programmed in C, C++ and something called Gupta SQLWindows that became Centura Team Developer and then withered away with Delphi, as Visual Basic, C# and Java took over. I couldn’t choose between C# and Java and didn’t like the thought of backing the wrong horse, so I chose management – the skills have a longer shelf life.

I took a couple of months off this summer to organise a 187-mile walk celebrating the London2012 Olympic Games, and to help my eldest son get ready to start university. It was a great opportunity to see whether I still had any talent and passion for programming.

So where to start? Picking Javascript was a no-brainer, but should I choose Python, PHP, Ruby, Java or ASP for the server-side? And what about databases – MySql, Postgres, NoSQL, MongoDB..? And how to learn?

The variety and sheer number of resources available for free online is staggering. Top of the heap for me is Codecademy, where you can learn Javascript (and plenty of other things) in a structured, highly practical, interactive way. It was PERFECT for my needs and I loved being able to learn at my own swift pace. I cannot recommend it highly enough to anyone wanting to learn how to program.

I really wanted to learn Ruby on Rails because it’s what the cool kids use and I am a big fan of 37signals (who kind of invented it) and their intelligent approach to developing software. But… well, as far as I can tell it is a pain in the ass if you use Windows rather than Linux or iOS, and it seems to me that the RoR forums pour scorn on us PC users. And I need love in these early days!

In the end I went mainsteram with PHP, and picked up a great book that got me started – Sams Teach Yourself PHP, MySQL and Apache. Armed with the book, the tutorials at w3schools, help from Stack Overflow and plenty of time, I got stuck in. Time will tell if PHP was a good decision – I’m open to alternatives.

So that brings us more or less up to date. I’m going to be writing about my adventures in programming here, and sharing anything I think is useful that I pick up along the way. There are bound to be plenty of mistakes, hopefully a few successes, and I hope you’ll join in the fun, and share some of your wisdom too!

Cheers, Mark