Why the name of your IT project matters

Project names have a surprisingly powerful effect on project success. The name sends important signals about what the project is intended to accomplish, or so it should.

Names are often based on the IT vendor, a product or a category of software application - use more powerful names focused on value and outcomes to signal the purpose and to increase support throughout the enterprise for IT-intensive initiatives.

CIOs sometimes miss this point even when the outcomes are known and utterly thrilling to the enterprise.

When we visited one CIO last year, he explained to us that he had inherited a major SAP implementation effort from his predecessor.

"What's the name of the project?" we asked.

"Project SAP," he replied.

"What's the business case for this project?"

"Well," the CIO said, "we haven't done the operational case yet, but the financial case says that we're going to double the company's margins."

What an opportunity missed! Surely the "Double the Margins Project" would excite far more interest throughout the company than "Project SAP."

As they say at Black & Decker, the customer buys a drill, but what they want is a hole. The lesson is simple: As with any value communication, focus on the outcome, not the tools. Don't name a project after the drill.

Gartner's advice

Never name a project or program after an IT vendor (for example, the Oracle, SAP or Microsoft Project) or, even worse, a particular technology product (for example, the SAP v.6.0 Project).

Similarly, avoid naming a project according to categories of software (for example, the ERP project or the CRM project), which to everyone outside IT conveys, at most, a vague set of generic functions and features, not value for their business or business unit.

Avoid fanciful names like Phoenix, Hermes or Unicorn. Symbolic names are only workable when the symbolism is well-understood.

The best name for a project or program is a brief statement of its value or rationale, such as "Single Face to the Customer" or "Global Scalability." Such a name reminds everyone involved of the outcomes desired — and why it is worth doing well.

A project name that does not reference business goals tells the enterprise that the project is all about IT, not about business.

And when a project is perceived as being all about IT, the natural tendency for the rest of the enterprise is to treat it as IT's responsibility, not theirs.

The consequences could include lack of support outside IT, delay and even failure.

Dave Aron is a vice president and Gartner Fellow in Gartner's CIO Research group.