As a consultant you are sometimes thrown into difficult situations. How do you deal with clients who have no processes, have no methodology and ask for things to be done for yesterday even though they do not fully know what they want?
How can such a situation be identified before you get committed to a project?
I fire them. You don't have to take every gig. If they are idiots, then leave them to themselves.
You tell them that you are not willing to work for them anymore unless they change their expectations. If they want quality work, they have to give you quality feedback.
Don't take the gig.
And I think mentioning names is a good way to let people know your exact experiences - just like voting here.
Life's too short to work on bad projects.
If you are an ethical consultant, you walk away.
If you are an unethical consultant, you just keep billing them by the hour until they figure out you aren't going to deliver what they want.
(BTW, I am an ethical consultant, which is why I will never be a wealthy consultant.)
Kris, I see an opportunity to develop a project management aspect to your consultancy.
You explain to them the age-old formula of software design:
You get TWO of these:
Then you charge them by the hour.
The closest I can think of is a person who wanted an Amazon.com like sales site for only their own catalog, with multiple payment options, shipping providers, barcoded labels, recommendations, promotional items, product variations, gift packaging, user accounts, reviews and feedback, forum based general discussions, newsletters/blog, email announcements, etc etc, with a management console for all features; without having any existing site or servers (currently the catalog was a bunch of Illustrator files), and all for a max of $1000 in about 1-2 months.
You manage expectations. That should allow you to either do what you can or move on right away.
I think they got an offer from an Indian company to customize something for them, and after spending the money, they were disappointed to find it fell short since there were no formal requirements. Eventually they went with a Yahoo store.
Document, Document, Document, and Document some more. The better the paper trail the better off you will be when they start to contradict themselves.
In fact I had a customer that would continually give me conflicting requirements. Once I started producing the documentation then I was able to nail him down to what he "said" he wanted.
With those kinds of clients make sure you CYA. That way when things go bad you have a paper trail to show your side if it actually reaches the courts.
Something similar happened to me recently. I was asked by the owner of a company to bring order to the development arm of his company. This a manufacturing company that takes orders online. Everything else in the company was well tuned except for the software aspect which was having all sort of issues.
After trying to talk to everyone and trying to get everyone lined-up to be more productive for a few weeks, I was getting nowhere. And then it dawned on me. What the owner of the company wanted was for me to go all Gordon Ramsay on his team.
So we went to the operations guy and asked him to revoke the developers access to production. Also move the source into a repository under our control where they had no write access. We instituted a policy where the only code that could get committed had to go in via a patch; open-source style. This slowed down everyone significantly but there was no more rogue code making it to production.
As far as crazy demands to get things done yesterday, we solved that by starting to say no. More precisely, we started scheduling these requests for specific release dates instead of saying yes and doing them whenever we could. So far, no one has complained. I think that the only reason why everything was asked to be done yesterday is historical. No one ever really said no before.
Start with the basics. Nudge them to put their code under a version control system, and to store issues, bugs, and requirements in an issue management system. This will put some order in two large areas of software development where lack of processes, tools, and methodologies leads to chaos. The immediate payoff of using these systems will give you credibility to push for additional changes. Then setup some lightweight processes for creating a software release, doing basic some regression testing, and reporting a bug. Continue by addressing the areas of the greatest pain. Applying a methodology for the methodology's sake is counterproductive.
It also seems that these clients are better suited to an agile programming methodology than more rigid processes. Have a client representative near you to provide feedback as you develop those incompletely-specified features. For every requirement of your client estimate the time you will need to implement it, and have the client rank the requirements they want implemented each week. This will take care of the "I want it yesterday" symptom.
Knowing how to manage and educate a client is as important as successfully managing a project. It is a skill that can lead to a long term mutually profitable relationship.
Hey, stop stealing my clients! :-P Seriously, dont do work for clients like that.
I am dead serious about this: abandon your natural tendency to avoid geek-speak when you talk to them.
Show them your IDE. Talk about fundamental principles of OOP, obscure Design Patterns, VARCHAR vs. NCHAR etc. Fully open your development process to them, and let them see the inner workings of software development.
Once they're overwhelmed and they start to glaze over, switch to talking about something they understand: their business. They usually do a good, eager job of explaining it at this point, and they will meekly accept whatever you tell them about processes and methodologies and time travel in the hope that you won't hit them with the geek-speak again.
It's a cruel thing to do, but it's for their own good.
Structure exists to protect both yours and the client's goals.
As a consultant, it's your responsibility -- part of the expertise you're bringing to the table -- to recognize where there are no processes or structure, and to impose it onto the process. You have to do it at the beginning of the project, but you also have to maintain it throughout. The key is to agree on expectations, get them in writing (a statement of work), and use them as your playbook. There will always be changes. Plan for them. There will always be disagreements. Keep the focus on the work and the playbook.
If you're not in a position where you can afford to fire your clients, and you don't have enough experience or expertise to have the confidence to guide the process, then... well, consider working for someone who's better at the consulting game for a bit. When you know your craft and your process backward and forward, and when you have enough experience under your belt, you'll know how to deal with these kinds of things.
Fire them. Don't waste your time on clients who don't know how to use it properly.
If they know they have a problem and are serious about fixing it, your first job becomes getting them sorted out.
Otherwise they absolutely have to go - they will suck the life out of your business.
Propose that you help them with process and methodology instead... for a small increase in your fee.
I think it depends on the size and maturity of the client. A small company may not have a process because they think they're still able to communicate with everyone directly. In this case, you may be able to identify one or two key people and convince them that some kind of process is needed to ensure reliable, consistent results.
If we're talking about a large company that has chosen to ignore the need for process and is still alive in spite of itself, the job is a lot harder. It can stil be done, but the pain caused by constantly banging your head against that wall might not be worth whatever they're paying you... :-)
Walk away. Fast. Better yet, just run.
Whenever I hear the word "yesterday" from a client/recruiter it's a dealbreaker for me. This means the client doesn't know what they're doing and got themselves into a jam by not planning well enough (if at all) and getting behind schedule. Then, when you don't learn pick up on things fast enough for them or it still doesn't get done on time, guess who's fault it is?
When you write up your contract, make sure you have things in writing. Let's say you are running a live website. Put it in writing that they must give you X days to post new content on said website. Put it in writing what the process is for making changes to the requirements, and what the consequences will be.
Sadly, some of the answere here are unrealistic.
As a consultant (I've been one for almost 20 years), you have limited ability to change the course of the IT culture in your clients. You can "suggest" process, you can try to iron out issues that exist with build promotion and version control, but in the end the client will do what they do because they sign the checks. If you are a proffesional, you try to do the best job for your client that you can, but you also recognize that you are in business to turn a profit and sometimes taking jobs like the one described above is necessary to pay the bills. They can be great learning experiences for what "not" to do with other clients.
Someone here suggested that it is unethical to take the position and charge the client, that is utter nonsense. There is nothing unethical about it if you are truly trying to help. There's a reason most consultants are paid by the hour (the smart ones), because our profession is much like being a lawyer. You get paid wether you win the case or not. You do everything you can to win within the constrainsts of the case, but in the end you are being paid for your time and expertise, not for a guarantee of success.
It has also been suggested (by the same person) that if you are an ethical consultant that you will never be wealthy, this is also rediculous. I don't know if I can be considered wealthy, but I (and many friends of mine) have made a very good living (upper 6 figures) as a consultant for more than a decade. We are all ethical and honest with our clients. In my experience the consultants who are not doing well financially either aren't very good or live in a market where there is little money. I'm fortunate enough to live in NYC where the consulting market bleeds gold (in a good way). Do not mistake poverty for nobility, the 2 are quite unrelated.
Eric