I had two separate conversations with two individuals who have nothing to do with one another over the past few days that has made me remember the old army adage: 'We can hang together, or we will surely hang separately.'
Who is allowed to do what?
I was chatting with a colleague this afternoon about a situation she is having in her company. She is the SQL Developer for an organization in the US, but is also an MCT and an MCSE so she knows her infrastructure as well. We will call her SQL Dev.
For the last couple of months she has been telling me (off and on) about a problem she has been having with the SQL Reporting Server. Now if you know me you know that I am no SQL specialist, but from the way she described her issue it sounded like there was an issue with the infrastructure and actual implementation of the SQL Reporting Server in question. Being one of those rare dev people who does speak IT she agreed with me.
We are in agreement that it is probably a relatively easy issue to resolve. The only problem with that is that within her organization she is the SQL Developer, and there is someone else who is in charge of infrastructure, the category under which server installation clearly falls. That person, whom we will call IT Guy, is very territorial, and refuses to let anyone else infringe upon his bailiwick. He also does not feel that SQL Dev's issue ranks very high on his list of problems to resolve. Where this becomes problematic is that SQL Dev needs this problem to be resolved before submitting work that is now overdue, which will probably benefit the entire organization, including the little corner of it that IT Guy controls.
There is a segment of the IT Professionals community who tend to put off issues that fall outside of their areas of expertise. Rather than ask a colleague for help, or even (perish the thought) allow someone to touch their servers, they let the problem sit until one of three things happens:
- The problem resolves itself on its own;
- The problem resolves itself because the person complaining finds a workaround for it; or
- The problem festers and gets worse until it grows beyond any reasonably manageable size.
We cannot be certain that this is truly the case here, but at this point all indicators seem to point to this being a distinct possibility. The problem is getting worse, there is no real workaround to be found, and though SQL Dev would have been able to resolve the issue within about an hour given the opportunity, the closely guarded bailiwick of IT Guy is sacrosanct.
Why can't we all get along?
I had a meeting with the IT Project Manager for a crown corporation in Canada with regards to that company's plans to deploy Windows Vista ® across their organization. There are roughly seven thousand desktops in the company, each with different versions of Windows® ranging from Windows 2000 Professional to Windows XP SP2. Although there are in several companies valid reasons to have multiple operating systems deployed, that does not seem to be the case here, and it is agreed upon that standardizing their systems on a single version would lower their TCO by reducing maintenance and downtime.
As a crown corporation I had assumed that they would have a proper license model in place which would include Software Assurance for their desktop OSes. With that hurdle out of the way, and with a number of projects that Microsoft Canada has to assist such companies with the costs associated with deployment, it would be a relatively inexpensive proposition for them to bring me in for a consultation to determine the best course of action. Unfortunately this is not an article about success stories, so without trying to spoil the suspense, you can imagine that something is not going to go right.
It turns out that there are a number of hurdles involved with this relatively straightforward plan, namely:
- Although the company can easily obtain the budget on a lump-sum basis to maintain their software licenses, the burocrats who control the purse strings have not been convinced of the benefits of Software Assurance, so they refuse to approve the recurring expense involved with that very beneficial plan; and
- Over the years (prior to the new Project Manager's appearance on the scene) a number of implementation projects were mishandled, and although desktop deployment should fall under a single manager's purview it currently seems to be divided among the various departments, compounded by the fact that it is an educational facility and, typical to such facilities, the end users seem to know (or think they know) better than the IT people, and will not allow anyone to wrest control of their desktops from them.
This is not to say that a deployment project is unfeasible or unlikely, only that because people – end users and department heads alike – are refusing to cede control over their systems.
How can we get things done?
These are two very clear cases in which projects are getting delayed because of territorial disputes. I will readily admit that when I was a network administrator I was extremely protective of my systems; that does not mean that when I was out of my depths – whether because of my own shortcomings or because of logical territorial boundaries – I knew that I would have to cede at least some degree of control.
As IT Professionals we can and usually do refer to them as our systems, our servers, our networks, our babies. I always felt that by taking mental ownership of our systems – by making it personal – we would feel compelled to treat them better, to do more than the minimum required maintenance, and to protect them from any threat, whether internal or external. True that this may be, we have to remember that in the end our systems belong to our organizations, and we should be working toward that organization's best interest, rather than trying to protect our own territories.
In the first case SQL Dev could have resolved the issue with relative ease. She has the necessary cross-section of skills required to do it, and knows what her requirements are so she could easily test her fixes. If IT Guy was worried that she might cause other systems to fail he could have worked with her, and probably would have learned something, thus protecting his position by increasing his value to the company, rather than just protecting his territory.
In the second case if our project manager is to succeed in working towards developing and implementing a proper deployment plan she is going to have to convince several groups that it will make their lives simpler and less costly immediately and not simply over time – and it will happen because it is a relatively simple case to make. Unfortunately because these groups are not working together she will have to spend weeks or months building her case for each business unit, time that would be much better spent actually working on her deployment.
In the simplest terms, cooperation breeds success. In 1993 Michael Jordan scored fifty points in an NBA game that his team lost. The glory of that individual achievement is marred by his team's defeat. In 1998 Mark McGwire hit seventy home runs – breaking a record that stood for thirty-seven years – and his team did not even make the playoffs. On the other hand the 1993 Montreal Canadiens did not have any one real superstar on their team, and they won the Stanley Cup.
Individual achievements look good on CVs, but the ability to work with others and meet goals looks good on performance reviews. I suspect that IT Guy will be updating his CV in the coming year, and it will not include the line 'Efficiently and properly implemented SQL Reporting Server.' It is too bad, because if it would, he would probably be due a raise. He would also likely solidify his position in the true sense, rather than some perceived notion that revolved around his turf.