Behavioral Project Management

My sponsor asked me to reduce the project schedule from 24 weeks to 16 weeks for a time constrained compliance project. I drew the Critical Path Diagram (CPM) and as I was thinking hard to find ways to cut it short, I heard someone calling my name.

"Hey Sekhar", I recognized the voice that I spoke to, the day before

"Hello Rana, you are back again…!?” I greeted him

"Yes sir! You left me with more questions and few answers yesterday" he was referring to the previous day’s discussion about Mind Templatization

"Sorry buddy, I had to get back to my class" I replied

"Shall we continue that discussion if you have some time now?" he was determined

“Okay, let’s go…I need a break from my CPM as well” I got up from my desk

We headed to the breakout area with coffee cups.

"So, where were we yesterday?" I asked

“You said all the functional knowledge, the PMP credential, other learning would only contribute 30% to being a successful project manager” he was quick

“Right…!” I nodded

“You also introduced the phrase behavioural project management. So, please help me understand what behavioural project management is” he requested

"Right…quickly define the term project management for me again, please" I asked

"Like we discussed yesterday, project management is the application of knowledge, skills and techniques to execute projects effectively and efficiently" he repeated

"So, according to you, the important pieces from that definition are knowledge, skills and techniques…right?" I was validating

"I believe so…without basic knowledge and good understanding of the tools and techniques, a project manager won’t be able to perform his job right" he was confident

"You are absolutely right…without good knowledge and skills, it’s very difficult for a PM to succeed. Only difference is your focus was on knowledge, skills and techniques whereas my focus was on the word application. It’s one thing to know estimation, scheduling, risk management and other techniques and it’s another thing to be able to apply them in the right project at the right time with right audience" I triggered my debate

"Oh...oh...oh...slow down...I understood a little, but confused more. Please elaborate it" he sounded interested

"Rana, in short, you are thinking that Functional Project Management is the key whereas I am suggesting Behavioural Project Management is the key" I confused him little more

"I am still lost" he was quick

“Let me give you some perspective.

• In 2005, KPMG did a Global IT Project Management Survey of 600 organizations and concluded that 86% of the organizations reported that several of their projects didn’t meet the targeted benefits.

• In 2008, a survey that IBM had done indicated that only 40% of the projects met schedule, budget and quality goals.

• In 2012, McKinsey & Company in conjunction with the University of Oxford did a Study on large scale IT Projects and concluded that on average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted

I have several more such survey results. In fact, way back in late 90s, I remember reading several articles which suggested that about 35% of projects fail globally. So, the failure rate hasn’t changed much in last 15 years.

But on the flip side, PMI had released, enhanced & upgraded PMBOK versions 4 times since 2000. Several project management tools have entered the market. Almost every second or third project manager is PMP or PRINCE certified. Pretty much every organization established PMO and started tracking projects closely. Majority of the organizations are adhering to at least one of the process improvement models such as CMMI, ISO or Six Sigma. Organizations have setup exclusive QA, QC and Operational Excellence teams. Still, project failures didn’t come down. Do you agree!?” I gave a pause

“You are making sense. With so much of enhanced knowledge, experience and quality practices being in place, if projects are still failing, there must be something else that’s causing it. So, you are saying that’s the behavioural part of the project team?” he was getting into thick of things

“That’s how I see it. End of the day, if my work failed, its because

• Either I didn’t know how to do such work (functional area) or

• I know how to do it, but I didn’t put enough effort into it (lack of self-engagement) or

• I know how to do the work and I am genuinely serious about getting it done but the environment & the stakeholders won’t support me (lack of organizational-engagement)

Granted certain projects would fail for lack of knowledgeable PM or a good team, but that would only be a subset. For rest of the failures, I believe the root cause is team engagement and/or organizational engagement.

So, you see, these definitions, tools, techniques, skills, all that you were talking about, I would classify them under Functional Project Management. Essentially, that’s the minimum knowledge that you need to have, to do your job. For example, you need to know different estimation techniques to be able to estimate well. You need to know good scheduling techniques to schedule the work. But that doesn’t guarantee you anything. Tell me, what you do most of your time as a project manager" I gave a pause

"Most of my time goes into communication" he replied

"What do you mean by communication" I stressed

"Interacting with different stakeholders, emails, meetings, documentation etc..." he was on dot

"Right...! If I could generalize, even those emails or meetings are with stakeholders, right? In other words, its people that you work with all through the project. Agreed?" I was building my case

"Agreed" he was prompt

"Now, tell me one instance, when your work couldn't move because you didn't know a project management technique" I made him think

"Interestingly, I can't recollect. I don’t ever think, my work got stuck because I didn't know something. But, let’s be practical here. It's only because I acquired good knowledge and techniques, right?" he was little confused now

"Absolutely…! Like I said, functional knowledge is the mandatory requirement for you even to be considered as a project manager. So, once you acquire basic knowledge and skills, that’s no longer your roadblock. Let me ask you one more question. Tell me an instance when you were frustrated by something not named stakeholder" I left him more puzzled

