Banking optimize

10 red flags that shout 'Stay away from this project!'

Like most consultants, you've probably gotten stuck on a doomed project at one time or another. But if you know what to watch out for, you can avoid getting mired in a project mess.

Over time, I have been involved in some of the worst projects ever as a freelancer, consultant, or some other "non-employee" relationship. When you are a direct hire to a company, you do not have the freedom to pick and choose what you work on. But as an outside person being paid to work specifically on one project, you do have the choice. I have been burned so many times it isn't funny, but I have learned a lot from my mistakes. Here are 10 of the biggest red flags I've encountered. I am sure you have more to share in the discussion thread.

Note: This article is also available as a PDF download.

1: No clear spec or goals

All too often, I've been approached to work on a project, but the person trying to arrange the deal can't tell me what they really need done. It's not that they are under some strange code of silence. They really have no clue what they want. They have a general idea of what the finished product should look like and a really good understanding of its differentiating factors or killer features, but outside of that they have not thought it through. This is one of the most common and most significant danger signs! How many hours' worth of work do you want to throw away on a regular basis because the client realized after you built it that what they asked for wasn't what they needed? At the very least, these kinds of projects should be contracted only at a per-hour rate.

2: Funding problems

Are you being offered to be paid a percentage of revenue or paid over time? If so, that is a warning that you probably won't get paid at all. It's not that they intend to rip you off, but a company that can't afford to pay cash on the barrelhead probably lacks the financial power to get the job finished. Even if you get the project completed, they are still going to be struggling to come up with a marketing department, hire a support staff, and so on. Sure, giving someone a slice of the pie is a good incentive. But the only way to make that work well is to pay people and offer stock options in addition to their pay.

3: Product pre-sold to a client

One of the worst mistakes companies make is pre-selling a product to a client. All too often, the customer saw some fake screenshots of an application that didn't exist and wrote a check. Now, you are being asked to bail out your customer because they sold vaporware. You'll be under the gun the whole time on a project like this. The end customer has (rightfully) certain expectations on functionality and timelines. Meanwhile, no one has even determined whether the functionality can be done (a lot of it probably can't be done reasonably well) or whether the timeline can be met (it can't; I guarantee it). Stay away from this project! Do you really want to do business with the kind of client who sells something that does not exist yet? And do you really want to have the pressure of rescuing them on your back?

4: Spending money in the wrong places

Here's another bad scenario: The customer has a snazzy logo and a gorgeous Web site but no product yet, and they want to cut your rates to the bone. What does this tell you? That their spending priorities are in the wrong spot. A client who seems to have all of the marketing in the world but no ability to actually produce a product is a dangerous client. Why? Because if they have limited funds to begin with, they've been spent on the sizzle but they forgot to buy the steak. Another very real concern is that a client who is so marketing focused will have a tendency to sell the product before it's ready to be sold, which we know leads to disaster.

5: A long string of previous consultants

Has the client had two or more consultants already working on this project? If so, it's likely that there is something very wrong with it. Ask them why the previous consultants are gone. If there is a lot of hedging, that is a bad sign. Sometimes when you ask about previous consultants, the client badmouths them: "They were all a bunch of jerks who cared more about sending bills than doing work" or perhaps, "They sold us a bill of goods and didn't deliver." While this is often the case with consultants (we all know bad consultants are out there), it is also how a bad client often perceives a consultant that can't fulfill unrealistic demands or assumptions. Another problem is that you don't always want to come in behind other workers who may have left in a hurry over a billing dispute or other issue. Chances are, the documentation is nonexistent and the work is a disaster.

6: The wrong workers

One of the worst situations I have seen is a client who has been trying to get a group of college students (or worse, high school students) to do the job. Usually, after the project has dragged on forever and nothing real has been accomplished, the client starts looking for a true professional to fix the mess. Of course, they've lost a huge amount of time and spent a fair amount of money on the amateurs. This is usually only a problem with the smallest companies, luckily. These kinds of situations stink, because the client is already behind schedule and over budget, and if they really were able to pay a pro, they would have done so since Day 1. The sure sign of this scenario is a warped vision of pay scale reality. When they offer you a per-hour price worthy of "Would you like to gigantic size that?" you know you are being asked to replace a part-timer who is new to the industry.

7: "Good buddy syndrome"

