Great article. Making friends and influencing people - particularly horizontally in a corporation - is perhaps the determinant input in how successful an executive is likely to be. Implementing Cialdini's insights in an IT context is pretty clever. Other good reading for this sort of insight is The Autobiography of Ben Franklin. The problems are timeless.

You RSS feed isn't working! Please fix so I can follow.

M

Never mind. Looks like they're rolling in now.

Excellent insights. Too many "business" executives are mystified by working with IT instead of just applying the same organizational effectiveness and common sense that they use with other business functions. Don't let the process get you down -- there are people behind all that lingo.

Susan,

I agree with your May 15th entry: IT projects outnumber IT staff. Getting an IT project approved may be challenging, but getting the project approved isn’t the biggest challenge. Getting the project to deliver the benefits is the challenge.

The easiest projects to get approved thru a governance process have 3 common characteristics:

• There is a stated alignment with mid-range strategies for the business unit or company.
• The planned change to processes is significant rather than incremental.
• There is a calculated dollar benefit and productivity benefit that is significant and achieved shortly after the project is completed.
• There is a non-calculated benefit that addresses customer happiness.
• The project is expensive.

Big change requires big money. Everybody wins with a capital project. The problem is how to make sure that a business unit gets the benefits it is paying for. This is where governance fails and frustration with IT flourishes. I’ve listed my best kernels of wisdom for getting benefits on a big project.

1. Make sure all of specialists in IT are aligned on the same priorities. IT is a loose confederation of specialists. A project team consists of business analysts, data modelers, database administrators, architects, developers, technical writers, networks, equipment, procurers, contract administrators, the PMO, a couple of project managers and a bunch of vendors. Scheduling IT specialists is like scheduling medical professionals at a hospital - except that IT doesn’t have the same terrific scheduling systems.

If your project isn’t the same priority for every IT function, delays occur until everyone catches up. Waiting is not a great use of your IT dollar. When money runs out, project scope gets cut. When scope is cut, benefits are reduced. My recommendation: don’t pay IT for project delays. Penalize IT by asking for budget back when schedules are not coordinated due to delay.

2. Don’t agree to build a foundation in Phase I. In my opinion, building infrastructure in Phase 1 is the single greatest way to reduce benefits. Infrastructure projects that are not attached to business benefits have no decision criteria for managing scope, no way for a business unit to test against requirements and no incentive to get done.
I like to create project plans where the biggest benefits are delivered first. If infrastructure change is required, do what is required to achieve the benefits. If the company needs a technology make-over, require the technology change to stand on its own merits.

3. Bring in the biggest benefits first. Accept that requirements will change, projects will have problems, delays are inevitable and new processes are hard to implement. All of the above eat up budget and are not a great use of your IT dollar. When money runs out, project scope gets cut. When scope is cut, benefits are reduced.
Do not succumb to a project plan that has a logical chronology. Require project managers and IT professionals to be creative about how to plan projects so that the biggest benefits are achieved first.

4. Map requirements to benefits. I love this technique for managing scope and achieve expected results. I am amazed at how often requirements drive a project while benefits are an afterthought for creating a business case. Mapping forces a business unit to match what it wants to what is good for the business. During the mapping process, some new benefits will be found and some requirements will be eliminated. When mapping is completed, it is easy to calculate the potential impact on benefits if scope needs to be reduced and requirements need to be cut. The potential impact on benefits is something a Governance Committee can understand and react to.

Ellen Bonnell
TrendSavants

Why, instead of moving under the radar, don't we try to solve the root problems?
I appreciate the effort and, as an IT manager, I LOVE to have a better communication with other colleagues: a lot has to be done both ways.
But trying to 'exploit' problems (like the x2, x3 shortage of resources) in this way will just rise entropy.
My 2 euro cents,
PierG
http://pierg.wordpress.com