Overturning "Myths"
| One of the most irksome debating techniques has to be the use of a straw man--the practice of misrepresenting an opponent's position and then attacking that misrepresentation. The straw man's first cousin in the management world is the device of writing a piece that supposedly overturns commonly held perceptions that aren't really commonly held at all. An associate of mine sent me an e-mail with a link to an article that purported to overturn project management myths, but I had never heard of any of them. One of these myths being overturned was that project managers are only concerned with scope, schedule and cost, and routinely ignore other parts of their projects, like stakeholders or resources. I must have read or heard hundreds of papers and classes on project management, and I've never, ever heard anything like this, but I suppose the article's authors felt such a perception was so widespread that they needed to spend a few hundred words correcting this wrong-headedness. I don't want to be left behind if this is where the management world is headed, so I'll do some my debunking myself. The commonly held perception that all accountants are weasels is provable false. I am familiar with many accountants, and I know for a fact that at least some of them have a minimum of one human parent. Another myth? The idea that risk managers are attempting to seize control of the project management world by baffling their opponents with statistical jargon until they give in for fear of looking ignorant simply can't be 100 percent true, as risk managers themselves would have to agree. The short answer here is that making a point about project management by overturning myths that nobody holds to involves a certain amount of making assumptions about readers' presumptions, and that is an unsatisfactory approach. Full disclosure: I once presented a paper entitled The Bottoms-Up Myth, where I argued against the practice of re-estimating the remaining work in a project, adding that figure to the cumulative actual costs, and declaring the result to be a better estimate at completion than the calculated version. I felt confident in describing such a practice as a myth, since almost everybody I've ever met in the estimating world seems to think that it's just great to do things that way, even when it's provably loopy. I'm interested in seeing what all of you think. |
Why People Don't Delegate
Categories:
Teams
Categories: Teams
| Why is delegation so hard for some people? Continuing from my earlier post, I want to expand on some of the excuses I've heard over the years: -"My team members lack the experience." -"It takes more time to explain than to do the job myself." -"A mistake by a team member could be costly for my project." -"My position enables me to get quicker action." -"There are some things that I shouldn't delegate to anyone." -"My team members are specialists and they lack the overall knowledge that many of my decisions require." But I think another big reason comes down to a deep insecurity that can influence how you deal with those who work under you. Do you think a team member is after your job? Or maybe you're afraid someone else will do the work better than you? Sound like you? Well, you may be protecting your immediate status, but you're hurting your opportunity to move up. I don't think of delegation as if I am doing the other person a favor. Instead, I think that I'm doing myself a favor. Delegation means I get added resources, leaving more time to manage my project. I focus on doing a few tasks very well, rather than doing a lot rather poorly. I increase my management potential. And, I'm training people to succeed me, so I won't end up shackled to one particular area. That does the organization a favor as well. As I delegate, output goes up, project work may be completed more efficiently, and team members feel free to offer new ideas. And to top it off, decision-making is improved, so the organization becomes more responsive--and more competitive. |
Managing Through Delegation
Categories:
Teams
Categories: Teams
| Project managers should never feel like they have to do anything that someone else can do as well or better. Delegation begins by determining tasks necessary to reach project goals--and then finding the best people to do it. But you still have to check results regularly. I suggest the following four steps for effective delegation: 1. Define the purpose, importance, deadline and scope of the project, along with the responsibilities of everyone involved. But be clear. You can't just expect team members to ask enough questions. 2. Provide the authority, resources and support team members need to get the job done. Otherwise, their requests to others for help and information may be ignored. 3. Set standards and then make sure staffers know they are responsible for meeting those standards. The key here is accountability. And when a problem arises, don't second-guess your staffer. Use the opportunity to show him or her how to handle it. 4. Set deadlines and enforce them. This establishes a commitment, ensuring decisions and tasks are handled promptly. |
Listen Up!
Categories:
Teams
Categories: Teams
| All good project leaders should have a good relationship with their
people and project stakeholders, but sometimes cultural differences
make it a little harder. In Spain, for example, people look in the face of the other person when speaking, while in some Asian countries they consider it offensive to look into the face or eyes of the person you are talking to all the time. Listening is such a routine project activity that few people think of developing the skill. Yet when you know how to really listen, you increase your ability to acquire and retain knowledge and understand and influence your team members and project stakeholders. Listening is hard work. Unlike hearing, it demands total concentration. It is an active search for meaning, while hearing is passive. Try to listen with these questions in mind:
|
The Brass Ring of PMOs
Categories:
PMO
Categories: PMO
| All successful project management offices (PMOs) have one thing in common, while all failed PMOs lack this same thing. Indeed, if your PMO has this one thing it's next to impossible for it to fail; similarly, if your PMO lacks this, you will not succeed, not matter how much more, time and energy you invest. So, what is this "brass ring" of PMOs? Cooperation. It's funny, too, because of the wildly divergent theories out there about how project management ought to be performed and advanced, and what manifestations of the organization are indicative of success or failure. Some believe that only cost and schedule baselines contained in one software represent a successful PMO, while others hold a rival software combination as the only acceptable setup. Many auditors will express outrage at the lack of internal procedures and guides, still others want widespread professional certifications. Many managers who, at some time, had been associated with what they perceived to be a successful PMO will have misidentified the primary casual factor that led to that success. As I discuss in my new book, Things Your PMO Is Doing Wrong, the idea that organizational clout can be leveraged to compel successful project management advancement is a myth, whether that clout-leveraging takes the form of forcing the tool (mandating the use of a certain software), issuing procedures and guides, or any of the other so-called coercive strategies. The only way your PMO will succeed is if you adopt a technical approach to advancing project management capabilities that centers on obtaining that brass ring--cooperation--from the other parts of the macro-organization. And that level of cooperation can be elusive, indeed, but consider what you, the PMO director, are asking: You essentially want everybody else to change the way they've been doing business, for decades in some cases. I would submit that asking anybody to change anything they've been doing a certain way for years, even in the face of overwhelming evidence that the new way is better for everyone involved, is difficult in the extreme. Difficult, but not impossible. How is it done? To find out, you can pose a question on the blog that leads me to tip my hand and disclose the optimal technical approach. But there are two problems with that: 1. You still won't know my take on things that can blow up your implementation, even with the optimal technical approach 2. I'm expecting people to try to get me to reveal this secret, so I'm on to you. Editor's note: You can purchase Michael Hatfield's new book, Things Your PMO Is Doing Wrong, in the PMI Marketplace. |
