Archive for 'IT Management'

CIO reports that Robert Half Technology has published the results of a study on IT project plans as the economy turns around. 1,400 CIOs were interviewed and here are some of the results:

[...] 37% intend to implement software and hardware upgrades that had been deferred due to poor economic conditions in 2009. Another 16% plan to roll out virtualization projects that were previously shelved, and the same percentage of IT leaders polled said Web site design initiatives would get the go ahead following an economic recovery.

These new IT projects include cloud computing and social media initiatives. Interestingly enough, our CEO recently published an article on how you can be ready for the recovery by prioritizing and executing projects that are coming off the bench.

Which of your IT projects might come back into play now that the recession is nearing its end?

The Requirements Network has an excellent article out on the necessity of well-developed requirements for any project. The author likens requirements gathering today to the popular 90s sitcom, “Seinfeld,” writing:

In a nutshell, we approach requirements the same way we approach any other communication or conversation. When you think about it, most communications and conversations are one-sided and egocentric. Seinfeld was an excellent example of multiple people carrying on conversations in the same room without either listening or being heard. Translate this into requirements gathering and you get ambiguity, miscommunication and missed requirements.

She goes on to recommend that requirements gathering adhere to the SMART philosophy, meaning that requirements must be Specific, Measurable, Achievable, Repeatable and Timed in order to succeed. She argues that there wouldn’t be such a dismal IT project failure rate if organizations adhered to this formula. Do you agree?

Many of us will face the day when we are assigned a project that we are not equipped for. Rather than letting it ruin our careers, TechRepublic suggests a 5-step plan for taking on the project and driving it to success.

1. Make the project a priority from the start.
2. Commit talented people to the project.
3. Get over the learning curve as fast as possible.
4. Plan the project work but adjust quickly.
5. Keep communicating.

The writer also encourages readers to keep in mind that it is often highly visible, challenging projects like this that can launch your career to a new level. Rather than run from it, IT professionals and project managers should embrace the opportunity.

Over at TechRepublic’s IT Leadership blog, Rick Freedman has written about the importance of not only focusing on projects in themselves, but also to understand the core business strategy that fuels the portfolio. He writes:

Here are my three best practice tips for keeping the overall project strategy in mind:

* Participate: The best scenario is one in which IT has a seat at the table as corporate objectives and strategies are being devised. Even if you aren’t invited to the strategy meeting, you can still contribute by posting your ideas and opinions in forums, suggestion programs, user committees, online communities, and various social media outlets.

* Study: Learn what directions your organization is thinking about taking in the future. Many enterprises have internal communication programs that are set up to ensure that all associates have a clear idea of the overall corporate strategy. Publicly traded companies must report to the SEC, and these reports are gold mines of data about the strategies, challenges, and risks associated with the company’s market, competitive position, and product mix. So are analyst opinions, which often cut to the heart of the challenges with a company’s strategies. In addition, trade magazines are one of the deepest sources of data on the risks, concerns, and opportunities in a particular vertical market, and they provide budding corporate strategists with plenty of great ideas about what the competition is doing and about what IT can bring to your firm.

* Think strategically: IT professionals and project managers who can think past their project and can see the entire context of the organization’s portfolio and strategy, are enabled to make the right decisions at every level of the project, from selecting the right components to pilot in a prototype or early iteration, to determining which projects should live or die depending on their overall contribution potential.

Most IT professionals know that project failure is a common and serious problem in organizations of all kinds. New research attempts to quantify the extent of IT failure in the worldwide economy.

Most IT failure research seeks to determine the percentage of projects that run over-budget, are late, or do not deliver expected results. While those numbers are important, they do not convey a concrete sense of the overall cost impact created by failed IT.

Read more at IT Project Failures.

I was at the store the other day to pick up a few items. I found what I wanted and walked to the front checkout counters. There I found a long line of people waiting to be checked out. I had spent a year with a personal coach working on patience so I didn’t let this bother me. Instead I drifted into thoughts of queuing theory. If you don’t understand queuing theory I am sure you can find thousands of articles and white papers on the topic. But it might be easier for you to grab one of your portable lawn chairs and go sit at the checkout counters of most any retail store. If you don’t get thrown out as a vagrant you can watch what happens throughout the course of the day.

You will notice there will be times where there are few or no people in line. People will arrive randomly and there will not be much wait time for any customer. Then there will be other times when many people arrive at the checkout counters at nearly the same time. At this point those random people that were arriving earlier continue to arrive and the lines get longer. (It seems that this is always the time that I arrive but I am patient thanks to my coach, Carly.) Finally these customers find their way out the door and you don’t see another customer for 15 minutes or longer. Why does all this happen? Queuing theory.

