Journyx Project Management Blog

The metrics organizations commonly use to determine whether an IT project is a success or a failure—whether the project is completed on time, on budget, and delivered the initial requirements—do more harm than good for IT departments, according to a new report from Forrester Research.

Organizations use these metrics because they’re easy for business people to understand, writes principal author Lewis Cardin in the report, Debunking IT Project Failure Myths. But these metrics are problematic for IT departments. In a way, Cardin suggests, they set up IT departments for failure.

The problem with these metrics, according to Forrester, is that they perpetuate the idea that a project is only successful when it is completed according to the initial schedule, budget and requirements—and therefore, that anything less is a failure.

Another problem with these metrics is that they don’t take into account the mercurial nature of project management and project delivery.

“Project requirements change for a variety of reasons, and schedules and budgets change during the lifetime of the project based on better information as to effort, complexity and interdependencies,” writes Cardin in the report, published July 28. “This would not be an issue except that project sponsors judge project success in terms of schedule-budget-meet requirements.”

Read more at CIO.com.

I’ve been seeing things lately that make the old software company CEO in me want to start screaming, “Change, or I’ll get someone else who can actually do your job.”

What has me so riled, as I visit the IT shops of my clients, is a lot of wasted energy. People are assigned to projects, sometimes for years at a time, that are just fantasies.

Who gets the blame for this foolishness? There’s enough to go around for both the business and IT.

I see long lists of projects that are officially under way but have no funding — and no plan for funding. Despite that lack of a key ingredient — money — periodic meetings are held, minutes are published, studies are done.

In one case I know of, four IT people are tied up for the third year in a row on a project that still hasn’t made the cut in the corporate plan.

The business wants and even needs this project. But the corporation needs other things more, so it waits. No progress is made, but everyone looks busy. Make-work maintains the fantasy that this project will someday matter enough to be funded. And maintaining the fantasy is all it does. None of the work being done will cut the project’s time frame should it ever receive funding; it will all need to be redone later.

Read on at ComputerWorld.

Some days I like to be gentle with people. Some days I sit and listen while people explain to me how important the work of a project manager is, how we have changed the business world, and how the present glory barely presages the coming glory of our reign. Perfect portfolios of properly prepared projects proceed purposefully into a paradise. Or something like that.

The reality of a project manager’s life involves a lot more process and a lot less project. Managing risks and performing earned value analysis certainly has its place, but most of our work centers on the simple workaday activities involved with keeping people on track. We build schedules, call meetings, talk with everyone who might be remotely interested in the project’s outcome (and their uncle, just to be safe), then stay up all night with the team while things fall apart. We file reports, oh the reports, and intervene only when the process’ steady hum stutters.

Wait a second. The process? Yes, the process. When we look only at the output, each IT “project” we engage in looks, in fact, suspiciously like a project. We have a unique product created to meet a particular need in a specific context and time. However, having a bunch of product midwives around is not what attracts corporations to the idea of project management. People were producing products long before our profession got off the ground and will be doing so long after PMI, PRINCE, and all the rest vanish into the dust of history. What attracts them is the idea that we can manage a repeatable, measurable, auditable process by which things mostly happen.

Read the rest at TechRepublic.

While many business leaders feel at ease developing a rapid growth strategy, appeasing cranky board members, or driving the company toward an IPO before their first cup of coffee, they shriek when asked about the company’s IT structure. Evaluating an enterprise resource planning (ERP) system or selecting servers simply isn’t their bread and butter. However, a healthy organization continually assesses IT issues for opportunities — and threats.

One of the most difficult aspects of leadership is recognizing when the time has arrived to make updates to the infrastructure that enables you to deliver for employees and clients alike. Before a do-it-yourself software projects goes awry or an application project falls behind schedule, business leaders should proactively identify potential IT weaknesses as a way to circumvent threats that might jeopardize security or render the network useless.

Below are the top five questions business leaders should ask when assessing the company’s IT solutions:

