10 Things I Hate About You:

The 10 Worst Mistakes In GIS Project History

10 Things I Hate About You:

The 10 Worst Mistakes In GIS Project History

Jeff MeyersMiner & Miner

10 Things I Hate About You

Introduction/OverviewOn Why It Ought To Be Easier, But

Isn’t

The Top 10The Critical Failure Factors

The Missing ThingsSome Things You Might Have

Expected

On Why It Ought To Be Easier, But Isn’t … On Why It Ought To Be Easier, But Isn’t …

GIS Implementation Has A Lousy Track Record (But Not As Bad As Some) Common sense tells us that there

ought to be a way …

… For GIS Project delivery to be more consistent

… For GIS project delivery to be more predictable

Books Have Been Written About This Stuff …… And Some Are Even Useful

On Why …On Why …

Why Isn’t There a One-Size-Fits-All Methodology?

Factors That Agitate Against Consistent Delivery:1. Legacy Technology2. New Technology3. Culture4. Mergers and Acquisitions5. Restructuring

On Why …On Why …

We Are Pretty Satisfied That There Isn’t Just One Way To Do It

But … There Are Several Ways Not To Do It

Reason No. 10:Reason No. 10:

Today’s GIS World is a Technical One Is It Getting Any Easier?

The User Experience -- Yes Applications and Database Admin -- No

Signs of Possible Trouble: You Say: ‘Enterprise GIS’

They Say: ‘It’s Just Mapping’ DBA(s) Let You Know

That They’re Available, Just Not Right Now

Not Having Enough IT Support

Reason No. 10:Reason No. 10:

What To Do About Not Enough IT Support You (Probably) Don’t Need a Huge Team Enterprise GIS Works Best When There’s a

Balance Between IT Standards and Business Needs Understanding the Business

Case IT Involvement From The

Start On-Going Commitment

Reason No. 9:Reason No. 9:

Seems Counter-Intuitive, Doesn’t It? The Occasional Conflict Between IT

Constraints and Business Needs Can Affect Timing of Deliverables On-Going Release Cycles

Having Too Much IT Support

Reason No. 9:Reason No. 9:

What To Do About Too Much IT Support Someone Once Said:

“Enterprise GIS Works Best When There’s a Balance Between IT Standards and Business Needs”

Understanding the Business Case Flexibility to Serve the Business

First Early Engagement By the Core

Team

Reason No. 8:Reason No. 8:

An Implementation Entirely Dependent On a Single Technical Resource

It Happens More Often Than You Think Fortunately For Us Most

Gurus Are Dedicated and Hard-Working Professionals

But, Beware of Accidents Illness Recruiting Bad Luck

Failed ‘The Bus Test’

Reason No. 8:Reason No. 8:

What To Do About ‘The Bus Test’ Don’t Put All Your Eggheads In One

Basket Emphasize Training

Internal Seminars Brown Bags Programmers Like Growth

Reason No. 7:Reason No. 7:

That You Need A Champion is Not Exactly A Secret

The Truth Is … The Champion Nearly Always Exists,

But They Might Not Have Enough Clout in

the Organization

Lacked a Sponsor (At a High Enough Level)

Reason No. 7:Reason No. 7:

What To Do About Lack of a Sponsor (At a High Enough Level)

Examine the Real Requirements Organizational Role And/or Personal

Relationships to Keep Management Peers Hitched When Going

Gets Rough Coach/Coerce the Core Team to Stay on Track

Look For Key Candidates Up the Chain Be Open Within the Core Team

Reason No. 6:Reason No. 6:

So Much Has Been Written and Said … A Good PM Has

In-Depth Knowledge of Content Mastery of Management Science 40 Years Experience Relate Well To Young Programmers

Defining the PM Role In Superstar Terms May Not Helpful

Had a Poor Project Manager

Reason No. 6:Reason No. 6:

What To Do About a Poor Project Manager

It Might Not Be Time to Hit the Parachute The 4 Most Important Characteristics

1. An Understanding of the Company Culture

2. A Clear View of the Business Drivers

3. The Support of Boss and Teammates

4. An Methodology That Works