Read more at the IT Project Management Blog.

IT projects herald the age of global networking. Great shifts are taking place in project management which has been catalytically influenced by the advent of global network formation.

The formation of global networks implies that managing projects is no longer bound by local parameters. Global networks thrive on diversity – Finding and connecting resources on the entire globe, then consolidating them for a common purpose. Networking enables a gravitation of skills, resources or materials from different formats of alliances which are formed and configured any which way we choose, to benefit or influence the project positively.

Read the article at PM World Today.

Only a third of IT PMOs will ever work, and the rest of ‘em won’t. For the mathematically challenged, such as myself, that means that two-thirds of all the IT project management offices (or programme management offices, or whatever you want to call them) will fail. Nothing scientific in these numbers, mind you, and I didn’t do an extensive survey, this is just what I’ve seen myself, and you’re going to have to take it (or not) on faith.

In my line of business, I see lots and lots of PMOs – in fact, I’d say that they’ve become almost fashionable in the last couple of years; you can’t seem to turn around without someone setting up, re-energising or re-engineering an IT PMO. There’s even a conference or two dedicated exclusively to IT PMOs; one recently wrapped up in Savannah, Ga. And I’ll bet some expert in Savannah told the attendees: “Two-thirds of PMOs will fail, present company excepted, of course.”

Think about the implications: that’s a significant amount of time and money that major organisations are putting into the idea of improving their project management practices (that’s good) and two-thirds of it is going down the drain (that’s bad). That’s two-thirds of the IS organisations who are ticked off with their PMOs and the people in it. That’s two-thirds of a whole bunch of good opportunities being wasted.

Why the dismal number? That’s easy: ’cause most PMOs are set up for the wrong reasons. Period. End of column. That’s it.

Read more at Project Smart.

Hello, Gentle Reader. Can I ask you a question? Do you have any children?

I remember when my son was 2 years old. He seemed to think that just because he wanted something, he should be able to have it. You couldn’t reason with him; he was only two. If you didn’t give him what he wanted, he would throw a temper tantrum. Sometimes his mother would give him whatever he wanted just to shut him up. That never helped. It just created a larger sense of entitlemtent for the next time, and there was no argument against it, since she had just given in.

Alright, I don’t actually have a son, but I’ve known plenty of kids who acted just like that (myself included). All children act that way at some point in their early lives, when they’ve not yet “gotten over” themselves, and when they still think that the entire world revolves around them. It’s called egocentrism, and Piaget theorizes that this stage occurs somewhere between the ages of 2 and 7.

On a completely unrelated note, I was talking with my McUsers the other day (all 4 of them) and they suggested that since we have “so many” Macintosh users these days, perhaps IT ought to give them special software and special considerations. Now I understand that Messiah Jobs has recreated our childlike sense of wonder, but did it necessarily require a childlike sense of math to come along with it? Let’s put it this way. Assuming I have 10 employees at Journyx (we have more), you’re still 40%, and only 40%. While it’s a relatively-large tail in such a situation, it’s still not large enough to wag the dog, children.

As I denied this request, I had one of the McChildren say to me, “But I’m a special case.” Oh, yes. Of course. I completely forgot the “special case” clause. You see, this particular developer has development environments installed on his personal, not-backed-up workstation rather than the RAID-ed and network-monitored VM build station which others use. Yessiree, Bob! You’re a special case alright. You’re just Yet Another Damn Mac User (YADMU) who ignores policies and procedures because they just don’t apply to you.

After this conversation, I then had 2 of the YADMUs come to me individually to “present their case” for why they should be given special treatment, special hardware, and special software. I spent the next 30-40 minutes attempting to blow them off while they treated me like a special specimen who should probably be wearing a helmet. I finally resorted to the 1st Law of IT: If you ignore them, they eventually leave. They did. That was nice.

Personally, I have nothing against the Macintosh. Actually, I think that Apple has put out a pretty fantastic product. It’s just that I believe strongly in the proper tool for the job. Breaking down my 4 Mac users in the company, we have “the web guy” which makes sense since he’s producing content and posting web stuff, and it makes his life easier. We have 2 professional services coders, and that makes perfect sense, since they… umm… spend most of their time in a terminal window… on a Linux server… writing code. Okay, maybe that doesn’t make any sense. Finally, we have a developer. See the part about the professional services coders, except this guy also builds our Windows installation on his Mac. While that’s a “neat” thing to be able to do, I certainly wouldn’t chock it up under “business-critical” when an equivalent Windows machine costs roughly 20% of what his Macintosh cost. Oh, we also have a couple remote users who use Macintosh, but they don’t count since they’re not here.

