One thing I really love in a project manager is bringing me in early, preferably before they even talk to a client, and then keeping me in the loop along the way. While I’m not a fan of time-interrupting meetings, I’d rather tell you about what sorts of things we do well, where we’re weak, and hear what sorts of problems the client is facing and your ideas to solve them than receive a set of requirements that have had no such input.

One of the keys to consulting, and problem solving in general, is that there is no one solution to any problem. There are usually several valid solutions, all with tradeoffs. While one solution may seem best from a client’s perspective, remember that your project team has to be able to deliver something on a schedule the client won’t hate you for later and on a budget your supervisor won’t fire you for at the end. So keep in mind that a solution that’s merely good enough for the client may be actually the better answer, as you can deliver it within their budget and according to their schedule.

Gung-ho, motivational execs and PMs who bang on about “instratovation” or “going the extra mile to deliver top-flight solutions to the client” tend to have several issues. For example, after hearing the talk of “insanely great” solutions, the client will imagine something far beyond their budget. They’ll believe, no matter how much you try to disabuse them of the notion, that you will deliver something that simply can’t exist in the real world (mind-reading is usually an unacknowledged part of the feature set). Unless you’re Steve Jobs with a Reality Distortion Field of your own, you can’t make them believe that your Widget 2.1 is really the answer to their prayers. So talk to your developers to get an idea of what you can deliver BEFORE you pitch those ideas to the client.

Another issue that can arise is the importance of details. While speccing out a new system, run the details by your project team before showing them to the client. It may be that the exact same functionality done with one widget or with a series of screens will be far easier to produce on time and on budget than the widget or single-page form you’ve imagined. You wouldn’t show a feature to the client without running it by your usability guru, and if you do it without running it by your developers, you’re begging for a budget-buster.

So remember, the key to keeping your client expectations grounded and your budget in the black is involving your project team from the beginning, and keeping their input flowing througout the design process. It seems like PM 101, but it’s the rare project manager who really understands it, believes it, and, most importantly, practices it.

Now that wasn’t so hard, was it? I’ll come back to the scheduling of such meetings and how to specify such functionality in later rants, I mean, uh, essays.