You are currently browsing the tag archive for the ‘cio’ tag.

My new article on the value of being connected to the core business of organization has been published by

Here is how it starts:
There is a reality TV show called Undercover Boss, where a senior executive of a large company takes a position at the bottom of the corporate pyramid. The executive discovers daily operations at the level of detail unknown in the executive suites. Epiphanies abound.

While the show is highly staged and predictable, and its entertainment value is questionable, few viewers are surprised that senior management knows so little about their core business. How do they run the company? Shouldn’t executive decisions be based on the knowledge of operations?

The distance between the executive suites and the front lines is often of galactic proportions. Because customers are found at the front lines (if you want to order a meatball sandwich or open a savings account, you don’t call head office), being light years away from the front line translates into being light year away from the customer.

The way I see it, the demand for management consulting services is not likely to go away any time soon.”

Continue reading…

You are about to listen to a recording of my conversation with Douglas Weidner, Chairman of the Knowledge Management Institute (KMI).

Douglas Weidner is a pioneering KM practitioner.  He is a respected KM consultant, columnist, speaker and mentor.  He co-founded the first KM professional society and is a past president of its Washington, DC-based Chapter.

Formerly a Chief Knowledge Engineer at Northrop Grumman. Among his clients are World Bank, the UN, NASA, the World Health Organization and many other government agencies and commercial firms. 

Full Bio (PDF)

Some of the topics we chatted about include:

–         the right place to start a KM initiative

–         how to encourage grassroots projects

–         how to avoid throwing millions of dollars out of the window

–         who should lead KM work at the executive level

–         the future of KM

Tune in !

My article named among the top three blogs of 2009 by Techrepublic:

My article on instigating change has been turned into a video by CBS Techrepublic’s Editor-in-Chief, remarkable Jason Hiner.

Click to watch the video

When making a decision, what else should you consider beyond the economic costs and benefits?

Techrepublic’s Chief Editor Jason Hiner has turned my earlier article on  into a video.

Link to the video

I recently answered this question and then thought it may be worth posting in the blog.

Question: What quality frameworks (ISO, CMMI, ITIL, etc.) have you used in your organization(s), and what pros/cons from each have you found in your experiences?

Answer: There are three key issues that I encounter time after time:

– Faulty belief that a framework (any of these) is a silver bullet for all and any problems. I have seen them applied to correct personality conflicts and dysfunctional leadership. I kid you not!

– Failure to customize. You gotta make it yours to work for you. An IT services organization I know lost customers because third line support found themselves compiling case documentation 80% per cent of their time. Resolved that, but not before some changes at the top.

– Falling in love with your methodology. This is not set-it-and-forget-it deal and you have to test your approach for relevance all the time. Is there a better way to do it? Are our assumptions still valid? A bank I know implemented user account management policies which require faxing (this was in 2008!) of a change form to the support centre. It takes 2-3 weeks to have a user set up. Meanwhile, the business has to put these people to work, so passwords are shared as a matter of standard practice. Formally, they have adopted ITIL. In reality, they are providing poor (if not dangerous to the business) service, having failed to re-evaluate their approach.

Business Intellegence (BI) systems have become a feature de riguer for organizations of all sizes. A BI implementation (whatever it may entail) is never a trivial investment and is prone to failures as any other complex project involving people and technology.

If you were to sit a few people who have been through a BI implementation at the table and ask them about the critical success factor, you would likely fill a few pages in your notepad, but let me share with you just three points that I consider most critical of all.

1. BI can offer excellent ROI but only if there are people within the business who have knowledge, curiosity and willingness necessary to understand the presented information, make inferences and initiate tangible actions. Finding such people in your organization is not at all a slam dunk. If you cannot identify them, don’t bother with BI.

2. There must always be a business sponsor (champion) and the higher this person sits on the corporate ladder, the better. In the absence of sponsor, adoption will meet resistance, the project may easily end up on a low priority list, and before you know it, the precious momentum will be lost. Don’t spend a sou before you identify the champion.

3.  As your business changes, so will the data. BI data is notorious for getting polluted very quickly in the absence of ongoing support. Once it happens, it can no longer be relied on for decision making, rendering the system unusable. You have to subscribe to the notion that an ongoing development effort will always be required. If you are not prepared to assume its cost, do not implement BI.