Is your IT infrastructure scalable?
IT infrastructure is not “one size fits all.” Do not make the mistake of taking this point lightly. Invest in systems that will grow with your business. Specific factors like the size and potential growth of the company should be thoroughly analyzed before a major hardware purchase. If your business is undergoing any substantial organizational changes, such as a merger or an IPO, issues in electronics systems, databases, routers, and networking need to be considered. The performance of your system should improve after adding hardware (proportionally to the capacity added) to be an effective, scalable system.

If your current system is not scalable or simply outdated, evaluate other options that have come on the market since your last IT purchase. In today’s market, software as a service (SaaS) is one preferred model of application deployment. The SaaS value proposition lies in the remote hosting of applications, which are then provided to customers across the Internet, rather than as an on-site desktop application or server appliance.

Read more at Inc. Technology.

Given the murky economic outlook, budgetary efficiency is an increasingly important part of every IT leader’s job. In fact, according to “The State of Enterprise IT Budgets: 2008,” a March report from Gartner Inc., 75% of enterprises say improving the efficiency of IT is a critical or high priority.

Think you have the budget covered? So did many others, who nonetheless found themselves explaining missteps that cost hundreds of thousands — even millions — of dollars.

Here are some of the things they learned not to do:

1. Always say yes. Acceding to constant demands can send the budget spiraling out of control, says Mike Gorsage, a partner and regional technology practice leader at Tatum LLC, an Atlanta-based executive services and consulting firm.

Gorsage cites the case of a hospital where the CIO worked under a directive to fulfill all requests. “The senior executives told IT if someone needs something, just get it done,” he says.

As a result, planned projects accounted for about 10% of the $100 million budget, while unplanned work sucked down a staggering 30%. And just over 60% went to maintenance. Best-practices models indicate that 70% should be spent on maintenance, 25% on planned projects and only 5% on unanticipated demands, Gorsage says.

The tipping point came when IT suffered a costly failure on a big project — a failure that stemmed from all those helter-skelter projects, Gorsage says.

“Finally, the CIO and senior management figured they had to put in strong governance, but it took six or seven months of pain to get that done,” Gorsage says. The new rigorous approval and planning process brought the hospital’s IT spending closer to that 75/25/5 split.

Read the rest at ComputerWorld.

IT certifications are one way to distinguish between well-trained job candidates and prospects whose skills on specific hardware or software aren’t quite up to par.

At least that’s the way it’s supposed to work. In recent times, however, an overabundance of certifications and widespread cheating on exams caused in part by lax security at testing centers have tarnished IT certifications’ reputation in the eyes of many human-resources executives and hiring managers.

“It’s a big problem,” agrees Don Sorensen, marketing vice president at Caveon, a Salt Lake City test security company. He says there are “literally hundreds” of so-called “braindump” websites that share or sell test questions.

According to a 2007 report from the Association of Test Publishers, of 101 IT vendors and certification test centers surveyed, slightly more than half said that 46 percent or more of their IT certification tests had been copied, stolen or breached in some other way in the recent past. Some test givers said their new tests could be found on braindump websites within a month of being published, and in some cases, as soon as two days, according to the report.

Read the rest at Inc. Technology.

Managing technology projects can be one of the most challenging arenas of project management. Ironically, it is rarely the technology itself that presents obstacles for the technical project manager. Being mindful of the most common traps that await the unsuspecting project manager can help ensure your technical projects don’t end up as financial disasters that don’t deliver expected function, and diminish the reputation of yourself and your technical organization.

1. It is about business process, not the technical tool

The intent of a project is to move the business to a better place. That better place can mean increased efficiency, additional capabilities or an improvement in the accuracy of the business’ output. Regardless of the nature of the business improvement, it is enhanced process that will drive the superior results. It is not necessarily as a result of a tool, a new IT system or improved technology – these are only the catalyst for the improved process which drives business results. Many project managers and their teams mistake the new technology as being the output of the project, rather than the enhanced process that results in conjunction with implementing new technology.

Read on at PM World Today.

The debate over whether to run IT like a business is hot right now. Before implementing a new management structure into a department, it is important to understand that each part of a business affects the others.

