Emerging Tech

Infighting in the IT department can lead to derailed projects

Constructive debate is an important component in healthy organizational dynamics. However, once a decision is made, the whole group needs to get on board and forge ahead. The CIO must clarify priorities and move the group toward that goal. Benny Sisko shares with you one story of IT infighting gone bad.

A friend of mine recently took a break from his daily routine to do some consulting for a few days. Specifically, he helped another organization roll out a new email infrastructure based on Exchange. The company was running a different system and is in the process of moving toward a Microsoft stack. Prior to his onsite visit in early May, my friend helped the organization design the new Exchange-based infrastructure after which they asked him to help them in person.

What did he find upon his arrival? There is significant infighting internally in the IT group with one group initially refusing to support a particular need. This refusal would have doomed the project, but after some wrangling, the refusing individual eventually relented and the project could move ahead. At this organization, Active Directory is apparently supported as a part of the overall responsibilities of the network group, while the Exchange system is supported by the applications group - these are different units within IT. As you know, Exchange is heavily dependent on AD, so a high level of cooperation between the two groups is essential.

A little background: The company moved toward Exchange at the specific behest of the CEO and with the full support of the CIO, who also made it a priority project. There are good reasons for the migration and the merits of the migration are not discussed in this posting.

How do some in IT feel about the migration? Evidently, some are not so happy about it. While Active Directory has been in place for a number of years, it's not been considered a critical service, nor has it been treated as such. As I mentioned, AD has been supported by the network group. This group is seriously concerned about encroachment of other applications into the AD space and appears to be particularly territorial in this regard.

Now, my friend completely understands the importance of securing the AD infrastructure, but it was relatively difficult to get things done while he was on site a few weeks ago. Although IT as a whole was completely aware that a migration to Exchange would be taking place, the network group did not prepare in any way. It was understood that some of the Exchange domain preparation work needed to be tested, but this was not done before the on-site visit. Further, no one was able to locate the Exchange media in order to extend the AD schema. Moreover, no one could locate the individual that could get the media. A comedy of errors! Finally, my friend downloaded the Exchange media and gave it to the network people along with complete instructions and implications for extending the schema. The task was completed, but it seemed to take quite a bit of what seemed to be unnecessary effort.

When it came to domain rights, it finally came down to the CIO telling the manager of the network group that he could make one of two choices (1) Make a staff person immediately available at all times throughout the term of the consultant's visit or (2) Provide a trusted member of the applications group with enough rights to be able to join Exchange servers to the domain and be able to perform any administrative and troubleshooting steps that needed to be undertaken. The network manager chose the second option.

From what my friend could tell, it looked like the network group was attempting to block the project or, at the very least, were upset that it had such an impact on their infrastructure. The word "security" was mentioned quite a number of times as well. While security is always an important consideration when rolling out any new service, "security" can also be used to accomplish the goal of task avoidance. Heck, the most secure network is the one that has every service blocked and has no users. Any time a new service is introduced that opens more ports; an organization is consciously making the decision to increase their overall attack surface with the trade-off that there will be better business processes or increased sales. I, personally, have seen the security excuse used for both positive and negative purposes. If something is going to truly endanger the organization, then tell me what we're facing so I can make a better decision. However, if you're interested in simply eliminating change and that's your primary motivation, then save it.

The result: Days of delays with an expensive consultant struggling through organizational dynamics. To be fair, the CIO at the organization was, at the time, facing a unique situation that made it difficult for him to effect some changes that could have cleared up this situation.

In my organization, when I outline an organizational priority for my staff, I expect that they will work together to see the job through. I do not expect to have to constantly get involved in interpersonal disputes and bludgeon people into doing their part. I'm more than willing and happy to listen to arguments and concerns ahead of time (and even along the way) but once the decision has been made, roadblocks should cease and solution-finding should begin.

Infighting between groups should never derail or stall a project.  Of course, there might be concerns shared between groups regarding prioritization of tasks and people, but these should be laid out at the start of the project so people know what to expect. Obviously, if the CIO is pushing the staff to do something completely ridiculous (i.e., "Hey! Let's take out the firewall to make the Internet faster!"), someone can go talk to HR or to the CEO.

