The Myth of the Powerless Project Manager

powerless 2It’s not uncommon to hear from worried Project Managers (PMs) that although they are held accountable for the success of their project, they aren’t given the necessary authority to control it. They say their Sponsors are no-where to be seen and their stakeholder support ranges from ambivalence to hostility. These PMs believe they are powerless to perform the responsibilities they’ve been assigned and ask for advice. My advice?…Stop allowing yourselves to be victims and build your project authority by beginning with taking control of yourself.

Experience has shown me that most PMs that claim to be “powerless” really do have the necessary talent to enable them gain the influence and control that they seek. They are only as powerless as they allow themselves to be. In my opinion, the notion of the “Powerless Project Manager” is a myth. This blog post offers a few suggestions for PMs on how they can avoid, or perhaps recover from, being a victim of powerlessness.

I suppose I should start by admitting that those of us who have chosen project management as a career, have done so, at least in part, because we have an inherent need to be in control of things. In return for the privilege of having project control, we are willing to take on the heavy responsibility and accountability for project success. Legitimate project control and authority, isn’t positional, that is, it isn’t given to you when you get the Project Manager title. You must earn it by demonstrating to the Project Stakeholders that you have the knowledge, good judgment, character and leadership skills to make the project and everyone associated with it successful. So, if you’re pursuing a Project Management career because you want to be in control, be the kind of leader that you’d want to follow.

Here are a few suggestions for building legitimate project influence and control authority.

Know and Trust Yourself. Understanding your own strengths and weaknesses and knowing when, and how, to leverage them with the strengths of others on your team is emotional intelligence. It’s a critical leadership competency and a powerful self-confidence builder. Understanding and believing in yourself is a necessary first step in gaining influence and control authority you require to successful lead all of the other project elements.
Build an Effective Relationship with Your Project Sponsor. Project Sponsors are responsible to the business for authorizing the project itself and for empowering and supporting you, the Project Manager. Your authority to execute the project comes from them and you must hold them accountable for making it clear to all Project Stakeholders that you are empowered to make decisions, set priorities and direct the allocation of resources related to your project. Meet with your Sponsor before the project starts to establish a set of mutual expectations. Agree on, and document, in a Project Charter, your mission, goals, and you resource control and decision authority. If you don’t feel that you have been adequately empowered to make decisions, or you are concerned about passive or uncooperative stakeholders, then make sure that the Sponsor knows that, and that both of you agree on taking immediate corrective actions.
Build Effective Relationships with Matrix Organization Managers. If you are leading a project in a matrix organization environment, although you own the project, the people, equipment and facilities you need to execute it are “owned” by Functional Managers. By building relationships with those Functional Managers, so that you understand their needs and concerns and they understand yours, you will reduce the risk of resource conflicts that impact your project, or at least make them easier to resolve when they do occur.
Build Relationships With Your Key Project Stakeholders. The term Stakeholder implies a person who has a vested interest in the success of the Project. If they are true stakeholders then, they should also have a vested interest in your success as the Project Manager. Do the best that you can to understand what their interests are and work to integrate those interests into your Project Plan and the processes you will use to execute to the plan. Keep them informed. That doesn’t mean they will always be happy, but the more open and honest you are with them, the more likely they will be to be supportive of your project needs.
Know and Be Engaged With Your Project Team Members. You earn you the privilege of having control and authority over your team by gaining their trust and respect. Communicate with them honestly, and frequently. Get to know them as people…their strengths and weakness, what fulfills them, what pisses them off, and what scares them. You must do this in addition to the managing the mechanics of the project management process. It takes time and it isn’t easy, but it’s necessary for you to consistently demonstrate to your team that you care about them as well as the execution of the project.

As you can see, I believe that gaining and maintaining legitimate project control and authority is all about the art of project management. Certainly the science of Project Management as embodied in the PMBoK and other standards, but it’s the art of leadership that enables PM’s to earn, own and exercise the control and authority to successfully plan and execute their projects.

Posted in Better Thinking, Leadership, Personal Development, Program & Knowledge Management | 8 Comments

Better Thinking About Project Management Practices and Tools

Better Thinking ImageThis is the first of a series of blogs I’ll be posting on the subject of Project Management Practices and Tools. In this post I offer my thoughts on how better thinking about Project Management (PM) Practices by Project Managers can make the selection and use more effective.

You may have noted that in introducing the subject matter I’ve avoided using the term “Best “, which is commonly used by organizations when describing their suite of mandated practices and tools. One of the many things I’ve learned over 40 years of working in the field of project and knowledge management, is that the pursuit of “better” provides more value and less risk than the pursuit that “best.” It isn’t that I have a hang up over grammar, or semantics, or dictionary definitions. To me, using “Better”, thinking induces a psychological state, which opens up the conventional limits that typically constrain our understanding and creativity and enables us to be better problem solvers, decision-makers and leaders.

