Hack Your CRM – Learning to Love User Problems

CRM_hacks_graphicYou’re the Business Analyst for a large distributor and you work closely with the Vice President of Sales and her sales team.  You’ve just learned that your company is going to invest in a CRM system, in fact, the very system that you recommended and with which you are very comfortable.  Can you avoid one of the most common pitfalls that await you on this project?

A Business System Analyst (BSA) or Business Analyst (BA) is a key member of any CRM Project Team.  It is important that you don’t let your familiarity with the system that has been chosen keep you from doing what you should be doing on the project.  Rather than listing functional and non-functional requirements, what you should be doing is cataloging the business processes and goals, and then working with the system architect to determine the best way to configure the system to achieve the goal for each process.  However, when you talk to the potential users of the system, you discover what all BA’s have discovered before you.  Users have at least 2 problems when it comes to expressing their functional and non-functional requirements: 1.) The “needs” expressed are too specific or 2.)  The “needs” are too general.  For example, a user might say, “All of the required fields should be highlighted in red.”  That sure sounds like a requirement, but it is really too specific to be valuable at this point, it is really a design element.  Possibly you’ve heard a user say, “It has to be really easy to use.”  Again, that may sound like a requirement, but it is too general to be valuable at this point as well since it deals with usability and not what the system will do.

You may have also discovered that users almost always have no hesitancy at all in talking about their problems.  You should be delighted whenever you find a user who can clearly express the problem he or she is having.  Those ‘problems’ will lead you to the real ‘needs’ of the user community.  Your job is to help them see that each resolution to a problem is really an achievable goal for the project.  Users are almost always focused on their problems.   Ask yourself, why is it a problem for them?  Better yet, ask them!  For example, Joe User states, “I never know whether or not one of my sales will be accepted”  Now that certainly sounds like a problem, but why is it a problem, and what is the cause?  Your questions should clarify the issue.  “Why is that a problem for you?”   “What do you think is causing it?”  In our hypothetical case, Joe User answers both:  “I am wasting my time if the sale isn’t accepted.”   “The customer is turned down for bad credit.”  In our simple example, you as the BA can now turn this into an achievable goal.  “So, the system should have a quick way to qualify the credit of a potential customer before you take the time to create and submit an order?”    Notice, this is a question back to Joe User.  Wait for the confirmation, you don’t want to insert your assumptions and your familiarity with the system and miss the real need.  In this case, Joe User says “Yeah, if we could do that, it would be a big help!”

Don’t stop there, are there other problems you can uncover and convert to achievable goals.  In fact, you may even want to do away with the traditional listing of ‘requirements’ and replace it with system goals and the design elements to meet them.  Remember, just because you know what a system can do, don’t assume that this is what the system should do.  That is the pitfall that you must avoid on this project.  Instead, listen to the users, find their problems, and convert them to achievable goals.  Sometimes the best hack is not taking a shortcut.

Jim Lindenfeld, Principal Consultant

Jim Lindenfeld, Principal Consultant

This blog was written by Jim Lindenfeld, who has been actively involved in customer relationship management during his entire professional career.  He is a certified sales and sales management trainer.  He has been involved in the implementation of CRM systems since 1987 and is currently a principal consultant in our CRM practice.

Illustration created and provided by Jonathan Pike, eVerge Group IT Specialist

Share : Share on TwitterShare on FacebookShare on Linkedin

CRM Hacks: Entering U.S. addresses into a CRM system

CRM_hacks_graphic“Hack” is one of the most over used words in the English language.  It can mean to chop, it can mean a carriage, it might mean a cough, or an untalented golfer.   More recently hack has come to mean to illegally accessing a computer system or just the opposite – provide a quick fix to a broken system.  If you are a ‘gamer’, a hack is a ‘secret’ way to do better on a game level.

So when a new show hit the airwaves on TruTV – Hack My Life – it was difficult to tell if they were going to talk about an axe murderer, a chain cougher, a poor golfer, a carriage driver, a computer hacker, or an addicted gamer.  It turns out that the show does none of these.  It instead refers to ‘hack’ as a ported version of the gamer definition to a non-gaming situation.  That is, a ‘life hack’ is a quick tip that will help you do better in certain life situations (Oven broken?  Cook that lasagna in the dishwasher!).  CRM hacks are intended to be quick ‘secret’ tips that help even casual users use CRM systems to their fullest potential.

This CRM hack reveals a couple of low cost ways to speed up the data entry of U. S. addresses and improve the data quality.   US Zip Codes in both the 5 and 9 digit configurations are very helpful if used properly.  Many CRM on premise and cloud systems can be easily configured to take the provided Zip code and fill in the City, State, County, Country, and Geo Location of an address.   This leaves the user the much reduced task of filling in only the street address.   As an added benefit, users can no longer enter an incorrect City/Zip combination or a misspelled City/ County/Country name, so your overall address data quality improves.  With a little more effort, your CRM system can be connected to a search engine map that can fill in the street address correctly based on the correct business name and zip code.     The investment in reducing keystrokes for your users (internal and external) will be rewarded many times over in more and better data.

If you need help avoiding this or any other pitfall in your CRM project, contact eVerge Group.

Jim Lindenfeld, Principal Consultant

Jim Lindenfeld, Principal Consultant

This blog was written by Jim Lindenfeld, who has been actively involved in customer relationship management during his entire professional career.  He is a certified sales and sales management trainer.  He has been involved in the implementation of CRM systems since 1987 and is currently a principal consultant in our CRM practice.

Share : Share on TwitterShare on FacebookShare on Linkedin

From Suspect to Customer, the Pipeline Funnel Explained

Suspects

purchase funnel

Whether vertical, horizontal, or some other fanciful design, everyone who works in or manages a sales and marketing organization recognizes the above images of the Pipeline Funnel.  The funnel graph is clearly intended to indicate that some effort is taking place to move people and businesses that don’t currently purchase goods and services into customers that do.  Many people see these graphs and misinterpret the funnel shape.  This is because the typical physical funnel that many are familiar with is a delivery mechanism in which every particle or droplet that enters into the top of the funnel, comes out of the bottom into the receiving container.  Often, as in the above examples, the funnel graph is shown in a 3D rendering.  Therefore, the casual observer is led to believe that the sales and marketing effort will convert all who enter the funnel into customers.

