Beware of project labels – they can set a project on an irreversible course to the wrong answer. 

Have you heard the riddle, “When is a car not a car?”
Answer: When it turns into a driveway. (groan)

Try another, “When is an IT project not an IT project?”
Answer: At the beginning.

Okay, that’s neither clever nor clear (I’m working on it), but read on…

A mortal enemy of smart decisions is ‘The Preconceived Solution.’ So, for example, when a project is dubbed “IT” from the outset, several things usually happen:

• An IT Project Manager leads the project team
• IT folks are assigned to the team
• IT vendors are invited to propose solutions
• Non-IT folks (marketing, manufacturing, clinical, etc.) run for the exits

It Is Your Destiny

Even when only two or three of the above predictions occur, an IT outcome is almost inevitable. It may well be the best IT solution, but what we’ll never know is: “What non-IT solutions existed?” And why would we have ever asked… it’s an ‘IT project’ (Duh).

On occasion, however, the best solution is not an IT solution. But, if only IT solutions are on the table, we’ll never know we settled for a second-rate investment. Fighting this tunnel vision with discipline pays off. In one case, a business thought they needed new inventory management software. Rather than following their habit of assembling an IT team with an IT leader and perhaps just one or two inventory managers, they put a logistics manager in charge.

While less than thrilled with being asked to lead what seemed clearly an IT project, he used the broader project title, “Inventory Reduction Project,” instead of the more obvious, “Inventory Management Software Upgrade.” He then brought warehouse and supply-chain people onto the team and challenged them to look beyond software options. In the end, the best choice was revising the warehouse layout and staging process, a solution that provided the desired reduction in inventory, yet used no capital and carried little risk.

Best Practices

How do we break out of this habit of stereotyping projects? By treating every project as a business project at the outset. Here are some specific disciplines:

1. Assign someone from a business department to lead the evaluation work: I originally thought IT project managers would bristle at giving up the reins at the front-end of projects but I’ve found most applaud this arrangement. They know that when business leads the evaluation, IT solutions enjoy much smoother implementation with clear definition and less re-scoping and scope creep.
2. Define the opportunity in business terms: This typically means we are trying to increase revenue, decrease costs or comply with regulations. So, for example, rather than saying the project is an inventory database project, define the project as an inventory reduction initiative.
3. Include a variety of professions on the team based on the business definition: For example, if it relates to inventory management, in addition to IT folks, include purchasers, warehouse staff, sales reps, etc. If it relates to patient care, include nurses, technicians, doctors, etc.

Even if the final recommendation is still an IT solution, you will likely see less re-scoping and scope-creep during implementation. That means lower costs, faster completion, and better alignment with business strategy.

So, when is an IT project not an IT project?

© Dave Wittenberg