“Best” type limited thinking about PM Practices brings with it, three serious risks for Project Managers:
The risk that past practices may not be relevant to current situations. Project management actions that were successful in the past typically get documented and mandated for future use in the same situations. The problem of course is, that for complex and dynamic projects, even if situations appear similar they aren’t exactly the same as those of the past nor are the capabilities, experience and personalities of the people involved in those situations. I’m not saying we should ignore what has worked in the past, but I am saying that thought and care must be used in assessing the relevancy of past practices to current situations in order to manage the risk.
The risk that valuable new knowledge will be ignored. A bias for learning is a critical competency for both individuals and organizations. A reliance on “Best Practices” may limit individual or organization motivation to search for new knowledge, which might provide better decision or problem-solving alternatives. Again, I’m not suggesting that we shouldn’t try to learn from the past, but we must also seek out relevant knowledge from all sources. Project Managers can handle this risk by demanding of themselves an on-going search for knowledge and setting those same expectations for their people.
The risk that past practices are applied in a “one size fits all” fashion. There is a tendency in many organizations to take a full-scale approach to the application of “Best Practices.” By that I mean that if the rigor, or maturity or level of sophistication of a practice can be described on a 1 to 5 scale with 5 being “best”, then the organizational expectation is that 5 is the required level of application for the project. Although some practices and some projects may indeed require level 5 PM Practice rigor, such effort is costly and requires significant management attention. My experience is that most practices on most projects do not require level 5 application rigor, and may be effectively scaled down to lower, less costly levels. Project Managers, in collaboration with their Sponsors, Customers and Teams should define the practices and tools to be used on the project and agree on an application rigor level that is commensurate to the needs and means of the project.

So, my recommendation to Project Managers is to take a “Better Thinking About Project Management Practices and Tools” approach when looking for the suite of PM Practices and tools to be used on their projects.

If you are interested in learning more about the subject of better thinking about thinking, I recommend that you take a look at the LinkedIn group In2:InThinking Network , led by Dr. William “Bill” Bellows. One of the excellent activities sponsored by this group is an on-going series of free Webinars on “Better Thinking About …”. I had the privilege of conducting a webinar with this group in September 2012, on Better Thinking about Project, Risk, and Knowledge Management.” I’m sure you’ll find that your engagement with the people in this as both a teacher and a student will be very fulfilling.

Posted in Best Practices, Better Thinking, Leadership, Personal Development, Program & Knowledge Management | 3 Comments

Project Decision Making – Simpler Is Not Always Better

Decisions Image 1Some years ago I bought my first scanner. In trying it out for the first time I used a document master that included text, a sketch and a signature. When I selected the “Scan” button, I was prompted to select either “Black & White”, or “Gray-scale”. Since my master was in black and white, I selected “Black & White” and the document was scanned then printed. The result was an incomplete reproduction of the master. The text and some the sketch and signature features were reproduced clearly, but the fine details of the sketch and signature were blurry or missing. My first thought was that I needed to increase the resolution and changed from 300 dpi to 3000 dpi, and although that helped, it increased the memory of the file to a very inconvenient size. As a final try before calling for help, I went back to 300 dpi and selected “Gray-scale” this time. I was rewarded with an excellent electronic reproduction of the master, including all of the subtle details in the sketch and the signature. I realized that my natural instinct was to assume that the simpler, binary, “Black & White” scanning option was “best”, and that I had missed the fact that the task was more complex than I had appreciated, and needed a complex response.

This over-simplified, binary thinking pervades our business and personal lives and causes us to miss the real contributing causes of problems, and to neglect potentially more effective decision options. It’s usually prompted by real or feared schedule and cost consequences. It’s also a perfectly natural human behavior, because our brains are wired to look

So, how can we avoid over-simplifying situations and putting our problem solving and decision-making at risk? Here are a few thoughts:
Take the time to thoroughly appreciate the context of the situation. Not only what it is, but also what it is not. Collect the facts and the feelings, they are both important, but be sure to keep them separate in your assessment.
Everything is connected to everything else. Use systems thinking and be ready to expand your definition of the system boundaries when looking and problems and making decisions.
Recognize biases and assumptions and keep them out of the decision-making. Everyone has biases and assumptions, that’s reality. By being self-reflective and honest, and listing these biases and assumptions you can avoid their improper influence.
Look cause networks, not root causes. The more complex the problem the less likely there is to be a singular root cause. In fact, the “relentless” pursuit of root cause often results in insufficient intervention and corrective action.
Watch out for the pursuit of data to fit a scenario. Too often, influential people with favorite theories, steer the investigation in the direction of finding and interpreting data to support their theory.
Intuition is OK, but it ultimately must be supported by fact. It’s OK for intuition to be part of the investigative and decision-making process, but it can’t be used exclusively, and real data is required to convert it into a credible scenario.
Engage knowledgeable, non-advocate people in the situation assessment for the problem or decision. Bringing in expert, and objective perspectives to the problem solving or decision-making process can avoid groupthink and enrich the pool of ideas and options.