"Good buddy syndrome" (GBS for short) is when a customer has a close friend or relative they trust and take advice from who you will never get to meet to refute. Usually, these good buddies have no clue what they're talking about. For example, the project's specifications make it clear that you really need to use a product that costs a bit of money, but then good buddy insists that freeware product XYZ can be made to work if you put enough effort into it. After you do the work the way good buddy says it should be done, your bill is bigger than the purchase price of the product you spec'ed would have been, and now the project is behind schedule, too. Sadly, GBS is usually hard to detect until you are actually working on the project, but sometimes there are signs you can see in advance. For example, you can ask the client if there is anyone who advises them from time to time or if they have someone they trust on technical matters who isn't at the table. If they say "yes," try to meet that good buddy and find out whether they can keep their distance or offer useful advice -- or whether they will be interfering in a negative manner from afar.

8: Lack of experience

All too often, a "client" is really just one or two people with little experience in running a project or a company that has an idea for a product. These clients are usually the most forgiving in terms of understanding that you are a freelancer who has other clients and maybe even a day job. But they also tend to lack the things you will need to do your job well and get paid. For example, they may not have a stable money supply or will be counting on an unrealistically high revenue stream in the beginning to fund continued development. If you are doing business with an inexperienced client, you will need to be extremely diligent when making up your mind to work with them. Due the same level of research that an investor would do, because by taking them on as a client, you are essentially investing in their project.

9: Hostile employees

Sometimes, a company will bring in a consultant whom their employees do not want to be there. Perhaps the employees are concerned that their jobs will be lost or maybe they wanted to work with the technologies you are being asked to implement. Maybe egos are bruised or perhaps the employees are simply against the project entirely, regardless of who is doing the work. No matter what the root cause is, taking on a contract where the full time employees do not want you there is always a challenge, and the pay usually does not justify the hassle. It is pretty easy to spot these situations; there will be one or two people constantly sniping or making sarcastic remarks, there will be an edge of constant tension on phone calls, and some people will be challenging your abilities in public. Unless this is a project that is critical for your long-term survival, you should avoid this scenario whenever possible.

10: The "skunk works" project

Once in a while, an outside consultant will be used by a department as a "solution" to an internal political problem. For example, the IT department might refuse to tackle a project, so the stakeholder decides to use operational budget to bring in a consultant to do it anyway. This kind of project combines some of the worst red flags listed above into the mother of all debacles. First of all, there are not just hostile employees (#9), there are usually entire "hostile departments." The project is officially off limits. Next, you have a budget problem (#2); the project has not been specifically budgeted and never will be, due to the official resistance to the project. On top of that, the stakeholder wants to get you in and out as quickly as possible, because they have no idea how long they can get away with having you working on the project. Of course, there is going to be a total lack of planning (#1) because this was never a fully thought out project to begin with. All said and done, this is a bad situation you want to steer clear of.


About

Justin James is the Lead Architect for Conigent.

82 comments
RSBPublishing
RSBPublishing

Awesome article! I've had all these clients and have learned the hard way! Wish I'd had this list ten years ago!! Great job!

christian.vigh
christian.vigh

Although I have significant experience in project management, my experience as a freelance consultant is really new. Your article has been of invaluable help for me ; I have taken a project that meets the don'ts explained in points 1, 2, 4, 5, 6, 7, 8 of your article. Reading this article helped me understand in a few minutes that I was spending energy on the wrong project. I took a decision accordingly. So again, thank you for having been so clear and pragmatic !

MichP
MichP

Last time I was job hunting, one ad made it clear they had a project that was in trouble, behind schedule, and they needed a programmer willing to work long hours to come in and fix it. I appreciate their honesty, but I was not that desperate.

spearson@8herons.com
spearson@8herons.com

You missed one warning sign -- when all the people involved in the project aren't listening to anyone else or each other. The biggest project I was ever involved in was a project budgeted for over $750,000 and involved a big customized relational database for insurance underwriting for an insurance company. The VP for the agents who would be the end users would ask if they could get certain requirements, and no one would respond. The people who would be customizing the design were asking the consultants if their software could do certain things, and the consultants would answer, "in the next release, due out sometime next year." The actuarial people who had to come up with the design requirements started looking at it and were telling people that the software couldn't meet their requirements of automating 80% of the underwriting which was the original reason for the investment, but at best could only automate about 10% of the underwriting. Everyone would bring this and more up in meetings and no one would listen. Everyone was talking to the air. I was supposed to be the DBA for the finished product and as such was involved from the start. My boss asked asked me how it was going, and I told him and I said, "I want out of this project." I was fortunate in that he agreed and pulled me out. Three people later lost their jobs because they were involved in the project, and they were the in-house developers who were supposed to make it work and the DBA who took over my spot.

Chuckchuckj
Chuckchuckj

sounds like looking for a good IT project is a lot like looking for a good woman/man :) No one is perfect.

