Project Team Blog

Consider this dilemma…  The IT department is backed up for six months.  It can’t take on any new projects for that time.  Not even a little 4 - 8 hour database installation.  With a log jam like that, they can’t get anything new in.

Management comes along with a new product evaluation.  Problem is, they need IT to set up a new SQL database so they can test the system.  Oops, can’t do it.  There’s a six month waiting list, and nobody get to the head of the line.

So, management can’t evaluate the product.  Even a product they desperately need.  IT has failed the company in a big way.  The frustrating thing is that most of those IT projects are probably lower priority, or impossible to complete.  Incompetence has allowed such projects to block real work.

The only real solution to an issue like this is “better generaling.”  I.e. better planners who know roadkill when they see it, and pitch it off the road so it can’t block the real projects.  That takes a smart person with a little experience.  Gain a skill like that (and a hundred others), and you suddenly become a valued member of the team.

–ray

eWeek did a little editorial on “IT Snow Days.”  (See link below.)  Anybody out there read eWeek?  It sure is collapsing slowly - down to 42 pages, and no more Spencer Katt.  The competitor InfoWorld went out about a year back.  Now, I suspect eWeek will follow.  I guess it’s pretty hard to get IT folks interested in industry news.  Anyway…  Here’s the article.

http://blogs.eweek.com/up_for_discussion/content/it_management/it_product_snow_days.html

I liked the article because it sympathizes with IT managers who are being hit with economic snowstorms.  It’s really hard these days.  Mostly for me, it’s hard staying motivated when everything around me is crumbling.  Anybody feel that way?  There will be a few snow days to make up for when good times come again.  That’s for sure.

–newshirt

I talked with an IT professional over the weekend.  This person lamented over their constantly late projects.  I told them about Standard Time®, and how it tracks project time.  They loved the idea!  But continued the lament, claiming they would never use such a product.

I just stood there stunned.  Why not?  I didn’t ask, but assumed it had something to do with the economy, frozen purchases, and what not…

But I just kept thinking…  Wouldn’t Standard Time pay for itself?  Late projects, especially persistently late ones costs companies money.  Lots of it.  A few thousand dollars for software would tighten up those schedules and force the company into compliance.  The ROI would be 3X or more.  So, why not use it?

I suspect it’s unfamiliarity.  People simply don’t know how to use time tracking and project management products.  No training.  No familiarity.  Nobody’s firing them for late projects, so they keep doing what comes naturally.  Oh well… 

–newshirt

Last night I attended a party at an old friend’s house.  After small-talking my way around the deck, I hooked up with some old acquaintances, with whom I had participated in a software project.  The gig we shared had taken place back in 1999, in Atlanta.  It was one of those 90’s love-fest dot-com jobs.

While sipping cokes and gobbling slices of homemade pie, we discussed the project’s failings.  “What went wrong?” I asked my colleagues.

“I think it was the fault of the CEO,” one said.  “He just had no experience, and wasted all the money.”

“No, the development organization was all messed up,” the second said.  “The lead engineer kept jumping in and changing everything I did.”

“Well, I think they spent all their money on marketing before they even had a product to sell,” I put in.  “You have to make some sales and get customer feedback before you can spend millions on marketing.  Don’t you think?”

The discussion heated up for the better part of an hour, and I realized that none of us, even ten years later, knew exactly where the faults were.  Who had messed up?  What had gone wrong?  Why hadn’t we succeeded in shipping a product and engaged the sales channel.  None of us knew for certain, yet we all saw some pretty gross mistakes.

That really got me thinking…  Sometimes project failures are not as easy to diagnose as one might think.  Even by salty old dogs like us.  And everybody has their own opinions.  Think about that the next time your project bites the dust.  Or before it does.

–ray

I once read a bizarre statement, written by an overloaded IT manager.  He was complaining about the heavy workload his executive management was throwing on him.  Here is what he said:

When a new project request comes down, I just ignore it.  I ignore it until management makes it clear my job depends upon it.

Wow!  That’s revealing!  Evidently, this poor soul is so swamped with exciting new projects that he is forced to ignore the bulk of them.  I can vividly see how these superfluous demands go down.