"Man...You got me again! Except for the workflow tool that we have, I don’t think anything else frustrates me besides my stakeholders" he is thinking now

"Right. Even that workflow tool causes frustration maybe because the owner of that tool is not listening to your challenges or issues, right? Now, one last question. All the times you got stressed out, what was the reason? Tools & techniques or people?" I threw the third strike

“People all the way” his hands also answered this time!

“Then, what do you think is the key to be a successful project manager?” I stressed

“Sekhar, I am all in. I see your point. Tell me more about this behavioural project management” his learning antenna stood up

“Before we discuss it any further, look at this picture” I drew something on the paper

“Rana, I am not an expert by any means in project management field. But based on my experience, for anyone to be successful as a project manager, they would need to be good in three broad areas. Functional knowledge, living the project management traits and understanding the behavioural aspects of all stakeholders” I took a pause

“I see what you are saying. So, where does the solution lie?” he acknowledged

“Solution was always simple. I kind of touched up on the subject of why do projects fail in my post Only reason projects fail. Additionally, I believe, Project Manager, Project Team and the Organization each have a role in this.

All project managers must practice traits such as:

Disciplined humbly – Project manager and the team should take pride in being disciplined. Lot of times, planned dates keep changing for variety of reasons. Some of them are genuine but most of those extensions are made for convenience. Project manager and the team should develop an internal culture where missing the targets is seen as an embarrassment no matter what the reasons are.

Working with ambiguity – This is the most important and least found quality of project managers. Project manager is one of the first roles that get engaged with a given project. So, project manager should have the intuitive ability to work through and uncover the ambiguity. More than 70% of the project managers that I have worked with in my career have the amazing ability to run away from ambiguity. Whenever they encounter ambiguous or uncertain situations, they would expect someone to clarify or provide answers. But the reality is that it’s the PM who should find ways to get that clarity.

Leap as you walk – The hallmark of a project manager is his/her ability to plan ahead. Project Manager must be at least two (2) weeks ahead of the rest, every time, all the time. He/she should be able to simulate the upcoming schedule, anticipate the potential roadblocks and showstoppers and find ways to eliminate/minimize them. Project manager should take up the leadership role on the projects than the executioner roles.

One size doesn’t fit all – One common mistake most of the project teams do is cover all stakeholders with one broad brush stroke. Personalization is an important aspect when working with a group of people. There is a risk of missing lot of relevant information if we end up applying same techniques and approach with every one of them.

The organizations should focus on:

Value based Execution – Most of the project tracking resolves around deliverables, effort variance, schedule variance and other metrics, but it seldom tries to review the value the project is going to add to the organization. Once the final deliverable is accomplished, project is closed with lot of fanfare. PMO teams not only should track the projects during execution, but should also track the value its bringing even after the project is delivered and in case things have gone wrong, understand where they went wrong. That way, at least for the next project, they should be better prepared. Unfortunately, organizations aren’t really learning much from failures because, the lessons learned or post implementation reviews consider only the project life cycle, but the challenge would also lie in pre-life cycle as well as post-life cycle. PMO should play a leadership role whose purpose is to drive value thru projects rather than a role of monitoring and governance.

Tools and Infrastructure – PMs spend so much of time and effort in preparing reports, manual tracking, follow-ups and other administrative activities, due to lack of right tools and infrastructure, that they don’t have quality time in fulfilling some of their core responsibilities. If organizations can invest on right automation, workflow tools and infrastructure, PMs can focus more on the stakeholders and deliverables.

Project Engagement – One of the obvious reasons for project failure is lack of proper engagement from both the project team and stakeholders. For long tenured projects, it would obviously help if stakeholder engagement is measured at project level. Most organizations deploy engagement surveys as a ‘broad brush stroke’ at the organization level which fails to identify specific details. Industry recognized platforms such as Gallup, Aon-Hewitt can be leveraged to measure the engagement levels of the team and stakeholders towards the project.

People First – Across the board, processes and methodologies have overtaken the individuals and interactions. Maybe there is a need for stringent processes looking at the risk exposure. But the culture of ‘processes first and people next’ isn’t helping to get the best output from teams. Before it’s too late, organizations need to call for the tag line ‘respect people first and respond to process next’!

Project team must focus on:

Understanding Whats and Whys - Team should understand why the project is being done, what is the problem it’s solving, what’s impact if it’s not done, what are the dependencies etc…A team that understands how their contribution to this project can help the organization will be lot more productive than a team that doesn’t know the big picture.

Being the Performing team – Obviously a team have to go through the forming, storming and norming stages before becoming a performing one. But sooner the team gets into this stage and builds the trusted relationships the better their productivity would be.

Raising Alarms – The group that’s closest to the ground reality about project progress is the project team. They should be able to raise the flag as and when they see challenges with the project execution. Lot of teams try to continue with “we can manage” attitude and although such attitude should be encouraged, but it can’t be at the expense of missing communication and warning signs.

So, if each of these entities play their role to adjust their behaviors and attitude towards projects, things would start improving” I thus concluded