Is the IT Industry corrupted or just ignorant

For the last year, the topic of kickbacks and let's say, under the table payments, has been getting much more attention. This is great news for our industry.

The most recent news came courtesy of Accenture in this news here on CIO.com. But it would seem reasonable to assume that this is not an isolated case. In addition to Accenture being named, Computer Sciences, IBM, PricewaterhouseCoopers, HP, Sun, EMC and Cisco have all been named in this article. Given the number of companies involved, this would seem to be an industry issue, rather than an isolated company issue.

In defense of their claims, the above organisations have referred to "Alliance Agreements", which presumably define the payment of kickbacks or incentives for organisations to recommend one software or hardware product over another.

So why should this be a good or bad thing for the industry. Well the simple fact is that the industry does lack credibility. We have many ugly project failures and many non IT executives cannot see the value in the money they spend on IT investments. Meanwhile the biggest players in the industry are recommending each other to ensure new business stays within their Alliance. Is this helping the industry be more successful and deliver better results?

This article from ZDnet makes an important distinction between an integrator and a consultant.  It says that an Integrator could take commissions and referral fees and not disclose them, and that consultants should not. 

However, this distinction is getting blurred when "Integrators" are providing consulting advice on what software to use, even having "consultancy practices", and some big consultants have "integration" or "implementation" or "transformation" practices.  And when clients are not familiar enough with the market, the technology or their own business to know (or argue) a better case then they are at the mercy of the advice they get, whatever basis this advice is made on.

The ZDnet article states "how can a consultant or systems integrator even pretend to be providing impartial advice and counsel to clients that are selecting new software or hardware if their employer benefits from steering the business to one provider over another."

Tony West, assistant attorney general for the Department of Justice's Civil Division, said in a statement quoted here, "Kickbacks and bid rigging undermine the integrity of the federal procurement process. At a time when we're looking for ways to reduce our public spending, it is especially important to ensure that government contractors play by the rules and don't waste precious taxpayer dollars."

US based ERP consulting firm, Panorama, has talked about the challenge for clients in getting effective advice when the industry is littered with these types of referal agreements.  You can read about their views here and here.

They suggest that clients ask their suppliers three questions:

1. Do you sell ERP software?
2. Do you receive any financial kickbacks or have any financial ties to one or more software vendors?
3. Do you have a staff of consultants that focuses on one or more software packages?

If the answer to any of these questions is yes, then you may need to consider the quality of advice you are receiving and look elsewhere.  It is highly likely that the advice will be tarnished by kickbacks and financial incentives.  You may still need a systems integrator but be cautious about the quality of the advice you receive.

I can confirm that Information Professionals can make a very clear answer to each of these and that answer is a definitive NO.  And we are happy to guarantee that.

Plus see:
HP Agrees to pay $55M to settle Gov't Fraud Charges
Kickback allegations include technology contracts

Why Change?....Success Criteria # 3

In Success Criteria #2, I linked culture to organisational performance in delivering projects mentioning that "an organisation always gets the project they deserve". But also when the project team exhibits great leadership they can overcome this.  We will therefore talk about leadership and team composition, but before doing so there is another more important criteria.

That is asking the question of why change anything in the first place?  Knowing why, helps define what the change is trying to achieve?  It could be a simple technology change like a desktop rollout or it could be something much more transofrmational.  Even with a desktop rollout there can a lot of reasons why this is being done and this changes the approach and the outcomes.  Is it a defined upgrade due to end of life or is there other reasons, such as a new enterprise capability that requires new desktops?  Is data and applications being migrated or accomodated in the new environment or discarded?  Will this have impact upon operations?  Is there variations to specifications allowed for specific needs by some users/managers?  Who pays for these?

I have only scraped the surface with questions.  The answers will define what outcomes the team is supposed to deliver.  Is it a low cost, tightly constrained project or is it allowed to consider value judgements that may cost more but bring some benefits. 

Why are these questions important?  All projects make trade-offs, some make them more explicitly than others.  If a project is not making trade-offs between time, cost, quality and benefits then it has a very loose direction, it is not finely tuned nor highly defined.  It is like saying just run over there and see how you go, versus you are about to run in the 100 metres on that track on this time and day.  To do things well, what you are doing needs to be clear, as do your objectives.  You cant do something well, when what you are supposed to be doing is vague.  Yet some projects are very unclear. In fact, it would seem purposefully so.  Not having clear objectives means you can't fail...well perhaps that is the view by some. 

Not having clear objectives also means you can never succeed.  and this forms Success Criteria #3, have a clear mission.

What changes will the OGC demise bring?

After last year's first step of moving the OGC, its pieces have now been split up and the OGC as an entity in its own right has now officially ended.  This was confirmed in mid-April.  What does this mean for everyone that uses the many methodologies produced by OGC (all trademarked to Office of Government Commerce), such as PRINCE2, MSP, Gateway, M_o_R and the increasing numbers of others.

Well to start with, what is clear is that everything that the old OGC used to do is being scrutinised.  It seems unlikely that they would get rid of things that generate revenue, and in most cases, it would seem that the training and accreditation programs supporting the methodologies would generate significant royalty revenue at the very least.  But just because they are revenue earning doesn't mean they will be maintained.  We see governments close down activities that earn money all the time if it doesn't fit within their priorities.

