Why I Like Being a Project Manager
| I have often been asked in the past about the benefits of working in project management. Having worked for many businesses in various roles, I have learned that what I like most about project management is the variety of roles and the type of environments I am exposed to. I was always drawn to the concept of managing, but didn't really want to stay with the same environment or be involved in long-term operational work. Project management appeals to me because it allows me to: - Manage teams - Work with different teams on the new projects - Work in different cultural environments - Be exposed to various architectures, systems - Manage my time and efforts against very specific deliverables - Work in multiple departments or areas, thus being able to gain insight into the ways of managing projects by looking at different angles and listening to different points of view The project management cycle is so finite that it creates an opportunity to refine skills a lot faster. As a project manager moves from one stage to another, you get to know the components of project management delivery. Therefore, you have many opportunities to improve how you manage each of them, be it budgeting, generating the scope of work, generating a work breakdown structure or managing the risks. The opportunity for lifelong learning in project management is also a benefit. While you get to do a complete job with the skills you have -- therefore covering all aspects of the project management -- you also get an opportunity to specialize in a particular area, such as risk management or schedule management. What other benefits have you discovered? |
Unselfish Networking
Categories:
Career Development
Categories: Career Development
| Several years ago a friend "in transition" (a euphemism for "unemployed and looking for a job") asked me to look at his résumé. He figured there must be something wrong with it because it never helped him find a job. The only way he ever found work was by knowing somebody. I'm not surprised. It seems to me the thing to work on is not just tweaking one's résumé, but rather getting to know more "somebodies." The way to do that is through professional networking. I'm a very proactive networker with connections around the world, but that wasn't always the case. In the past I found (my mistaken understanding of) networking to be distasteful. If you'd asked me what I thought of it, I would have said: 1. Networking is self-serving. 2. I want to make it on my own. 3. It's enough to be really good at what you do. Live and learn. Somewhere along the way, I realized no one really makes it on their own. And it isn't enough just to be good at what you do. We are social creatures. We exist as part of the wonderful super-network known as human society, within which we create sub-networks to suit our particular needs. Yes, some "networkers" are self-serving, in the same way that some people are selfish. But one need not be selfish to network. On the contrary, I decided to turn the idea on its head. Rather than network for selfish motives, rather than seek to meet and know people to advance my own agenda, I would network for others. (This was a revolutionary idea for me, but that's because I was ignorant. Good networkers knew this already.) Each of us has gifts and talents, and I'm no exception. What I know and what I can do are valuable, and I would like to use what I know and what I can do to help other people succeed. If, in the end, that contributes to my own success (it will and it does) that is a delightful consequence. It's simple: Know more people, help more people. When I recently found myself "in transition," I appealed earnestly to my network. The response was overwhelming and touching. Ultimately, it helped me succeed. It's very satisfying to have seen the goodness and generosity of my network and to know that so many fine people stood ready to help. You can't achieve that with a résumé, however perfectly crafted. |
The Gift of Criticism
Categories:
Teams
Categories: Teams
| I love it when my associate Sonia tells me in her direct, to-the-point way that she really doesn't like a course segment I put together. It's sometimes uncomfortable to hear, but I find criticism invaluable -- and worth acknowledging. When I ask Sonia what she doesn't like about what I have put together for a program, for example, her reasons are solid, helpful and almost always merit making a change. Who needs a "yes" person, when a person who tells you the truth, even if it is uncomfortable to hear, can really make a difference to the achieved results? Ginger Levin, PhD, PMP, PgMP, drove this home in a note that she sent me a few weeks ago: "Recently, I gave a program management boot camp. As it seems too often be the case, people in the class found some items that they felt needed change. I thought this was wonderful and I was so pleased that they had pointed them out to me. One person pointed out the majority of the changes, and I decided to send him a small present as a token of my appreciation. I also thanked each person who did so. One person in the class remarked that such thanks had not been given in previous courses she had attended. I welcomed the comments, as they can only help me improve next time." Can you imagine being given a gift for the criticism you deliver to a colleague? I believe this is a rather rare response to such feedback -- too rare. Wouldn't project excellence be much more commonplace and achievable if we all responded similarly? And it takes a master like Dr. Levin to truly value this kind of input to keep herself in a mode of continuous improvement. So let's acknowledge those who tell us the truth -- and make us and what we do better! Their integrity, their commitment to excellence and their unwillingness to shortchange the end result by accepting the mediocre are their gifts to us! |
The Value of Trust
Categories:
Teams
Categories: Teams
| Trust is a fascinating element of business and relationships. Where trust exists, all that's needed to manage most work is a brief conversation to ensure understanding and a handshake -- real or virtual. It's lack of trust that leads to the constant measuring and checking of performance, writing complex and detailed contracts, and meeting with people. Trust speeds everything up and lowers transaction costs. As the level of trust goes down, the speed of doing business goes down, costs go up and relationships and communications are largely ineffective to the point everything has to be proved or validated. Interestingly, it would appear trust is not a fundamental element of a relationship. Relationships can work with remarkably low levels of trust, as long as both people have a common objective, and at the beginning of any new relationship there is little to base trust upon. Within both personal and business relationships, trust tends to build as the overall relationship is established. It is built over time and is based on your observation of the other person's actions within the relationship. The effectiveness of the relationship progressively improving as trust between the two people builds. According to Stephen Covey, PhD, author of The Seven Habits of Highly Effective People, trust is built on three behaviours: - Transparency: Tell the truth in ways people can verify and validate for themselves. - Keeping commitments: Do what you say you will do. - Trusting others: Extend trust to your team and they will trust you in return. Trust that has taken years to build can be destroyed in minutes and rebuilding trust is far harder once it has been lost. The first challenge facing project teams and their stakeholders is to identify a pragmatic level of trust that will allow the work of the project to proceed effectively but to also have sufficient checks and balances in place to insure against untrustworthy behaviours. The second challenge is to create trust quickly enough to allow the teams to function in the early stages of a project. This is particularly true for virtual teams. How do you manage trust with a new team of people you don't know well and may never meet? Post your advice and I will combine them with a few of my suggestions in my next post. |
PMBOK® Guide for the Trenches, Part 4: Risk
Categories:
Risk Management
Categories: Risk Management
| If PMI ever invites me to rewrite the risk section of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) I think there are two things I would change. The first deals with the inclusion of "upside risk," or opportunity, as part and parcel of risk management. I don't think it belongs. As my exhibit A, I cite the Oxford English Dictionary definition of risk: 1 a situation involving exposure to danger. 2 the possibility that something unpleasant will happen. 3 a person or thing causing a risk or regarded in relation to risk: a fire risk. As author Mark Twain said, "Beware the man who would win an argument at the expense of language." Beyond the semantics, though, let's consider the three most prevalent ways of analyzing risk and see if they apply in managing a proposal backlog (a listing of an organization's outstanding and upcoming job bids -- or opportunities). The simplest (and crudest) risk analysis technique is classification, in which you basically go through your work breakdown structure at whatever level and assign high-, medium- and low-risk classifications to the tasks. Associate each classification with a percent, e.g. high may mean 50 percent, medium 25 percent and low 5 percent. Multiply the percentages by the original budget/time estimate, and you've done a risk analysis (of sorts). Try this with the proposal backlog, and you'll inevitably look astonishingly inept. Then there's decision tree analysis. For each activity, assign alternative endings, with their impacts and odds of occurrence. Unfortunately for "opportunity" management, the only two possible outcomes of a submitted proposal are that you either win the work or you don't. Data on the gray middle is pretty useless when there's no gray middle. Finally, Monte Carlo analysis is essentially a decision tree on steroids, with lots of statistical chicanery thrown in. My second objection has to do with the use of risk management after the cost and schedule baselines have been set. I agree that prior to the finalization of the baselines, risk analysis is crucial to identifying and quantifying cost and schedule contingency amounts. The risk analysis can lead to informed decisions on how much and what type of insurance to buy, and what sort of alternative plans should be in place if a contingency event occurs. But once the baselines are final, persisting in risk management strikes me as institutional worrying expressed in mind-numbing statistical jargon. To what end? Unless the response to a contingency event (in-scope, uncosted) was to significantly change from how the project team would have reacted normally, what difference does it make if it was anticipated? I'm looking forward to the responses to this, and not necessarily from just the risk management aficionados. Update: Risk management experts and enthusiasts are encouraged to join PMI's new Project Risk Management Community of Practice. |