Sometimes simpler is better, but in this increasingly complex world we live and work in, our problem-solving and decision-making thinking must be more sensitive, objective and inclusive.

Posted in Leadership, Personal Development, Program & Knowledge Management | Leave a comment

Project Management Rescue Tips – Smoke Jumping

Smoke Jumper Image 5

Every year, wildfires ravage huge areas of the world’s forest and grassland resources. One of the specialized tools employed to fight these wildfires in remote areas of Russia, Canada, United States, and a few other parts of the world, is a cadre of highly trained “Smoke Jumpers.” Smoke Jumpers and their equipment are deployed by parachute at the earliest stages of potentially dangerous fires. A Smoke Jumper team, deployed to the right area, at the right time, can significantly reduce the likelihood of a small fire becoming a big one.

The concept of using Smoke Jumpers can also be used effectively as a technique for helping troubled Projects in particularly sensitive business areas. By deploying a skilled team of Smoke Jumpers to assist the Project Manager at the first indications of execution problems, business leaders can significantly reduce the likelihood that “project trouble” will turn into “project failure”. In this blog post some tips on the “What”, “When”, “Who”, and “How” of using Project Management Smoke Jumpers.

Although I’ve had a fair amount of experience in doing this kind of work, I don’t claim to be an expert. I welcome the comments and ideas of others with relevant experience to enrich the discussion.