I guess what I’m getting at, here, is that I have nearly 100 machines up and running in our infrastructure at any given time. You’re a lousy 4%, guys. 6% if you include the remote folks. 2% if you only include people who actually NEED a Macintosh to perform their job more effectively. And, you know what? In most companies these percentages are going to be about the same, so where do you get off with a childlike sense of entitlement?

Oh, I forgot. You’re a special case.

Hello Gentle Reader. This month I am going to regale you with some of the top “rights” that people seem to assume they have, as seen from an IT perspective. I’m sure you all know some of these people.

1. I have the right to do 50% less of a job and assume that someone else will clean it up.

Wow. I don’t even know where to go with this one. I should have started with something else.

No, really, you don’t. You do not have the right to do half of a job just because you think it might be easier for someone in IT to complete it for you. This reminds me of working at UT when frazzled freshmen would come running into the lab at the Zero Hour needing a computer and waving a sheaf of papers, begging me to do everything but actually type their paper which was about to be late. They were 17 or 18 years old; I sort of expect it from someone that age, but after that? Really, people?

2. I have the right to a 2nd (or 3rd) monitor because someone down the hall has one.

No. No, you don’t. If you need extended real-estate for some BUSINESS reason, we can probably make that happen, but unless the business makes the standard desktop setup include 2 monitors, you don’t have any right to that whatsoever. Citing that “so-and-so has an extra monitor,” doesn’t work for two reasons. First, in all likelihood, “so-and-so” needs two monitors, and that would be why it’s there. Second, I assure you that “so-and-so” didn’t whine to IT that he/she needs to keep up with the Jones’ – they requested it with a good business reason.

3. I have the right to a new machine because:

    a. “She” just got one, and I was hired before “her.”
    b. I constantly complain about mine being slow.
    c. I install every extension I can on the machine.
    d. I’ve had it for over a year.

This is a common misconception. You have the right to a new machine when your manager budgets it a thing for you. If it is up to IT to provision the entire company from our budget, then you have a right to a new machine based on an end-of-life policy determined by IT and agreed to by the principals in the company.

4. I have the right to have my problem prioritized much more highly than someone else’s because:

    a. It’s mine.
    b. I’ve told you about it 5 times in 30 minutes.
    c. I emailed, called, and opened a helpdesk ticket.

You have the right to get out of my office. The squeaky wheel might get the grease, but it’s a temporary fix. The squeaky wheel gets replaced or stuck in the trunk as a spare. The squeaky wheel rarely remains part of a well-tuned machine. Remember that the next time you think that a problem should be prioritized. Perhaps you should just ask where on the list you are and why. If you don’t understand, that’s fine. If you’d like to discuss prioritization based on importance, that’s fine too. But do not walk into IT with your head held high, assuming that because it’s You, we will drop everything.

5. I have the right to complain about things not getting done after I have willfully violated procedure.

Ahhh, yes. When you have not followed procedures and things get dropped through the cracks, do you really think that we did it on purpose, or is it possible that we put these procedures in place so that things would NOT drop through the cracks? Think about that for a second. Is it possible that we like our jobs? Is it possible that we want to keep them? Is it possible that we would prefer to go through the day without pissing people off? Is it just
possible, then, that these procedures are there to help you as much as us? They are.

To be honest, though, sometimes when you violate them, we do ignore your request entirely then pretend to have forgotten it. You can tell this because when we do, we usually make a pointed comment about the fact that something got violated, and that must be why we forgot
about it.

6. I have the right to violate policies of other departments because they are inconvenient to me.

See above, and be careful, guys. I know a few people who got fired over doing this consistently. Really, we usually put policies and procedures into place to protect (in order), ourselves, our clients, and you. When you violate them, you usually cause a large number of people (yourself included) unnecessary pain and work.

7. I have the right to go complaining to everyone that can make anything happen if the answer I receive is “no,” because:

    a. I don’t like the answer.
    b. I should get everything I ask for.

You have the right to ask your question. We have the right to answer it correctly. Every now and again, “no” is the proper answer. I know you probably don’t like it, but, no, I’m not going to buy everyone Microsoft Office 2007 when there’s a free converter pack for the older versions. It’s just not going to happen unless you want to pony up the dough. Now that you have your answer, however, feel free to go complain to your boss, my boss, the officers of the company. Create a firestorm if you like. Just remember this: IT has a very long memory, and when you do that, it is personal. Also, it’s not just IT that sees and remembers when you act like a baby. It’s everyone you involved. Not us. You.