He hates Doctors, always has. He's had some terrible experiences, one in particular has prevented him from going back. He had a terrible back spasm and went to a Chiropractor. Because he's so big, she felt she had to place him in some strange position and attempted to pull his head off. Atleast that's the way it felt to him. HIs back was worse and his neck started to hurt. He never returned.

My Doctor put him totally at ease with humor and his wonderful way of talking with his patients. I mean he actually talks with his patients. He sat with my husband and went over each of his ailments, one by one and addressed them all. His fears were put to the side and his health will finally be addressed by a caring individual.

What things do we all put off because of our fear? Going to the dentist, the doctor, the accountant. Wouldn't it be great if each of those listed above strove to make it easier for us?

Creating passionate users reminds us that Fear is the killer app.

The high-pitched screech of the drill. The sickly smell of antiseptic and fear. The long nervous wait for the attendant to call your name and take you… back there. We assume that people are afraid of the dentist, but we don't usually think of software as scary. Maybe we should rethink that. Our users might be more afraid of us and our products than we think. And those who can reduce or eliminate that fear have a huge advantage. Not to mention a passionately loyal following.

One of my favorites was the build from hell. The developers would toss the source code in zip files over to the software integration team. The integrators would then put it all into a central directory, piece by piece. If the developer got it to build, he went home. Then they would build each part and place it in another directory. Then they took all the components and built the entire product. Again, the test was is if built, they were done. Next they hurled that over to the testing team. The following day, the testers would report the bugs back to the developers and the cycle would begin again.

That is if every step along the way worked, and it rarely did. Each piece would have to be rejected and returned back to the developers. Everyone hated one another, everyone hated their tasks.

Introducing an automatic build process was a lengthy task, and very rewarding. We tackled it like eating an elephant, one piece at a time. As we built a component's build process, we handed it over to its developer to maintain. As we created the testing process for their component, with their involvement, each person was in charge of their component's outcome. Developers didn't go home until their product built and tested. Integration didn't receive zip files, they received a completed, tested component with no errors. If it didn't pass, they didn't get a new one. No more throwing things back over the wall. Testing got a completed, tested product. They tested with a working product, one that did what we thought it should be doing, not what we hoped.

Is there anyone out there still running a build assembly without an automated process to complete it from start to finish? Do you still have sanity, and hair?

So, what makes a good PM? Jeanette Cabanis-Brewin writes about Integrity: A Project Manager's Level. Ganthead writes about The Five Ws of Project Management. The Standish Group has launched a search for The World's Best Project Manager.

No, I didn't misspell the title. I am trying to convey the horrendous nature of watching a project hurl itself into failure. I've been hired by management several times to reverse a failing project. My optimism about being able to rescue a project from hell quickly fades on that first day.

No users involved in the project – We don't need no stinkin users.
Scope of project is off – We aren't quite sure what we're making.
Poor Change Management – Oh they just tell us what's wrong and we fix it.
Technology Choices – Our team lead likes that tool, so that's what we use.
Changing Business Needs – They don't really need it anymore, but we've already started.
Unrealistic Deadlines – The first release is due in two weeks, we started yesterday.
User Resistance – We don't want it, we don't need it and you can't make us use it.
No Sponsorship – The spearhead for this left about a month ago…
Team Member Skill Level – We're just finished training on X this morning.
No Best Practices – The Y team is different, we don't use their methods.

J.S. Reel writes about Ten Signs of IS Project Failure via K.D. Maxwell and R.J. Custer. Robert Gordon writes about Projects that Succeed: 7 habits of IT Executives that know how to succeed. Gopal K. Kapur is quoted on his Management's Seven Deadly Sins via CIO magazine. CardboardNU has checklists that help a project stay on track.

Computer gaming companies seem to conduct postmortem efforts more than other types of projects.

Eiji Aonuma, Director of the Legend of Zelda: The Wind Waker, says I'm always questioning myself after a project is over. GameDev.net has an article on how to conduct a postmortem by Steve Pavalino. Michael Greer has a list of review questions for a postmortem. Ed Yourdon recommends mini-postmortems.

John Lockwood offers a comparison to how we might hire carpenters if we hired them like we do programmers here.

Its a great anti-analogy and exposes how terribly the process of hiring a programmer actually is for the programmer. Most hiring managers want specific and exact experience. Developers with more than one language skill may feel that learning another language is simple and they could pick it up easily, they don't understand why they have to have the specific skill the hiring manager needs and wants.

Although its painful to be analyzed as much as programmers get analyzed in a job interview, we have to be aware that in many cases its because of others who have gone before us. Some programmers attempt to pass themselves of as more skilled and educated than they actually are. When they jump into the actual fire pit of the project and can't do what they were hired for, the hiring manager gets a bad taste in their mouth, their hiring practice becomes that much tougher.

I consider myself a professional developer and feel capable that I could pull off learning just about any language or API. But does a hiring manager really want to pay me to learn or does he want me in front place straight out of the gate. I've also been a hiring manager, project and team lead responsible for doing the interviewing. Its not simple or fun to be on either end of the process.

So how do you make it easier? Identify the absolutes that you must have. Don't be so specific that you eliminate the stars that truly could offer your project something even if they don't have the specific skills you need. Look for people with skills that aren't as easily taught. Look for the developer with communication skills, the team lead with development skills, the QA with software distribution knowledge. You don't need a perfectly formed diamond, you need a diamond in the rough.

Business blogging is establishing a project website for companies that either couldn't afford the expense or the headache of installing more complex or expensive solutions. Blogging isn't a silver bullet, but its a quick, inexpensive way of communicating among project members.

Publishing a project weblog via Inctura Daily. Phil Wolff refers to the process as Klogging. Articles by Phil Windley and Jonathan Peterson offer different perspectives on how projects can be managed with blogs. Another view is offered on Weblogs for PM.

A customer has the responsibility of creating a valid list of expectations and communicating them to the vendor. A customer has the responsibility of managing expectations as they change and they do change.

A vendor has the responsibility of communicating to the customer which expectations are valid and which are unreachable. A vendor must keep the lines of communication open before a problem develops.

What is the key to project success or the guarantee of failure? A lack of communication or a break down in communication. Communication is a two way process, it takes two to tango. Set the rules for communicating up front. Keep the lines of communication open and flowing. Don't wait until its too late.

Is your project limping along at half speed? At your last meeting with your boss were you making excuses or accolades for your team? Do you spend too much time yelling and not enough time getting the work done? Do your team members hate one another, have trouble getting to work, spend little time with their families and yell right back at you? These are visible signs of a problem but projects in a bad state may not exhibit such obvious signs.

A failing project can hide itself. No one wants the boss to know that its failing, so a long chain of secrecy is established to hide the truth. Measurement slides off the radar. Keeping track of resources becomes more of an issue, people don't want to know how many hours their working, its too depressing. There aren't a lot of smiling faces at meetings and some people may just clam up all together. If your project doesn't feel pulled together, it probably isn't. If it continues to slide, it will fail.

Unless all hope, time, resources and funding is gone, its never too late to rescue a failing project. Don't give up, don't let it hide itself.

Identify, reduce and simplify. Identify what's fallen to the side. No meetings or too many? No measurements or too many? Low morale or too much work? Remove anything that isn't working. Simplify anything still standing. Put all your checks and balances back in place. Once its back from the brink, give a heads up to management and let them know how you plan to keep it going.