So with formal confirmation of the OGC being split up less than one month old, it is probably too early to know exactly what the future will hold.  However, so far, it seems the only thing that is under threat is the Gateway Hubs.  This may have an impact on some government bodies in Australia, although in some cases, they themselves have started moving away from a strict interpretation of Gateway, and adding more pragmatism into their gating/governance frameworks.  Of course we encourage this approach in all methods, and while strict methodology purists may frown upon it, some of us have the experience to go with the methods to know what actually works.  As a result, the retirement of Gateway Hubs may not be a huge impact.

Also worth considering is that supplier risk is always a consideration in any procurement and in the adoption of any standards.  When relying on another government department for supply, supplier risk is probably not considered so seriously by most, after all, aren't all governments going to be around forever.  Of course governments themselves are, but how long will they support a particular initiative, well that can be anyone's guess.

Success Criteria # 2 - Talking about Behaviour

Criteria # 1 was about risk management.  We all do risk management to some degree.  Let's face it, that is the only reason a project starts.  How many projects have you started because you didn't want to change something that was likely to happen in the future?  None I suggest.

Whether you use risk management explicitly or not, future risks (or opportunities)  are likely to be the very reason why you are embarking upon any change.  You are doing risk management, well in part anyway, even if not all of it.

But even if you were to establish some stronger risk management standards, what gets in the way of organisations who have risk management but still fail to successfully change the way they operate is culture.

Consider how many policies, processes, standards etc your organisation has or doesn't have.  Which ones get used, how often and how?  This is defined by culture.  Most organisations today have a defined risk management standard or policy.  Corporate governance dictates it.  Yet the difference between those that use it and use it well and those who don't depends on culture. 

Sometimes risks are managed, but some risks are not spoken about.  That is defined by culture.  Sometimes there are areas of sensitivity to management or to corporate history that some in the company cannot face or face constructively.  This is culture.   Sometimes valid risks are escalated by a team to management but ignored or rejected and not dealt with.  This is culture.  Sometimes risk management is seen as not relevant or important because operational priorities are the only things that get interest and traction.  That is culture.

What every successful team realises though, is that whatever the culture of the organisation, they must stand up for what they need to do to be successful.  They must create their own culture, as a variation to the organisation at large.  In other words they must lead.  They must lead the change.  And the bigger the change, the bigger the leadership must be.

A colleague has a saying that "an organisation always gets the project they deserve".  To some degree that is true because a project is a part of an organisation, and organisational behaviour is defined by culture.  But there are exceptions to that rule, and those exceptions are when the team exhibits great leadership and redefines the culture that they operate to, and shows the organisation how to do that well.  Of course it may be a short period of time, but that can be enough to successfully implement its outcomes.

Starting with Success Criteria #1

This post represents my first blog in a while and a fresh commitment to blog more regularly.  See Making a Fresh Start for that post.

To restart here, I have recapped on Success Criteria #1, Risk Management.  That sounds boring doesn't it!  Well perhaps so.  But let's get real about what we are doing when we implement changes  to a business.  Aren't we creating a new future?  Risk Management is about doing things today to create a future state tomorrrow, or to avoid a different future state.  Given we are implementing changes to create a new future state of the business, then it makes sense that risk management should be a key capability.  However it is often not the case.

When we look at programs and projects that are implementing change, one of the first things we look for is whether risk management is being practiced.  If it is we know that the team is looking far enough ahead and doing today what's required to manage any future challenges they expect to encounter.  If they are doing that, this it is good.

If they are not doing that, we consider whether they are doing Issue Management.  If  so, the team are at least identifying, categorising and prioritising tasks for those challenges they are facing today.  This is OK but not as good.  Lastly, if they are not doing either of these then they are scrambling to cope with every issue as and when it arrives.  The team is therefore in a reactive mode.  It is impossible to be high performing in this mode.  The team may feel busy and may feel like they are making progress, which they are, but they will never be more than mediocre.

Making changes to any business encounters problems.  That much is normal.  How you deal with them is what varies.  Issue Management gets the team triaging problems,  Risk Management gets the team ahead of the curve and gives it and the organisation the best chance of success.  This is why this is the Number One Success Criteria.

I'll cover # 2 of 5 in my next post.

Brisbane Office Closure

With the current flood conditions in Brisbane, and the shutdown of the Brisbane CBD, our Brisbane office is closed this week.  We plan to reopen on Monday 17th January subject to access, services and utilities being available.

E-mail and mobile phone communications are still in operation.

How many change programs can we deal with?

Have you noticed how we have so many more projects, change programs, new initiatives and strategies in our organisations today?  Have you noticed that so many more people are Project Managers...all demanding some attention and resource?

The 2000's was the decade of Project Management I beleive.  We now have so many PMs, and almost as many projects to go with them.  That means we probably have more focus on objectives that we did in business in the 90's.  But the dowside can be that in the face of limited resource, where do we put our attention, where do we direct our energy?

We may have more focus on objectives but less clarity on which ones are important.  This blunts the edge of gaining effective change, when we are spread so thin doing a lot of things in mediocre ways.

I sometime write for a Singapore based magazine called Walk Your Talk.  I wrote an article on this very subject and some ways of dealing with it.  The article is available from our website. 

You can access the full article here.  I hope you enjoy.