Creating an Acknowledgment Culture
| I recently presented a keynote session on the power of acknowledgment to 800 attendees at a global project management conference in Helsinki, Finland. Before my presentation, I kept hearing project managers say things like: "In Finland you know you are being acknowledged when your boss says, 'That wasn't too bad a job that you did.'" They told me repeatedly that acknowledgment was just not done in Finland. I'd heard a similar trend in Germany--being acknowledged is when your boss doesn't say anything to you, I was told. Now, I'm a perpetually optimistic person who always tells people they can single-handedly be agents for dramatic and powerful change--that it only takes one person to start the process. If someone acknowledges others in a heartfelt and authentic way, it will start to catch on. But an entire culture? Could 800 project managers turn a whole culture around? Even I had my doubts. During my presentation, I invited everyone to think of one person in their professional life that wanted, needed and deserved their acknowledgment but to whom they had never fully delivered it. Two brave people stood up and shared their profound and heartfelt acknowledgments of their Finnish bosses--who just happened to be in the audience! Each time I asked both the acknowledger and the acknowledgee to stand. People in the audience were deeply moved and said this kind of exchange never occurs in Finland. Well, it did. Just because something is missing from a culture does not mean that it is not desirable or essential. Acknowledgment is, I believe, a basic human need, no matter what one's cultural conditioning. I have since received e-mails from people in Finland telling me they've started to acknowledgment colleagues and family members in a profound and sincere way and are extremely pleased with the results. So I'm now becoming confident enough to say that yes, one project manager can certainly begin to change a culture. Now just think of what 800 can do! Germany, stay tuned! |
Risk Is Not An Opportunity
Categories:
Risk Management
Categories: Risk Management
| In my continuing series on commonly held but, in my opinion, highly suspect project management practices, I want to ask the question: Exactly what do the risk analysts do that improves a project's ability to come in on-time, on-budget? Now, as the firestorm I've just ignited races to engulf me, let me be crystal clear about what I'm asserting. I am not saying that risk management is without value. What I am saying is, once the contingency budget and/or schedule have been baselined, the value of the information produced from risk-analysis techniques drops off dramatically. U.S. General Dwight D. Eisenhower believed that once you're on the battlefield, all plans were out the window. And, while (most) projects don't approach the level of chaos and mayhem associated with a battlefield, I think his ideas are highly applicable in our works. That's what project managers do; they respond to the changes in circumstances, resources, demands, and hundreds of other parameters, every single working day. The notion that project management decisions can be quantified and reduced to formulaic responses in most circumstances is absurd, and furthering that approach using excessive statistical jargon does not automatically make it legitimate. As for the assertion that risk management includes an "upside risk" component--a.k.a. opportunity management--I would like to point to the Unabridged Webster's New International Dictionary, Second Edition. Its definition of "risk" reads, in part, "Hazard; danger; peril; exposure to loss, injury, disadvantage or destruction." Indeed, nowhere in the definition will you find any reference to any possibility of a positive outcome or environ, much less opportunity. And yet, you see people make the comparison risk management equals opportunity management. I know the risk management aficionados have had a lot of success re-defining the verbiage associated with their area of expertise in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) space, but isn't there another way of furthering risk management notions without pounding away at the lexicon? |
Hierarchy of Team Needs
Categories:
Teams
Categories: Teams
| In Abraham Maslow's hierarchy of needs, the lowest level consists of basic needs we all have, like air, food and sleep. Once those are met, we begin to move up the hierarchy to higher-level needs, such as safety and esteem. The same hierarchy applies to the project teams, which are comprised of people with various levels of needs. We often assume everyone is at a level comparable to ours and our remarks or comments will simply be understood the same way we would understand them. This is not to say the age or experience of project team members is directly related to these needs, as even most experienced members of the team may have gaps in fulfilling their needs. Whether it's the need of a job or of recognition, all of these needs influence behavior and it's important to be attentive to them. They can influence various project activities and their outcomes, such as meetings, conversations, use of resources, vendor relations, compliance, ethics and fraud. When organizations recruit project talent, they look at skills and experience as well as personality and cultural fit. But attention should also be paid to team member needs, including those of the project manager, director and sponsor. Doing so can contribute to better understanding of the project environment and the elements that will require special attention. |
Scrutinizing Project Conventions
| Within the realm of project management--or any other complex system, for that matter--accurately identifying failure is difficult to the extreme. There are simply too many parameters to isolate, which makes writing about management a precarious proposition. Oh, there are certainly those cases where a project manager insists that no cost or schedule management systems be used, and it doesn't take long to drive that project into the ground. But in most other areas the link between act and consequence is not nearly so stark. Renowned psychologist, B.F. Skinner, wrote that a variable rate of reinforcement virtually guarantees a behavior will continue. If that is so--and I believe it to be--then it follows that a practitioner who has experienced success using a particular technical approach may be inclined employ that approach over and over--even when it fails over half the time. That same practitioner might also be inclined to join with like-minded project managers to advance a new model or structure for success. Their assertions may be correct and insightful universally, in some specific environs, or completely off base. I entitled this post "Part 1" because I intend to take a close look at some conventions that may have been adapted in that spirit and without the scrutiny of an iconoclastic wise guy such as me. Next up: Does risk management really help bring in projects faster, cheaper or with higher quality? See relevant research from Project Management Journal® as reported in PMI Community Post: Avoiding Project Failure by Managing Organizational Culture |
Optimizing Project Delivery Strategy
Categories:
Agile
Categories: Agile
| One element missing in much of the discussion around project management is a focus on the key early decisions that determine the project delivery strategy. At the project level, strategic decision-making focuses on optimizing the way the project will be structured and managed. Choosing between using Agile or Waterfall, pre-fabrication or on-site assembly, won't change the required project deliverables but will have a major influence on how the project is delivered and its likely success. One size does not fit all; simply following previous choices ignores opportunities to enhance the overall probability of the project meeting or exceeding its stakeholders expectations. Some of the key steps in designing a strategy for success include: • Familiarization with the overall requirements of the project and its stakeholders The problem with implementing this critical stage of the overall project delivery lifecycle is that it crosses between the project initiators and the project delivery team. Both parties need to be involved in developing a project delivery strategy that optimizes the opportunity for a successful outcome. Unfortunately, the opportunities to engage in discussion and planning for project delivery are difficult to arrange. Frequently contract documents effectively prescribe a delivery process, and/or the client and senior management don't know they need to be engaged at this stage of the project lifecycle. I suggest that project managers and project management offices start focusing more on the project delivery strategy during critical early stages of a project. What has worked or not worked on your projects? |