What is Project Management Smoking Jumping? – Project Management Smoke Jumping (PMSJ) is one of several intervention or rescue methodologies that can be used by business leaders and Project Managers to investigate and determine the causes of, and corrective and preventative actions for, emerging execution issues. PMSJ deployments are initiated and authorized by the Project Manager and Project Sponsor to remedy real or perceived issues in project execution performance. They are quickly planned, short duration (~ 1 week) efforts performed by a small ad hoc team, in collaboration with the Project Manager and Project Sponsor. Deliverables are: 1) a set of findings describing the causes and contributing factors for the observed issues; 2) a set of recommendations for short and long term corrective and preventative actions; and 3) a set of risks and opportunities related to the issue and corrective action plan.
When should the Project Management Smoke Jumping Process be used to intervene in a Project? -Project Managers and Project Sponsors should initiate the deployment of a PMSJ Team in the earliest stages possible of a potentially significant, emerging project execution issue. Picking a point at which to make an intervention isn’t easy and requires a good set project performance metrics, effective risk management and sound leadership judgment. Because the interventions have cost impacts, they should be used only on Projects for which failure could have significant business consequences. When possible, PMSJ’s should be conducted in conjunction with key project milestones. Using this approach, they can provide an additional, 3rd party input to the gated risk assessments that are typically conducted at these project milestones.
Who are the key stakeholders in Project Management Smoke Jumper process?
o The PMSJ Team is a small group (~3) of project management subject matter experts (SME’s) led by an acknowledged expert-level project manager. The SME’s should have experience in the planning and execution of projects, and training in the forensic science of project performance evaluations, and the arts of interpersonal communication. The PMSJ team leader should be a recognized project management expert with demonstrated interpersonal and leadership skills.
o The Project Manager and Project Sponsor play a key role in the PMSJ process. They detect the need for, and the type of intervention required, coordinate with the PMSJ process owner (PMO or equivalent) and authorize the resource expenditure. They brief the PMSJ team, support the investigative process and are responsible for the acceptance and implementation of corrective and preventative actions.
o Project execution issues frequently involve the effectiveness and efficiencies related to the supply chain. Supplier’s, who provide products and services to the Project under evaluation, must be included in the investigation and corrective action activities.
o Last, but not least, the PMSJ process must involve the Project customer. Often, the customer senses emergent project issues, even before the Project Manager is aware of them. Sometimes they even drive the request for an intervention. Customers must be included in all aspects of the PMSJ process.
How should a Project Management Smoke Jumping intervention be conducted?
o In some companies, the responsibility for the organization, training and deployment of PMSJ teams is assigned to a Project Management Office (PMO), which owns the project management process for the business. The PMO identifies and trains a cadre of project management SME’s who will be on call for short-term assignment to a PMSJ team. Business leaders should consider the building and sustainment of this project management SME cadre as an investment in the development of a specialized strategic reserve labor force. The PMO also identifies and trains project management experts to serve as team leaders. Some organizations elect to use retired expert-level project managers as consultant contract employees to lead these PMSJ’s. This prevents the disruptive effects of temporarily borrowing experienced project managers from their current assignments.
o Part of the risk management responsibilities of the PM is to prepare for the possibility of a PMSJ and should establish effective project metrics with meaningful PMSJ triggering criteria to ensure timely call-up of a PMSJ Team.
o Once the Project Manager and/or Sponsor become aware of a condition that should trigger an intervention, they contact the PMJS process owner to initiate an evaluation.
o The PMJS process owner selects a team leader and they collaborate in selecting the needed SME team members.
o The PMSJ Team is briefed by the Project Manager on the circumstances leading to the decision to initiate and intervention.
o The PMSJ Team leader and the SME members prepare a preliminary investigation plan which includes: the project management practices to be evaluated, the personnel to be interviewed, the documents to be checked, and the team timeline and work assignments and the communications and reporting plan.
o The initial ~40% of the PMSJ team period of performance should be spent in the interview of personnel and evaluation of relevant documents. Interviews must include all appropriate personnel including the PM, the Sponsor, the Customer, Project Team Members, and Project Suppliers. The interviews must be conducted so as to be non-threatening and un-biased, and offering anonymity for those requesting it. Facts are critical, but so are perceptions or feelings. The PMSJ team members need to skillfully gather both inputs. Based on the initial interviews, follow-ups may be required.
o The PMSJ must evaluate the Project Teams discipline, effectiveness and efficiency in the application of relevant project management practices, including, but not limited to such things as: Requirements Management (Completeness?, Stability?, Documentation?); Baseline Management (Established?, Change Control?); Planning & Scheduling (Complete?, Documented? Used to Manage?); Performance Measurement (Metrics? EVM?, Variance Mgt?); Risk Management (Plan?, Tracking?, Mitigation Plans?); Communications ( Frequency?, Timeliness?, Usefulness?, Team?, Customer?).
o Daily, short PMSJ team meetings to consolidate work completed, preliminary findings/recommendations, investigation plan adjustments.
o PMSJ briefs to Project Manager and Sponsor at the conclusion of the information gathering portion of the evaluation
o The PMSJ spends the next 40% of their period of performance to analyze, consolidate and document findings; identify the cause network for the project performance issues; discuss and formulate recommendations for corrective and preventative actions; and identify relevant risks and opportunities.
o The last 20% of the PMSJ period of performance should be spent in de-briefing the Project Manager, Sponsor, Project Team Members, Customers and Business Leaders on the findings, and recommendations. Just as with Smoke Jumpers putting out a fire, the PMSJ team must place particular emphasis on the immediate actions required to stop the current unfavorable performance trend and limit any further damage. Although the PMSJ may offer recommendations on long-term preventative actions, their primary job is to “quench the current fire.”
o The final responsibility of the PMSJ team, prior to their extraction, is to document and communicate to the PMO or business, the relevant “lessons learned” from their investigation that should be shared across the business to prevent similar issues from occurring on other projects.

Posted in Uncategorized | 3 Comments

A Leadership Learning Moment

 

 

 

 

 

Learning to Be A Leader

There is much to learn in the leadership arts
But just one most important part.
You can rent peoples muscles and minds
But to be their true leader you will find
You must earn the right for them to give you their hearts.

Don McAlister,

14 November 2012

Posted in Leadership, poetry | Tagged , , | 4 Comments

Managing Project Risk By Looking Inside Your Team

In a September 2012 post I introduced the idea of “Implicit Metrics.” Implicit metrics are all about the nature and health of the project team operating environment and the ways in which it affects the interactions and knowledge transactions between the stakeholders. Although I think most project managers would agree that the health of the work environment is a factor in project success, I don’t think they really understand the connection, and we rarely see it discussed in project plans. In this post I’ll offer my thoughts on why a healthy work environment is directly linked to project risk, and I’ll provide some ideas on how project managers can get an indication of their internal environment risk level.

I’ll begin with a discussion of what I think are the attributes of a healthy project team environment.