The reality of the ‘funnel’ chart is actually just the opposite!  It is intended to indicate that only a small fraction of the people and businesses that enter into the process eventually become customers.   Implied in the funnel graph is the idea that there are mechanisms in place to not only get people into the funnel, but also to get them out!  It is vital to your organization to recognize that getting people and businesses out of the pipeline efficiently, at the lowest cost possible, is just as vital to the success of your business as getting people and businesses into the funnel in the first place.

“Marketing” is getting people into the funnel from the entire universe.  Many times these entrants are called Suspects.  This blog doesn’t deal with getting businesses and people into the funnel, but deals instead with getting them through it.  Here is a set of ‘agreements’  that can be incorporated into your sales methodologies that quickly determine if a person or business should continue on in the selling process.

Agreement One:  The Suspect agrees to enter into some form of discussion with you.  This is often called interest.  Examples of this:

  • They take a phone call
  • They agree to an appointment
  • They click on an offer in an email or on your website
  • The respond to SEO or SEM
  • They meet with a sales representative on a cold call

This is the first agreement that you should strive to achieve – the sales process doesn’t continue with those Suspects who don’t reach this agreement with you, they drop out of the ‘funnel’ and it narrows to Prospects.

Agreement Two:  You and the Prospect mutually agree that you can help solve a problem or take advantage of an opportunity the prospect is facing.  You have gathered information from the initial discussion, usually centered on BANT (Budget, Authority, Needs and Situation, Timing).  You have established guidelines for BANT assessments to indicate quickly whether or not you are interested in continuing with the selling process.  Your Prospects have their own criteria which you have researched in general and understood.  If you can’t reach mutual agreement here, the Prospect drops out of the ‘funnel’ and only Leads remain.

Agreement Three:  The Lead agrees that by taking your proposed action, his or her problem will be solved or s/he will be able to take advantage of a new opportunity.  This is the very subtle agreement that many methodologies miss.  The Lead isn’t agreeing to take the action (e.g. Buy the service at the quoted price) only agreeing that the correct proposal has been made.  If you can’t reach this agreement, the Lead falls out of the ‘funnel’ and only Hot Leads remain.

Agreement Four:  The Hot Lead agrees to take your proposed action (i.e. commit resources to acquire a product or service).  This is, of course, where most of the focus falls in the ‘funnel’ because it is the commitment of that one-time Suspect’s resources that makes the process appear to be successful.  If you have obtained all of the other agreements in the correct order, agreement four should be much simpler to obtain.  All of the Hot Leads that reach this agreement with you become Customers (of course, you have to do the appropriate customer service follow-up to keep them, but that’s the subject of another blog!).

So I advocate for 2D or 3D ‘pipes’ that are horizontal (or even slightly uphill, indicating real effort), that clearly show the agreements that must be reached as the best graphic for that purpose…

Pipelines

Let us know if this is successful for you, or if you have some additional refinements that you believe to be even more effective.

Jim Lindenfeld, Principal Consultant

Jim Lindenfeld, Principal Consultant

This blog was written by Jim Lindenfeld, who has been actively involved in customer relationship management during his entire professional career.  He is a certified sales and sales management trainer.  He has been involved in the implementation of CRM systems since 1987 and is currently a principal consultant in our CRM practice.

Share : Share on TwitterShare on FacebookShare on Linkedin

Project Killers: The Resourceful PM (with apologies to Dr. Seuss)

projectManger_lorax

 

 

 

 

 

 

At the end of the building, where the CIO goes

And the air smells of ozone when the AC vent blows

And no music is playing, except the Black Crows

Is the cube of the gifted PM.

 

And way down the hallway, some people say

If you look far and hard you can still see today

Where the PM once stood, just as long as he could

Before somebody carried the PM away

 

Who was the PM, and what did he do?

And why was he carried to some place so new?

Far from the building and the projects long ago

The old BA still lives here.  Ask him.  He’ll know!

 

You won’t see the BA, don’t darken his hall

He stares at his laptop and waits for the call

He lurks in his cubicle, cool, calm and aloof

Where he makes up reports out of miff-muffered moof

And on special release days in April he peeks

Out past the window blinds and sometimes he speaks

And tells how the PM was carried away

He’ll tell you, perhaps…if you’re willing to pay.

 

He leans back in his chair, his shoulders a-hunch

And taps on his watch and says it’s time for lunch.

You have to be clever and take up the clue

And invite the BA to come dine with you.

 

As you settle to eat, he looks anxiously ‘bout,

and begs you be certain that you never shout.

He orders the priciest dish he can find,

and follows that up with a bottle of wine.

 

Then he grunts, “I’ll call you tonight, I’ll use secure phone,

For the secrets I’ll tell you are for your ears alone.”

BUZZ!

He’s good as his word; you move the phone to your ear

And the old BA’s words come through, though not very clear

Since he’s speaking to you through a cloth by choice

In the hopes that it will somehow help disguise his voice

“Now I’ll tell you,” he says, with his teeth sounding gray,

“How the PM came to be carried away…

 

Way back in the days when the science was new

And the people were eager, but knew not what to do

And the business thought all projects were as easy as pie

I was hired by this place to give it a try.

Then I first saw the list, the Requirements List!

The long standing reckoning of what had been missed

Sorted ‘what would be nice’ and ‘what would be bliss’

 

And promoting the list were requestors galore

Dancing and happy to see what was in store

Certain their system would soon do much more

 

But that list! That list! That Requirements List!

All of my life I’d been searching for a project like this.

A litany of needs more urgent than eating

And requestors with funding all plaintively bleating

I felt a great leaping of joy in my heart

And set up my laptop galumphing to start

 

In no time at all, I had devised a new plan

To knock off each listing as fast as I can

So with great skillful skill and with great speedy speed

I took the first entry.  And I sized up the need.

 

The instant I’d finished, I heard a ga-Roar!

I looked.  I turned to see something framed in the door

of the office.  My eyes said it was sort of a man.

Describe him?…That’s hard.  I don’t know if I can.

 

He was tallish, and youngish, but sharp dressed and preppy

And he spoke with a voice that was controlled but peppy.

“Mister!” he said in a sibilant hiss

“I am the PM.  I speak for the list.

I speak for the list, to give the words meaning

And I don’t like the way that this project is leaning”

He was upset now; I could see his hands tremble