In my consulting work, I have met scores of IT leaders whose beliefs kept their departments from flourishing and becoming truly valuable to their organizations. Instead, they exhibited passable performance, produced little innovation and were viewed by the business as a painful but unfortunately necessary expense.

I wrote an article on a small assortment of such limiting beliefs for The article can be viewed here.  Have you observed them in your organization ?

Comes to IT procurement, there remains to be a significant room for improvement. In fact,  many of the contracts sitting in your filing cabinets  today are likely to contain dangerous gaps and areas subject to interpretation, which may come into into  play one day, in the most unpleasant of fashions.  I have seen many legally binding agreements that would fail when you need them most that I thought it would be useful to list a few points that should help to prevent a disaster.

I am a believer in hiring a professional when you need something done well. An IT agreement for a business critical system or service and a non-trivial consideration is not a place to skimp on legal help. Get a lawyer involved.

Disclaimer: I am not a lawyer, nor am I associated with any law firm. This is a completely unbiased opinion. Please do not ask me to recommend anyone.

Key success factors (in no way an exhaustive list):

1. I suggest to establish a relationship with a legal professional who specializes in technology contracts at a partner level of a larger law firm.

2. Do not simply rely on your house legal counsel. (Caveat: many technology firms have experienced legal professionals on staff who can easily trump any outside help. )

3. Establish a trusting relationship – this is essential.

4. Only work with a firm/professional who are willing to understand your business.

5. There is an advantage in working with a larger law firm as they will be able to leverage their other competencies, such as labour, intellectual property or international law experience.

6. Never simply sign the standard vendor agreement. (Caveat: I would like to have a different contract terms for my home phone, but I can’t. I am not talking about cases like this.)

7. Involve the lawyer early in the contracting process. Do not simply ask them to “check it over when we are done negotiating”.

8. Establish the understanding that you are the one driving the negotiation process, not the lawyer.

9. Ditto for your opponent – explain that you are in charge (usually they will agree and assert the same on their side, if they don’t, ask for it). If you don’t do this, you risk listening to bickering over legal terms ad nauseum (and paying for it, too!)

10. It is possible to make every contract completely watertight, it is just not practical. So, you have to compromise.  Listen to what your legal professional is telling you but apply business sense to everything you hear.  Is the problematic scenario too far fetched ? What is the worst that can happen? Do we have other means of mitigation?

11. It is ok to start with the vendor’s standard contract as a template – this will speed things up. If you start with your own, you may lose a lot of time waiting for the counterparty’s legal to review it. Sometimes, they just won’t entertain it at all.

12. The key to closing a contract is in finding common points and converging on differences. It is never an “us against them”.

 13. Keep your own house legal counsel informed of the process. They may want to take a look at the contract before it is signed, in fact, it may be mandatory. If they raise points, listen to them and seek to address, but beware of situations when the “not invented here” syndrome kicks in and trivial points are raised just for the sake of it.

14. Ensure that you and your law partner are clear on fees. I strongly suggest seeking an equitable fixed fee arrangement.

15. Maintain the relationship going forward. Ask to keep you apprised about developments in technology law. They should be happy to oblige.

You have probably heard about the CHAOS  study into project failures, now 15 years old but still often quoted and referred to. Since then, a few similar studies were undertaken by larger consulting companie, but they have offered little insight beyond what CHAOS report was saying.

If you read one of these studies, you will see that they go into estimating losses from derailed projects and you may notice that they only take very large projects into the considerations, those worth millions of dollars.

In my opinion, it is not the large projects that bleed money from organizations, but the smaller stuff, tens to (at most ) low hundreds of thousands in spend that can be authorized by mid-management because they “have money in the budgets to do it” .

Larger projects, which also fail spectacularly at times, are usually carefully looked into at the inception and measured agaist the strategic objectives. They usually receive enough attention from the C-level, which ensures good governance and strong sponsorship and project management. They are usually well funded. Usually is the key word in my assertions.

By contrast, smaller projects often receive little scrutiny in respect to their alignment with strategic business objectives, are often done on a whim, suffer from the lack of sponsorship, and are  poorely managed. In my experience, such projects die in droves and with little visibility, if any.

To ensure prudent cost management today, management must divorce itself from the notion that budgets are given to them to be exhausted, but this notion has to be subscribed to and instigated from the top of the organization to be successful. The seemingly insufficient trickle of waste from smaller project turns into a sea of waste which can be prevented.

website email phone (905) 278 4753


Bookmark and Share