Supporting Those Is the Shortest Path Remember: Many/Most Good PMs are

Plodders

Reason No. 5:Reason No. 5:

The Author Now Appears to Reverse His Field …

The Roadmap Can Make All The Difference A Proven Set of Tasks Adjusted to Local

Conditions Of Course, We Can

Take It Too Far It Is Truly Amazing

How Many Projects Don’t Have One

Had a Poor Methodology, or None

Reason No. 5:Reason No. 5:

First of All: It is Never Too Late1. Find the Resource That Will

Work For You

2. Identify Your Present Coordinates

3. Socialize the Crew

4. Stick to It

What To Do About a Poor Methodology

Reason No. 4:Reason No. 4:

Your Boss is In a Hurry She Doesn’t Really Want GIS Tremendous Pressure Deliver

(Or to Say You’ll Deliver) In A Very Short Time

Leading To Taking the Shine of Some Good

Work (Occasionally) D & D

Had Unrealistic Schedule Expectations

Reason No. 4:Reason No. 4: What To Do About Unrealistic

Schedule Expectations Don’t Go For the Big Bang

(If You Can Help It) Try To Give ‘Em What They Want, In

Chunks1. Pick 1 Substantial Piece of the Business

Problem

2. Call That a Delivery and Name It

- Define the Critical Functions

- Add a Few Nicetas

3. Estimate the Schedule (BACAP)

4. If It Looks Like You’ll Be Late, Let Go of a Niceta or 2.

Reason No. 3:Reason No. 3:

This Is the Hardest Thing Release Cycles Are Measured

In Months, Not Years Faster Than Your Absorption

Rate Disruptive to Test and

Acceptance Waiting for a Critical Piece of

Functionality, vs Building It

Didn’t Plan For Technology Change

Reason No. 3:Reason No. 3:

What To Do About a Plan For Technology Change

This Is the Hardest Thing Get Involved/Find Out Things

1. Attend Your User Group

2. Participate in Production Direction Discussions

3. Offer Advice/Suggestions Use the Incremental Delivery

Strategy

Reason No. 2:Reason No. 2:

Your Vendor/Implementer Can Do a Lot

There are Some Things That You Should Do for Yourself The Turn-Key Syndrome But What If It’s Your First Car?

Didn’t/Wouldn’t/Couldn’t Take Internal Ownership

Reason No. 2:Reason No. 2:

What To Do About Taking Internal Ownership

Mostly, It’s a Matter of Expectations and Planning

Define Your Core Team Think About the Lifecycle: What

Will Your Needs Be During Data Acceptance? During Training? Right After Deployment?

Look For Heroes

Reason No. 1:Reason No. 1:

Whatever the Cause(s), It Can Lead to Disaster

Had Unrealistic Scope Expectations, Or None

Maybe It’s The Vendors Fault

Maybe It’s Management Enthusiasm

Maybe It’s Internal (Scope Creep) Core Teams That Are Their Own Worst

Enemy

Reason No. 1:Reason No. 1:

What To Do About Unrealistic Scope Expectations

All Previous Suggestions Apply Use The Incremental Delivery

Strategy1. Get Everyone Used to Thinking of It

As a Process, Not an Event

2. Make It Work, Make It Right, Make It Better

3. When It’s Hard to Say ‘No’, Say ‘Yes, But Not in This Delivery’

Remember Selective Hearing

Some Things You Thought Were Missing …

Some Things You Thought Were Missing …

… Like Unrealistic Budget Expectations

… Or Poor Change Manage-

ment

… Or Selecting the Wrong Technology

Last Thoughts On The Top 10Last Thoughts On The Top 10

10. Didn’t Have Enough IT Support

9. Had Too Much IT Support

8. Failed ‘the Bus’ Test

7. Lacked a Sponsor (at a High-enough Level)

6. Had a Poor Project Manager

5. Had a Poor Methodology, or None

4. Had Unrealistic Schedule Expectations

3. Didn’t Plan for Technology Change

2. Didn’t/couldn’t/wouldn’t Take Internal Ownership

1. Had Unrealistic Scope Expectations

AvoidingThis

It’s A Nice Thought, Anyway