“Isn’t the right starting your team to assemble?”

 

“Look PM,” I said.  “There’s no cause for alarm.

I took the first entry.  I am doing no harm.

In fact it’s quite useful to jump in the lead

And convert the entry to a Fine-Something-That-All-People-Need.

 

The PM said, “Sir! Your actions are hasteful.

If no one can work with you, you’ll find they are wasteful!”

But the very next minute I proved he was wrong,

For just at that minute a user came along

And she thought that the entry on line one of the list

Was understood well, I had gotten the gist.

 

I laughed at the PM, “You poor stupid man!

You have to get to it as fast as you can!

“I repeat,” cried the PM, “I speak for the list!”

“I’m busy,” I told him.  I showed him my fist.

 

Then I looked back at the screen and in no time at all

Had blown the doc up to hang on the wall

And I reached out to requestors with meetings galore

And promised them results betterer than before

 

Soon I found I was working full tilt.  I was sizing up needs.

IT and the business were as busy as bees

tackling list entries and gathering more.

Soon the requirements list rolled clear to the floor.

Then…  Oh! Baby! Oh! How that requirements list continued to grow.

Now taking one entry at a time, or even tackling two

I found that the task was more than I could do.

 

So I quickly invented a new requirements tracker,

which allowed me to whack out four lines with one whacker.

I was writing down needs four times as fast as before!

And that PM? … He didn’t show up any more.

But the next week he again darkened the door.

 

He stated, “I’m the PM who speaks for the list and the listers

It seems you’ve forgotten those missuses and misters

They’ve asked me to speak in hopes that you’d heed.

You don’t have a plan to solve the first need

And my poor users are all feeling fright-full

that you will not produce something delightful.

They loved making the list.  But they didn’t realize

that with everyone asking it would grow so in size.

So they’ve taken a vote and they found with dismay

that they don’t have a need worth the price they must pay.”

 

I, the BA, felt sad as I deleted their asks.

BUT… business is business!  There were still lots of tasks.

And the project continued despite their sad masks.

 

I meant no harm, I most truly did not.

But I had to get going, so going I got

I biggered my tracker, I biggered the poster,

I biggered a chart to resemble a coaster

with buckets of needs that I got from the list

and circulated to all so that no one was missed.

I went right on working, finding more needs

And I biggered my bonus, which everyone needs!

 

Then the PM came back, I was just starting to type

when that old-nuisance PM came back with a gripe.

“I am the PM,” he paused for effect,

“and I speak for the list which now is a wreck.”

“BA!” he cried with a cruffulous croak.

“BA! You’re making this project a joke!

“My poor IT team, how they all like to wail

they can’t seem to make out the head or the tail.

“And so,” said the PM, while pushing a sigh

“They’re all lining up and saying goodbye.

“What’s more,” snapped the PM his patience had failed

“Let me say a few words about your E-mail!

“You churn out new memos day and night without stop

Most filled with Glupp and Schloppity-Schlopp

“And who reads the letters that they get from you?

“I’ve asked everybody and I’ve found that it’s few!

 

And then I got mad, I turned terribly blue!

I yelled at the PM, “Now listen here, you!

All you do is yap-yap and say what you would do.

Well, I have my rights, sir, and I’m telling you

I intend to go on doing just what I do.

And for your information, I’m just about through!

 

And at that very moment, out in the hall

We heard the soft rustle as the poster did fall

on the floor ‘neath the feet of the oncoming CIO

accompanied by shouts that the project must go.

He held out his arm and opened his fist

He flatly demanded, “Hand me the list.”

 

No more list.  No more needs.  No more work to be done.

All my hopes had been smashed and dashed, every one.

Now all that was left to be seen with my eye

Was a big empty office, the PM, and I

The PM said nothing just gave me a look

When the walls of my cubicle suddenly shook

with the pounding of feet from the people outside.

They picked up the PM.  They gave him a ride.

And I’ll never forget the look on his face

As they carried him off to a much better place

That was long, long ago

But each day since that day

I’ve sat here and relived what the PM had to say

Get the resources first, get the team to assemble.

He’d told me that with his hands all a-tremble.

Once the resources are certain I have now realized

Lists are much more easily prioritized.

And the users and listers, once they know the cost,

can easily understand the gain and the loss.

Once the plan is created, and each knows his task

Reading an e-mail about the project is the least we can ask

 

Each project has potential just like some seeds

Give them clean water, clean air, and meet all their needs

And each of them will become a healthy plant.

But if you rush them or starve them you’ll find that they can’t.

Jim Lindenfeld, Principal Consultant

Jim Lindenfeld, Principal Consultant

This blog was written by Jim Lindenfeld, who has been actively involved in customer relationship management during his entire professional career.  He is a certified sales and sales management trainer.  He has been involved in the implementation of CRM systems since 1987 and is currently a principal consultant in our CRM practice.

Illustration created and provided by Jonathan Pike, eVerge Group IT Specialist.

 

Share : Share on TwitterShare on FacebookShare on Linkedin

Project Killers: Lions and Tigers and Bears Oh my!

OZYou’ve just discovered yourself surrounded by Witches and Munchkins in Munchkin land and you desperately want to get back to Kansas.  You’ve heard that the Wizard of Oz in Emerald City can help you get back, but how do you find the Wizard?  Just follow the Yellow Brick Road!

Do you see the similarities to your CRM project?   In Munchkin land Dorothy had a clear goal, return to Kansas with the help of the Wizard of Oz.  Your CRM project has a clear goal; help grow your profits by delighting your customers.  The path from Munchkin land to the Wizard is the Yellow Brick Road.  Your path to delighting your customers is your project statement of work.  Just as Dorothy gathered helpers on her journey to Oz, you will assemble a project team to assist you in getting to Deployment.   Finally, just like Dorothy you start off confidently down the road.

If you have watched the 1939 classic movie the Wizard of Oz, you should remember that the Yellow Brick Road was a path filled with risks to the journey – or as the Strawman and Tin Woodman stated – Lions, and Tigers and Bears.  There were also belligerent fruit trees, wicked witches, and deadly poppies along the way.  Dorothy hadn’t planned for any of these risks and would have been stopped ‘dead’ in her tracks if not for the help of her companions and finally the intervention of Glinda the good witch.

