Indeed, Curran ascribed the current running time of CIO tenure, of 4 to 4 ½ years, to the length of business lifecycles — the time that lapses between a company’s last major strategy and its new one (my definition). The logic is that the person who was right to lead IT in the last business cycle isn’t the one to take it to the new next level, so that person moves on (at his own behest or not).
A few years ago, our first major CIO salary and careers study showed roughly that same length of tenure, even accounting for a certain group of CIOs who had been at their jobs for 20 or 30 years (Curran also mentioned this). Our analysis, which roughly complements Curran’s, was that four years or so was how long it took a certain set of “transformational” CIOs — those brought in to lead major change – to establish what needed to change and then change it. When that job was done, it was time for them to move on and for an operational CIO to take over.
The concept of a transformational CIO — among other CIO archetypes — isn’t new, but it does call to mind the likelihood that once the economic recovery begins in earnest, we are likely to see a lot of movement. Those CIOs who have used the downtime of the recession to re-evaluate the business, examine business processes, develop a strategic plan for IT investment that awaits an economic trigger, are like tigers waiting to pounce on enacting those changes — they’ll stay put. Those at less dynamic businesses, though, are like a sprinter on the blocks for a new opportunity. They’ll get the job that might be yours today, because your management doesn’t see you as up to the task to embrace whatever’s next.
Which brings us back to getting fired. As Curran said, many CIOs who get fired aren’t bad CIOs — they’re just not right for the situation at hand. And with technology and business inexorably changing, that merits continual review, particularly as the next business cycle comes upon us.
The code donation was certainly “a break from the ordinary,” according to the official Microsoft press release, in which a Microsoft official said the move was due in part to the current economic climate, to help companies consolidate their hardware and software.
“Many companies are turning to Microsoft more frequently to help them succeed in a heterogeneous technology world because we understand that reducing complexity is a key factor to reducing cost,” said Sam Ramji, senior director of platform strategy in Microsoft’s server and tools organization. “We are seeing interoperability as a lever for business growth.”
Some of you are probably thinking what Frank Basanta, director of technology for Systems Solutions, said in a recent interview: “Microsoft only does things that benefit Microsoft.”
There is a backstory to the code release that supports that view. Microsoft initially licensed the Linux drivers in violation of the GPL. A network driver in Microsoft’s Hyper-V was using open source components licensed under the GPL, as well as linking to closed-source binaries — a big no-no. Stephen Hemminger, a principal engineer with open source network vendor Vyatta and a Linux contributor, found this out with a bit of Googling (ironic? Nah – it is the standard after all) and passed on the information to Greg Kroah-Hartman, Linux driver project lead – hoping Kroah-Hartman could address the situation with Microsoft. And voila.
In any case, the deal isn’t likely to have much of an impact, especially among the many Microsoft shops in the midmarket. Few IT shops have mixed operating systems on one server, according to Gordon Haff, a principal analyst at Illuminata Inc., in a recent interview with SearchServerVirtualization.com, but the released code will make it easier for Hyper-V users to incorporate Linux into their environments.
“The typical user for this is the IT shop that’s primarily a Windows shop, but that is using Linux for some things,” Haff said. “This makes it easier and better for them to just use Microsoft [Hyper-V].”
That’s great for Microsoft, and not bad for users looking to do virtualization more affordably on Hyper-V.
Time and time again, I hear the stories of the initial implementation process: Company purchases software, company implements relevant parts of the software in stages, company stops the process once it has implemented what it needs.
I once bought a 160-piece kitchen set. Out of the 160 “useful” kitchen tools, I use about 10 of them — the rest sit in my cabinets, waiting for the day I decide to make eight individual servings of crème brûlée or require a tool for removing my strawberry stem. At the time, I had big plans for my cooking skills and thought the new tools would inspire me to learn a bit more in the kitchen — maybe I really will try my hand at beef Wellington, I thought.
People get excited when they hear about all the possible benefits, how much time it could save and the transparency it could provide (“Really? We can narrow down the project failure to that time Mitch forgot to check his email?!”). But these organizations are not always ready for the extensive PPM software and end up with a partial rollout.
PPM Software as a Service options are available for CIOs unwilling or unable to invest in expensive software with a lot of up-front costs. Many other organizations (some 31%, according to our survey) opt for a less complex solution like Microsoft Project.
One CIO I spoke with has had a project management office for over five years and has used Microsoft Project from the beginning. “It’s easy to use and it provides the functionality we need — which is project management,” he said. “We don’t get lost in it.”
And getting lost is not something you want to do. Project failure rates are up from last year, and some experts believe this is due in part to additional processes and procedures related to project management strategies.
So don’t be intimidated if you haven’t yet started with any PPM efforts, and/or any PPM software. You can start simple — when you’re ready to scale it up, all those other tools will be waiting for you.
Seventy-five percent of the 236 respondents to a recent SearchCIO-Midmarket.com survey said they have project queues with three to 12 months’ worth of work in them. And most (71%) are maintaining only one type of project queue for all types of projects.
So if you’re a midmarket company facing a high demand for projects with limited resources, how can you effectively streamline the project prioritization process?
Some companies that still have money to spend are investing in project portfolio management (PPM) software to address the project prioritization issue. But not every one has the budget to purchase costly PPM software.
One company I spoke with recently invested no money in a very basic project scheduling system they developed themselves.
At XanGo, a global nutrition company with 650 employees, they have an informal project scheduling system they call the “project backlog.” The way it works is that each project team has a list of projects and they are managed in their own individual “war rooms.” In any given war room, you’ll find a wall of index cards listed under one of three headings: current, current plus one or current plus two. All projects are scheduled in two-week cycles. So if your project is listed under current, then it’s scheduled to be done in two weeks. Those listed under current plus one would be concluded in three weeks (two weeks plus one). And finally, if your project falls under current plus two, it will be completed in four weeks (two weeks plus two).
Although very basic, this system seems to work at XanGo. In addition to using the index card system, the company also uses Agile development to prioritize the application development process.
XanGo is actually in the minority for midmarket companies using Agile development. According to our recent PPM survey, only 20% of midmarket companies are using agile development. However, of those that do, 76% say it has made the application development process faster.
So whether they’re using index cards or formal PPM software, midmarket companies with limited resources and budgets need to invest in some type of project scheduling system to better allocate resources and complete projects on deadline.]]>