tasllc
tasllc

Add - NO relations. The Only project I Had that failed was When I was given the team and the Main IT Programmer was the Son of the woman the Owner was dating. Deadly

dba88
dba88

A few more: 1. No change management initiative / program in place. 2. Refuse to train their people (on SAP for example). 3. Culture that may be steeped in meetings. In other words, meeting after meeting after meeting, etc. 4. Overly political. If you're not comfortable with internal politics, don't take the engagement. You'll be eaten alive.

zishanov
zishanov

Wonderful article. I felt like you wrote my experiences. I am also an independent IT/Telecom consultant and have faced almost all the above situations in the past.

oldbaritone
oldbaritone

If the PM is a glad-handing grinning "fair-haired boy" who can do no wrong in the eyes of management, RUN AWAY! Frequently, that type has little or no integrity, lots of narcissism and ambition, will grab all of the glory for successes, and spread the blame for failures without accepting responsibility. And since he's "always right", someone else must be the dolt, not him. Eventually, they will move on to "greener pastures," but in the meantime, they wreak a lot of havoc. And the project team members suffer.

mjstelly
mjstelly

You nailed it. I've been in most of these situations on "both sides of the fence." The only positive spin I can see is, "that which doesn't kill you makes you stronger." Here's hoping to your continued existence in these situations.

g-man_863
g-man_863

How many other employees and/or freelancers are or will be working on the same or related projects at the same time you're doing your thing? If other contractors have already been hired to perform tasks which could make or break your work, it's like Charlie Brown, Lucy and the football: If Lucy pulls the football when you're making the kick, you're the one who ends up falling on your ass. Case in point: I've had two situations in the past few years where the client subcontracted Ethernet wiring projects without my input. In order to set up and test the Point-Of-Sale hardware, software and wiring prior to the store opening, reasonable deadlines set weeks in advance had to be met. In both cases, the wiring contractors blew me off since I did not have direct authority over them and the owner (who did hire them) believed their lies stating their part of the project was on schedule. The same problem can happen with software vendors whose help desk techs are clueless on fixing bugs. Ask up front: Who else is working on issues related to this project? Do you have experience with them? If the owner states he's used the company for many years, it's a Good Buddy System red flag. If you have to work with other people who could make or break your work, get a written document from the owner showing the overall project's Chain Of Command and be sure he/she trusts you enough to respond to any issues caused by the other people he/she brings in.

etherfix
etherfix

Spot on Justin. This could well be the best article I have ever read on TechRepublic. I have been involved in IT projects of various shades and hues for 32 years and you have encapsulated all my worst experiences in a single article. I have saved it and will use it as a guide to accepting or rejecting all future projects passed my way. Thank you.

locum
locum

In a perfectly well organized well disciplined company I would agree. However I would think of this as items to look out for in gauging the potential of success vs. failure. Probably 99% of all my development projects have one or two of these items. You can't turn down 99% of your projects. But if 8 out of 10 of these items are present you may want to walk. Anyone can manage a "by the numbers" project where everyone is brilliant, you have all the funding you need, all the time you need, clear goals and full designated ownership with a proper timeline. But rarely if ever happens. And seriously,,, what's the fun in that?

Overcharge
Overcharge

I got suckered into a project when I was in the Air Force. The recruiting advertising directorate had a project that they wanted ASAP and the in-house support gave them an untenable time-line. I was brought in for a 6wk project (writing a shared database to interface between the prime contractor and the directorate) that I was supposed to coordinate with them. They (in-house support) wouldn't talk to me for the first two weeks. When they finally did, and laid out the specs, I was obviously behind the power curve. I was coming in at 6am and leaving at 11pm. I got it done, it was evaluated by the in-house folks who nit-picked the documentation and the source code. I barely got an atta-boy. A year later, I was up for a position and the selection was down to myself and another with very limited programming experience. Who contributed to the final selection? Those same in-house support folks. Needless to say I didn't get it. But, that was back in the good ol' days (prior to windows).... Things like that don't happen now.....