Your project path is a lot like the Yellow Brick Road.  yellow brick roadWhat are the lions, and tigers, and bears you will face?  Where are the belligerent fruit trees and deadly poppies?  Who are the ‘bad witches’ and what risks do they introduce?  Every project faces at least one risk to successful completion.  Most of the time, there are myriad risks to successful completion.  If these risks are not identified and/or not mitigated, they become impacts.  Impacts cost the project time, money, and scope.  In the most severe form, they kill the project before any benefit can be realized!

Dorothy ran head long into her risks and impacts, and unless you have a ‘Glinda’ protecting you, we don’t recommend that approach.  Instead create a detailed project plan using a tool such as MS Project that can point out some of the most common risks faced by a CRM project.  Here are the top 10 risks as identified by online-crm.com:

  1. Invalid project assumptions (different expectations among stakeholders)
  2. Project planning omissions. Significant delays incurred not because project planning tasks were underestimated but because project tasks were completely omitted (forgotten)
  3. Data conversion delay. Unanticipated data scrubbing due to poor data quality
  4. Lack of continuity or consistency of business processes among multiple locations (as well as the introduction of sub-optimization by some locations)
  5. Failure to proactively anticipate and mitigate user adoption challenges – fear of change, sub-optimization and/or sacred cows. Closely aligned with failure to recognize the change in cultural due to a CRM implementation
  6. Missing or infrequent active and visible executive sponsorship
  7. Project is perceived by users as optional; CRM software failure is an option
  8. Failure to backfill project team schedules/workloads
  9. Failure to recognize weak (basic PC operation) user skills assessment prior to training
  10. Failure of Risk Management and proactive risk mitigation

Interesting to note that one of the top 10 risks to any CRM project is the lack of proactive risk mitigation!  Your job as a project manager is to identify these above risks (and all others) well in advance of running into them, determine the potential each has for becoming an ‘impact’ to the project, determine whether or not to accept or mitigate the risk, and establish a risk mitigation plan for each risk that you have identified should be mitigated.  Those mitigation plans should have tasks, resources, and due dates that are tracked on your project plan with strict adherence.  Each risk that is not mitigated becomes an ‘impact’, you will have to deal with impacts to the project, but by the time you are dealing with them the project has been delayed, made more costly, reduced in scope, or all 3.  If you don’t have more time or don’t have more money, and Glinda doesn’t come to your rescue, your project has just come to the end of the Yellow Brick Road with the gleaming Emerald City far in the distance.

Jim Lindenfeld, Principal Consultant

Jim Lindenfeld, Principal Consultant

This blog was written by Jim Lindenfeld, who has been actively involved in customer relationship management during his entire professional career.  He is a certified sales and sales management trainer.  He has been involved in the implementation of CRM systems since 1987 and is currently a principal consultant in our CRM practice.

Share : Share on TwitterShare on FacebookShare on Linkedin

Project Killers: Does X Mark the Spot?