Alignment. We want all team members to have a common understanding and belief in the mission, goals and objectives of the project. This is the foundational attribute of a healthy environment, and requires constant, consistent, and articulate communication with all stakeholders.
Belonging. Research has shown that the human brain is a social organ (Elaine B. Johnson, “A Beginner’s Guide to the Brain”, January 2012). Our brains not only like to interact with other brains, they demand. Being an accepted part of a group is a fundamental human need. A healthy project environment is one in which all of the members feel like they are valued and respected members of the group.
Fairness. Research has also shown that we are born with a fundamental moral sense. One aspect of this is an expectation of being treated fairly within a group. Inequities in the treatment of members of the team, whether real or perceived damages the health of the team environment.
Safety. I’m not just referring to physical safety, although, depending on the project, this is certainly critical to a healthy environment. I’m also referring to psychological safety. The absence of fear of retribution, arbitrary decision-making, and uncertainty, all contribute to project work environment health. The project manager may not be in complete control of some of these elements, but they can influence the extent to which external causes of these fears influence the behavior of their team members.
Leadership. Project teams expect and deserve leaders who are not only technically capable of planning and executing projects, but also are trust-worth, empathetic, fair, open communicators, and inspirational in the way the lead. Our brains are wired to respect, and to be responsive to legitimate leadership.
Resources. This goes beyond the obvious needs of physical, financial, time and human resources. It also means that the team members must have assured access to the training, tools and the necessary explicit and implicit knowledge resources required to perform their jobs. It also means they must have comfortable access to the project manager when they need direction, advice or help.

You may have additional team environment health attributes ideas, and I welcome your thoughts.

The degree to which any, or all, of these six attributes are missing from the team environment creates dysfunction and adds to the personal stress load of all of the team members, including the project manager. Project execution, with it’s challenging requirements, difficult constraints, and external risks is already naturally stressful, so we want to avoid adding any unnecessary work environment stress. Stress not only affects our physical health, it also affects our ability to think. Elaine B. Johnson, in her book “A Beginners Guide to the Brain,” describes research that shows that elevated and prolonged stress interferes with normal brain function, by inhibiting the communication paths between the parts of the brain that control our emotions and our reasoning. People in this situation are at greater risk of making mistakes, having lower energy, being more easily distracted, more withdrawn, and less empathetic. This of course translates into increased project execution risk. Here’s the way I think this works:

Deficiencies in the team health attributes create a dysfunctional project work environment. This elevates the stress levels beyond normal and interferes with brain function by impairing memory and cognitive capabilities. These impairments increase project risk because they increase the likelihood of people making mistakes of omission or commission, which can have unfavorable cost, schedule and quality impacts on the project. Further, the realization of those impacts and the additional work required for their resolution, adds more stress, and the continuation of the negative cycle.

OK, so if we accept the idea that dysfunction in our internal project environment is directly related to project risk, how can we monitor our work environment to assess the risk and determine what corrective or mitigating actions are necessary? I have used, and recommend a combination of two methods.

First and on-going methodology requires that the project manager and any other personnel filling project leadership roles, to be out amongst, and engaged with, the project team members on a daily basis. They must listen, watch and speak with team members regularly to “get a feel for how they feel” about the project and what is going on inside the project team. If behaviors or attitudes indicate problems with the health attributes, then project leaders must take positive, but not heavy-handed action right away. Communicate, communicate, communicate.

The second method is to conduct a survey to assess the work environment health. It’s more involved, but it provides real data to enable trend monitoring, reveal alignment issues, facilitate team discussion, and inform decision-making. Use of a third party is recommended, but not required. The advantage of using an objective third party to conduct the survey, collate the data and facilitate the communication of results is that enables people to be more open about what they really think about the operating environment. I also recommend that the survey be done in a way that preserves the anonymity of the responding team members. The survey must, of course, include the perceptions of the project manager.

Here is a process that I’ve used successfully in the past for this kind of survey.

• Design a survey, which allows people to express the degree to which the project environment attributes are healthy. Limit the survey to 5 to 10 questions, with provisions to add comments. Use a 1 to 5 or 1 to 7 scale for people to express their opinions. An example of a couple of questions is shown below, but clearly you will need to tailor the statements to fit your situation.  Here is an example:

Using a 1 to 5 scale (1. Strongly Disagree; 2. Disagree; 3. Neutral; 4. Agree; 5. Strongly Agree)  please circle the score which most closely represents your feelings in response to each of the following statements.

1. Our Project mission, goals and objectives are clear, consistent and credible.

Comments:

2. I feel like a valued member of this project team.

Comments:

3. Our project work environment is open, fair and without fear.

Comments:

4. Clear, timely and logical daily direction is provided

Comments:

5. All the needed resources and training to perform the work are provided.

Comments:

The Survey Administrator first gives the survey to the Project Manager and anyone else in a project leadership role, and then gives it anonymously to all other project team members.
• The Survey Administrator collects and collates the data. The absolute values of the responses to the questions are generally less important than the relative gaps between the project manager and the team and spread between team member responses.
• Comments should be carefully reviewed and grouped as appropriate
• The Survey Administrator briefs the Project Manager on results with emphasis on any significant gaps between the their perceptions and those of the team members. Significant comments should be highlighted.
• The Survey Administrator then briefs the project team members. Emphasis here is on gaps between their perceptions and those of their leadership, as well as any significant spread in the views of the team members. Comments should be summarized. Although the survey is anonymous, respondents should be offered the opportunity to explain or expand on their scores and comments. Their willingness to give up their anonymity is in itself a measure of the trust level in the organization.
• The Project Manager and team members discuss the results, explore any resultant ideas, and agree on actions that should be taken to incorporate improvements.

I’ve also used this survey methodology to examine the variations in perceptions between the project manager and the team on the implementation effectiveness of the project management processes, tools and practices.

Posted in Leadership, Program & Knowledge Management | Tagged , , | 4 Comments

Today I Met A Wounded Warrior

I had the honor of speaking with a wounded warrior today. His name is Nelson Holman and he’ll celebrate his 93rd birthday in October 20th. He sustained his wounds on December 7, 1941, while serving on the USS Pennsylvania at Pearl Harbor, Hawaii. He is confined to a wheel chair, and although his body is frail, he has a firm and friendly hand shake and speaks with a clear voice. His short-term memory sometimes falters, and he often re-greets and re-thanks those he just met a few minutes before, but his memories of that Sunday morning in December of 1941 are vivid and precise. He told of seeing the faces of the Japanese pilots as they flew their planes over his ship. He remembers seeing the torpedoes slung beneath the planes, and then seeing them drop into the water and watching the white trail of bubbles that followed them to the ships that they struck. He said he was at the guard post next to the ship when the raid started and the General Quarters alarm was given. Running up the gang plank to the ship, he made his way to his battle station, a gun which unfortunately had a barrel that couldn’t be depressed enough to use against the low flying attack planes. As the torpedo planes dropped their weapons, other planes began strafing and bombing runs. It was the explosion of a bomb in a nearby ships compartment that killed many others, and injured him, breaking his legs and wounding him in the back. He managed to crawl out of the debris to reach rescuers who braved machine gun fire to carry him to an ambulance. As he described these scenes he stared straight ahead into space as if watching the horror on a screen. And as he continued speaking, his voice gradually become softer and more hesitant, and then stopped and he ended his story with a sigh and a shake of his head. He said it was bad, really bad. I lost a lot of friends that day.

Meeting Nelson today inspired me to write a poem to pay tribute to the sacrifice and courage of all wounded warriors.

Today I Met A Wounded Warrior

Today I met a wounded warrior
And he told me of his time
In service to his country
And how he’d held the line
With all his brother soldiers
As they faced the battles roar
And sacrificed both life and limb
On distant fields and shores
He said I’m not a hero
The ones I served with are, not me
Today I met a wounded warrior
And with respect sir, I disagree.

Don McAlister
18 October 2012

Posted in Heroes, poetry, That's Life | Tagged , , | Leave a comment

Project Management Decisions – Logical or Emotional?

For those of us who pride ourselves on making logical, data-driven decisions, recent neuroscience research says we’re kidding ourselves. A recent discussion posted by Paul McFadden in the LinkedIn Group, “NeuroLeadership in Project and Program Management Leadership” captured my attention. His post included a link to an article, titled “Decisions are Emotional, Not Logical: The Neuroscience Behind Decision-Making” by Jim Camp, on the “Big Think” Website. Mr. Camp cited recent research that says that in it’s final stage, decision-making isn’t made in the logic center of our brains, it’s done in the part of the brain that drives our emotions, the amygdala. This discovery was revealed by Antonio Damasio, a Professor of Neuroscience at the University of Southern California, in his book, “Descartes’ Error.” He and others studied the behavior of people who had suffered, damage to their brain’s emotional center. The studies revealed that although these people could effectively use the logic and thinking centers of their brains to understand the information required in preparation for making a decision, when it came to the actual point of making the decision, they were incapable of making one. Apparently, the emotions we have related to decision alternatives mark them with a “good”, “bad” or “indifferent” feeling that is the pre-requisite for us to make a decision. So, accurate and complete data, and solid logic are necessary to set the stage for good decisions, but at the point at which the decision must be made, it’s our feelings about the alternative courses of action that are the critical enabler.

This information started me thinking about the significance this new knowledge might have for Project Managers? The following are a few thoughts on why I think this is important, and how, by knowing it Project Managers can apply it to be more effective in their jobs.