GrizzledGeezer
GrizzledGeezer

If the company has clearly stated goals, but they're not consistent with the way /you/ think the project should be handled -- get out.

dave.stafford
dave.stafford

There is an interesting dichotomy in this article: If the project is prefectly specced, funded, staffed and supported, than frankly you don't need a project manager. The worth of a good project manager is to make it a success even if you have 10 red flags. No point in whining that the customer is inexperienced, if they were experienced why would you be there? If you fail at the impossible project, so what? And if you succeed where all others have failed - you're a hero. The important thing is to set the criteria for success and failure up front, and shout them long and loud. Most PM's I've known are very poor at this, and just assume the criteria. Also make sure you have prepared an exit strategy for the 'doomed political project'. And ultimately there is money to be made irrespective of how 'good' the project is. Just don't ever go fixed price on the impossible project.

gbsuyat
gbsuyat

Very Poor unprepared and inexperienced author. How would you know those things you mentioned before you get in to the project? DUH.

rwparks.it
rwparks.it

My brother guarded himself and his business by using contracts to clearly define the terms. This helped to set a baseline and structure for the project. When the customer deviated (sometimes at presentation of the finished product), he could respond with the original agreement and note such changes would cost them. This has kept them on target; Results in successful outcomes, or protects both parties if things were to come apart.

ramonabeth
ramonabeth

This article can be used 2 ways. Obviously its a warning about what kind of work to take. It also would be a good thing to measure yourself against to make sure you aren't "That" company.

Chief Alchemist
Chief Alchemist

I'd like to add: 11) Roles & Responsibilities - If it's not clear who's who, what's what, etc. then that's a big red flag that leads to feet dragging, finger pointing, etc. 12) Universal Buy-in - Defining the goal is one thing, having the key players in agreement is another. If there are too many scopes and too many sub-agendas it's going to be a rough ride.

larry
larry

If you follow these steps, you'll never work on any projects. Reality is that you have to learn how to deal with them. Good list, though.

jim
jim

The author should learn the difference between the words Due and Do.

r_cubed_engineering
r_cubed_engineering

In my opinion, if we shied away from #1 (whether as an internal employee or as a consultant) we would miss most of the most interesting work. As a consultant you cannot know the internal politics in the shop until you have been there a few days, but if you can establish one key contact on the client side and keep them involved in the project's development, you stand some chance of getting out at the end with your sanity and bank balance intact!

trashmail
trashmail

Excellent post. There are at least 10 more red flag items, but this list covers a lot of territory I have trod in 35 years. It also seems applicable to employees and not just consultants.

drowlfs
drowlfs

I am a contractor, and the last few years I've been working on a few different death march projects (the current one, doesn't even know it yet). They meet most of the flags for 1, 4, 6, 9, and 10. But the alternative is not eating. We don't all get a choice of what we're going to do for work. On some of the projects I fought hard to turn things around, but failed miserably because the backing from management just wasn't there. This time around I go to work miserable, keep my head down, do my contracted job efficiently, and say nothing. I get paid. Food goes on the table. And that's that. Yeah my life is pretty crap and unfulfilling at the moment. I also lose a part of my soul... when someone comes to me with a big problem I really don't care - if it's my fault I fix it, if it's not I tell them that. I know not to get involved because it almost always means exposing that someone ELSE didn't do THEIR job. And that NEVER ends well.

ibnanouk
ibnanouk

I concur with several of the previous posters: these are precisely the reasons that "project troubleshooters" are brought on board to deal with when a project reaches this status level. I guess, I would say, in other words, these are the reasons I look to get involved with a project since that is the focus of my private practice. Take care, PNanouk

arthurborges
arthurborges

On No.1, clients don't properly explain the strategic purpose of a document OR they know what they want so specifically that if the English translation is a few words shorter than the French original, the client suspects you of a rip-off (FR/EN should be 10 to 15% shorter). On 2 & 10: same story. I'll add an 11th issue, however: too many middlemen. I once bailed quickly out of a project for a French multinational, which had a translation subsidiary consisting of a single secretary who re-farmed out the work to a mix of agencies, who went and recruited the foot soldiers of the keyboard. Result: working from quasi-illegible faxes + rockbottom fees + very very late payment. 4, 5, 6 & 8: You learn how to distinguish the experienced fly-by-nighters from the 19th century Romantics who believe bankers will believe in their dream. In either case, secure your fees by getting 50% upfront so that any injuries will be non-lethal to your own firm. On 10 too, information retention for security reasons or whatever are a sure-fire path to poor translations and poor translations tend to get rejected and go unpaid (see my first point above). On 7, the good buddy is hardly ever a fellow professional translator but who does have a vested interest in protecting her/his relationship to your client. Said buddy will happily nod in vigorous agreement when your client says you skipped a word that the English equivalent does not need and English grammar forbids. Upshot: the translation is rejected and, if the client is a human being, you get 50% of your fee although you retain all publication rights. Still, one unhappy customer shares her/his grief with 11 to 15 other potential clients. Thanks Justin: this has been a delicious read!

