The Asian Banker June 2011 (print edition), June 14 (online edition)…
Joanne Flinn, author of “The Success Healthcheck for IT Projects”, feels that the cost of failure of new IT projects is too much for banks to continue delaying much-needed triage.
There is a private club in banking in Asia which costs $200 million to join. It’s the club for business transformation projects that fail. It’s tragic it exists. Membership i…
For more, log into … the Asian Banker June 2011
Joanne Flinn speaks ‘On Success’ at the Asian Banker Summit in HK on April 6th 2011 to the Technology and Innovations Conference.
The key questions answered in the presentation were:
Joanne Flinn is invited to contribute to Oxford’s 3rd Futures Forum held at Oxford University in April 2011.
Joanne Flinn presents a Keynote and Master Class to the ACMP’s first conference – held in sunny South Africa, delegates represented all corners of the globe.
How do we really measure customer satisfaction? ~ on IT projects!
Clearly not, I deduced as this particular person marched off. The waiter stood there looking perplexed. It was a busy day, hot and crowded.
I turned to my companion to hear how he was satisfied.
Ahhh, honey! He said, that was an experience…
It was the perfect shave, he practically soliquised in rhapsody. I wondered – isn’t a shave a shave?
Clearly not – a shave can be an experience. At the Art of Shaving, it’s an aromatherapy facial, hot towels, a freshly stropped blade and the personal service of a fetching attendant. A shave of the manly chin, I was told, is more than a Mach III blade in action.
I asked him to focus on our discussion: were projects products or services? Were they about deliverables – things? Or were projects also a service?
And if they were a service, how would we rate them?
Projects are a product
Yes, we decided, projects were about a product. Projects are about delivering something tangible – like a shave.
Yet getting to success is more than being OTOBOS (on time, on budget, on scope).
OTOBOS, even with a 10% variation is simply good hygiene. It’s like a C grade.
Yes, it takes focus, discipline and team work to get there, but OTOBOS is not a wow factor.
Consider, was it good for you honey? OTOBOS is scarcely even a smile factor.
Projects are a service experience
Project are also about intangibles – the experience. Many an executive has said to me, ‘We aim to survive our projects’.
Side bar comment: What would happen if we explicitly agreed the service experience as part of our project definition? For example:
- Would you like an food court experience or a fine dining experience?
- Would you like to be in the action or be a bystander? (Ride the river or watch the video)
- How would you like this to feel? Like a Lexus experience or a bullock cart ride?
- And the crucial business questions:
- What are you prepared to pay?
- What would it take to do this?
Else it might be “Fine dining at hawker center prices – with aircon” on one side while the other is thinking that they will organize a picnic where we each bring a dish.
In IT project terms, the experience might be something as novel:
(It’s almost embarrassing to admit this standard of service is not just common practice in our industry – even the great organizations slip-up.)
More satisfyingly, we could learn from the likes of Disney (an experience we are in) or Circus de Soleil (an experience we watch). Creating the intended customer experience is a professional capacity in customer relationship management.
It’s reported that 50% of an experience is emotional. If we recognize this factor in ‘was it good for you’ (or me for that matter!) then for an IT project, qualities like:
Would influence both our design, how we choose to implement a system, our internal project processes and our resourcing.
This difference in product/service is measurable: Executives report projects as 15-20% as less successful. They have the same data on deliverables, on OTOBOS. Executives are flagging something more: their perception of the project from their experience. They reflect on the pain they’ve born that’s seen as ‘outside the project’ as it is not a physical deliverable – but it is a result.
This affects the value that executives attribute to a project.
As more businesses focus on creating a great customer’s experience, executives and other staff will expect this of IT projects – whether they state it or not.
Project managers and teams can develop a great reputation by considering service in their project approach. Projects earn it when they deliver to the agreed service standard.
Guidelines for Service Goals:
If it was good for you honey, then share in the good.
Yes, I can hear those who say ‘don’t to this, it makes it too hard to reach agreement’. Let’s be blunt here – if the business doesn’t value the service goal then they won’t invest in it – and they then own the choice.
Each of the ‘experience’ goals listed above has a multi-million dollar down side if not delivered. That’s worthy of investment – and of due credit.
We count cost to life and limb on a building project yet strangely not on IT projects
I was walking past the Marina Sands site in Singapore on the phone to a friend. At several billion dollars in design, man hours, fine art and no doubt many interesting stories, this project is amazing. I saw a sign reporting safety with a tagline of ‘everyone home without harm, every day’. Ie no deaths, no injuries. A back of the envelope calcuation told me just how amazing a feat this was – over several hundred man-years have gone into this construction.
‘I’m having heart palpitations’ my friend said. My attention returned to the call. ‘One of my male Korean colleagues has just burst into tears, and the new American guy has just done the hairy foreigner’. (‘doing the hairy foreigner’ is a term meaning to lose one’s temper at staff in Asia – very un-cool).
“Just a moment! Hasn’t your transformation program just kicked off?’ I asked…
The writing is on the wall
Those few seconds re-defined the project in my mind. From one that looked well set up, there were now warning signs for failure. Three of the senior team leading the transformation were showing signs of major stress and after the last year, most of the people in the business were likely to be stressed (coping with recession, family members loosing jobs, having your savings depleted supporting them, worrying about your own job will do this even for the lucky folk with a job).
Stress on both sides. Next step, heart attacks or long term leave for people. For the business, project results and organizational productivity at risk.
Often, these risks are considered once an executive has a heart attack. Other people step up to carry the team – more stress, a negative cycle begun. It becomes normal. For most of us in project land, we are used to the adrenaline of overdrive.
Pollution Costs
Just what will this cost the organization? Project delay becomes likely as replacements are found. Key relationships are broken as people depart (either from resignation or from death). Results are delayed as people and the business focus on recovery and repair. This is before the long term consequences of the way the project would introduce change are considered. It is obvious that a project is about introducing change. The question is… are the intended consequences palatable?
Consider for a moment, France Télécom and 20 suicides (that’s death) attributed to the way a major transformation was managed. Death from suicide or heart attacks is major. More subtle is the psychological and social impact of change on the people in the organization – and their families.
This dimension is rarely taken into account.
It’s pollution. Intended or not, it’s a cost that someone else bears.
In the world of IT projects and business transformation, it might be a decision that saves project effort and leaves a work-around for the business. It might be a process change that puts more responsibility onto another department without their informed agreement. It might literally be body count or injury.
The construction industry actually measures this. They are held accountable for health and safety of those on the site. They even need to keep their environment clean (the wheels of trucks leaving a site are hosed down to remove dirt so streets aren’t polluted in Singapore).
For a business seeing itself as an integrated system, one whose performance is driven by people, processes and technology, a change process that succeeds on the technological front but fails on the people front is a failure.
Certainly, long term business results from transformation are jeopardized. Few executives would like to be under the investigation at France Télécom. Likewise, few people like to be on the receiving end of ‘pathogenic’ restructuring.
Will this project succeed or fail?
The business case stacks up, the intended goals are clear, risks to results are considered. The project looks great. Yet, what is the body count? What injuries are considered ‘acceptable to health and safety’ in the workplace? Where is the project likely to create pollution in the business?
Has the project considered these? Does the organizational change charter pay adequate attention to managing these risks to results? To people? To performance?
An Organisational Change Charter defines the project’s approach to introducing change into the business from the perspective of people and processes. It dovetails with the IT Program Charter which defines expectations of the IT side of the business transformation.
Executives leading successful projects focus on people.
Rules of Engagement
It’s about respect. In all relationships. Define how people are to be respected thru-out the course of the project. This applies equally to executives, the team, partners and to people affected by the project in the organizations.
What is good (enough) for one is for all.
[A byline comment… Big projects require partners. It is a rare organization that knows so much or has spare capacity that they can run their business and transform at the same time without support. Respect operates here too. Results are a team effort. Partners are part of the team.]
Four questions to ask about Body Count and Pollution:
Validate the responses to see that the project is prepared to recognize reality. Body count is real. Injury is real. Pollution is real.
Next consider where risks to results lie in the project team and in the business. Move the Organisational Change Charter into an effective Organizational Change Strategy.
Returning to my call as I walked past Marina Sands… ‘Have the executives sponsoring the project realized where the team is right now? And the business implications of current reality?…’
‘I don’t know why I bother’, she said. It sounded like the relationship was deteriorating
‘The sponsor didn’t really intend projects to succeed, he had other goals’, said one disenchanted IT executive to me last week.
I overheard the couple as I met with a group of IT executives. Of the IT executive, I asked ‘What did the sponsor intend? What happened?’ The story unfolded. Others pitched in their stories.
What is success?
Success is achieving what we set out to do. This can range from getting to a meeting on time to longer term and more complex goals like a life-long marriage, an IT project, to transforming the way rice is grown and affecting the lives of three billion people.
One of the disenchanted told me of how he’d led projects in a company where the CFO would launch a project and announce it to the market to lift stock prices, but he didn’t seem to care if the project delivered. The CIO and team knew the project was doomed, but the ‘edict was…’.
Another of the disenchanted told me of how the company executive had decided not to outsource to India for a variety of reasons. Each year, the CEO went to a conference of his peers and heard each of them was outsourcing. After the third year, he returned and appearing to change his mind said ‘we must outsource.’ The IT teams felt it was purely to say ‘yes, we do’ as the business reasons that had blocked this decision previously still remained.
A third told me that in his organisation the accepted way to get promoted or a good bonus was to announce a glamour project, do a successful pilot and then let the project die.
I can understand why the female IT project manager above was wondering why she bothered. In her world, none of these projects makes sense:
In her IT worldview, these were project failures.
The disenchanted IT folk wanted to deliver a functioning, used, value adding project, do good work, get to use some interesting technology, be respected by their peers, get home, see their spouse and kids and generally enjoy their lives (as well as get bonuses and promoted).
So did the business executives.
They just had different ideas of what success looked like.
Is intent clear?
Business folk and the IT folk often have different viewpoints of what makes a project successful. In the cases above, the CFO, CEO and business executives who got promoted would have each seen their projects as successful.
The IT folk didn’t see the project as success and were disenchanted if not a little cynical. (I’ve heard similar comments from the business about ITs enchantment with cool toys and the latest technology, too.)
All these projects were a success in one perspective: they’d achieved what they set out to. They were failures in another. Writing off a project or increasing the levels of cynicism in an organisation is not value adding.
A multi-party challenge
The practical reality of IT projects is that there are many parties to a project: the sponsor, the team, the IT organisation that needs to operate the systems, the business departments that will use the system, customers who will be benefited or affected – this is before we even touch the executives and shareholders who may benefit in other ways.
Let’s use a non-mainstream example of an information technology project that has the following business characteristics:
Its technical characteristics are:
Logically, we’d say this particular piece of technology should race through the particular business/industry globally in a short period.
A few more details:
Now the project looks less easy, more complex and more likely to fail.
Yet the value stays the same.
The multi-party challenge is that for the business to get value, multiple parties need to align and act in concert. If the technology delivers, but the way resources are managed by these businesses does not change, then no value is achieved.
It’s the opposite problem to the cases mentioned earlier – in those cases, the business was fine with the result, IT wasn’t. In this case, IT would be fine with the technology, but the business might not be. Just because there is a brilliant business case, does not mean that the business is prepared to fundamentally change how it manages a key resource or risk a key product and the business.
I’ll share more — the business is the global rice business. The technology is a tool that helps rice farmers in irrigated rice paddies reduce the water they use to produce rice. Globally, rice is one of the largest users of water. A single bowl of rice represents about 500 litres of water. Major rice areas are water challenged as cities grow bigger and need more water. For many rice farmers (most earn less than $2,000 a year), this technology and the methods that come with it would allow for another child or two to go to school.
The methodology that allows the business to benefit from the data and technology requires rice farmers to let the rice paddy dry out for parts of its growth. This is counter to everything they know. For them, Rice = water = life, rice without water is impossible.
(Source: Dr Bouman and the International Rice Research Institute)
The mindset that affects uptake is often the challenge. The business case and technology are sound. The value is clear. The probability of success is not.
Trying ‘harder’ might not be the solution. Rice farmers work hard, they are simply not prepared to risk their rice crop. They are willing to improve profitability. Results and value are possible with the new technology if this project recognises that the risks to results are not about technology or the business case, but are about uptake.
Will this project succeed or fail?
It comes full circle. What is the value? That’s the first dimension. Is it clear? Does the statement of value consider the interests of the varied parties that are part of the solution?
Secondly, is the project likely to succeed? What are the risks to success?
Back to being an investor: what is the return and what are the risks? Is the trade-off of risk/return reasonable?
Map your projects on a Results Probability Matrix like so:
Executives leading successful projects initially focus on value.
Step 1: Four questions to ask about value:
Step 2: Validate the responses to see that the value equation stakes up.
Step 3: Consider where the risks to results truly lie. Start exploring dimension 2, probability of success. Much of the technology we use in business is well-proven, yet, business may yet see the benefit or the reason for uptake. The record of delivery project may also suggest substantial risks lie in that area (see how-to-make-a-marriage-work).
It’s a multi-party challenge.
The couple’s discussion had continued. ‘You don’t tell me what you really want, I can’t read your mind’ she said. He’d sat back and considered. Then he started to talk. She explored what he said and asked how it would be if she did x or y. She said what she needed for it to work. They finished their coffee with a clear(er) aligned intent.
JA Flinn is a regular columnist at www.MIS-Asia.com. This article is based on Part 1: Productivity of her forthcoming book ‘The Success Healthcheck for IT Projects’ (Wiley 2010).
I asked as we finished our dinner. He’d cooked, I’d enjoyed. ‘Go for it’ I’d been encouraged, ‘but don’t be surprised if …’
The ultimate complex long-term personal project, marriage seems to have more success than business-IT projects: 15 per cent are in dire shape, 51 per cent are challenged. Few are real stars.
By the way, that’s business-IT projects! Depending on your definition of marriage, divorce and happiness, the figures for marriage aren’t so different. Still, I decided, that’s no reason not to try for success. There have to be ways of getting this right, I thought as I expressed my feeling to the Man-I-Love (MIL for short).
Posted as a contributing author at MIS Asia
Getting it right
Life is looking up in the bigger world. Business investment in IT is going up in Asia particularly in India and China. Those I talk with in MNCs say they are getting back into project land with a vigorous ‘let’s get things done’. It’s exciting and energising after a year when many projects were put on hold, even teams disbanded. Still, are we setting ourselves up for the same mistakes?
At the height of the last cycle, project write-offs were estimated to be US$333 billion. That’s practically a financial crisis of our own. It’s a huge capital cost – one that is unpalatable in good times is unacceptable in tighter times.
The cost of failure
Most of us know the Gartner and the Standish stats on project failure. Eighty per cent under-deliver, 33 per cent written off. It’s all out there. So when I came across Chris Sauer’s work on variations to expected project results (as measured by time, cost, scope), I couldn’t help myself. I was curious. I calculated the yield like I would any of my financial investments. I treated it like a portfolio.
With Sauer’s data from experienced project managers, the results initially look pretty good: just 9 per cent of projects were written off, 23 per cent delivered with a large variation in time/cost/scope, 60 per cent delivered within a 10 per cent margin and seven per cent exceeded expectations. These last two categories were considered ‘successful projects’. Most organisations would be proud to have projects delivering with this track record. (At least those who actually measure what they do are. Those that don’t, have no idea of what the cumulative impact of a little less than expected and a little late for a little more is to the business bottom line).
This is much better than the bad old days of the 1980s where Standish reported 33 per cent written off. Good experience project managers and advisors help reduce this cost.
If you are squeamish, skip the next few paragraphs.
Still, I thought, what is an investment worth without the functions expected? It would be like having a kitchen built and having things missing. I pressed the button (Excel did the work) and found: with the reported variations to time, cost and function, the actual business value effectively delivered was negative. Minus 27 per cent.
Ouch!
Hmmm.
An investor expecting a return:
Do a quick back-of-the-envelope calculation for your business/project:
Calculate the yield.
Would you invest based on the track record represented by your average?
A bit like marriage, a certain percentage of projects end in disappointment or more. Some are the stellar successes that I’ve seen and wish for.
The path to success
I went out and asked a group of business and IT executives what their experience and advice was. (To be open, it was fully vetted research done under the auspices of Oxford University UK and HEC, France involving executives in MNCs around the world – over 50 per cent were based in Asia or had worked in Asia). Distilled, they had six recommendations:
On a personal front, I realise that these probably also apply to my relationship: see what works and do more of it, it takes two of us, letting issues lie just makes them harder to handle, so be aware and be proactive. In the dating stage – if it’s not right, it’s not. Lastly, have effective ways of coming to and upholding mutual agreements as well as dealing with issues. To modify a quotation, ‘a successful relationship is a journey not a station’.
As a foundation, MIL and I have trust, respect and an ability to communicate (and love) so we presume misunderstandings are innocent errors rather than intentional efforts to disrupt and annoy. It’s a good basis for business – IT project relationships too.
Hmm, I still want mine to succeed! While the executives had plenty of advice on that, it’s a topic for another time.
This article is based on Part 1: Productivity of her forthcoming book ‘The Success Health Check for IT Projects’ (Wiley 2010).
What this is about, and why I’m out here connecting with you. Business transformation through successful projects is what I do – been doing it for 20 years. I’ve been changing as a person too. As some great person once said ‘as a human being, we either grow or die’. I’ve chosen to keep growing.
- interviews, discussions, conversations with others who are passionate about things really working well: that’s Success
- debates, digressions and reflections about change. Business change, organisational change, personal change
- tips, tools, and check lists that clients and executives use to get better results from their projects.
- the book creation and publication process: Share how to get successfully published on your first book: my experience of it all
The Book. Wiley 2010.
Forthcoming.
The Success Healthcheck for IT Projects is a practical real life based approach for executives and IT project managers who are committed to successful projects. It shows where good projects need to look if they are to become great.
Based on project practitioner experience and research, the Healthcheck offers tools, diagnostics and action for managing project success.
Keynote speaker, consultant, author