X Marks the SpotProject Killers are waiting to pounce on every project – from inception to transition.  In this series we are looking at the most common assassins and exploring the ways to preserve the health and well-being of your projects.  The most heinous killers are:

 

  1. Dead on Arrival (a.k.a. DOA) – A project without the proper estimations for time and resources somehow is initiated. (The Path to On Time, On Budget and In Scope : http://blog.evergegroup.com/?p=1385)
  2. Death by Documentation (a.k.a. Strangled in Red Tape) – A great deal of time and effort goes into plans, requirement documents, and design documents with no real benefit to the project. (Project Killers: An Ode to Death by Documentation: http://blog.evergegroup.com/?p=1389)
  3. Death by Indecision (a.k.a. Analysis Paralysis in its milder forms) – Key project decisions are delayed or avoided altogether. (Project Killers – PSI – Project Scene Investigation “A Case of Slow Death” http://blog.evergegroup.com/?p=1400)
  4. Death in Unchartered Lands (a.k.a. Scope Creep) – The participants, stakeholders, scope, and methods, are never agreed to formally when the project starts. If you don’t know where you’re going, most any road will take you there – but it may take a lot longer and cost a lot more!
  5. Sudden Unplanned Death (a.k.a. Running into a dead end) – risks are not properly identified and mitigated
  6. Death by Starvation (a.k.a. Bottlenecks) – resources are not properly identified and allocated.

We have already dealt with DOA, Strangulation by Red Tape, and Analysis Paralysis in previous blogs.  This blog deals with Scope Creep, enemy number One and the most hated project killer of all time.

Imagine that you make your living by looking for and recovering treasure.  It shouldn’t take much imagination, because that is exactly what you are doing as a project manager, but let’s carry out the analogy to show the congruence.  First, as a professional you wouldn’t chase a treasure that was known to be too small or too costly to obtain.  Second, you would have a ‘map’, literal or figurative, that has a definitive ‘X’ that marks the spot where the treasure can be found.  Third, you would obtain the permissions and licenses needed to hunt for the treasure.  Fourth you gather your investors to fund the trip.  Fifth, you would assemble your treasure hunting team.  Sixth, you would plan your treasure hunting trip.  Finally, you would hunt for and recover the treasure.

It is easy to see the analogy, an IT project is a lot like a treasure hunt.  You initiate the project to benefit (the treasure) your organization.  You have an estimate and a statement of work (the map).  You license the software.  You identify the business stakeholders and obtain the funding.  You put together the project team.  You write up a plan to obtain your objectives.  Finally, you carry out the project and obtain the desired result.  Or do you??

Do you instead ‘get greedy’?  A new map has been found, lying close to your original treasure is another one.  It is temptingly close by and by extending your trip, and pushing your resources to the limit, that treasure can be had!  X no longer marks the spot.  Your careful plans and preparation are no longer going to assure you of finding the treasure you seek, because you now seek more than you had originally planned to.  You have literally released the ‘bird in your hand’ to seek ‘two in the bush’.

When this happens to your IT project, when you reach out for that nearby benefit, you have exposed the heart of your project to the most deadly and feared project killer, Scope Creep.  Yes, there may be more benefit to be had, and yes, it may be reachable by running the project longer and pushing the team to the limits.  However, you must realize your carefully created plans and preparation are no longer going to assure you of a successful project.  Prior to giving up on your original ‘treasure’ in favor of a new, expanded one, you should think of the professional treasure hunters.  What would they do?

The truly successful, professional treasure hunters stay focused on the prize to the exclusion of all potential distractions, they also draw up a charter and make every member of the team commit to that charter, and finally they set up the reward system for the team members in such a way that they are only rewarded for the treasure they are chartered to find.  Do the same for your projects and you will find that X indeed marks the spot much more often than not!

Jim Lindenfeld, Principal Consultant

Jim Lindenfeld, Principal Consultant

This blog was written by Jim Lindenfeld, who has been actively involved in customer relationship management during his entire professional career.  He is a certified sales and sales management trainer.  He has been involved in the implementation of CRM systems since 1987 and is currently a principal consultant in our CRM practice.

Illustration created and provided by Jonathan Pike, eVerge Group IT Specialist.

 

Share : Share on TwitterShare on FacebookShare on Linkedin

Project Killers: PSI -Project Scene Investigation “A Case of Slow Death”

project-killer3

It’s late in the evening in Los Empresas, TX. Even the most dedicated employees at Pastells, Inc. have abandoned their desks, secured their laptops, and joined the sinuous stream of cars on I-47 headed for anywhere but work. Only five grim faced men and women remain around a table in a conference room; the executive steering committee for Project Uplift.   Project Uplift is the CRM project that will propel Pastells into market dominance.   A silver-haired gentleman, Oliver Pastell, jumps from his chair, obviously agitated, pointing excitedly at the screen where the final slide of the executive review still glows. “What this slide tells me,” He shouts “is that Project Uplift is dead!” In the silence that ensues, no one can disagree.

Dead projects are common in Los Empresas. It’s our job to investigate them and bring the killer to justice. Call me Mike, an engagement manager with PSI, Inc.; it’s my pleasure to head up the investigation team. Morgan is my project manager, she’s best at organizing the facts and keeping the team on task. She won’t quit as long as the killer remains at large. Ajay is my architect; he can follow any thread in the investigation and flesh out the facts, determine the probabilities, and plot the next steps. My developers, Harish and Jason, are equipped with the latest tools and training to analyze the evidence and synthesize the facts that either support or disprove our theories on the killer’s identity.

The Project Uplift case came to us the next morning. Ajay, Morgan, and I met to discuss the case over a box of Krispy Kremes and a ½ gallon of hot coffee. “Mike, what do we know about the project?” Ajay managed between bites. I shook my head, “Based on what I have seen so far, this one is a bit baffling. The project had a clear charter, it had good support from the Pastells executives, the plan was pretty well developed and clear, and the objective and scope were understood and well communicated.” Morgan chimed in, “That sounds like a healthy project, what about the people working on it?” I quickly reviewed the list forwarded from Pastells, “It appears that the project team included consultants from the Nopuedes Group, the Pastells Project Manager, Maria Ansiosos, some Business Analysts, some Subject Matter Experts from the business, and the CIO, Raul Espere.” Ajay spoke first, “I know some folks at Nopuedes, and I’ll talk to the project PM.” “Morgan, see if you can speak with Maria,” I directed “and I will send the project documentation to Harish and Jason to see if they can find anything we’ve missed.” I reviewed the list again, “I’m not sure how much the CIO Raul will want to talk to me, it looks like this project was his brain child and he might be like a father in mourning, but I’ll do my best.”

My appointment with Raul is set for later this afternoon; I decide to stop by the developer’s bullpen on my way out. I settle into an office chair next to Jason, grab an Old Dutch pretzel from the open tub and ask, “Anything suspicious, yet?” Jason turns to the keyboard, after a few strokes he turns the monitor towards me. “All of the documents that we have are in order. “ He shows me the original Statement of Work from Nopuedes, the project charter, the budget, the project plan, the requirements, the design, the testing plans, and the resource list before I stop him. “Are you saying that there is nothing wrong?” Harish chimes in, “What we are saying is that there is nothing wrong with what we have been sent, but there is something very import missing – the RAID!” “You mean the Risks, Action Items, Issues, and Decisions log?” I clarify. Harish beams, “Correct! Why did they provide all of the other project artifacts, but leave out the RAID log for Project Uplift?” I look at my watch, time to leave to meet with CIO Raul, and that will be one of the first questions I ask.

“Thanks for meeting me on such short notice.” Ajay says as he shakes hands with Jorge, the Nopuedes PM. Jorge laughs ruefully, “With Project Uplift dead, my calendar was suddenly clear!” “I am just as interested in finding the killer as you are, Ajay, Project Uplift seemed to be a real winner and so important for Pastells.” Ajay continues to keep Jorge talking, “So the demise of the project came as a complete surprise?” Jorge scratches his chin and screws his mouth into a wry smile, “No, Ajay, not a complete surprise, there were rumblings and grumblings but nothing definite.”   Ajay pounces, “Grumblings about what?” Jorge considers his answer carefully. “I can only say what I heard from Maria, the Pastells PM. She told me that the subject matter experts and business analysts thought ‘things’ were taking too long. When I asked her what ‘things’ she was vague. I got the vibe that she was protecting someone. Find that someone and you will find the killer.” Ajay saw no reason to pull his punch, “So you’re saying I could look at your internal project documents and you would have nothing to hide?” Jorge pauses, turns his laptop towards Ajay, “I was just about to do that review myself, you’re welcomed to help.” Ajay starts the review and hopes that Morgan can get some answers from Maria. He jerks the iPhone 6 from his pocket and dials…

“I don’t know what more I can provide than we provided by email this morning”, Maria Ansiosos stated tersely. “I hope you can appreciate that we are busy at Pastells trying to pick up the pieces.” Morgan knows that this is a sensitive subject for the Pastells PM, but she also knows that Maria has important information. “I just want to hear from you why you think Project Uplift died; we’ll be talking to everyone involved.” “I don’t deal in speculation,” Maria replies in clipped, frosty tones. Morgan decides a direct approach will work best, “I just spoke to my teammate Ajay, he heard from Jorge at Nopuedes that you had a conversation with Jorge and that the Pastells team believed ‘things’ were moving too slowly. Were you implying that Nopuedes was to blame?” Maria’s face turns ashen, “No, Jorge and his team did the best they could under the circumstances.”  Morgan moves closer to Maria, “What were the circumstances?” Maria’s shoulders slump, she starts in a low whisper, “I expect every project to have different circumstances, but we’ve been through many projects at Pastells successfully despite that.” Maria stands, turns her head, and with her voice rising declares, “I love my job, I need this job, and I am good at what I do.  I didn’t kill Project Uplift and I don’t know who did!” Morgan follows Maria’s eyes and sees that they are firmly fixed on a nameplate on the corner office door. She slides the Galaxy S6 edge from her pocket, dials and speaks quietly when the phone is answered.

My first impression of Raul Espere is that he looks like a man who has just lost a son or perhaps a brain child. His eyes are bloodshot; his clothes have obviously been on his body for at least the last 36 hours.  The coffee mug in his left hand trembles as he reaches to shake mine.  “Mike, I know I look like hell, but Oliver Pastell wants answers about Project Uplift, and he wants them now. I’ve been up all night pulling together information for him.” From the tone of Raul’s voice, I can tell this isn’t the first all-nighter he’s pulled for Oliver; I decide to follow that line of questioning right after I clear up the number one question on my mind. “Raul, you sent us every other project document, why not the RAID log?” Raul looks over his mug at me, and then he slowly sets it down. “Can you excuse me for a minute?” I watch as Raul speaks quietly with his administrative assistant, he returns to the room and carefully closes the door. “Mike, the RAID was withheld because it contained sensitive Pastells information, I had originally included it in the packet, but after review a decision was made to keep it in house.” I hide my initial surprise, “Who did the review, Raul?” “The executive steering committee,” Raul immediately replies. “The whole committee?” I ask, “Or is there one very important member who might have made that decision?” Raul simply sips his coffee, though I can see he is about to explode. I continue, “What was on that log that could be so important? From what I heard from Ajay and Morgan, the PM’s had done a good job of identifying risks and issues and ways to avoid and mitigate them. Harish and Jason have verified that the plan was resource loaded and action items were included. Raul, that only leaves – Decisions!” Raul blurts out to stop me, “I made every decision asked of me, I weighed the facts, gathered opinions, brainstormed solutions, and delivered decisions!” I could tell he was telling the truth, but not all of it. “I believe you Raul, but without that RAID, there really is no evidence of that. I know that this project was your brain child, that you mourn the death of Project Uplift more than anyone else, but that’s no reason to let your career go to the grave with it.” His weary head with the blood shot eyes lifts towards me and then turns to the corner office. “Let me guess and see how close I come,” I continue “they key member of the executive steering committee that decided not to send us the RAID log was Oliver! I can only guess at how many late nights you’ve spent feeding him information waiting on a decision only to be asked for more time and information. I bet that when the RAID surfaces, and we will dig until we find it, it will be red with decisions waiting on Oliver.” Raul slowly pulls open a desk drawer and lifts out a thick Pendaflex folder, clearly marked Project Uplift. From the center of the folder he extracts a printout of an Excel spread sheet that looks like a RAID log. He hands it to me and begs quietly, “This is what you need, be careful how you use it.”

Oliver Pastell is gracious as he invites my team from PSI, Inc. to take a seat. Ajay and Morgan find conference chairs to my left while Harish and Jason choose the leather couch to be closer to the box of See’s chocolates. I can hear the candy wrappers rustling as Oliver starts to speak. “What have you uncovered with your investigation?” I decide ‘careful’ is the right approach, “Mr. Pastell, Oliver, we understand that this is your first major project as the CEO, is that correct?” Oliver is obviously discomforted by the question, “Yes it is.” I follow with, “In fact, you only recently returned to Los Empresas and took control of Pastells after your brother was killed in a private plane crash.” Oliver leans forward, hands on desk, “What does that have to do with Project Uplift?” Just then Jason blurts out, “Project Uplift died because you didn’t make the timely decisions on project direction when they were needed, a clear case of Death by Indecision.” So much for a ‘careful’ approach. Oliver looks at Jason, then Harish, Ajay, Morgan and finally me. It is clear to him that we all agree with Jason that he is suffering from severe Analysis Paralysis. Finally he speaks, “Ever since that night I learned Project Uplift had died, I had a nagging feeling it was my fault. How can I avoid this in the future?”   As always, we are prepared to help keep Project Killers at bay and I hand Oliver a reprint of a decision making article from David Ingram:

Identify Problems

The first step in the process is to recognize that there is a decision to be made. Decisions are not made arbitrarily; they result from an attempt to address a specific problem, need or opportunity.

Seek Information

Managers seek out a range of information to clarify their options once they have identified an issue that requires a decision. Managers may seek to determine potential causes of a problem, the people and processes involved in the issue and any constraints placed on the decision-making process.

Brainstorm Solutions

Having a more complete understanding of the issue at hand, managers move on to make a list of potential solutions. This step can involve anything from a few seconds of thought to a few months or more of formal collaborative planning, depending on the nature of the decision and the time allotted to make it.

Choose an Alternative

Managers weigh the pros and cons of each potential solution, seek additional information if needed and select the option they feel has the best chance of success at the least cost. Consider seeking outside advice if you have gone through all the previous steps on your own; asking for a second opinion can provide a new perspective on the problem and your potential solutions.

Implement the Plan

There is no time to second guess yourself when you put your decision into action. Once you have committed to putting a specific solution in place, get all of your employees on board and put the decision into action with conviction. That is not to say that a managerial decision cannot change after it has been enacted; savvy managers put monitoring systems in place to evaluate the outcomes of their decisions.

Evaluate Outcomes

Even the most experienced business owners can learn from their mistakes. Always monitor the results of strategic decisions you make as a small business owner; be ready to adapt your plan as necessary, or to switch to another potential solution if your chosen solution does not work out the way you expected.

We stand to leave, and Oliver walks with us to the door. I turn to him with one last piece of advice, “The most valuable decisions are not only well informed, but are also timely as well.” As the door closes behind me, I smell the unmistakable scent of dark chocolate enrobed salted caramel from the stolen box of Sees. It is delicious!

This case is closed.

Jim Lindenfeld, Principal Consultant

Jim Lindenfeld, Principal Consultant

This blog was written by Jim Lindenfeld, who has been actively involved in customer relationship management during his entire professional career.  He is a certified sales and sales management trainer.  He has been involved in the implementation of CRM systems since 1987 and is currently a principal consultant in our CRM practice.

Illustration created and provided by Jonathan Pike, eVerge Group IT Specialist.

 

Share : Share on TwitterShare on FacebookShare on Linkedin

Project Killers: An Ode to Death by Documentation

project_killers

The story below illustrates one of the most common project killers – documentation for the sake of documenting, performed at the expense of making true progress towards project completion.

This is the story of one Guru Kumar, a brightly shining Acme PMO star.

Guru was an expert on SDLC, RTM, UML, and Rational Technology

Microsoft Office, and Visio, and Plan, were as familiar to Guru as his right hand

So as soon as the project began, everyone knew Guru would be the ‘man’

First he redid the requirements list, just in case an item was missed

He re-estimated the tasks with pep, to ensure the Plan would have each step

To prevent any false move, every document would be doubly approved

And Guru proved that he could wait, even when the approvers missed the approval date

Days turned to weeks with no code begun, but the documents piled up one by one

Requirements Traceability in 2 different views, Gap Analysis for every screen to be used

Scenarios, Use Cases, Success Metrics and more, each crafted with greater care than the one before

Next came the RAID, test cases, and executive summaries too, each with redundancy about what the project would do

The project team once eager to get started, became very quickly broken hearted

The project with such potential for return, was just about certain to crash and burn

Some dared to ask wouldn’t it be smarter, to start instead with a Project Charter?

That document defines the scope and rules, defines what will be done and what will be the tools

And surely, wasn’t enough about the project known, that the first seeds of a Project Plan could have been sown?

That the other docs would be needed there was no doubt, but would it have been possible to spread them out?

At last Guru felt that the documents were created, but to his dismay found that the team hadn’t waited

New priorities in the Acme business had been found, and some from the team were no longer around

The budget for the project was almost all spent, the investigation begun into where the money went

Guru Kumar found to his dismay that Project Killers are always eager to hold sway

Guru learned that no matter how hard he was working, Death by Documentation is always lurking

He found that the method that works the best, the method that has been tried and passed the test

Is to keep in mind that the project objective is best achieved when you are selective

About the documents you think you need, and discard the rest like a noxious weed

Only create them when needed and ensure that they are living as long as the project endures

Cry not for Guru, his bridge wasn’t burned; Acme realized the lessons he had learned

The Acme PMO once again has a brightest star, the much wiser, and less busy, Guru Kumar.

Jim Lindenfeld, Principal Consultant

Jim Lindenfeld, Principal Consultant

This blog was written by Jim Lindenfeld, who has been actively involved in customer relationship management during his entire professional career.  He is a certified sales and sales management trainer.  He has been involved in the implementation of CRM systems since 1987 and is currently a principal consultant in our CRM practice.

Illustration created and provided by Jonathan Pike, eVerge Group IT Specialist.

 

 

Share : Share on TwitterShare on FacebookShare on Linkedin

Project Killers: The Path to On Time, On Budget and In Scope

project_killersA new IT project has been initiated. The CRM system is going to be upgraded and integrated. Visions of new capabilities and increased profits fill the waking hours of the CEO and the VP of Sales. By day the CIO appears to share in that dream, but while everyone else sleeps, the CIO is visited by the nightmares of projects from the past where deadlines were missed, cost overruns were the norm, and a severe reduction in project scope was inevitable. Sometimes, when the nightmares are the scariest, the CIO even allows his psyche to relive the horrors of several projects that were complete failures. Meanwhile the IT Project Management Office, the Business Analysts, the System Architects, and the Developers stare in disbelief at the list of approved requirements and the approved budget and timeline for the project and sadly shake their heads. “Do they even have a window in that ivory tower?” they mutter. To all but the most uninitiated, the project is dead on arrival. How did this happen, how can it be prevented in the future?

Successful IT projects can no longer be optional or left to chance. Due to the inseparable integration of IT and the rest of the business, the success of IT at any business is the success of the business. We are taking a fun and somewhat irreverent look during the next few postings at the Project Killers in our midst and how the white knights in business and IT can vanquish them in as part of a successful project.   These Project Killers are usually easy and inexpensive to avoid, yet most of us have fallen victim to one or more of them:

  1. Dead on Arrival (a.k.a. DOA) – A project without the proper estimations for time and resources somehow is initiated
  2. Death by Documentation (a.k.a. strangled in red tape) – A great deal of time and effort goes into plans, requirement documents, and design documents with no real benefit to the project
  3. Death by Indecision (a.k.a. analysis paralysis in its milder forms) – Key project decisions are delayed or avoided altogether
  4. Death in Unchartered Lands (a.k.a. scope creep) – The participants, stakeholders, scope, and methods, are never agreed to formally when the project starts. If you don’t know where you’re going, most any road will take you there – but it may take a lot longer and cost a lot more!
  5. Sudden Unplanned Death (a.k.a. running into a dead end) – risks are not properly identified and mitigated
  6. Death by Starvation (a.k.a. bottlenecks) – resources are not properly identified and allocated

Many projects are Dead On Arrival – DOA.   Often this happens because the actual amount that would have to be invested to achieve the expected results is significant enough to reduce the return on investment to a level that is no longer acceptable. So instead of a fair estimate for a reasonable gain in productivity/reduction in cost, companies and their suppliers “tweak” the estimates to be more favorable – the delivered system is estimated to bring more benefit, the investment in licensing and maintenance costs is underestimated, the resources required – both internal and external to the company – are estimated at reduced levels, and all of that will happen during an accelerated time line! Perhaps this has happened to you once or twice?   Perhaps you have even had the project approved based on those over and under estimations to find that you can’t even get the project successfully started – in other words, the project is DOA.

If your corporate culture is geared to delivering a number of DOA projects, you can break the cycle and get back to successful IT projects that deliver fully on their promised benefits, on time, and within budget. Here are the simple and inexpensive steps to avoid a DOA project.

Good, Fast, Cheap – Pick any 2: This is a great way to prevent DOA projects. First, define ‘Good’ – what is the real problem that you are trying to solve – increased productivity, cost avoidance, customer satisfaction, employee morale, competitive advantage, new legislation, etc.? How much is solving that problem worth to your company – try hard to put it into dollars and cents! Next, define ‘Fast’ – is there an event on the horizon that dictates the release date? You should consider product releases, fiscal years, acquisitions, competitive activity, corporate recognition programs and national meetings, and meeting legal requirements among other time related drivers. Finally, define ‘Cheap’ – based on preliminary estimates what is the maximum amount of money you are willing and able to invest in the system? When putting together the project, simply remember that you will always be able to have only 2 out of Good, Fast, and Cheap. If you want a complete, high quality solution (Good) and you need it quickly (Fast) it will NOT be inexpensive (Cheap). If you want a high quality solution (Good) and you want it to be inexpensive (Cheap) it will NOT be Fast! Finally, if you want it Fast and Cheap, it will NOT be Good!

In today’s IT environment where the pace of innovation is constantly accelerating, few if any businesses can afford to choose Good and Cheap at the expense of Fast – the project delivery will be so far in the future that the envisioned benefit may not be realized (and we have seen this happen!). So that leaves just 2 choices – Good and Fast; and Cheap and Fast. That is why it is so important to carefully define ‘Good’ and ‘Cheap’ initially. If your definition of Cheap is significantly fewer dollars than Good (project has a high ROI) then pick Good and Fast and recognize that your investment may be higher than estimated. If your definition of Good and Cheap are closer together, consider breaking the project into smaller, quicker wins and choose Cheap and Fast to keep to budget with a partial solution. Finally, if your definition of Good is less than your definition of Cheap realize that the ROI for the project will most likely be break even or negative and only proceed where required by legal or business conditions and choose Good and Fast since it is likely that you are proceeding only in the cases where you need a quality, complete solution in a hurry. In this scenario, expect to invest more than you initially thought you would.

Remember “Good, Fast, Cheap pick any 2” and your projects will be vital and alive at inception. Avoiding the other Project Killers can be just as easy. We will discuss the process over the next few postings to this blog.

Jim Lindenfeld, Principal Consultant

Jim Lindenfeld, Principal Consultant

This blog was written by Jim Lindenfeld, who has been actively involved in customer relationship management during his entire professional career.  He is a certified sales and sales management trainer.  He has been involved in the implementation of CRM systems since 1987 and is currently a principal consultant in our CRM practice.

Share : Share on TwitterShare on FacebookShare on Linkedin

Keys to CRM System Adoption: Executive Involvement and Commitment

In previous articles in this series we pointed out that high rates of user adoption maximize the benefit of a CRM system to every system user in an exponential way as every key process in the business; planning, marketing, selling, servicing, and analyzing, is enriched by the increased information and functionality of the CRM system. In subsequent articles we described the drivers to user adoption, and the best ways to make them part of your corporate DNA. This is the final article in this series.

An old joke:   What is it that no man wants but no man wants to lose? A bald head! It seems that we could easily paraphrase this to fit the topic. What is it that no Executive uses but no Executive wants to lose? A CRM system! It has been proven over and over in thousands of CRM implementations (in fact in just about any corporate initiative) that the number one success factor in the implementation is early commitment to the system and early adoption of the system by the Executive team. It is the #1 success factor for 2 reasons; 1.) The commitment leads to adequate funding and resources, and 2.) The adoption by the Executives drives adoption by the other employees in the company.   Unfortunately, many CRM systems deliver far less value than they should because the Executives, who committed millions of dollars to the system in hopes of a healthy improvement to the bottom line, never fully commit to or adopt the system. Ask any executive at a company with a comprehensive investment in a troubled CRM system if they want to lose the information and functionality that it provides and you will get 2 answers, both start with NO! You will either hear; “NO! We have the right system and we get some valuable information, we just need more participation.” or you will hear “NO! We are evaluating a new system that will be easier to use so that we can get more information and functionality.”

Assuming that they have addressed the other factors that drive user adoption (Pay for Play, EASE, and Coaching) it can be safe to say that if the CRM system is still suffering from user adoption issues (to mangle Shakespeare) the fault, dear executives, lies not in your users but in yourselves. This can be quickly and easily fixed, but it means that executives, who likely brought the change of a CRM system to the company, will have to move to the front and lead that change!

Another old joke to demonstrate the difference between commitment and involvement: At a bacon and egg breakfast – the pig was committed and the chicken was involved. Executives must be committed and demonstrate it by:

  1. Including the CRM system as a budget category for all business departments
  2. Creating channels for corporate change management messages about the system and ensuring that a pipeline of messages is queued up in each channel
  3. Committing to the time, money, and people needed to develop the system
  4. Committing to the time, money, and people needed to train the users
  5. Committing to the time, money, and people needed to maintain and improve the system
  6. Committing to joining and participating in industry councils
  7. Committed to the CRM System to gain a sustainable advantage in the marketplace
  8. Commit to be a key member of the executive steering committee

Executives must adopt the system and demonstrate it by:

  1. Personally using the system for forecasting, quota management, and pipeline analysis (sales). This means, no ‘one off’ out of the system spreadsheets or databases with layers of analysts between the executives and the rest of the user community
  2. Using the system for measuring performance to SLA’s, customer satisfaction, cost of service, and cross sell revenue (service)
  3. Using the system to see the ROI and effectiveness of marketing campaigns and to understand the handoff from marketing to sales and finally to service
  4. Using the system for the corporate intranet, internal communications, file transfers and storage, collaboration, and event management

Most importantly, you have to do all this with a smile on your face (and in your heart!) and you have to be the first in line to do it! Here is a quick check list of questions to ask yourself as an executive:

  1. Am I leading the change management effort for the CRM system?g. Did I organize and chair the committee? Am I involved daily in promoting the system in some way?
  2. Am I the best trained user in the company?
  3. Do I get 100% of my analyses from the CRM system for Sales, Service, and Marketing?
  4. Do I have a road map for what improvements need to be made and when to make them? Do I even have a process in place for continuous system improvement?
  5. Do my teams see me using the system proficiently?

Final old joke: Doing things the same way and expecting different results is the definition of insanity. Ask yourself, “Did I invest millions in a CRM system, expect everyone else to change, while I remained the same and still get different results?” Instead, isn’t it time to pick up the flag, face the line of retreating users, and charge right back at the competition with a renewed commitment to the system and a promise to be the first and most important adopter!

Jim Lindenfeld, Principal Consultant

Jim Lindenfeld, Principal Consultant

This blog was written by Jim Lindenfeld, who has been actively involved in customer relationship management during his entire professional career.  He is a certified sales and sales management trainer.  He has been involved in the implementation of CRM systems since 1987 and is currently a principal consultant in our CRM practice.

Share : Share on TwitterShare on FacebookShare on Linkedin