Up until the 1990s, when an IT project failed, you could always blame the technology, according to Daryl Conner, chairman and cofounder of Conner Partners. Today, your client’s ability to accept and best utilize the IT projects you bring to the table is the best indicator of success.
For a project to be beneficial, employees must embrace the new systems and actually use them. Realization, then, is the new measure of project success, as even projects that are successfully installed may still fail to produce their intended benefits unless attention is paid to your client’s workplace.
In this article, we’ll give you some tools to assess your client’s ability to cope with the change brought about by a major IT project. The assessment should include three “Rs”: roles, resistance, and resilience.
Roles: Why sponsorship is critical
Sometimes the web of informal relationships in a company is more significant than the official organization chart in determining how a change is adopted. In his book Managing at the Speed of Change: How Resilient Managers Succeed and Prosper Where Others Fail, Conner identifies the following roles that people play during a change project:
Targets are those who are being asked to change. People at every level are affected by change — even top management, who may not realize that they, too, will have to change their behavior due to a project they initiated.
Sponsors have the power to influence people to change, both by communicating the reasons for the project and by setting consequences for adopting or failing to adopt it. But beware: The sponsor may be someone other than the boss. A union representative or respected coworker may have more influence over people’s actual behavior than management rhetoric.
Change agents are charged with actually implementing the change on behalf of the sponsors. This is the most common role for a consultant.
Advocates want to see a change occur, but they lack the ability to sponsor it.
These roles may change as the project progresses. A manager who is the target of a change initiated by the CEO may become the sponsor of that change to those who report to him or her. When a consultant initially proposes a change, he or she takes on the advocate role. If the proposal is accepted and the consultant is asked to implement it, the consultant becomes the change agent.
In an interview with TechRepublic, Conner suggested identifying who is playing which roles in the project. Speaking about the advocate role, he advised consultants to beware of advocates with checkbooks. He cautions that although advocates may want a change badly enough to start a project, without real influence over the behavior of those who have to do the changing, their projects will fizzle. “It’s not hard to start a change; it’s just hard to sustain it,” Conner said.
Resistance: It’s inevitable, so make it open
All changes disrupt people’s expectations. Even desirable changes, such as getting a promotion or getting married, bring with them unintended consequences. Conner argues that workplace changes are no different than major changes in one’s personal life: We expect to live in equilibrium, so when change disrupts that equilibrium, we resist the change to minimize the disruption.
With this in mind, you can assume that resistance to implementing a project is inevitable. The key question is whether that resistance will be overt or hidden. Overt resistance, in the form of complaints or criticism, is much easier to work through and provides valuable feedback to the project team. Hidden resistance, such as spreading rumors or outright sabotage, is difficult to detect until it’s already done significant damage.
Ask yourself if your client’s organization encourages dissent or if its culture tends to drive dissent underground. A lack of open resistance is a danger signal. If you don’t see any signs of resistance, work to draw it out into the open. If people have a constructive way to express their concerns, you will more likely be able to respond to such resistance.
Resilience: Gauge the organization’s capacity to change
Resilience is the ability to absorb major change without showing dysfunctional behavior. Just as a sponge can only hold a certain amount of water, people have limits as to the amount of change they can process. ODR, Inc. (which is now Conner Partners) tracks 29 different attributes that resilient people possess, which fall into the following five categories:
Positive: They believe they can succeed, even when faced with the ambiguity that accompanies change.
Focused: They keep the end goal in mind and let it drive their decisions.
Creative: They stay flexible when the landscape shifts under their feet.
Organized: They are able to impose structure on the chaos surrounding them.
Proactive: They embrace ambiguity as part of the process instead of wasting energy running away from it.
In extreme cases, consider turning down projects for which the capacity for change just isn’t there.
Conner argues that there’s nothing wrong with taking on installation-only projects, for example, as long as that expectation is set up front. The problem comes when a client is ready to write the check, expecting to realize a certain benefit, but the organization can’t support more than installation.
According to Conner, consultants who work on developing their own ability to absorb change will be more valuable to their clients. “Consultants are at a disadvantage if they’re trying to help other people through change if they’re not resilient themselves,” Conner said.
As you work with a client, try to get a feel for the capacity for change of the organization’s people. If they’re facing multiple major changes already, it’s not likely that they will be able to appropriately process the change associated with this additional project.
Friday, May 21, 2010
Thursday, May 20, 2010
Talking business: Three reasons why your opinion is being ignored
IT leaders and their staff must act assertively, if their words are to have any weight, and establish themselves as the authority in all decision-making involving IT. Here are three ways to do it.
——————————————————————————————————————-
Here is a typical issue that IT professionals, managers, and even executives experience: They often feel they are not listened to by their business counterparts and decision makers.
A typical scenario goes like this: A meeting is called to discuss acquisition of a new mission critical application. The business side of the organization favors a solution that seems to offer the widest range of functionality. The IT representative (this could be a CIO or an application developer or anyone in between) is aware of serious limitations of the underlying technology and lets the business know of his concerns. Kindly thanked for his contribution, he finds out later that the decision was made against his advice.
Some time later, the organization finds that the technical limitations they were warned about are a great hindrance. It may be that integration with other systems is painfully difficult or the application data cannot be accessed easily or the application fails sporadically or any one of a million other things that could go wrong. The business feels hamstrung by the inefficient technology, while IT support costs skyrocket and IT staff is unable to work on anything else. The business wants a replacement, IT is blamed for being unable to support business needs and the cycle starts again.
Does this sound familiar?
Because this problem is so pervasive, a significant part of my consulting work is devoted to enabling IT management and professionals to communicate with the business effectively. In my experience, among the reasons for the voice of IT to be ignored, there are three that transpire in most if not all cases:
Lack of business knowledge
Using the wrong language
Lack of assertiveness
Let me explain what’s behind these points.
Business knowledge
Imagine that having developed the sniffles, you decide to see a doctor. At the clinic, a physician greets you and without saying a word, proceeds to writes a prescription. What? Without asking about your symptoms and looking at your health history? Without checking some key “metrics,” such as whether your lungs are clear and the heartbeat is normal? Absurd!
Yet time after time I come across projects that are proposed (and, often, initiated and executed) by IT departments without much consideration for the current economic climate, the state of their organization’s industry, and the needs and priorities of the company. I believe that this is the key reason why in so many organizations the CIO plays a second fiddle to the rest of the C-level ensemble.
If this is how things play out in your organization, know that this condition is curable. Whether you’re a network administrator, a project manager, or a CIO, for your words to be taken seriously, you need to be able to converse on business topics, demonstrate your knowledge and appreciation of current business challenges, and be able to introduce ideas that are relevant, exciting, and profitable. By doing so, you will establish your credibility and people will start listening to what you say (and may even hang on every word, if you are seriously good).
Language
You have every right to be concerned over the lack of transactional integrity in the vendor’s application or the fact that the vendor suggests rebuilding all indices a couple of times a month. Let me assure you that these words usually mean nothing to your business counterparts. Voice your concerns using these terms and people’s eyes will glaze over. They will nod politely and may even appear mildly concerned, rarely asking for clarification for the fear of appearing incompetent. The problem, however, is this language fails to relay your message with the sense of importance and urgency it deserves.
The key to making your words impactful is translating them from IT argot into business language. The best way to explain what I mean is by the way of an example. How should you relay your concerns about the lack of transactional integrity? I think something like this should work:
“The application design does not prevent complete transactions. Our customers may receive goods for which they have not paid. We may fail to ship equipment that has been paid for, jeopardizing our service levels and opening the door to contract penalties. And we will never know for sure how much inventory we have on hand.”
Now, all of a sudden, your message can be understood because such nightmare is easy to visualize from a business point of view and most shareholders will want to avoid it at all costs.
Here are some more before and after examples, just to re-enforce the point.
Before: “This call center application is buggy.”
After: “While on the phone with customers, agents will experience delays in processing orders and at times will be unable to complete a sale. Our revenues will go down, our cost of sales will skyrocket, and our image will suffer. We will lose sales and customers.”
Before: “The application will not scale.”
After: “It’s an adequate solution if we believe that the volume of business will remain the same or decrease. If we hope to develop this line of business, we must look for an alternative”
Before: “This DRP solution does not provide sufficient client data redundancy.”
After: “There is a distinct possibility that we will lose all of our sales data without a chance of recovery. We won’t know what we sold and to whom and what is owed to us and how much we owe to our suppliers. If you think that year-end is stressful today, it will be a picnic compared to what it may become if this scenario comes true.”
Before: “Customer address is manually entered into a free-text field, which is not a good way to do it.”
After: “You won’t be able to base your marketing decisions on objective information about clients and their location. I’m sure we want to spend scarce advertisement dollars in the areas where sufficient ROI is assured.”
Before: “For this advertised functionality to become useful to us, we need to do a lot of development.”
After: “We need to budget another $300K if we want to use this feature.”
Before: “We won’t be able to use QoS on this network segment.”
After: “We won’t be able to utilize this connection effectively and accommodate the evolving needs of the business.”
Get the idea? Give it a try today and see how much difference this approach makes.
Assertiveness
Today, most people know a little bit about computers and have ideas on what IT people actually do all day long. In the corporate setting, few business executives would admit that IT is something that they just might not understand to the degree necessary for decisions involving technology considerations.
In my observation, IT professionals and management seem to forget at times who the IT authority within the organization is. If it is inconceivable for a CIO to tell the marketing head how to run advertisement campaigns, why is it a widespread occurrence that IT departments have become order takers, being told what solution to implement and which vendor to select? What an unfortunate position to be in–not a trusted advisor and valuable asset but merely an implementer, an expense item on the income statement.
IT leaders and their staff must act assertively, if their words are to have any weight, and establish themselves as the authority in all decision-making involving IT. They must work to address business problems and opportunities, looking at the business content and applying innovative solutions. They must educate their business counterparts on the new developments in the IT and explore their application together.
Do not allow solutions to be foisted on you. It attenuates your department’s value and status within the organization and, above all, leads to misguided projects and missed business opportunities.
The three key factors discussed today can be effectively addressed in most settings, generating positive energy, revitalizing IT departments and delivering great value to the organization and its shareholders. Start changing today - and let me know how it goes.
——————————————————————————————————————-
Here is a typical issue that IT professionals, managers, and even executives experience: They often feel they are not listened to by their business counterparts and decision makers.
A typical scenario goes like this: A meeting is called to discuss acquisition of a new mission critical application. The business side of the organization favors a solution that seems to offer the widest range of functionality. The IT representative (this could be a CIO or an application developer or anyone in between) is aware of serious limitations of the underlying technology and lets the business know of his concerns. Kindly thanked for his contribution, he finds out later that the decision was made against his advice.
Some time later, the organization finds that the technical limitations they were warned about are a great hindrance. It may be that integration with other systems is painfully difficult or the application data cannot be accessed easily or the application fails sporadically or any one of a million other things that could go wrong. The business feels hamstrung by the inefficient technology, while IT support costs skyrocket and IT staff is unable to work on anything else. The business wants a replacement, IT is blamed for being unable to support business needs and the cycle starts again.
Does this sound familiar?
Because this problem is so pervasive, a significant part of my consulting work is devoted to enabling IT management and professionals to communicate with the business effectively. In my experience, among the reasons for the voice of IT to be ignored, there are three that transpire in most if not all cases:
Lack of business knowledge
Using the wrong language
Lack of assertiveness
Let me explain what’s behind these points.
Business knowledge
Imagine that having developed the sniffles, you decide to see a doctor. At the clinic, a physician greets you and without saying a word, proceeds to writes a prescription. What? Without asking about your symptoms and looking at your health history? Without checking some key “metrics,” such as whether your lungs are clear and the heartbeat is normal? Absurd!
Yet time after time I come across projects that are proposed (and, often, initiated and executed) by IT departments without much consideration for the current economic climate, the state of their organization’s industry, and the needs and priorities of the company. I believe that this is the key reason why in so many organizations the CIO plays a second fiddle to the rest of the C-level ensemble.
If this is how things play out in your organization, know that this condition is curable. Whether you’re a network administrator, a project manager, or a CIO, for your words to be taken seriously, you need to be able to converse on business topics, demonstrate your knowledge and appreciation of current business challenges, and be able to introduce ideas that are relevant, exciting, and profitable. By doing so, you will establish your credibility and people will start listening to what you say (and may even hang on every word, if you are seriously good).
Language
You have every right to be concerned over the lack of transactional integrity in the vendor’s application or the fact that the vendor suggests rebuilding all indices a couple of times a month. Let me assure you that these words usually mean nothing to your business counterparts. Voice your concerns using these terms and people’s eyes will glaze over. They will nod politely and may even appear mildly concerned, rarely asking for clarification for the fear of appearing incompetent. The problem, however, is this language fails to relay your message with the sense of importance and urgency it deserves.
The key to making your words impactful is translating them from IT argot into business language. The best way to explain what I mean is by the way of an example. How should you relay your concerns about the lack of transactional integrity? I think something like this should work:
“The application design does not prevent complete transactions. Our customers may receive goods for which they have not paid. We may fail to ship equipment that has been paid for, jeopardizing our service levels and opening the door to contract penalties. And we will never know for sure how much inventory we have on hand.”
Now, all of a sudden, your message can be understood because such nightmare is easy to visualize from a business point of view and most shareholders will want to avoid it at all costs.
Here are some more before and after examples, just to re-enforce the point.
Before: “This call center application is buggy.”
After: “While on the phone with customers, agents will experience delays in processing orders and at times will be unable to complete a sale. Our revenues will go down, our cost of sales will skyrocket, and our image will suffer. We will lose sales and customers.”
Before: “The application will not scale.”
After: “It’s an adequate solution if we believe that the volume of business will remain the same or decrease. If we hope to develop this line of business, we must look for an alternative”
Before: “This DRP solution does not provide sufficient client data redundancy.”
After: “There is a distinct possibility that we will lose all of our sales data without a chance of recovery. We won’t know what we sold and to whom and what is owed to us and how much we owe to our suppliers. If you think that year-end is stressful today, it will be a picnic compared to what it may become if this scenario comes true.”
Before: “Customer address is manually entered into a free-text field, which is not a good way to do it.”
After: “You won’t be able to base your marketing decisions on objective information about clients and their location. I’m sure we want to spend scarce advertisement dollars in the areas where sufficient ROI is assured.”
Before: “For this advertised functionality to become useful to us, we need to do a lot of development.”
After: “We need to budget another $300K if we want to use this feature.”
Before: “We won’t be able to use QoS on this network segment.”
After: “We won’t be able to utilize this connection effectively and accommodate the evolving needs of the business.”
Get the idea? Give it a try today and see how much difference this approach makes.
Assertiveness
Today, most people know a little bit about computers and have ideas on what IT people actually do all day long. In the corporate setting, few business executives would admit that IT is something that they just might not understand to the degree necessary for decisions involving technology considerations.
In my observation, IT professionals and management seem to forget at times who the IT authority within the organization is. If it is inconceivable for a CIO to tell the marketing head how to run advertisement campaigns, why is it a widespread occurrence that IT departments have become order takers, being told what solution to implement and which vendor to select? What an unfortunate position to be in–not a trusted advisor and valuable asset but merely an implementer, an expense item on the income statement.
IT leaders and their staff must act assertively, if their words are to have any weight, and establish themselves as the authority in all decision-making involving IT. They must work to address business problems and opportunities, looking at the business content and applying innovative solutions. They must educate their business counterparts on the new developments in the IT and explore their application together.
Do not allow solutions to be foisted on you. It attenuates your department’s value and status within the organization and, above all, leads to misguided projects and missed business opportunities.
The three key factors discussed today can be effectively addressed in most settings, generating positive energy, revitalizing IT departments and delivering great value to the organization and its shareholders. Start changing today - and let me know how it goes.
Wednesday, May 19, 2010
12 tips for arguing a point!
So, here we go.
Realize that a dialogue should not be about you, the opponent, the turf, or the superiority but about making the right decision. Accept the fact that you just might be wrong and treat the opposition with respect.
There are two parts to every argument: A position and a bunch of points that support it. Always separate them and be clear on them both. "I support solution A. The reasons for my recommendation are as follows." On the flip side, learn to identify and separate these two parts in your opponent's argument. If you can't do so reliably, ask for clarification.
Never accept an argument that you don't understand. Ask for clarification.
To each decision, there are objectives (what we want to achieve) and alternatives (how we can achieve it). Are you disagreeing on the objectives or on the alternatives? Make it clear and ask the opponent to clarify their position. This is very important as often there is a lengthy raging battle over easily reconcilable implementation preferences.
Not to belabor this, but.choose the language both you and your opponent understand.
When you make your point, nothing is as effective as the masterful command of the language and use of relevant examples and metaphors.
Often, your opponent will pass his beliefs and opinions for an unquestionable truth. So, be on guard for and readily reject ad hominem attacks (when your opponent targets your persona and not your argument). For example: "I don't see how this approach can ever work, coming from someone who can't control his weight, let alone an initiative of this importance!"
Watch out for arguments that say that something is right just because it is either new or old. These are known as ad novitam and ad antiquam arguments.
Don't fall for arguments that rely on wide acceptance and popularity. What's right for many is not necessarily right for you, even if the others are in the same industry, market, or building.
Beware of the straw man attacks, which happen when the opposition objects not to your position but to a similar but much weaker and sometimes ridiculous one. For instance, you say: "I am of the opinion that this application will not resolve the issue, because." Your opponent retorts, ignoring your argument: "Julie, of all people, I wouldn't expect to hear it from the CIO that high technology is not the way to go!"
Red herring anyone? Watch for arguments with little to no connection to the issue at stake, which are introduced to misdirect the attention of you and the rest of the audience. This also often happens inadvertently.
Sometimes you may lose on the basis of unobtainable perfection. Your way may be the best available but not perfect, while "perfect" is either out of the question or not viable, such as due to prohibitive costs. When you feel that the conversation has fallen into this rut, call a spade a spade, invite the other party to acknowledge that perfection is not possible, and talk about mitigation of the imperfections. You may still lose this battle, but you'll know you have done your best.
You have probably noticed that in a number of points I advised you to "watch out" or "beware of" or to "be on guard" against various acts of chicanery. It goes without saying that you shouldn't commit these transgressions either. The Golden Rule applies.
Realize that a dialogue should not be about you, the opponent, the turf, or the superiority but about making the right decision. Accept the fact that you just might be wrong and treat the opposition with respect.
There are two parts to every argument: A position and a bunch of points that support it. Always separate them and be clear on them both. "I support solution A. The reasons for my recommendation are as follows." On the flip side, learn to identify and separate these two parts in your opponent's argument. If you can't do so reliably, ask for clarification.
Never accept an argument that you don't understand. Ask for clarification.
To each decision, there are objectives (what we want to achieve) and alternatives (how we can achieve it). Are you disagreeing on the objectives or on the alternatives? Make it clear and ask the opponent to clarify their position. This is very important as often there is a lengthy raging battle over easily reconcilable implementation preferences.
Not to belabor this, but.choose the language both you and your opponent understand.
When you make your point, nothing is as effective as the masterful command of the language and use of relevant examples and metaphors.
Often, your opponent will pass his beliefs and opinions for an unquestionable truth. So, be on guard for and readily reject ad hominem attacks (when your opponent targets your persona and not your argument). For example: "I don't see how this approach can ever work, coming from someone who can't control his weight, let alone an initiative of this importance!"
Watch out for arguments that say that something is right just because it is either new or old. These are known as ad novitam and ad antiquam arguments.
Don't fall for arguments that rely on wide acceptance and popularity. What's right for many is not necessarily right for you, even if the others are in the same industry, market, or building.
Beware of the straw man attacks, which happen when the opposition objects not to your position but to a similar but much weaker and sometimes ridiculous one. For instance, you say: "I am of the opinion that this application will not resolve the issue, because." Your opponent retorts, ignoring your argument: "Julie, of all people, I wouldn't expect to hear it from the CIO that high technology is not the way to go!"
Red herring anyone? Watch for arguments with little to no connection to the issue at stake, which are introduced to misdirect the attention of you and the rest of the audience. This also often happens inadvertently.
Sometimes you may lose on the basis of unobtainable perfection. Your way may be the best available but not perfect, while "perfect" is either out of the question or not viable, such as due to prohibitive costs. When you feel that the conversation has fallen into this rut, call a spade a spade, invite the other party to acknowledge that perfection is not possible, and talk about mitigation of the imperfections. You may still lose this battle, but you'll know you have done your best.
You have probably noticed that in a number of points I advised you to "watch out" or "beware of" or to "be on guard" against various acts of chicanery. It goes without saying that you shouldn't commit these transgressions either. The Golden Rule applies.
Subscribe to:
Comments (Atom)
Posts
