Posts Tagged ‘intent’

Published in MIS Asia – ‘You don’t want it to work’ he said

Thursday, April 1st, 2010

‘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:

  • A project whose goal is not a functioning system, but whose purpose is to affect the share market.
  • Outsourcing so that an executive has bragging rights of ‘yes we do’ when he sees his peers.
  • Doing a pilot but not a project to get brownie points for bonuses and promotion.

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:

  • Increased business profit by seven per cent
  • Investment cost of less than one per cent of profit
  • Reduced work effort by 10-30 per cent on a major time consuming task.

Its technical characteristics are:

  • Provides key data on a core input to the major product of the business.
  • Can be implemented in under a day.
  • Is robust and low maintenance.

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:

  • Using the data, each business manager has to fundamentally change how he manages his key resource to produce his core product.
  • If the product fails, the business unit fails and all employees starve.
  • Globally, around 100,000,000 businesses unit managers who can benefit from this technology.

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:

Results Probability Assessment

Executives leading successful projects initially focus on value.

Step 1: Four questions to ask about value:

  • Is the value based on dollars, building a strategic capacity or addressing regulatory requirements?
  • What are the short and long-term objectives of the project?
  • What are the needs or interests of the varied stakeholders?
  • How does this project affect time to market or business resilience and responsiveness?

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).