First, the executives get a great idea.  Yeah!  Let’s restructure the customer database to maximize the communication [read: spam] we send out.  We’ll get some great sales!

The project is handed off to Harold in IT.  “He’ll make it happen,” the suits say.

Harold comes in Monday morning, sorts through 400 spams, and finds the outlandish request.  He rolls his eyes and drops it into the “Oh Boy!” folder.  And then he checks the ESPN stats.

The execs never give the project another thought.  They just go off and reinvent the company ten more times, dumping an equal number of requests on poor Harold.  And he ignores them all.  He doesn’t have time for the fun.  He’s got real work to do.

Am I off?  Got it all wrong?  Honestly, I don’t think so.  I’ve seen numerous projects like this get swept under the rug.  Execs don’t run the show, the little guy does…

–ray

Every project manager knows he must identify project risks, document them, and resolve each one.  In other words, he must learn what could jeapardize the duration, budget, or quality of his project.  If you don’t, the project may fly off the tracks and you’ll look bad, or worse.

Problem is, your engineers are hiding those risks from you.  The fictional dialogue below shows how it happens.  It is a faux conversation between your project manager and one of the engineers on the team.

PM: “I love your new designs!  This project is really coming along.”
Eng: “Uh-huh.” (hoping to be left alone.)
PM: “Do you think you’ll be finished by October.  Big deadline you know!”
Eng: “Of course.” (barely lifting his head.)
PM: “Any risks or unknowns?  How about that integration task?”
Eng: “Nothing I can’t handle.” (peering deeply into the montor.)

Engineer-boy has two problems.  First, he’s a little too independant to admit he needs help.  Secondly, he won’t risk the tarnish to his stellar reputation.  No white-shirt, tie-bearing, non-pierced PM will ever get him to crack.  He’ll work all-nighters if he has to, or so he tells himself.

–newshirt

Nothing slows a project team quite as well as a pathological scenario or a person focused on that scenario. There is a huge chasm between the due diligence of “what if” questions that are likely possibilities worthy of consideration and the terminal scenarios that will, more than likely, never happen. The goal as a Project Team leader, or any manager for that matter, is to quickly separate the two and move on with the real issues. Too often, equal time and weight is given to both scenarios.

In fact, that nearly happened to me this week. I spent about 2 hours in a meeting discussing various topics and questions when a pathological expounder forced the whole group to spend 20 minutes on a crazy “what if” scenario. This leads to critical slow downs and ultimately analysis paralysis. I was lucky  to defuse this situation before it ate up the whole meeting. 

So, the next time someone asks a “what if” question, ask a few of your own. How likely is this? What is the foundation for the question and what is the impact? By asking these simple questions you will force the person to evaluate their questions more clearly which removes the emotion and fear that typically drive these issues. Now, you have given logic a chance, which gives your projects better focus and makes them more likely to succeed. Any questions? 

–Warren

Project Management Advice: Get Corporate buy-in for your projects.

In other words, make sure the corporate executives are active stakeholders in your project.  I suppose this goes without saying, but I’ve seen lots of projects where this is not the case.  Project teams somehow come to the conclusion that their project will be funded and accepted, even though corporate has not explicitly said so.

Just because your team is developing a new product or in-house tool, doesn’t mean corporate will stand by you.  Without vested stakeholders at the highest level, your project could easily be canceled.

The name “Harold” comes to mind when thinking of this subject.  I worked with a man named Harold who was researchinig a product for his company.  Months went by as he studied the features and benefits.  He eventually took a job with another company and I discussed the project with his boss.  His boss said he never knew what Harold was up to, and had no intention of adopting the product!

–ray

There are a lot of possible reasons for this.  I’ll enumerate the reasons why I think projects cost more than expected, and then discuss the most probable ones.  Let me know what you think!  Got a few more reasons?

1. Forgotten tasks
2. Unknown tasks
3. Customer expectations change
4. Feature creep

