Voices on Project Management

> Back to Voices Home

December 2009 Archives

Acknowledgment Isn't Just for Teams

| | Comments (3) | TrackBacks (0)
I always have plenty to say about acknowledgment, but in this post, I'm going to let you draw your own conclusions from portions of a letter I received from W. Pond, PMP. During my session on acknowledgment at the PMI® Global Congress 2009--North America, Mr. Pond says he found his mind turning to his first mentor, Tom:

"The two of us met in the hospital; patients with similar diagnoses. Tom would complete treatments two weeks prior to me. As a result he would prepare me for what to expect and the lessons he learned to make things more bearable for myself.

[We stayed connected during our recovery] and found ourselves taking  many walks together and when one or both of us was too tired we would sit [and talk in] front of the fire.

Tom later offered me a position with his [telecommunications company]. He [taught] me more about business, management, operations and ethics than any university. I have been in so much debt to him and my personal appreciation was given in a conversation where only a verbal thank you was provided.

During the session, as suggested, I drafted a letter of acknowledgment to my mentor:

Dear Tom:

Death comes to all of us faster than we all expect, as we both know. You and I have been through more than we would like.

I wanted to thank you for all that you have done for me. You sacrificed so much even in your time of need. You embraced and assisted me despite your own family and financial responsibilities.

I need you to know that all of my professional and personal successes can be attributed to your influence.

Memories of our walks and conversations by the fire about life and the meaning of being a man will always be treasured.

You were twice my age and my best friend.

Thank you for listening and providing comfort even in your own pain and anxiety. Thank you for hiring me and giving me the chance to find my own niche.

This has been so long in coming. I apologize for not sharing my utmost appreciation years ago.

Now, as I hold my wife, I recognize the things she loves in me were given to me by you. You have given so much of yourself without asking for anything in return. For these things, I wanted to thank you. For these reasons, I love you.

 
It took a while to find Tom. We had a phone conversation discussing our lives since the hospital. I sent my letter acknowledging his role in my life. Since that time I have felt a closeness to Tom once again. Sending this out has provided me a clear conscience and a renewed friendship.

While I continue in my role as a project manager, husband and father, I hope to acknowledge those in my life in a timely manner. If you're wondering whether or not to acknowledge someone, take it from me, do it. Do it now, today."

Thank you Mr. Pond for being a demonstration of the living, breathing power of acknowledgment. You moved everyone in our session deeply with your story--leaving many of us in tears. You cannot begin to know how far the ripples of your story will be felt and acted upon. 

Making Vision Real

| | Comments (2) | TrackBacks (0)
This is a guest post from Roger Chou, PgMP, of the Institute of Taiwan Project Management

Leaders have vision.

They put forth a dream and direction that other people want to share and follow. This "leadership vision" goes beyond a mission statement.

It permeates the workplace and is manifested in the actions, beliefs, values and goals of the organization's leaders. It's also known as "charismatic leadership."

A recent and famous example of leadership vision was shown by U.S. President Barack Obama in his election campaign. By offering a dream of a fairer society, he was able to mobilize people to work on his campaign without payment. The campaign was of a door-to-door nature, obtaining 13 million e-mail addresses in the process. From this, more than one billion e-mails were then sent, and in return 4 million people made donations--generating a record US$500 million, with an average donation of US$85.

Why did people respond to this campaign so enthusiastically?

Obama's campaign promised new possibilities; people were persuaded by this prospect of positive change for the better to help him achieve change. Therefore, for them, responding to and working for Barack Obama meant working for themselves. In helping him realize his dream, they were realizing their own dreams. What they gained was far more valuable than a day's pay.

At the Institute of Taiwan Project Management, the organization I run, we rely on four key ideas to create and achieve vision leadership:

1. Continually evaluate the business environment and propose a vision.
2. Express this vision through persuasion and encouragement.
3. Gain the trust of those you want to share your vision and engage them in this vision.
4. Lead others in fulfilling this vision.

With this shared zeal, we were able to quickly mobilize 300 volunteer project managers for a flood-relief operation after Typhoon Morakot hit Taiwan in August. Together, we prepared a work breakdown structure (WBS) that helped the relief operation.

Since then, the WBS has been sent to the President's Office, the Executive Yuan, the Post-Flood Reconstruction Committee, the Domestic Affairs Bureau, the Major Construction Association, the Taiwan Red Cross and other charity organizations.

I believe leadership vision will continue to allow our Taiwan PM Institute to thrive.

How has your organization benefited from leadership vision?

Flawed Reasons for Avoiding Project Management, Part 2

| | Comments (0) | TrackBacks (0)
In my previous post I addressed two common, but profoundly flawed, reasons team members offer up to avoid implementing the systems to sustain project management capability. Here are reasons three through one:

Objection 3: "If the cost and schedule performance reports indicate a negative variance, upper management will go on the attack, even if the reports are wrong."

I'm sure this happens. What makes this objection so astonishing disingenuous, though, is that it's obviously an indictment against upper management, not the information system itself.

Once a project has been baselined, the primary value of the work breakdown structure (WBS) is that it enables variance to be traced to their root causes. This analysis, known as "drilling down" through the WBS, quickly reveals if the variance is indicative of a genuine problem or simply a data anomaly.

It it's a real problem, then is it not appropriate for management to get involved? And, if you're getting beat up over non-problems, then the cost/schedule system is still doing you a favor: It's telling you that you need to get another boss.

Objection 2: "If the cost and schedule performance reports indicate a positive variance, upper management will want budget/money back."

In addition to the problems with this objection addressed in No. 3, this push-back tactic is often indicative of a padded baseline. When creating the budget, some control account managers will inflate line items as a hedge against project risk. If all goes as planned for, say, the first half of the project, any earned value system worthy of the name will identify padded baselines and the extent to which they are overstated.

The correct approach, of course, is to produce as honest a cost baseline as possible and then perform a risk analysis for identifying an appropriate contingency fund.

But for those who don't want to go through the trouble of doing it right, the cost/schedule performance system represents quite the check against this particular cheat.

Objection 1: "We don't need earned value or critical path to provide us with cost or schedule information because we're using (fill in the name of another system here)."

As I discuss in my book, Things Your PMO Is Doing Wrong [PMI, 2008], one of the most effective but non-legitimate tactics is to employ rival systems.

The quick reason behind this is that there is no project cost control without earned value, and it's next to impossible to control a schedule without critical pat, and anyone who asserts to the contrary is either insufficiently skills or attempting to deceive.

Most of the time, it's not lack of skills in play.

Feel free to offer your comments, and have a fantastic New Year! 

The Other Side of the Argument

| | Comments (0) | TrackBacks (0)
As I said in my last post, customers' perceptions are their reality--and if you're going to make the sale, you need to deal with their reality not yours. This poses a number of challenges for technically oriented people (i.e., project managers) focused on "the facts."

The first challenge is recognizing that if you want someone to take on your ideas and work to help you, you have to get them to accept your ideas. This is a sales process. Even the terms we use to describe the transfer of the ideas are sales-based. You have to "sell the idea" to get "buy-in."

The second challenge is recognizing perceptions are highly unlikely to change quickly. You can deal with this in one of two ways:

- Accept that the perception is real and deal with it by providing a direct solution (even if it's not really needed)

-
Differentiate yourself from the perception by separating yourself from the general stereotype

Pretend your type of business is plagued by a reputation for overcharging customers and
arriving late for appointments. You can differentiate your business by guaranteeing a time, offering a US$10 discount for every 5 minutes you're late and proposing to quote a fixed price before starting work. This solution is partly differentiation and partly working within the reality of the perception by offering a benefit (the discount) if the perception holds true.

The difficulty with managing perceptions is that most people don't advertise their views openly.

The only way to unearth another person's perceptions is through a combination of observation, active listening and careful questioning -- in that order. This takes time and effort and needs to be focused on the stakeholders who matter.

At the PMI Asia Pacific Congress in February I will deliver a paper called, "Beyond Reporting--The Communication Strategy" that builds on this idea. I will discuss more on this idea in upcoming posts.

Building a Great Project Team

| | Comments (14) | TrackBacks (0)
I've worked on a number of great project teams. And I've noticed five key factors that led to us working well together--and to successful project completion.

1. Communication Tools
Good communication is a team commitment. We used tools that worked for everyone on the team. For quick communication and reports, we relied on e-mail, but chose personal visits, phone conversations or conference calls when immediate responses or further clarity was required. And for document exchange, storage and update tracking, we turned to a shared web-based tool.

2. Role Clarity
Teams work best when everyone can just work on what they know, rather than trying to figure out what they're supposed to do, and whether or not someone is covering other parts of the project. Clarifying roles in the beginning of the project helps teams steer clear of conflicts. Making sure team members focus on their specific work definitely helps keep the focus on project deliverables with a higher rate of success in the end.

3. Professionalism
No matter how odd we may feel about something that someone says or does, we have to keep our cool. It allows us to focus on the solution rather than the problem. Handling matters professionally doesn't mean teams are perfectly aligned at all times or that a team member can't make a comment about someone being late on delivering a task. But what helps teams stay together and focused on the prize is the ability to evaluate a situation and correct whatever requires correction--whether it's a communication breakdown, badly handled process or missed deliverable.

4. Fun
When appropriate, joking around and bonding outside of work can help team members get to know each other and break the barriers to communication and collaboration.

5. Authenticity and Integrity
Although two items, they work hand in hand. And they are the basis for trust on a team.

Integrity includes: keeping your word, committing only to work that you are qualified or can complete in time, keeping private discussions private, sticking to the confidentiality clauses and believing in team members.

Being authentic to yourself and others is paramount. It also means keeping others accountable for the work they do, raising concerns, and listening to the input of others.

What are some of the keys to great project teams you have seen?

Eye-Opening Audits

| | Comments (6) | TrackBacks (0)
I've been preparing for the Capability Maturity Model Integration (CMMI) level 3 audit along with my team for the last year and a half.

Though we were quite comfortable that we would clear the audit, we were still apprehensive when the time finally came. You can never predict the mood of the examiner. He or she may ask some unexpected questions and you'll fail.

The project team was excited before the audit and the process kicked off with a short opening ceremony. But the next five days were eye-opening.

It was like the auditor was showing us a mirror--where we stand, where we need to improve. It forced us to look at our understanding of the fundamental concepts on the software processes and the metrics we utilize.

For instance, he discussed the interdependencies across metrics. When it comes to software defect density, the value is determined by dividing total defects by actual effort. To keep defect density low, the auditor discussed that we would have to put in more time and effort. But that would increase the effort variance of the defect density formula. And it gave us something to consider.

Audits by independent people or groups help us find our weaknessess, areas of improvement and strengths. I also do audits for our internal projects and highly recommend having an audit process every month or at least every quarter.

Have you ever been audited by anybody? Please share your experience.

Flawed Reasons for Avoiding Project Management

| | Comments (0) | TrackBacks (0)
Implementing the information systems needed to sustain a project management capability will often meet with resistance from within the organization. And much of this resistance can be rather fierce.

For now, I want to discuss the most commonly used objections I've heard over 20 years of work. These actually come from those opposed to doing project management, and my intention is to assess whether or not there arguments are reasonable. I'll concentrate on two in this post and then pick up the other three in my next.

Objection #5: "Project management systems, like earned value (EV) or critical path, don't apply to this kind of work."

These arguments occasionally have merit, especially in organizations that have experienced attempts to impose project management information systems on non-project work.

However, if the work has three or more of the following characteristics, then you do have a project:

-If has discernible beginning and end dates
-It has a service or product that is delivered
-Resources are dedicated to it
-One person or organizational element is responsible for the work's completion
 
There is no doubt that some unconventional project work will need adaptations from classic EV and critical path management systems. But to assert that project management has no place in managing the work is an excuse and should be left to personnel who are not involved in management decisions.

Objection #4: "EV and critical path are too difficult and expensive to implement."

Again there's enough credibility in this argument to provide a fig leaf of cover to project management antagonists. But a closer look utterly destroys the assertion.

There are two aspects to project management information systems: They provide a valuable information stream on cost and schedule performance and they provide an audit trail for the customer in the event the project goes badly.

It's this second aspect that makes these systems labyrinthine. The performance information stream, when simplified, is actually very easy and cheap to install. But as is so often the cases, when "experts" get together to document the "proper" way these systems should be implemented, the requirements quickly get out of hand.

The audit trail aspects of EV and critical path can be overemphasized to the point that their ability to provide needed management information is eclipsed. However, I must emphasize that simple EV and CPM systems, when freed of their audit trail baggage, are cheap and easy to install--and even the simple systems can provide very powerful management information.

Setting Your Project Resources Straight

| | Comments (0) | TrackBacks (0)
Getting things done is easiest when responsibilities are clear.

Because when it comes down to it, there's no special formula for project success other than being clear on key parameters such as requirements, scope, deliverables and resources.

Take team members as an example. We need people with specific skills to execute project activities well. And knowing what's to be delivered and roles that are required to deliver those results creates for the team a picture of how the project will be completed.

In project-based organizations, many project team members are not carrying out day-to-day functions. Team members often are brought in for a specific project with a specific role to fill. That role is not always as well-defined as, say, someone's role in auditing, marketing, operations management or human resources.

As the project leader, figuring out and clarifying everyone's role and their responsibilities often comes from spending time on the project, asking questions and consulting project definition documents. Setting expectations of what is required of team members before the project is in full swing should be standard practice.

One way to set expectations would be to clearly identify each role with its set of responsibilities and accountabilities within the project definition documents.

Include an RACI chart--a matrix of all the activities or decision-making authorities undertaken in an organization set against all the people or roles--for areas such as communication, deployment, quality assurance and testing.

When describing the role of a particular team member, it's also a good idea to distinguish his or her on activities that may not directly relate to the project, but may be required within the organization.

What challenges do you face when doling out team responsibilities.

About This Blog

Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with — or even disagree with — leave a comment.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll

Categories