dmcgarigle
dmcgarigle

After programming every day in IBM Assembler Language for 36 years at 17 shops, I say that THIS ARTICLE ROCKS ! The author has written an excellent article As Ben Franklin put it, "Experience is a dear (expensive) teacher, but fools will learn at no other".

jos
jos

I'm working on a project right now that i KNOW i should never have taken on. The most telling sign before the start was this: Back in 2008 we were requested to make an offer for a project. There were still funding problems, but they were being sorted out. Anyway, we were asked to write a project proposal for the finished product, based on a pretty elaborate but utterly chaotic spec document. The project was then iced, because said funding problems were not resolved. One year later, in 2009, we were suddenly given the green light, but were asked to revieuw our proposal based on some new specification issues. So far so good. Changing specs are always better before you write anything but a global proposal. The real tell tale was, that the new spec document was also utterly chaotic, but had absolutely nothing in common with the original one, but was written by the same person! We did ask to meet this person, because as it turned out he would be our contact during the project and he was just as chaotic as his document. Sadly, we did sign on to the project, it was just too interesting to pass by. After almost a year we managed to get the chaotic project manager sacked from the project. This is where we stand now. Hoping we'll see the end of it with a new project manager.

dave.stafford
dave.stafford

Hmm, have you ever worked in the corporate market? If you stayed away from projects with any of those problems you'd never work. And your #1 issue: no spec, can be a big plus for the smart PM. What your (naive - sorry) article should be called is: "When to go fixed price and when to go T&M." Or maybe: "Why you shouldn't hire prima donna PMs who can't cut it when it gets difficult" Or perhaps: "Why I only do Blue Sky projects, and can you spare some change please as I haven't eaten in weeks"

Tony Hopkinson
Tony Hopkinson

every developer who proves not to be a telepath with a strong pre-cognitive ability to improve IT alignment. Works every time.... It was im !!!!

itssri
itssri

The points in the article are more suitable for the freelance coders or specialists, not for consultants or project managers. Isn't the consultant or PM actually supposed to get around (or manage) these and many more foreseen and unforeseen red flags? The author has ironically, replied to one of the comments that he would still have been there in the safe-playing company if there was potential for his growth! The points are good, but they should not be criteria for walking away, rather these should be used to draft a clearer contract.

gueibor
gueibor

With his Ineffable Pearls of Wisdom.

Justin James
Justin James

#1: Should be clear in initial discussions #2: Should be clear before the contract is signed, they won't say it, but you'll see the signs (like constant haggling on your rates, questions about how long they have to pay bills, etc.) #3: If this is a product they will be selling, all you have to do is ask if they already have clients on board #4: Look at their Web site, look at their office... does it look like they are spending big bucks on things that don't deliver products? #5: All you have to do is ask about the project history before you start, you'll find out #6: Again, ask who has been working on the project before you #7: This one is one of the hardest to find out before signing a contract, but you can ask if there is someone who they trust to get advice from #8: Research the client before you sign a contract, that will tell you what you need to know; are they a start up? Ask about their funding. Who is advising them if they are a start up? Etc. Much of this will be obvious just by the way they handle themselves when discussing the project. #9: This is not always obvious up front, but if those hostile employees are involved in the pre-signing discussions, they will often be hostile even then. They'll grill you on trivial stuff, for example, hoping to discredit you. #10: Ask who the project stakeholders are, what their positions are, etc. You'll need to know this anyways, so find out up front. I'll say this: nearly every project I was on that went bad, I knew it had problems before the paperwork was signed, but I either had no control over it (working for a firm, not myself), needed the money more than I needed peace of mind, or I applied wishful thinking. Likewise for taking a job with a bad employer. I got burned a number of times, but only once did I not see the problems coming. J.Ja