My biggest issue is always ‘forgotten tasks’.  In my experience, forgotten tasks results in project cost overruns more often than any other reason.  People tend to throw out a cost before they have listed all the work involved.  Halfway down the road, they remember 25 - 50% more tasks.  That adds up!

Sometimes, one thing leads to another.  Tasks that you didn’t know about pop up.  What are you going to do when that happens?  You can’t just abandon the project.  You have to eat the extra work and absorb the cost overrun.

Once your customer gets a look at the product, he may have a few new ideas of his own.  He may see something he likes, and feel free suggest some additions.  Those add up too.  Just make sure he knows that he must absorb the additional project costs.  Otherwise, you’ll end up eating that too.

Feature creep happens when customers and developers like what they see and want a little more, and little more, and a little more.  Before you know it, there’s an extra 10% cost in the project.  Yikes!

–ray

If I give you 90 days to complete a project, but don’t hand you a checklist, chances are the project won’t be completed.  A project without clear deliverables is a green light to surf the web all day.  It doesn’t have the teeth to get anything concrete done, and leaves you without direction.  Given such a project, most people will simply say, “I’ll do what I can,” and then do almost nothing.  I’ve seen it happen.

Measurable goals
Consider making your goals measurable in some way.  Find a way to boil them down to simple numbers.  Example: this new feature will let us process 1,500 new transactions per day.  Or, the new system will let 1,000 new customers to submit service requests.  Don’t just say, “make it better.”  Make it measurable instead.

Make it quick
Giving arbitrary timeframes like 90 or 180 days without milestones is foolish.  Some people will believe they have all the time in the world, and wait until the night before to start.  Remember cramming?  That’s the mode most many people work in.  Instead, tighten in the deliverable dates, and let the project go late, if necessary.  That tends to keep people on task.

Make it simple
Don’t try to boil the ocean.  It never works.  Simple, foundational projects work best.  If they are completed to your satisfaction, you can build upon them later.

Now you can roll your eyes (like I do) when you hear, “it’ll be finished in 90 days.”

–ray

I thought I was done with this subject last week.  But then it struck again, Analysis Paralysis!  I am near completion of a deal that is over 4 years in the making, not for me, but for a fortune 100 company.  In other words, they’ve been work it this long.

This company has been looking for a solution and had contacted one of our reps back in 2003.  They were about to move forward with the implementation but someone convinced them to wait, and ultimately pushed to build the program in-house.  It’s the same story I hear time and again, “we can build it in-house for half the cost”.

Yeah, right.

So here I am in a conference call with a handful of representatives from this large company and they are sharing with me how after 4+ years they couldn’t build a good tool and wanted to use ours.  This happened for a number of reasons.  Reason #1…It’s not what they do!  Sure it looks easy, but when you actually set out to do it, reality hits.  Reason #2…not enough time.  Building a tool takes away from their core business, and that always takes a back seat.

Suppose I wanted a nice wooden baseball bat and I see that Louisville Sluggers cost $29.  If I’m not careful I could be talked into buying a piece of lumber, sticking it on a wooden lathe and saving myself ten bucks to make my own.  We all know that would be a disaster. Yet somehow in business we don’t always take that same common-sense approach.  Instead we waste too much time arguing, waiting and losing money.  Isn’t it better to pay a small premium for another’s well invested expertise?

Waiting usually costs more than doing nothing or delay.  As one CEO recently said, “After hearing all the facts, make a confident decision, even if you aren’t certain.  It’s indecision that is costly”. 

–Warren

Biblically, 7 is the number of perfection, and 6 is the number of “man.”  Remember 666, the “number” of the Antichrist?  In light of that, I’m going to enumerate the worst sins consulting companies can make.  These are the ones that doom them to hell on earth.  If you’ve been in business for any length of time, you have probably already nailed these and gotten past them.  But they may be worth reviewing.

#1: Ignoring your customer’s complaints
The customer is always right, right?  No, not true.  But, when they believe they are right, you had better be there to work things out.  Sometimes you can make them see your position in a disagreement, but more times than not, you’ll need to suck carpet and make things right.  That’s part of what they expect of the relationship.  The mere fact that you take money from them puts you in that position.  Cruel fact of life - get used to it.

