Name two company activities that are expensive, create overhead, and smell a lot like cost centers to your CEO.

You know IT is high on the list. But project management is a close runner-up. On any given day, the project management office, like IT, is either wunderkind or problem child, depending on how recently it snatched business project victory from the jaws of defeat.

Staying on the right side of that line is a matter of thinking like a startup, defining success up front, and blurring the lines between IT and business projects. To that last point, a prime example is ERP and other core enterprise software, where 80% of the cost is retraining and process consulting and 20% is software and hardware. Of course, IT must be involved, but don't we have enough scars from failed projects where we held on to control way past where it made sense? It's time to say, "This is a business project, not a technology project."

That street goes both ways. Nowadays, too few business leaders get IT involved early in product planning efforts, even though tacking technology on at the last minute sends costs through the roof. There can't be a wall between business and IT projects.

If you're thinking that fostering this environment sounds like a lot of work that you have no time for, remember: You can pay that bill now or you can pay it later, with interest. Business stakeholders have an unpleasant way of blame-storming project failure not on project management organization (PMO) shortcomings or poor employee engagement or lack of staff or budget, but on technology failings. It's not that they're out to get you. It's simply that technology is the least-understood piece of the project and therefore the easiest to cite as the cause of failure.

Finger-pointing is easy to do when not everyone is pulling together. How divided are we? Sixty-three percent of 421 respondents to our 2014 InformationWeek Project Management Survey, all from companies with 100 or more employees, say enterprise and IT project management organizational units are separate -- and 23% cite outright antagonism.

To get everyone working together, start by pinpointing what you're trying to achieve.

Project success metricsTwo questions frame the goal of any project management effort: What does spectacular project success look like, and how do we spot and kill dud projects that won't advance business goals?

One red flag in our survey suggests IT had better figure this out: Just 34% of respondents say that IT projects almost always deliver value to the business. Twenty-one percent say IT projects "sometimes" deliver value. The No. 1 answer, at 41%, is that results are mixed -- and remember, our respondents are predominantly IT pros. If history is any guide, business execs are less-generous judges.

"Effective project management really comes down to the project manager knowing both sides of the table -- what the sponsors or management want, and what it takes for the IT developers to get it done in the time frame set by the sponsor," says Chris Lucas, an analyst with Jones Day, an international law firm, summing it up pretty concisely. Other success factors include making sure decision makers not only have the authority but are confident enough in their roles to make and stick to hard calls (such as re-allocating resources), and that they understand that process is a means to an end. Value the outcome more than the process.

A survey respondent from a large manufacturing company in North Carolina identified some ways we fail: taking on too many projects, failing to tie projects to business strategy, and failing to manage resource constraints. Resource management isn't static; it requires continually adjusting projects based on the resources available during a certain period of time.

Here's another sign of failure: projects that come in on time and within budget but where customer satisfaction is an afterthought. That's worth remembering for our respondents, who overwhelmingly chose "on time" as the No. 1 indicator of project success (61%), followed by "within budget" (57%). Stakeholder and sponsor satisfaction trailed at No. 3, with 33%. Talk about out-of-whack priorities.

The beauty of small projectsAnother truth our survey reveals about projects: The "moon launch" methodology of project initiation and planning is still popular, and it's killing us. Nearly half of respondents budget and plan for big projects up front, in one fell swoop. Just 30% are agile and break large projects into shorter time frames, smaller deliverables, frequent evaluation checkpoints, and incremental budgets. Hello, HealthCare.gov.

Indeed, just weeks prior to the massive problems of HealthCare.gov being exposed, Clay Johnson, a former White House fellow, shared a salient observation at the 2013 Code for America Summit regarding project procurement. As risk tolerance goes down, he noted, budget size goes up because leaders are willing to pile on resources to avoid risk. Yet as budget size goes up, the probability of failure also increases.

Why is this? Big projects and big budgets are hugely risky because you're also increasing scope and therefore complexity. Complexity increases risk, which in turn increases the chances of failure. But we're still not done with this doom loop! Big-budget projects also create a "failure is not an option" mentality that spawns two more problems. First, when failure is not an option, the possibility of failure is not factored into plans, further increasing risk should things go south. Second, even when a project should be canceled or folded into a different project, it won't be. ("They told us failure of this project was not an option.") That increases the risk of completing the project with a bad outcome -- the operation was a success, but the patient died.

Respondents understand how closely project risk is tied to financial investment. When asked the two most important ways they evaluate project or portfolio risk, respondents gave financial investment the top spot, at 70%, followed by organizational complexity, at 54%.

Jonathan Feldman is Chief Information Officer for the City of Asheville, North Carolina, where his business background and work as an InformationWeek columnist have helped him to innovate in government through better practices in business technology, process, and human ... View Full Bio