Start With Acknowledging Yourself
| After my last post, I received a thoughtful e-mail from a project manager in Barcelona, Spain. Because she was constantly criticized growing up, she said she had difficulty acknowledging others. One's ability to acknowledge is an interesting and important topic. Although it focuses on our personal issues regarding whether or not we were acknowledged in our families, our schools and in our early jobs, we are all people first and project managers second. Therefore I would like to address the heartfelt question that was raised, as it has importance for all of us. A person's ability to acknowledge others freely, generously and sincerely is linked to the way we're raised. If we were encouraged and praised as children, we're likely to grow up with a deep sense of self-worth and confidence. If we were constantly criticized, we have more work to do to gain a sense of self-worth. We have to become our own support system, which can be hard. And it's even harder to acknowledge others when we've feel like we have not been acknowledged for who we are and the contributions we make. If that's true for you, then you will have to push yourself more to deliver acknowledgments that may come to mind but that you may have trouble carrying out. We as human beings crave acknowledgment. Receiving acknowledgements releases a chemical called dopamine in our brains that makes us feel good, perform better and work harder to get more of what's called "the dopamine drench," per an article titled "In Praise of Praising Your Employees" published in the Gallup Management Journal. So here's my advice if you were underacknowledged in your earlier life: Start by taking stock of who you are and what your contribution is to your workplace, your family and to the world. Then you can exercise the muscle on the underside of your right arm, as you reach up and over to give yourself a pat on the back! In my courses, we always start by telling each other something special and unique about ourselves. I invite all of you to do just that--share something special about yourself with a friend or coworker--and send me an e-mail telling me about it. With your permission, I might even post it. |
T. Boone Pickens Talks to PMI Today®
Categories:
PMI
Categories: PMI
| Project managers have to express authority, legendary oil and gas executive T. Boone Pickens said in an exclusive interview in the September issue of PMI's member publication PMI Today. Founder and chairman of BP Capital Management and author of The First Billion of the Hardest, Mr. Pickens will serve as the keynote speaker for PMI Global Congress 2009--North America. In the PMI Today interview, Mr. Pickens discusses everything from innovation to leadership. Here are some highlights: On his predictions for growth in the alternative energy sector--and the chance of a bust like the dot-com industry: Sure, you could have a runaway for awhile, but I think renewable energy is here to stay. There is an opportunity to make money and develop new products in the sector. If we get 200,000 megawatts going in the Great Plains, it is unbelievable what it would do for the economy, jobs and taxes in the small and mid-sized communities, which have lost population over the past several decades. It can all be done with the right leadership. On what advice he has for project managers: You have to express authority. You can't just tell everyone to go do their best and then sit back. You are in a role where you can direct. ... On what project managers thinking of turning to consulting should keep in mind: Hang out your own shingle. Don't figure out what you are making by the hour because it will make you cry. Go out on your own, double your time, work harder and make it your own. Suck it up and know you are able to accomplish what you want to do. PMI members can read the full interview in the digital edition of PMI Today on PMI.org. |
Communicating With the Right Stakeholders
Categories:
Communications Management
Categories: Communications Management
| Any project team will have far more stakeholders to potentially communicate with than they have either the time, money or people to manage. But selecting the right stakeholders for a sustained communication effort in a project is not simple and can be a very resource intensive process. My research over the last 10 years suggests a three-phased approach works best. One: Identify the stakeholders and figure out what you need from them and what they want from the success (or failure) of the project. This is called 'mutuality'. If you can show the person they're likely to achieve at least some of their aims, they're far more likely to provide you with what you need from them. Two: Work out which stakeholder is most important. This requires assessing at least three aspects for each: • How powerful is the stakeholder? Can he or she close the project down, force change or do they have little direct impact? • How much effort is the stakeholder likely to invest in asserting their position or 'rights'? Some stakeholders will go to almost any lengths to assert their position while others are really not that interested. • How close is the stakeholder to the project? People actively working on the project have more impact than those who are relatively distant. Three: Determine the attitude of each important stakeholder towards the project and how receptive they are to your communication. Now you have the information needed to focus your communication efforts where they can achieve the greatest benefit. People who have a supportive attitude simply need 'business as usual' communication. On the other hand, important stakeholders who are assessed as having a less than optimal attitude may need heroic communication efforts to change their views if the project is going to succeed. And always remember: People change. Reassessing the stakeholder community on a regular basis helps ensure the communication plan is working or if it needs changing. |
Time to Empty Your Bag Full of Issues
Categories:
Risk Management
Categories: Risk Management
| Time and again we see projects with a trail of issues that, if not dealt with, build up into this "issues bag," as I call it. The further you get into the project, the bigger and heavier the bag becomes--making it harder to control. Carrying around these unsolved issues creates several risks. 1. Schedule risks: The project isn't completed on time because the issues left unresolved have caused delays in project activities or phases. 2. Budget risks: An unresolved issue creates a requirement to redo the work. If this work isn't done within the allocated timeframe--when it's still possible to refine requirements and while keeping the changes within the scope of the project--any changes would require additional funding. 3. Staff risks: The issue, if not dealt with by the project team, may be passed on to the baseline/production support team. This would impact other departments--and their time and money. So how can you make sure the issues bag is empty at the end of the project? Here's what I suggest: • Keep track of the issues. • Maintain a list of the risks involved with these issues. • Keep a list of assumptions about what? and validate them. • Maintain a list of all changes executed during the project. • Perform quality assurance and close-out any outstanding quality? issues. • Ensure appropriate user-acceptance testing phases and garner signoff on the testing. • Pay attention to the organizational and business environment your project is impacting and any issues that arise. • Notify systems support teams of any impacts that may be caused by your project, directly or indirectly. |
Eulogy to the Old Agile
Categories:
Agile
Categories: Agile
| Escorted on stage by a bagpipe rendition of Amazing Grace, Alistair Cockburn, Ph.D., began his keynote address for the Agile 2009 Conference by waxing Shakespearean on the death of agile as we know it: I come to bury agile, not to praise it; The evil methods do lives after them, The good is oft interred with their bones, So let it be with agile. The noble Waterfall Hath told you agile was ambitious: If it were so, it was a grievous fault, And grievously hath agile answered it. (Adapted from Julius Caesar, Act 3, Scene 2. You can read Alistair's full monologue here.) Melodramatic (in a good way) to be sure. But Alistair, an IT strategist and co-author of the Agile Manifesto, doesn't really believe agile has "met its maker" as the saying goes. Instead, he said agile is in transition--it's not the agile of the 1990s. The landscape has changed. It's grown beyond small organizations and is being applied to much richer, much more complex concepts and projects. Agile shouldn't be "new news," he said. "We're focusing so heavily on things that are 15 years old, I want to start focusing on things that are current." He also shared three pillars of 21st century software development: • Software development is a craft: Developers must pay attention to their skills and to the medium--they must relearn every few years. • Software development is a cooperative game of invention and communication: It relies on teamwork, communication and strategies. • Software development should use lean processes: That means small queues, cross-trained people and varied processes. Hosted by the Agile Alliance, the conference has pulled in 1,400 attendees from more than 38 countries. You can follow all of the conference happenings on Twitter. Did you attend Alistair's keynote address? What did you think? More to come. |