Phyllis Post, Senior Director, Global Business Planning & Management, Corporate IT, Merck & Co., suggests that IT should be managed like a portfolio. In fact, to function as well as possible, Post adds that companies need to understand that the IT department must be included in the “rhythm” of a business. Additionally, to create the best marriage of the two, the overall values of the business need to be up to date. The IT department should not be viewed as a regular maintenance or office supply expense. The department can break a company’s budget if not respected as an integral department within the company as a whole.

Good portfolio management involves checking in on a team regularly (monthly, quarterly and annually). According to Post, the three parts of portfolio management include value creation, knowing the demand and ensuring effective execution. By managing the IT department in this way, a company is able to continually measure how well the IT department is staying on strategy in relation to the rest of the company. Without a set strategy to keep the IT department in sync with a company, more money will be spent overall as the company may rush to spend on the IT department to get it back on track. However, if a strategy is set and followed and there is a budget cutback during this time, the CIO will know where to trim, instead of evenly shaving off a little money dedicated to each project.

Read on at CIO.com.

Top programmers are not easy to find. It takes time to cull through dozens, if not hundreds, of resumes to find the magic combination you want, and it takes hours to perform interviews. After all of that, you still need to jump through hoops to make sure that your best candidates accept your offer rather than someone else’s.

Yet all too often, these hard-to-find (and hard-to-hire) employees are neglected once they come on board. While proper compensation is, of course, a large part of employee retention, the top programmers need more than a great pay check. Here are 10 reasons why your star programmer might be looking to leave, and what you can do to convince them to stick around.

#1: Poor pay
No one works purely out of a charitable nature. So when your best people feel like their pay is severely out of line with market standards, they may start to view other pastures as being much greener than yours. Your worst enemy in retaining the stars is the thought, “I am the worst paid senior developer in this town.”

I see a lot of companies that look at what the market is like only when they hire someone. Meanwhile, your best people are often aware of what is happening in the market consistently. If you have not re-evaluated your pay packages in a while, you need to. While the package may have been competitive when you hired someone three years ago, your best employees may be able to get a substantial raise by making a lateral move (if not taking a higher level position) to another employer.

#2: An uncertain future
The best people often have no intention of leaving until something out of the ordinary prompts them to stick their toes in the job market waters. At one company where I worked, the trigger for a mass exodus was the sale of the building our employer was renting to a major company that obviously was not going to keep leasing to us. A lot of people panicked and wondered whether the loss of the office space would prompt a move of the operation to another city. Instead of sitting around waiting for the other shoe to drop, they left. At another company where I worked, a large layoff spooked those who survived, and they left as soon as they could.

There is little you can do to prevent these outside influences from occurring, but you can do a lot to reassure your people when they do happen. Your best programmers are not dumb; they know when you are trying to puff them up with hot air instead of being forthright. When these events happen, give your people the straight truth and show them what you and the company are doing to prevent the need for your stars to lose their jobs. It’s a tough path to walk, but too many managers cave in to the temptation to cover up the problems — and those cover-ups tend to drive people out even faster.

Read the rest at TechRepublic.

Readers of this blog know IT initiatives generally fail for business, organizational, or cultural reasons. Sure, technology screw-ups occur all the time, but that’s one of the realities to be managed. Success or failure ultimately depends on how project leadership manages the full range of technical- and non-technical issues.

Blogger and enterprise architect, Mike Kavis, who’s obviously been through some battles, has created ten guidelines describing critical areas of weakness in many projects:

1. Poor Communication. Enterprise projects usually impact a large amount of people. This requires constant communications to all levels of people throughout the organization. A strong communication strategy can help with this.

2. Underestimating or ignoring impact of change. This is another way of saying poor change management. People need to know WIIFM (what’s in it for me). Resistance to change can kill any project. Your initiative must have a champion who carries a lot of clout.

3. Lack of Leadership. IT Leadership requires excellence in three key areas: Technology, Business, and People. If the leadership is missing any of the three components you are doomed.

Read the rest at IT Project Failures.