Miami Steve
Miami Steve

Anyone who has been in this business more than 10 years who has worked on multiple projects with multiple clients can smell these land mines. It's really simple to determine a project situation in a single meeting, just ask the right questions. I think the author is spot on, great post.

BitHammer
BitHammer

True, some of these issues are difficult to see coming, but not all. The budgetary issues will be evident up front, if you're paying attention. Likewise some employee hostility (If they don't want you there, they may try to be intimidating in the initial interview). But you are right in saying that you don't really know how deep the swamp is until you step into it. I think that the article has gotten several smart people to discuss how they've handled similar situations, what has worked and what hasn't, and to me that's valuable.

arthurborges
arthurborges

Pro: If forces each party to define exactly what they expect and undertake to supply: that minimizes sincere misunderstandings where everybody gets self-righteous and alleges trickery on the part of the other party. Con: If there is bad faith on the other side, the most tightly-worded a$$-whipping contract is perfectly worthless. BOTTOMLINE: Do it because lawyers help you concentrate and really work out and pin down what each side is committing to a deal and expecting in exchange.

kdawg3484
kdawg3484

I'm the project manager for a small engineering and OEM company (IT is my secondary, self-appointed job), but I found a lot of this article to be similar to what I deal with as well. It definitely has more general applicability than just to the IT consulting sector. I very much agree with trying to establish a contract up front if you can for a job that may take a while. Whether you're designing and building a chemical plant for someone or designing and implementing a network, you're acting as two separate entities doing business with each other, and you need to have a contract to delineate how your pieces fit with each other. This serves to hopefully keep a leash on Red Flag Number 1, which can be a killer. This is particularly important for anyone quoting a fixed price for their work as opposed to open-ended T&M. We've gotten burned multiple times by customers who decided they wanted us to add equipment halfway through that they'd just "presumed" was part of the initial contract. Or maybe they want us to run piping in a way that's three times more expensive just because it looks better to them. A lot of time they've gotten away with it because some part of the specification might have been a little too vague and or there wasn't a section in the initial contract covering the pricing for unforeseen add-ons. Now, that's our fault for not writing a more airtight contract, but when you sometimes have a quick window to get work you need to stay afloat, you can forget about these things. My advice is to be prepared for this. Perhaps have a template contract written up that you can modify with your customer for the specific job. It doesn't need to be an awkward process between you and your customer; it's business. If your customer's unwilling to put their name to a legal document that you two work out, then that may tell you right there what they think are their chances of holding up their end of the bargain. With a signed contract, when things go wrong later on in the project, you've at least got yourself a lifeline to hold on to. It doesn't mean you have to stubbornly bludgeon them over the head with every little detail of it. It can just be used as polite leverage maybe even without having to invoke it specifically. I help write and review every contract we do now, and I keep these things in mind while doing it. Finally, on the flipside, I think this article has quite a bit of wisdom for business owners and project managers. If you're contracting a consultant or hiring a specialist, it would be good to look at your company and see if any of these pitfalls are there. If you really need the person's help and, you may want to be prepared to deal with some of these things if you can in order to make sure he or she stays. I'll be keeping these in mind as we get new jobs at my place.

v r
v r

I agree that these red flags apply to employees. In my 30 years I have seen all. When the client is the department manager who is a completely incompetent, overly-promoted programmer whose previous experience is from very small companies, the result is the same red flags. He couldn't even spell "project management", believing that anyone (really anyone) could do it well. Because at my last company my team was very bright, talented, hard working, focused on doing their best work, yet disasterously and unfairly maligned by the incompetent boss, I stayed (rather than leave after a few days when the situation became obvious) to protect the team and to prove to the internal customers that IT was not the enemy. Upshot: The internal customers very quickly began to work closely with IT (at least my department) and the right work was accomplished within the time alloted. Great article. Thanks.

Justin James
Justin James

That's odd, because most of the consultants I know are practically drowning in work. Companies that laid off full time employees still need projects done, so they call in a consultant to do the critical projects that they are too short handed to do. It depends on skillset, though. Right now, there are certain generic skillsets (say, "Java developer" or "Windows system administrator") where there are too many good people who lost their jobs floating around, it is very hard to find consulting work in that environment. But for specialized stuff (say, setting up Exchange or programming against a particular CRM project), it's a gold mine. Companies need the work done but laid off everyone who had the time to learn a new tech just for one project. This is why I am not doing consulting at the moment (as a full time, "put dinner on the table" job, that is), I don't have a particular specialty that would allow me to survive this economy. But the folks I know with those specialties are doing quite well and have the luxury of turning down projects. J.Ja