PM “Soft” Skills. There is an on-going discussion about the relative value of “hard” versus “soft” Project Management skills. The majority of PM’s seem to agree that although both types of skills are necessary, it’s the “soft” skills that make the difference between success and failure in complex and difficult situations. I believe this research adds credibility to that belief. Similarly, there is much discussion and debate around the existence and value of Emotional Intelligence (EI), or Social Intelligence (SI) if you prefer. EI/SI is the ability to understand your own emotions and feelings, be sensitive to how others are feeling or might feel in a given context, and using this “sense” to inform your decisions and actions. I’m convinced that EI/SI may be THE most important PM skill and it seems to me that this research adds strong neuroscience evidence to support that conviction. Perhaps now, with a more informed awareness of the role that emotion plays in how we make decisions, we can more effectively build and use our “soft” skills.
PM Critical Thinking Skills. Critical thinking is a process by which we reflect on, and question, our own, and others, standard ways of solving problems and making decisions. Elements of the process include identifying and challenging assumptions and biases; thoroughly understanding context; creative development and exploration of alternatives; and thoughtful, respectful skepticism. These skills are important to PM’s. Based on the Damasio research it’s clear that critical thinking as I’ve characterized it here, may challenge emotionally anchored assumptions, beliefs, theories and practices. It’s clear then that PM’s who use critical thinking techniques might find that an appreciation of the emotional heritage of the assumptions and ideas that they are challenging will reduce any resistance to the adoption of alternatives.
Communications. In my experience, communications and relationship management is the most important and pervasive activity of a Project Manager. PM’s who understand how the people they’re speaking with really make decisions, should be able to build logical, AND emotionally compelling arguments to convince others to do the things that they think should be done to make the project successful.

What do you think? In what other ways might Project Managers leverage the findings of the Damasio research?

Posted in Leadership, Personal Development, Program & Knowledge Management | Tagged , , , , , | 3 Comments

Are You Managing All of Your Project Baseline Risks?

During the initiation and planning phases of a project we establish the baselines. Once the preliminary scope, schedule and cost baselines are defined we then conduct a risk assessment to identify the critical uncertainties associated with those baselines and incorporate mitigation and contingency actions to protect the project. This becomes the risk baseline. We define, analyze, track, and act on those risks throughout the project. I’m going to refer to this process as Primary Project Risk Management (PPRM), because there is another secondary set of risks that only emerge during the execution and control phase of the project. By “secondary” I don’t mean to imply that they are less important than the planning phase risks, just that they manifest themselves later in the project. In fact, they are just as much of a threat to project success as the primary risks, and, in my experience, they are often overlooked by project teams. I’ll call the process of handling these late emerging risks as Secondary Project Risk Management (SPRM). This blog will offer some insights and tips into SPRM.

The domain of SPRM is the execution and control phase of a project, and its focus is on protecting the project from the potential consequences of variances from the project baselines. Variances from the project baselines can be both intended and unintended. Intended variances are those variances that occur as a result of conscious changes that we make to formal project baselines or the processes we use to create our deliverable products. They can be as obvious as Project Change Board approved changes to technical, schedule, cost or risk baselines, or as subtle as deviations in the sequence and/or location of activities that are performed in well-established processes. I’ll refer to these self imposed changes as Out of Sequence (OOS) and Out of Place (OOP) variances.
Unintended variances are those latent changes that occur in our processes that un-expectedly manifest themselves as Out-of Family (OOF) performance data.

The problem is that OOP, OOS and OOF variances, whether intended or not, always,…yes always, introduce risk. Those secondary risks must be identified, analyzed, and handled with the same rigor and discipline as the primary project risks in order to protect the project.

Here are a few tips you can use for your SPRM:

1) First and most importantly, you must look for them! Provide templates and training to the project team members that will help them step back and look for OOP and OOS conditions and objectively assess their consequences.
2) OOF process behaviors can be very subtle, and it’s easy for those unfamiliar with process control to ignore data that should require action or to take ineffective, or even counter-productive actions. I would strongly recommend that project managers and team members become familiar with the ideas of W. Edwards Deming to better prepare them to recognize real OOF process data and take appropriate action.
3) Introduce the use of independent, or non-advocate reviews to evaluate key project performance records and baseline changes at periodic milestones throughout the project. These reviews should include a strong focus on OOP, OOS and OOF indicators, and should trigger a thorough cause network and consequences assessment when found.
4) “Freeze” critical product build processes. Require that a knowledgeable third party validate proposed process changes. It’s common for people involved in executing those processes to make well intentioned, but inadequately thought-out, and undocumented changes, because of schedule or resource availability pressures. The OOP and OOS risks that emerge from this behavior can be very serious.
5) Pay careful attention to the acceptance or repair of discrepancies that are found during the execution of processes that produce the deliverable products. These are by definition, OOF conditions, and their disposition must ensure that the risk they pose is thoroughly examined.
6) Ensure that process failures are thoroughly investigated and that the causes are understood and addressed. Superficial analysis/correction of an OOF condition, will come back to haunt you. I’m a firm believer that for complex systems, there is no such thing as a root cause (See my May 2012 Blog) for failures. So use a cause network to evaluate problems and address all of the primary contributors.

