8 Things They Don't Teach You in Project Management School

When my grandmother was living, I spent hours in her kitchen trying to see how she made her trademark apple pie. I watched every step, took copious notes and tried to replicate what she did.

Recipes for my grandmother were an oral tradition. She never wrote them down, and those of us who wanted to learn were left to trying to find out what she did. Of course, we never quite could!

Project management is no different.

In my many years of managing projects, I have read books and articles and have reviewed project management courses. None really explained the intangibles that make good project managers great, so here are eight of those intangible ingredients I discovered:

How to dance with the stars when they don't want to dance. When many projects are underway at once, IT project managers compete for the services of the same people. Because these folks are technical gurus in short supply, they can develop big heads about it and become difficult to deal with in their own right.

I once needed the help of a transactional software guru on my project. This techie “star” was in demand on many projects, but since I was a rookie newbie PM, she put my project at the bottom of her list and wouldn't even return emails.

After several weeks went by, I realized my project deadlines were slipping. I made the decision to use a more junior but a very enthusiastic person. The project took longer, but we met deadline. The moral of the story? That cooperation and enthusiasm beat technical expertise if you have tech stars who hold your project back.

How to pull a project plug. Early in my career, I worked for an IT project manager who was afraid to tell the IT director that our project was behind schedule and failing. The project did fail and nearly everyone, including the IT director, lost their job. Great project managers never get themselves into situations like this. If they see a project start to fail, they immediately inform upper management. They keep management in the communications loop, and they have a “Plan B” ready to roll out if and when the project fails. The plug is pulled swiftly, and staff moves on to other work. A manager at Teradata told me this: “We launch many experimental projects that try out data algorithms, and we know that some will be breakthrough but that others will fail. As soon as we sniff failure, we pull the plug.”

How spouses and significant others can complicate projects. Many corporate HR departments insist that spouses and significant others work in different departments, and it’s not a bad policy in IT projects, either.

I once was assigned to a software project being led by a strong project manager with outstanding technical and communication skills. Then, the company decided to hire his wife, who also had great skills and capabilities. As luck and logistics would have it, the PM’s wife began working on our project. Before long, the two of them were actually competing with each other to establish who was most valuable on the project. Staff morale get impacted and the project nearly fell apart. The issue was resolved when the spouse was reassigned to another area. The lesson? Avoid using spouses and significant others on the same project, as these relationships and their dynamics can sometimes impede project work.

How to know a project is really going well. You're getting status reports from your staff that tell you everything in the project is on schedule, yet somehow there is this instinctive “sixth sense” that tells you something is wrong. Great project managers listen to that sixth sense. As soon as they sense something is wrong, they get out from behind their desks and into the trenches, whether it is spot-checking QA, looking at UI designs, or talking to DBAs and vendors. They never rest until their sixth sense warning signals deactivate.

How to know when your user support starts slipping. Great project managers make sure that their projects maintain enthusiastic levels of user support and participation. If they see that support start to wane, they act.

Here’s how user support can slip: The project starts out with an enthusiastic kickoff meeting with full attendance from IT and end users. User attendees include the C-level officials from user areas. Then, over time, the project meetings begin to wear on folks, so the higher level managers from the user areas begin sending their subordinates instead of themselves. In time, even the subordinates stop attending regularly.

Great project managers don't miss these signals. They take action by getting in touch with the initial C-level project sponsors and by asking them if they still want the project or if priorities have changed. These communications are critical, because if the users aren’t participating and contributing to the project, the project is likely to fail, no matter how good the end product is.

How to develop project staff bench strength. One mistake that good to average project managers make is that they try to bring all of the top tech stars into every project. When they do this, they fail to develop new talent that can build their IT resource bench.

Let’s say that you have one DBA who does all of the database design and schema definitions for your projects. This means that the DBA will get tied up with a major project, and that meanwhile, other projects needing DBA services will sit. Wouldn’t it make sense to train a more junior person working alongside the DBA to take on simpler tasks like schema definition so this junior person could assume some of these duties in the future and leverage your project DBA resource pool? Great project managers are visionaries who see this. When they staff projects, they build in time for cross-training that creates IT bench strength and options.

How to prevent burnout when your staff insists you shouldn’t.

Burnout is major factor in IT, and long hours and tight project deadlines don't make it easier. Great project managers understand this. They circulate and take action when they notice staff members beginning to get irritable, or when they start seeing work from these folks that is sub-par. They usually address the issue by sending these employees home for a comp day.

But there’s another side to burnout that many project managers exploit when they should instead be taking action to protect a staff member from himself/herself.
This is the burnout experienced by chronic over-performers who refuse to take time away, even when it threatens their health and wellbeing.

Early in my career, I was on a project with a next-day deadline. A team member had to leave mid-afternoon because she was experiencing labor pains. She had her baby that evening and was back at her desk coding the next morning. A great project manager would have sent her home, and gone to their “bench” to cover for her. Why? Because great project managers understand that you are as obligated to your staff’s welfare and wellbeing and you are to the project.

How to ensure your project will really be adopted. There are thousands of IT projects that met deadline and conformed to specifications but ended up failing because users wouldn't use the software. Why? Because ease of use was poor.

A project manager at a large agribusiness company told me this story:

He had been asked to take over a failed dairy ration system the company had developed because none of the users would use it. The dairy feed formulation ratios were excellent. Unfortunately, users instead opted to buy a cheap off-the-shelf package that gave the company inferior results, “I quickly realized that the user interface to the software had been so poorly designed that the users just gave up on the system!” said the manager. “We fixed the problem by trimming away two-thirds of all of those drill- down screens. Within six months, everyone was using the new software.”

This was an example of great project management. The best project managers know that human factors like ease of use go just as far as excellent software in making a project successful, and they never forget that.