Healthy debate is an integral and critical part of any project; without it, poor and incomplete decisions are made. However, if that debates turns into something more - passive aggressiveness, for example - something is wrong and the users and the organization will suffer.

What do you think? Am I full of hot air? Unreasonable? Or, does this outlook make sense?

About

Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive w...

79 comments
RealGem
RealGem

You say the network guys are concerned about the "impact on their infrastructure". That's the key point. It's not theirs. While I have to concede that the network folks are the most knowledgeable, they are also the least concerned about reaping returns from infrastructure investment. They have to realize that the network is not theirs, but is a corporate asset. Based on my experience, this is a very common misconception.

abhinawsharma
abhinawsharma

Debates and arguments are very important to bring out the best in a team. Once a decision is made then the whole team should work towards one common goal. This is true. The problem that I can think here is skill and knowledge of the decision maker and also the EQ of the decision maker. CIO and CEO can not go into details and if they listen to the debate then will incline towards either 1) the more clever or 2)towards the stream of thoughts which they can understand. I have seen it in my experience that if CIO or other decision maker is from GUI(VB,C# etc) then he.she will incline towards that group and if the decision maker is from SQL/ORACL/DB2 experience then DATA guys will be able to convince him and the final decision will depend not only on the best solution possible but also on the skill sets of the decision maker. Company suffers and also the whole team. we should have a better way to judge the best solution rather than just relying on the arguments ans discussion. I have worked on a project where 90% of the business logic is implemented in the Stored Procedures because the partner of the owner was a SQL server programmer earlier. The result is a completer failure of the project and loss of revenue and layoffs.

ovandeneede
ovandeneede

sometimes it happens between teams, sometimes even within the same team, there are more factors than territoriality, there might also be a factor of personal honor, i.e. if someone has implement a rigorous 'block' on a certain service, and has advertised it actively throughout the organisation, putting their 'weight' behind that decision and if then a certain application needs to have that service enabled, that person might think he/she risks losing 'face'... and then use all possible reasons (security indeed often being the first one as you mentioned) not to take a decision...which means a project only being half implemented or implemented with such caveats that it might become a nightmare to manage. Frustrating for the IT people involved, but in the end it is the end user who will be refused (or never offered) a service which could be beneficial for him/her..

rAllcorn
rAllcorn

I loved the article! Good points in it to follow. I'm not refuting that at all. But there are some things we have, in our development and e-progress, forgotten. Leadership. True leadership. It starts at the top. One of the most important jobs of the IT manager, and the CIO, in reality, is to generate a spirit of "team work", of "team building". If a "team spirit" cannot be accomplished, this scenario is just the beginning of time consuming, budget costing problems that will arise. Strife (arguing, constant disagreements, contention, differing ideas with no real resolution, etc.) can destroy the working environment. All of the HR forms, paperwork, rules, and procedural changes will not fix this. The manager (or the CIO, effectively) NEEDS to use some old fashion leadership (you know, what we used to use before we started to delegate the leadership to different departments) and take the bull by the horns and start building relationships with these guys. These are people. Nothing has changed. We still deal with "people". Just because you give someone an "action plan" or "direct them" towards a goal, does not mean they are going to jump onboard. It does not mean that they are going to change the way they think, or the direction they are going to lean. "THEY" must want to change, from the inside ... themselves! THEN, and only then, are you going to see the smooth flowing, free atmosphere of teamwork and productivity. - rich allcorn -

kpeters01
kpeters01

Having been in the military, I prefer the analogy that once a directive has been given you have two choices - carry out the directive or resign. Examine the first option - as a manager the last thing I want is for my boss to call me in and tell me I am not getting the job done, so rather I like the directive or not I will put a plan together to carry out the directive on time, in budget, and meeting customer expectations. That's my job. Examine the second option - if as an IT professional you disagree with the decision, for whatever reason, and you think it compromises you as a professional, then finding another job is probably a good idea. For example, I worked in an IT shop where the size of the IT service to the organization had outgrown the capabilities of the CIO. There were very significant issues coming from the user community regarding the poor service from IT. The CIO finally decided to retire and a search committee was organized to find a replacement. Unfortunately, none of the current IT managers were considered for the position because they were viewed as a part of the problem. While it is possible to look at this from various perspectives, go back to my original thought - if you believe the situation in not in your best interest as a professional then looking for another job is probably a good thing. In the meantime, the CIO has the responsibility to make sure the project is completed on time. In this case, I would venture that the CIO was not effective in his position. It is easy to be an armchair coach, however this is one of those cases where the CIO should have called in the key players and said either get this job done or else I will find someone else who can. Is that clear? Which by the way can be taken to the next level up - the CEO calls in the CIO and makes the same statement to the CIO. Perhaps even the CEO was not effective?

tracy.walters
tracy.walters

I agree that the infighting was a direct insubordination to the CIO. The managers should have stepped in early and put the rebellion to bed, there is no room to waste time on that kind of soap opera in an business environment...not if you want to stay competitive. The people who were causing the problems should have had it made clear to them that their jobs were on the line. And you folks here...I'm proud of you, not one single snide or underhanded remark about a vendor or OS. It's great to have a good discussion without degenerating into name calling. Thanks!

corneliusgoh
corneliusgoh

This is more a turf protection game within IT, with one camp worries about the other camp takes control over their 'power of control'. If I were the CIO, I swap the heads of the 2 camps, then the problem would disappear, because they would wear the other's former shoes and be more willing to cooperate. => eliminate the 'inner fear' of both camps is the job of the CIO !

LarryD4
LarryD4

Infighting is only a problem when its allowed to happen. There are CIOs, CEOs, Director's, IT Managers and even supervisors, that see this type of inter department arguing as healthy. They think that if their people are not fighting for what they want, then things aren't being pushed. This is an old school mentality which, from what I have seen, usualy stems from older CIO/Managers, +25 years in. They sort of feed in to the infighting and as with my current director, he thinks its actually a good thing. Personally I think it only adds to red tape and issues as descrbed in the article. Their is not much to do when its the higher ups that promote it, other then live with it until they retire.

CanyonR
CanyonR

"To be fair, the CIO at the organization was, at the time, facing a unique situation that made it difficult for him to effect some changes that could have cleared up this situation." I have found that it is often the case the IT Management feels that they can't fix problems or make drastic changes to remove roadblocks because of the political or personal fallout. I'm sure that this happens in other departments, but with the mix of personalities and responsibilities that make up many IT departments, I think it is more pronounced there. One common problem is the "indispensable expert". These people hold some obscure, mission critical technical details, usually only in their heads. Often these are the same people who throw up roadblocks because they see change as making their job harder or diminishing the importance of their special knowledge. IT Management is often worried about the fallout of theses "experts" leaving and so they tolerate or even enable them to cause problems for projects and co-workers that they don't agree with. This of course will eventually lead to more problems and delays than if they just left with all of their information and trouble making going with them.

Tony Hopkinson
Tony Hopkinson

No one outside can say whether there was something to fight over, and no one inside fighting can claim to be without a bias. One thing that did stand out big style is AD is not a critical service, how can this possibly be true in an integrated large scale MS offering? Love or hate AD you aren't having an integrated solution without it. So not a technical issue at all, this is Age of Empires. Somebody had a big piece of a high profile pie, and someone gave it to someone else, what can you expect but a fight? P1ss poor communication, poor planning, and a failure to make it attractive to key stakeholders is what this was. Was this derailment, or was it the coolies going on strike?

bennysisko
bennysisko

RealGem, Although there are a lot of IT staff that do claim ownership of "their" infrastructure, I think you've hit on an important point here. The infrastructure exists to support the needs of the organization - nothing more. Sure, the people responsible for maintaining the infrastructure must be involved in making change decisions related to it, but at the end of the day, it's the needs of the business that will (and should) be the driver. It's funny... one of my closest work buddies is the person responsible for our physical plant. Those folks never seem to believe that, because they're responsible for the maintenance, that they own the buildings and grounds. Benny

Tony Hopkinson
Tony Hopkinson

Oh my ribs Give up your day job, I haven't laughed that hard since I saw Lee Evans. I can't see my monitor for tears, good one. It was real gem that one.

bennysisko
bennysisko

I agree with you completely on all counts. People are the most challenging aspect for any leader and building a spirit of teamwork is essential to smooth operations. There are some people, though, that simply won't get on board and, in the spirit of "team" must be corrected, one way of the other. To me, making sure that the team on the ground operates at maximum sometimes means forcing a person off the team that is bringing everyone else down. Your thoughts?

kevaburg
kevaburg

If you don't like what you have to do then put yourself in a position where you can make the right decisions. Otherwise shut up. Resigning in the military is not an option. I know. Over 20 years in Her Majesties Armed Forces has taught me that. 5 major conflicts and leading a team that may not come back has taught me that. I have always listened to my subordinates because they also have insight that I may have missed. I have also listened to my superiors a: because I had to and b: they might also have insight. In the end though, I make the decision that affects us on the ground or I put a case forward during the Op Planning Phase. Please never tell me that I should follow blindly because that is what I should do.

Tony Hopkinson
Tony Hopkinson

Is that a special REMF option? Captain neutralise that machine gun nest. I resign! I don't think so... It's a military maxim to never issue an order that won't be obeyed is it not? Saying that "my way or the highway" is at least honest, far too often we are asked to kill our careers or engineer ourselves out of a job and treated as too thick to understand what's happening. Well I aren't that thick and seeing as you don't have the option of shooting me, you are just going to have to live with my choices, which are in my best interest.

bennysisko
bennysisko

There does come a point at which people simply need to do their jobs. As long as people have had their say and it's considered, once a decision is made, just do it. Inevitably, the project will get done with or without the people who are trying to sabotage it.

Tony Hopkinson
Tony Hopkinson

CIO knows best???? Are you for real? Most of the time their major qualification is the ability to lose convincingly at golf. You obviously spend far more time telling management what they want to hear than what they need to hear. We are subordinate to no one. The CIO in this case might have been completely right in technical and business terms strategically, tactically though, well sucks, is about as generous as you could get. People are a lot more complex and far messier than technology, and IT is nothing without them. Get your people issues sorted the tech bit will happen, the other way round you get this sort of screw up and lame ass excuses like my subordinated rebelled. Try and work on the shop floor for a bit, you'll be better for it.

Tony Hopkinson
Tony Hopkinson

All that would happen is they would reverse their positions!

bennysisko
bennysisko

There is a huge different between healthy debate and infighting. Healthy debate is generally an open, transparent undertaking with the shared goal of creating a better project or process. Infighting is simply a turf war... nothing more... and shouldn't be tolerated.

jmgarvin
jmgarvin

Some managers think infighting "makes the departments get stuff done." What they don't see is that nothing is getting done everyone is stopping everyone else from doing work. It's mind numbing having to argue and fight for a VLAN just because that's the way it is...

Deadly Ernest
Deadly Ernest

about to become part of a larger network when the new corporate purchase was integrated in the corporate gateway. My duties were to oversee the basic operations of the existing network while I documented it and then wrote up how to change it to best fit the new situation on being connected. The day I was hired the senior manager spoke with me, we left his office and collected two security guards, and took me to another office. There he introduced me to another man, he locked his computer, got up and came round the desk - I later learned he always locked his computer when someone entered his office. After the introduction the boss pulls an envelope out, saying, "Frank, here's your final pay with a month in lieu of notice. Grab your coat, you're out of here, right now." The two guards who'd been waiting outside promptly escorted him out of the building after he picked up his coat and coffee cup. The boss turns to me, "He's had two months to do what we hired you for, and done nothing. He actively fights any changes to the system. He was the company's original IT guy and all they had for many years. He has a lot of corporate knowledge of the system which we're not happy to lose, but rather that than have him do any more hindering of improvements. I suspect he may have booby trapped his computer. So try to close it down and examine it without triggering any traps if you can. This is now your office." He left after that. Frank was well liked, so I was hated for replacing him. Boy, did THAT attitude by most of the staff motivate me to get the job done quick, that and the bonus for quick completion. This happened so long ago that I was glad I'd recently heard of this thing called a Linux Live CD. I used it to examine the system, copy all the data files I could find, then reformated both drives. I took no chances with what may have been loaded. I finished the task and was out of there within four weeks, and got three months pay for my trouble, as that was the contract period. They let me go and had the job subsumed into that of an IT manager in the closest other corporate company. That incident proved to me that it is sometimes best to take the hit with lost knowledge and just push the roadblock over the side of the cliff they made. edit = O

Tony Hopkinson
Tony Hopkinson

don't just happen. They didn't get up one day and say I'm going to write a dbms or a new styling language, or recable the entire business. Someone let them, someone for intance decided to give them an entire task, to not give them someone to help, to not resource the task and have them do it in their spare time, to use someone cheap and cheerful instead of a professional. Yes, it was 'you'. I loathe working with people who've ended up in this situation, what option have they got but to fight their corner. What database did you use at your last job Tony? TonyDB, I wrote it myself. Don't call us we'll call you! :( Leave a guy with no options, he fights to the death.... You've got three options in this situation, leave it and stop whining, get rid and take the hit, or give the expert some help and the huge task of working his own stuff out of the picture, leaving him still your expert, but now in how you use a standard product. IT management never worry about the fallout until the guy has made the bomb. Should never have happened in the first place. Seen it too many times, I'm often the guy brought in to clear up the mess.

LarryD4
LarryD4

Though yes it happens all the time, the "indispensable expert", is a load of bulldinkies! If an IT Manager has one of those "indispensable experts" then they have created their own monster or may have inherited one. With proper documentation, forced if need be, you should never be so out of control that you have an "indispensable expert" that dictates policy.

b4real
b4real

It can make things go ugly.

Tony Hopkinson
Tony Hopkinson

What does being accountable mean? What does being responsible mean? And unless you own the business without share holders, how is anything in the business more your's than a junior support tech's? Why do you assume that your needs as manager are those of the business and mine as mere staff aren't? Are you saying you've never seen a boss put peronal gain in front of that of the business? You can't possibly be that naive, and I couldn't possibly be that stupid....

rAllcorn
rAllcorn

I'm with ya' on that one! Yes, "technically", it IS a Corporate Asset. But if this group is a team ... truly a "team", then they've got some ownership about this network. They have invested of their "time" into seeing that it runs smoothly, and is the best that it can be. Like anything else "corporately" built, they are going to be a bit protective. If they're not, then all you've got is a bunch of "yes men".

Tony Hopkinson
Tony Hopkinson

and the other one. It was confusing until I realised you hadn't actually understood what this guy was saying. You do know lead implies you out in front and others wanting to follow. If those aren't true, you ain't leading. Is that the fault of those you wish to follow or those who purport to lead? There's a simple trick to it, head in a direction people want to go....

bennysisko
bennysisko

I agree that you should not blindly follow a leader that is making poor decisions. However, there is a difference between a poor decision and a decision with which you don't agree. If you believe that every decision with which you don't agree must be poor, there is a likely a serious problem with your world view. I know for a fact that I don't agree with every decision made by my CEO, but I also respect his right to make the decision -- and to face any blowback that could result. Don't follow blindly... but there does come a point at which you need to decide if a particular issue is worth falling on your sword. If you really, really, really hate Exchange, for example, and wouldn't be able to stand to see it implemented and it's going to happen anyway, it's time to move on. In my comments on this post, I don't mean to imply that people should blindly follow leaders, but there is an expectation that, once a decision is made, best efforts will be undertaken to support that decision to a successful conclusion. Personally, as a CIO - and as a subordinate to my CEO - I wouldn't be able to, not should I have to, accept less from my staff and neither should my CEO expect less from me. PS - Kevaburg - this comment is not directed at you, but to all... I just happened to respond to your comment ;-)

Beoweolf
Beoweolf

The one thing I learn - worth remembering - from military service, is no matter how much you disagree with the order, once the plan is made, the orders are given; do the assigned duty to the best of your ablitity. If you still have a problem with it, then take it upstairs...with the valid reasons for your objections. Taking orders and giving orders are boots on your feet, you can't move well if one foot is dragging or refusing to move. The time to complain is before or after - never during.

Deadly Ernest
Deadly Ernest

"My way or the highway." I once had a case of being ordered by my boss (top brass' fair haired boy) to not compromise, but to totally shred my professional integrity and ethics in order to do a job he wanted done the way he wanted it done. I wrote a wells et out memo on why it should be done the other way and the issues with what he wanted done, some being legal. Got a no nonsense response, do it as I said. The next week his face was incredible when I gave him my notice and it clearly stated the reason was my refusal to compromise my person integrity on this issue. I left, he got others to do it his way. I wasn't happy about being out of work, but it was the lesser of two evils. A couple of years later I found out the top brass weren't so happy with him as my job was being advertised for filling every three to five months - he just couldn't keep anyone in it. they wondered why, but I didn't.

Tony Hopkinson
Tony Hopkinson

if you have no intention of listening. Might as well be honest and just tell them to do it or f'off. Is it sabotaging the project, or trying to make it work....

Tony Hopkinson
Tony Hopkinson

Who didn't want to resource the documentation? Who didn't want to resource an extra person for fall back? Who didn't want to pay for the off the shelf package, tuning, fitting and necessary hardware and training? Who didn't manage it? I've never seen anyone deliberately engineer a situation like this, I've seen a lot deliberately maintain it though.

Tony Hopkinson
Tony Hopkinson

So a project got derailed, can't have been that important, otherwise self interest would have kept it on track. There is a school of management that says we should subsume our own interest in favour of their's, but I don't give up anything I value to an idiot.....

Tony Hopkinson
Tony Hopkinson

and now you sound rational. This is what infighting is about, it's failure to communicate. You delegate the care and feeding of something to me, I take ownership and assume responsibility for it for you. If it all goes nipples up then I'd fully expect, that final kicking would be mine, even if you got one first. :p But then you give me a contradictory task, I tell you it's going to make my task harder or even impossible, you tell me why, and the task gets redefined. No fight required. For that to work both parties have to communicate, if one party doesn't the other can't, it's a two way process. Convincing in business is easy, we will make more money this way because, or this will cost us more because. Not I like mircosoft and you don't, or Norton is the best AV, or you got a free lunch from a vendor, or I'll have to get off my arse and do some work, for once. It's easy, all you need, is enough respect for each other to make it work, and respect is another two way street, don't give it, you don't get it. If you go down the Nike manager route "Just Do it", you'll get a fight, that was your choice and an invetible consequence of hiring people who will, can and do take their responsibilities seriously.

bennysisko
bennysisko

Keep in mind that we're talking about a relatively routine project. If staff can't be counted on to eventually get on board with even the simplest (I know Exchange can be complex, but let's keep the exact task out of it for the discussion sake) of projects, something is seriously wrong in the organization. I never make the assumption that a staff person's needs are and more or less those of the business. If I felt that an employee had different objectives - i.e. non-business needs - I'd have that person in my office to figure out what was going on. Did I miscommunicate? Does the person have a different agenda? I don't claim ownership over things like the infrastructure, but I do have overall responsibility. If the executive team has indicated that IT should make something a priority and as long as that priority has been adequately (or at least reasonably) resourced, I'm looked at as the person on the executive team responsible for getting it done. I've also seen the word ownership used and I think it can be misconstrued into something it's not. Rather, organizations are based on the idea of delegation. Ultimately, the board/CEO has responsibility for all areas of the business - sales, marketing, IT, finance, etc. Realizing the one person can't do it all, there are divisions created around the major areas and executives are hired to manage those divisions on behalf of the CEO. In IT, one person can't do everything either, so we hired DBAs, network people, technicians, programmers, etc to handle the tasks, on behalf of the CIO. Obviously, there can be additional organizational layers there, but it all works the same way. Ideas can and should be able to come from anywhere in the organizational hierarchy and if an idea makes its way to reality and is approved, it becomes an organizational priority. Hopefully, people can be trusted to say their piece and be listened to so that the best decisions can be made. There is a flawed assumption by a lot of people that goes like this: "Well, I told him why the idea won't work and he didn't listen to me so we're going ahead with it anyway." More than likely, there was a disagreement over the concern and it's possible that the CIO decided to move forward despite those concerns. Sure, it would be better if the CIO could convince the person as to a projects merits, but there are also a lot of people on this planet that would simply refuse to back down even when presented with good reasons to do so. And, yes, I have seen bosses put personal gain ahead of that of the business. Sucks, but it's life. It's another situation where you basically have to decide if it's worth fighting and possibly losing your job over - of if it's worth quitting over. I have quit over things like that in the past.

kevaburg
kevaburg

I lead by example. Following my example, others follow. I'm not talking about pleasing people or "leading by being friends". I'm talking about people having faith in a leader that they trust. It doen't matter if that person is liked. They just have to be trusted. In my experience, once the trust has been developed, the other isn't normally to far behind (although there are exceptions). The leader that pushes people forward from the rear, is the leader people will resist the hardest against.

bennysisko
bennysisko

Nah... I understood it just fine. I do try to see all sides of an issue, though.

Deadly Ernest
Deadly Ernest

go watch the 1980s movie Convoy - there's a great scene where the situation has blown up into mega proportions and the media ask Kristoffenson's character why he's leading the drivers, and he replies he's just the guy up front. Leaders lead and others choose to follow them because they are leaders.

philr
philr

I am with Tony on this one. Good leadership will always give those led the opportunity to buy-in to their vision. Sounds like he was not a leader or that he was hiding something from his people. (Need for compatability with and organisation about to conduct a take-over or something like that). A sense of mission is important. We need to be able to answer the "why question". my 2c

Tony Hopkinson
Tony Hopkinson

doesn't neceessarily mean guide to chosen detsination, it does mean persuading them to follow though as opposed to the whip from behind manouever.

rAllcorn
rAllcorn

That's not leadership. Anyone can do that. That is what God King Saul kicked out of the position as "King". He was a "people pleaser". He followed what the crowd wanted to do, instead of following the plan ... his directives from the Big Guy.

IainBegg
IainBegg

It's not about technology - A lot of the posts seem to have focused on the technical or ligical issues but you can't win an argument through logic alone, you have to deal with personalities & feelings. It's also not about top-down decisions or mandates or escalation or leadership - Many of the posts have suggested escalation to solve the problem and for the CIO to put his/her foot down but this doesn;t solve the underlying issues. In my humble opinion if you have to escalate then you've failed. Everyone in an organisation has a resonsibility to work with others to achieve results and we do this through influence & persuasion. We've all met people who are resistant to change and we've probably all resisted some changes ourselves, it's natural. But instead of escalating the problem, we should be working through the problem but seeing from the other person's (or team's) perspective, understanding their concerns, addressing them where we can or empathising where we can't. I've often used the phrase "We're a team we either succeed together or fail together, what's it going to be?" - this is effective at breaking down competitive barriers and to find constructive ways forward. When we've tried these techniques in an un-emotional and constructive way and still they've failed, then by all means escalate but in my opinion "Escalation should be a LAST resort, not a FIRST resort". Leadership from the CIO should encourage these behaviours as being important in a mature team-based organisation - more important than technology which keeps changing anyway. And a quick footnote on why I like your attitude - it's because you implicity recognise that to achieve results you need both decisions and actions. The equation is Decision + Action = Results! If you continually challenge the Decision you won't achieve the results. And even a poor decision well implemented will achieve some degree of success. When I hire staff, I believe that Attitude is more important than Aptitude - if you have the former, the latter can easily be learned, however the reverse is sadly not always true. P.S. We have develop a suite of Training Courses entitled "The Art of..." since it is the People-Skills that will make or break a Projectised Organisation. I'll be very interested in your opinions on the above?

Beoweolf
Beoweolf

However, nothing is that cut 'n dry. Management should have a review before implmentation, set out timetables, responiblities, backup and backout plans, pilot programs....Then upon the termination of the project; sucessful or not ... should have another meeting to discuss what went right, wrong, could be improved and generally dissect what happend. More often than not - few IT groups have a formal policy in place to open or close a project. Thats a big mistake. Triage/dissection is a good thing - It doesn't have to be a suit and tie, big deal; rules of order and all the trappings, but it does need to address and document what was attempted and what were the results... and close all the documentation that went into the process. As IT pros, we can no longer toss projects out to "joe" while walking down the hall and expect reasonable results.

Tony Hopkinson
Tony Hopkinson

and a bad one. Is do you get input before (very rare in my experience, HR are more likely to get a say). And if after more of a review than a complaint, do you and management and any one else vaguely involved learn. Even if it's not to trample all over the sensibilities of your people just because you can. If you don't resolve any issues before, the only time I'm going to shut up is if I turn out to be wrong, which admittedly has happened. Don't tell me though, show me. I've had far too many managers who've proven to be complete arses, to simply take their word for it. I know that the military can't afford that, I was in, not for long though, for some reason. :p

Tony Hopkinson
Tony Hopkinson

Don't confuse listening with hearing. Just continuing on with out explaining why you've made that decision is not listening, after all I might as well have kept my gob shut. You've got to tell me why. I'll admit that's a problem if the issue is. If I do that you won't need me anymore, and that's the plan.... IT's worst disasters all proceed from poor assumptions. A good boss won't assume he's been understood nor will a good tech. I'm a good tech, are you a good boss?

bennysisko
bennysisko

You seem to make the assumption that asking for feedback and still continuing down a contrary path means that I haven't listened to the feedback. Quite simply, it probably means that I haven't agreed and there is a big difference between "not listening" and "not agreeing". Both sides need to make compelling arguments. If someone makes a good case, I'm more than happy to listen and adjust as necessary to make sure that projects come off the best they can.

bennysisko
bennysisko

In this particular case, the infrastructure group did not like the app group needing such deep integration with AD... it had nothing to do with "religion" but was a group of very stubborn people well entrenched in the organization. One group - the app group - was onboard and had responsibility for the project, as per the CIO and CEO, who (like it or not) are responsible for setting priorities.

Tony Hopkinson
Tony Hopkinson

This is if we do this I won't have a job anymore, or I won't want the job anymore, or it will will marginalise me on the market reducing future employment potential. This is it will look really cool on my resume so I can get promoted internally or get a better job. This is being the new broom, this if safeguarding the borders of the empire. If any one of the players your current implementation plan needs to play ball, is going to sulk and take it home, it has to be addressed. Get rid of them now, retraining, cancellation, transfer, change the perception, blackmail, threats of violence, but do something. Sit there in your office and hope everybody scarifices their interest no matter what their reasoning for yours, well that's at best naive, is it not? It's completely lack of management understanding, successful project management is all about getting and maximising the necessary buy in. If you aren't doing that you are merely that guy who produces charts full of smileys.

greyopz
greyopz

but when ego is presented as self interest, the value of this arguement collapses. in an IT infrastructure , especially where departments are competing, ego is usually the driving force. Most arguemnts devolve to whose OS or Systems (ie their religion) have either the most supporters or loudest supplicants, and in many of these cases, there is no arguement that will sway them either, so it is not just a "lack of management undestanding" that dooms a lot of these projects. If neither team is able to put aside blind ideologies and deal in logic and fact, the infrastructure will never be capable of supporting any project, regardless of its scope or value.

Editor's Picks