This is Where Project Managers Fall Short in Managing Project Work

Finally, finally, finally I am at the stage in the Knowledge Areas where I can discuss project execution.

To this point, I have written 78 articles that parallel the Knowledge Areas within the PMBOK® Guide (Project Management Institute (PMI), 2017, p.25) that are specific to the Initiating and Planning Process Groups.

I set out on this 52-week journey of presenting three project management success tips on a single Knowledge Area topic each week. These tips and instruction are all based on my personal experience and observations over 43 years in IT project delivery. I saw early in my career that project delivery and the methodologies we have built around it is focused almost entirely on the process aspects of project management.

But can I let you in on a little secret? Throughout my career, I have seldom seen a project fail to meet its objectives (or fail outright for that matter) because of poor process – nor because of technology issues.

That leaves only one major source for project failure. The people aspects of project delivery. The people aspects of project management. In my initial article in this series, “This is Why So Many IT Projects Fail: A “People First” Companion to the PMBOK®”, I provide a more in-depth discussion of this.

As I considered what to write in this article about the people aspects of directing and managing project work (the next PMBOK® Knowledge Area to be addressed), a myriad of topics immediately came to mind. I could write an entire book just on the project delivery “war stories” I observed over that time. At the same time, I thought how ho-hum-obvious these observations would be to any Project Manager with even minimal delivery experience.

So, I did a little research as to what other experts may be saying about this topic, hoping to fuel some other ideas about what to write in this article. To my surprise (well, not really), many of the articles I read were on topics such as:

following the guidelines of the Project Management Plan, and directing and managing the specific tasks in the Plan,

• creating excellent deliverables according to established processes and constraints,
• implementing approved changes,
• utilizing appropriate PMIS (Project Management Information System) tools,
• using expert judgment,
• holding meetings,
• creating work performance data,
• reporting status,
• updating project documents as the project progresses and more becomes known,
• managing risks and issues, and others.

Do you see the common theme in these topics? Process! For all the expertise indicated by the individual or organization authoring these articles, their natural bent was to resort to process. Even topics that lent themselves to people aspects – such as “using expert judgment” or “holding meetings” – typically resorted to the “how” (process) and not the “what” of the topic.

As I said earlier: I have seldom seen a project fail because of process or technology issues; it’s almost always people issues.

I recall several years ago being asked to perform a project review for a major project gone bad. The Project Executive forwarded me the project plan, the weekly, monthly, and quarterly status reports, the requirements documentation, and several other items he wanted me to review. I conducted two interviews on my first day on the project site – one with the IT provider’s Project Manager and one with the client-side Project Manager. Within minutes in each interview, it became apparent that the project was failing because of people issues.

From that experience, I changed my entire project review process to explore the people aspects of project execution before considering any other factors. I even reorganized my project review checklist to accommodate this.

Now when I am hired to conduct a project review (whether for a failing project or for one that is performing well), I begin with a review of the people aspects. The points that follow are but a few of the items that I expressly evaluate because these are items that directly contribute to project failures. These are based on real-world experiences gleaned over many years of project delivery experience, and any one of these can derail a project.

Note, every one of these and others not included here can be instilled into your Project Managers and staff as readily as instruction in PMI concepts or technology training. And every one of these is equally as important as training in methodology or technology:

• communication issues – IT staff speaking over the heads of their client counterparts, and client staff too embarrassed to admit they don’t understand. This is most evident in requirements gathering sessions where IT staff’s lack of understanding of the client’s business also results in miscommunication and incorrect requirements.
• condescension, arrogance towards client staff – staff exhibiting the previous behavior usually does so unknowingly. This behavior is willful. Client staff are typically plucked from their day jobs to serve on the project. IT staff must be patient and accommodating as they come up to speed. Client staff want to be heard and understood. They want to contribute.
• assumptions – IT staff assuming that the client staff on the project know how to read requirements documentation, know how to develop test case scenarios, know how to write proper defects, know how to use automated tools. Rather than learning the client’s business, IT staff expect their clients to learn IT processes.
• poor written and oral skills – not to be confused with the previously mentioned communication issues, many Project Managers are simply ill-equipped at getting their messaging across. Rather than put themselves in their audience’s chairs to understand how they are coming across, they expect their audience to make the effort to understand.
• poor email, texting, instant messaging skills – bordering on the rude, poor electronic messaging etiquette has the potential of causing grave misunderstanding.
• poor meeting facilitation – more time is wasted and less information shared in formal meetings than in any other project activity. Meeting facilitation is a skill that must be learned and executed efficiently.
• creating an “us vs. them” atmosphere – IT and client staff are on the same team, both with the same primary objective of delivering the system that was contracted for, on time and within budget. Taking sides when issues arise rather than compromising contribute to project failures.
• lack of recognition – failing to recognize the efforts and accomplishments of project staff, both IT and client. Similarly, treating classes of staff differently when administering recognition creates resentment and lowers morale.
• unfair expectations and demands – cancelling leave, mandating overtime, reducing privileges, or requiring star performers to compensate for poorer performers over time when behind schedule result in poor morale.
• lack of staff involvement – especially staff who have been in the trenches and understand the underlying challenges. Project Managers are often their own superheroes, believing they can create the project plan, negotiate technical contracts, advise the clients on what they need, and many other activities that could be handled better by other project staff.
• treating staff as cogs or mushrooms – expecting staff to churn out the work while keeping them in the dark, and missing the benefit of their collective wisdom and experience. This is different than the previous point in that this point shows a callousness and disrespect for staff.
• inability to read people – inability to pick up on non-verbal cues, facial expressions, gestures, cultural norms. This lack of awareness, prevalent in many delivery specialists, can cause relational difficulties.
• inadequate training – inadequate training or coaching in these areas exacerbates the people issues, which contribute to project failures. A technical certification does little good if the team member is unaware of his or her difficult interactions with people.
• “cookie-cutter” training – when training in these skills does occur, it is often contracted to generic training services not tailored to IT projects by IT delivery experts. Generic training is not effective.

I could go on. I am still amazed at how often IT solution providers and in-house IT departments focus on process in their project execution. I am aware of major client organizations that won’t accept a Project Manager unless he or she is PMP (Project Management Professional) certified. But process is NOT the reason that projects are failing.

When I ask IT managers and executive about the people aspects of our profession, I hear comments like, “You’re either a people person or you’re not;” or, “Those are soft skills; we put our training efforts in tangible skills.”

On the client side, I’ve heard such statements as, “Yes, they delivered on time and under budget; and we’ll never work with them again;” or, “They treat me like I don’t know anything just because I’m not technical.”

And IT projects continue to fail at an alarming rate.

Directing and managing project work goes beyond process and technology. After all, we’re a people business first and foremost.

Footnotes

Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition. Newton Square, PA: PMI Publications, 2017, Print.

Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.