Posted in Program & Knowledge Management | Leave a comment

Ideas for Better Project Metrics

Project metrics are a suite of parameters that we choose during the planning phase and then monitor and analyze during execution to help us make course corrections. They inform us of our performance against the plan and trigger us to take actions when unfavorable variances are detected. Project success is dependent on the relevancy, accuracy, and timeliness of those metrics.

In this blog, I’m going to provide a different kind of perspective on project management metrics than you may have seen before, and I’ll offer some new ideas for metrics that I believe will improve the probability of project success.

Projects are executed by people who perform a logic-linked network of knowledge transactions. Throughout the transaction network, interim sub-products are created at network nodes, and ultimately at the end of the network they are combined into final deliverable products that are essentially the artifacts of the aggregated project knowledge transactions. Typically, in defining the key metrics for a project, we select objective, or “explicit” parameters and measure them at the output of particular logic nodes in the workflow. Examples of these include: Requirements Completeness vs. Plan; Design Models Completed vs. Plan; Lines of Code Completed vs. Plan; Tests Objectives Met vs. Plan; Technical Performance vs. Requirement etc.

Because of the time required to collect, process, and analyze the data, every explicit metric looks back in time and gives us information, which lags behind current reality. In the case of Earned Value Management metrics for example, by the time the Project Manager sees a variance of concern, the information may be more than a month old. On a fast-moving project, operating in a dynamic environment, this lag can allow small problems to become big ones very quickly. This doesn’t mean that explicit metrics are without value. A good set of explicit metrics, collected and acted upon, in a timely manner is a must for every project.

But what if, in addition to these important explicit metrics, there were other metrics that could really look forward, and be predictive of unfavorable performance or at least advise us of an emerging execution performance risk? I believe that there are such metrics. Since projects are executed by people, it makes sense to me that we ought to include metrics that focus on people and the project environment within they are required to operate.  I think of these as “Implicit Metrics.” Implicit metrics are all about nature and the health of the project team operating environment and the ways by which it affects the interactions and knowledge transactions between the people. They are implicit because although everyone seems to understand that the quality of the work environment is important to project success, we rarely see it discussed in project plans or incorporated into on-going project health monitoring efforts.

My idea is to pay more direct and sustained attention to these implicit metrics and integrate them with the explicit metrics into a more holistic evaluation of project performance.  While Project Managers are selecting the suite of metrics that they will use to monitor and control the execution of their project, they should look beyond the traditional explicit metrics and add some implicit work environment and team interaction metrics which I believe have a profound effect on overall project performance. It’s been my experience, in the investigation of many troubled projects, that the attitudes, confidence, and morale of the project team are always significant, but often hidden as contributing causes of problems.  Project environment and interaction health issues are predictive of future problems and ultimately the potential failure of the project.   Implicit metrics offer the opportunity for the only real forward-looking parameters project managers may have to forecast future performance. Project Managers using observation, interviews and perhaps surveys, can gather important information and insight into the health of their project environment and its impact on people by looking at subjective metrics that address topics such as:

• The degree to which team members understand, respect and support each-others objectives. We want them to care about each-others success. This is especially important in matrix organizations.
• The degree to which team members communicate openly with each other. Infrequent communication and communications of contrived formality often mask hidden agendas and conflicts that impair performance.  We want people to want to communicate effectively and efficiently with each-other.
• How effective they are in collaborating to solve problems and make decisions.
• The degree to which the work environment is viewed as “enjoyable.” The work may be complex and difficult, but the environment doesn’t have to be oppressive and fear-based.
• The degree to which people perceive fairness in making assignments, and offering recognition.

The “science” of project management provides us with many explicit methods and metrics that help us monitor and control execution. What I’m suggesting here is that success may be further enhanced by using the “art” of project management to build a complementary set of implicit metrics that focus on the work environment and its effect on the interactions of the people doing the work. I’m convinced that an artful project manager can monitor, shape and improve the work environment and the health of the interactions between team members to enhance the probability of success of the project.

Posted in Leadership, Personal Development, Program & Knowledge Management | Tagged , , , , , | 1 Comment