#2: Failure to smooze
This one is akin to the first, but slightly more on the positive side.  Remember the old adage “out of sight, out of mind?”  That’s what happens when you haven’t had face-time with your customer in a while.  They literally think less of you.  The relationship grows cold and they are less likely to call on you when a need arises.

#3: Letting sales slip
Consultants and consultancies have two big jobs: consult and sell consulting services.  Both are equally important.  Once a gig has been landed, the tendency is to settle in and forget about what comes next.  Looking for the next gig is hard.  It’s much easier to do what you’re competent at, and let the sales work take care of itself.  Problem is…  it often doesn’t.  When the gig ends, you’re on the street again without work.

#4: Shoddy work
This one’s so obvious, it’s hardly worth mentioning.  But it really goes deep down to the type of person you are.  Keep your standards high.  Remember that you are competing with other consultants, and for future work.

#5: Low utilization
Got a nice high billing rate?  Higher than working at Wal-mart?  Consider this: your “effective” billing rate (or utilization rate) is your revenue divided by the total calendar hours.  For example, $50,000 divided by 2,000 possible billable hours in a year is an “effective” rate of only $25 per hour.  You may charge $100 and hour for your time, but only book 25% of the total possible hours.

#6: Not picking up the scraps
Nobody likes to think of themselves as a handyman who takes odd jobs.  We’re skilled professionals with higher education.  But there’s no shame in stooping down to pick up small jobs.  Sometimes you can even charge more for them.  They can fill gaps between the big gigs and give you interesting new experiences.

–ray

This is a follow-up to the post named “Why IT Projects Get Killed.”  I began to wonder at what stage IT projects get killed.  In other words, when they are canceled.  Most of the projects I’ve worked on have been successful, but I’ve seen my fair share of canceled projects.

For this post, I decided to take a guess at when I felt IT projects are canned.  Of all the canceled projects, these are my guesses at when they occur.  I have no detailed surveys to back up my assertions, just a little experience.  So, here goes…  Post a comment and let me know what you think.

    25% In the investigative stages
    50% In the requirements gathering stage
    10% In the development stage
    10% In the final QA stage
    5% In the pre-sales marketing stage

25% In the investigative stages
This one’s fairly obvious.  A project passes the “good idea” stage and passes into the “due diligence” stage to learn its true value.  That’s when it dies.  Not all good ideas have true merit, or can be marketed effectively with the given resources.  It’s common for projects to die here.

50% In the requirements gathering stage
Here, the project members are interviewing customers and collecting information.  They may even be building prototypes to prove the concept.  But just as in the investigative stages, the idea may die because it cannot meet requirements or marketing expectations.  Again, lots of possible reasons for cancelation, but most of these are because the idea wasn’t feasible.

10% In the development stage
By the time it’s gotten to the stage where development resources are committed, it’s probably proven to be viable or too highly visibility to cancel.  By this stage, the project stakeholders may never cancel it, even if it isn’t viable.  Egos and persistence are at play here.

10% In the final QA stage
Sometimes products never meet customer expectations, or will cost too much to do so.  The project may have gone terribly over budget, and customers hate it.

5% In the pre-sales marketing stage
Surprisingly, some get to this last stage, and still die.  I was once involved in such a project in 1995.  It was killed after two years of intense development, before a single sale was made.  That’s right!  We finished a two-year death march, only to find the product pulled from marketing.  There were too many competitors and not enough customer value.  That fiasco, and a few others like it, eventually killed the entire company.

–ray

We’ve all heard the term analysis paralysis, and frankly it is a millstone around the necks of many corporations, especially ones that are heavily layered in management.  In today’s world economy only the quick and flexible survive. 

Imagine you have a great idea you spend days, if not weeks, researching.  You run the initial numbers and cost analysis that shows a marked improvement with a bottom line benefit.  You can hardly contain your excitement!!  So, let’s get started, right? Wrong!