Justin James
Justin James

Yup, I *have* worked in the corporate market... that's where I learned these lessons! Yes, most projects are going to have one or two of these... but if you see more than one or two, you are going to have a PITA project. My experience has been that most really good consultants have some choice in the projects they take, so why choose the bad ones? And for that matter, I worked for a consulting firm at one point that was so good at picking their customers, our projects somehow didn't have these problems at all, and I tell you, it was a wonderful thing. If that company had a little more growth opportunity for me, I probably would still be with them. J.Ja

pivert
pivert

yep, I fully agree :-) I can put a name or department or project on every number in the list. But all of them got a solution. Perhaps not exactly what they envisioned, perhaps not on time, but after a week or so, they are happy and we can start talking about a serious "next step".

tbmay
tbmay

....and excellent advice.

blhelm
blhelm

There is just no substitute for experience. We all learned these lessons the hard way and have experienced the stress, loss of revenue and sometimes loss of integrity (and soul). The reasons we took on the heady challenges were numerous and sometimes putting food on the table tops that list. However, the experienced professional should be positioning himself/herself such that they can be comfortable turning down a project that is just trouble from the start.

dave.stafford
dave.stafford

It's actually not possible to smell landmines (evendogs can't do that), and it's definitely not 'really simple' to determine the project situation in a single meeting. It's naive to think that if you ask the right questions you will get an honest answer, or indeed any answer at all. There is nothing wrong with the list, but they are not red flags, just some of the usual things to be aware of when taking on a project. I've never done a project where most or all of the list didn't exist. Think of them as indicators on where to focus.

markh@yorkwater.com
markh@yorkwater.com

I do some work for this company from time to time. Most of the time it's really good work. I received a call from one of their IT people the other day. The specs were vague. I asked a few questions. I got the impression that the person who really wanted the work done would probably never be available to talk to me. I expressed concern and was encouraged to move ahead and "just give them something." I did as little as possible (about 2 hours) and sent it off for some initial feedback. About a week or more later, I received an email that said they were just going to do something else. I don't even think they looked at what I had sent. Good news is that I didn't waste too much time, and it looks like I'm still going to get paid for the 2 hours. If you do this stuff for a while, you often can feel it coming. While you can't always avoid the jobs, you can and should have your radar up and protect yourself. Good list. Take care. Mark

Frgood
Frgood

As a consultant with the reputation for resolving the PITA projects, I could command a significatnly higher rate. These are the projects that warrant a consultant (person with specific expertise in resolving a specific issue). Now, in contrast, a contractor may want to follow this criteria as that would seem to make sense. In the past 20 years, I've learned to raise an eyebrow only when there is a constant questioning of "Is this billable time?". If there is a strong concern of lack of understanding of what is accruing during the first few hours of a job, then I know that the invoice is going to be questioned ad nauseum. I will bolt as fast as I can.

blhelm
blhelm

I've been in the IT Industry for more than 28 years - long before many of these "consultants" were playing with their Nintendo?s and thought it would be cool to play with the big boys in the corporate world. I've encountered every one of these red flags at the more than 250 companies I've been involved with over the years. Many of these companies make the Fortune 100, 50 and 25 lists and many of them were entrepreneurs that were family owned and operated. If someone believes that they can be the "savior" or the "Knight in Shining Armor" to ride in and save the day, I say go for it. It takes a callous, bull headed, "Do it my way" attitude (mostly communicated to no one though) in order to survive the stress and the idiocy of the environment. You did preface your piece with the fact that it is a choice for the consultant whether to take on a project that shows a red flag. Frankly, if the PM believes that they can overcome the obstacles, great. However, honesty with the customer is paramount. And someone else mentioned that the contract then should be billed on a T&M basis - PERIOD.

spearson@8herons.com
spearson@8herons.com

I was a little slow on the uptake there. Didn't need psychic powers to know something was wrong with that project. Psychic powers would have been nice to prepare for what eventually happened to the company (it went down the tubes in a rather spectacular but undignified slow-motion hara-kiri).

Tony Hopkinson
Tony Hopkinson

irony by most people, and sound business thinking by corporates....

Frgood
Frgood

An excellent and reasonable solution.