Bob, over in development, isn’t sure this will actually save the company money and he thinks they “might” be able to build their own tool.  So he talks to Chris in accounting and before you know it there are too many cooks in the kitchen and everything is on hold!

It took 6 months before a decision was made to build this tool in-house.  It took Bob’s team over a year to figure out they couldn’t build the tool properly, and they spent 12 times the amount the original “off the shelf” implementation would have cost!  And the final result?  Still waiting…

If they had simply gone with the original idea of an off the shelf tool they would have saved the company enough money to buy the thing 20 times over!  Instead they’re back at square one.

I am all about due process and thinking things through.  However, at some point a decision must be made and all too often one isn’t made out of fear, job security, or simply because someone is being territorial.

This is a common story and that’s why strong leadership is important.  If you’ve done the homework and you know it’s a worthy endeavor… push, push and push some more.  In the end you will be rewarded for a job well done or sleep well knowing you gave everything you had.  To use a sports term, “Leave it all out on the field.”

–warren

I like CIO Insight.  They seem to hit a lot of relevant issues.  Their “Why IT Projects Get Killed” is a short slide-show with a simple breakdown of the top five reasons IT projects get killed.  A link to the article is below, and I’ll comment on the top reasons.

http://www.cioinsight.com/c/a/Management/Why-IT-Projects-Get-Killed/

Reasons:

1. 30% Business Needs Changed
2. 23% Does Not Deliver As Promised
3. 14% No Longer a Priority
4. 13% Exceeds Budget
5. 7% Does not Support Business Strategy

Well, that’s only 87%.  I suppose the other 13% fall into the “Other” category.  I’d like to take a crack at interpreting the numbers.  Here are my thoughts on why IT projects are killed.

30% Business Needs Changed
From the time a project is first proposed until it is started, things have changed.  These are often projects tightly connected to cultural events.  For instance, your proposal for a new drive-through pharmacy may lose 7% of its expected revenue if the price of gas goes to $5.  Anything that tightly connected to consumer behavior must be watched closely.

23% Does Not Deliver As Promised
Oversell and hype.  Lots of people do it, and lots fall for it.  It always surprises me how pessimistic people are when investing money, but how easily they fall for a good story.  Almost a quart of the projects don’t live up to the promise.  But it’s not jsut hype that contributes to this number.  Sometimes people simply don’t realize how big a project is when they start it.  That’s understandable.

14% No Longer a Priority
This feels like reason #1.  Business needs change, and the project is no longer a priority.  But I suppose there other reasons a project may no longer be a priority: Can’t make money at it, Other solutions have arisen to replace it, Employees or customer have changed.  But still…  aren’t these all “business needs.”  If so, a full 44% are canceled just because “things change!”  Yikes!

13% Exceeds Budget
I expected this to be higher.  Most people I talk to go over budget on their projects.  That’s why they use products like Standard Time®.  They know they’ll be cancelled if they go over .  Well, maybe it’s doing its job!

7% Does not Support Business Strategy
This happens when unlearned individuals go off on exciting missions that the executives don’t support.  A project gets started, but killed soon after - once it’s discovered to be nonsense.  I’ve run into quite a few of these individuals.  But I don’t fault them; they try.  And that’s all the CEO really expects of them.

–newshirt

If you’ve ever read a project management book, you’ve run across the statistic that 50 - 70% of all projects are over budget.  Seen that, right?

What’s up with that?  More times than not, I would guess that is a tactic to hook you into something.  Maybe, it’s to buy a book.  Or, a take a webinar, or buy consulting services.  Look closely at the context the next time you see that.  I will too.  Now I’ve gotten myself curious. 

But I wonder how they know.  First off, only organizations that track their projects (time tracking, resource tracking, etc) know if they are over budget.  And most people don’t do that.  Instead, they fly by the seat of their pants, relying on hunches.

Secondly, so what?  When your project is finished, you’ve probably happy about that, and don’t care to look back - unless you’ve taken a real black eye.  It’s usually the fit-and-finish that takes three times longer than anticipated, but you’re always proud of the final product.  So why worry about a little extra moolah.

How’s your project coming?  Is it over budget yet?

–ray