When a project manager or team member is unsure of what to do, it's often because there's something lacking. And in my experience, it's usually lacking in all or some of these key areas: knowledge, experience and the project's intended benefit.

In an IT project, for example, let's say you are in charge of the rollout of new computers and rearranging the workstations. You would need to be clear on the requirements first, and you would have to assess if the budget is sufficient for all the required resources and activities you will need to execute. It's your project management knowledge and experience that will aid you in completing the required tasks correctly.  

You may have had experiences where you felt that you were clear on the goals and direction of the project. But depending on where you got the information, and if you don't understand how a particular organization operates, you might be going in the wrong direction.

No matter how much project management knowledge or experience you have, if you don't have knowledge of or experience with the stakeholder or project owner, you will end up failing or negatively impacting the business.

While this might seem like common sense, my experience shows that many people are struggling and looking for creative and advanced solutions to something that is simple. They spend countless amounts of energy and time to figure out a complex solution rather than just looking at the obvious.

In reality, they are missing something in their knowledge, experience or understanding of the project goal or direction.

Use examples from your life to validate this for yourself. Look at an area where you are actually having trouble or an area that is not working as well as you'd like it to. Something is likely missing in your knowledge, experience or project comprehension whether you want to admit it or not.

Have you ever been unsure of what to do in a project? Was it because you were missing something in one of these key areas?

How can you still use the people you currently have on your team rather than replace them?

One suggestion is to look to your junior project managers, provided that they are sufficiently skilled, to complete the work that needs to be done.

But how do you train the junior project manager quickly and sufficiently?

As project managers, we, especially those with credentials, have a strong belief in this profession and the desire to advance our knowledge and practice. Those of us who are already senior project managers have the responsibility to work with our junior project managers or team members and support them in their growth.  

As a project or program manager, you have the power to give them the tools they need to unleash their power as coordinators and junior project managers. As a project manager, you already know how to manage the project. It's up to you to help the less experienced know what they should be doing, what they shouldn't be doing and what tools they should or shouldn't be using.

For example, I worked with one junior project manager who lacked experience in working with those who were directly involved in the business operation. The solution we found was to involve her directly with the business analyst. The business analyst could help the project manager communicate her needs into "business speak." This allowed the project manager to learn, and adjust her management and communication styles.

Knowledge sharing gives junior project managers more confidence. By providing them with an experience working with you on a project, you are creating an environment that fosters growth and development and is fun and rewarding.

Are you a senior or junior project manager? What has your experience been like? How do you foster growth for junior project managers?

As project managers, we have to manage various tasks in multiple lines of work. At times, we operate from our technical background and impart that knowledge and expertise more than our project management knowledge.

There needs to be the distinction of when we use our "project manager hat" versus our "technical specialist hat."

Many project managers work in two common extremes: process focus or technical detail focus. This is common for junior project managers and for project managers who are new to an organization. That often happens, in my opinion, because those project managers haven't developed their management style yet or haven't adjusted to the organizational culture.

When the project manager thinks something is going wrong on a project, either with how someone is performing a task or the results of a deliverable, we often try to fix it. We do that with our strongest toolkit -- usually, that's our technical background. We often take over and hijack the task just to do it "our way," based on our experience.

Remind yourself that as a project manager, you have a different role as a leader. You also can't be a technical skills expert for your team.

Realign yourself to the deliverables. Gain a clarity of the project goal, the project management approach you are using and your role in managing the given project resources.

Project managers can be quite connected and attached to the project outcome. But when you see an opportunity to improve something based on your technical expertise or what you would do differently, stay focused on your role, which is to deliver the project according to the business requirements, aligning with the business sponsor and the organization. Let your team handle their tasks according to their experience and expertise.

Do you ever rely too heavily on your technical expertise?

Read more from Dmitri.

Project management has begun to play an increasingly important role in organizations. Projects are identified to continuously improve the existing business performance and to prepare for the future per organizational strategy. Unfortunately, many of those projects fail.

It's my belief that if you approach a project with management, leadership and entrepreneurial mindsets, the success rate of projects will improve.

A management mindset helps project managers to initiate, plan, execute, monitor, control and close projects to deliver on time, within budget and expected quality deliverables. The management mindset focuses mostly on tasks, and not much on people. Under this mindset, project managers might fail to create a vibrant or positive work environment and satisfied teams -- even though they will satisfy the customers.  

A leadership mindset helps project managers to drive the project team toward a common project goal. It also focuses both on tasks and people, allowing the project manager to create a positive and enjoyable work environment.

A project manager with both the management and leadership mindset will satisfy his team and customers, but might fail to deliver complete business value to customer. That means that although a project is delivered on time, within budget and expected quality, the customer may not feel that the value he expected out of the project was not completely realized.

An entrepreneurial mindset is like an executive mindset for the project manager. He or she would focus on delivering high value to the customer, employees and his or her organization.

Ownership of projects is at its peak, innovation flows like water and alternative project techniques are used for continuous betterment of projects. A project manager's risk appetite is high in this mindset, and he or she also builds many reusable assets to repeat the success of future projects.

Is your organization focusing on building project management, project leadership and project entrepreneurship as an integrated competency?

Every major turning point in my career within the last eight years -- everything that I would call progress -- can be traced back to one thing: public speaking.

Eight years ago, on the advice of a few colleagues and friends, I decided to take my project management stories and experiences to a broader audience and enter the world of public speaking. I hadn't anticipated how wonderful it would be to share stories and experiences with so many fine people. Nor could I have ever imagined the world of possibilities it would later open up to me.

Success in project management certainly depends on capability. But it also depends on exposure and on the image you convey. What better way is there for you to gain exposure and to project an image as a capable project manager than to stand before a group of colleagues and share your knowledge on the profession?

When asked about public speaking, people often say, "I wish I could do that."

I say, "Why can't you?"

Each one of us has a unique perspective and unique experiences. All that remains to be done is to tell the stories in a compelling way. That takes some work and some practice, but it is within reach of any professional. I'll address some ways you can be a great public speaker in my next post.

In the meantime, I'd like to know if you ever considered public speaking? Why or why not? How has it helped shape your career? What tips can you share?

Many of today's agile project teams are distributed around the globe. While simple implementations of agile processes assume co-location, in larger enterprises, this is rarely the case. Selecting tools to assist remote communication helps, but it's not enough.

Here are some human factors to consider, beyond the tools, to work successfully with a distributed team:

Cultural differences can become apparent when working with global talent. Some people are uneasy if some social small talk is omitted as part of doing business. Some are uncomfortable if we don't simply get to the point. This affects agile teams as they implement practices such as self-organization, pair programming, and retrospectives. Remember people's assumptions can vary.

Time-zone differences can be helpful by providing longer hours of coverage. But check with your teams on when they begin and end their workday. Different cultures have different laws and traditions on when to go home. Not all people have private transportation, and not all countries use daylight savings time.

Finding teams in compatible time zones can be an advantage with more hours of coverage, if the hours and needs are remembered. Partnering with teams that are north or south of each other makes this easier because the time difference is less extreme.

Communication differences among distributed teams also require forethought. Agile teams will notice a need for engaging and informative tools in their story grooming, estimating, planning and retrospective meetings.

Telephone calls can be awkward because there is no visual cue as to who is speaking and no person to look at. Also, sound varies for each person depending on if they are in the same conference room, on a speakerphone, using a headset or cell phone. Make it a point to include people on the phone if part of the group is face-to-face.

Video conferences or webcams might be a better option. Be aware of the background so it is not distracting. Also be aware of the lighting quality and direction -- illuminating an attendee's face is better than a dark silhouette.

Spatial user interfaces, which extend traditional graphical user Interfaces by using two or three-dimensional renderings, give people someone to look at and allow positional body language and gestures to convey nonverbal information. However, be sure to allow training time for participants so they can make the most of these environments before needing to concentrate on a meeting.

By using the right tool and having the right mindset, agile teams can work together across wide distances.

How do you work successfully with distributed teams?

To be great in project management, we can't only be familiar with our role as the project manager. We must be educated about other roles in the profession, as well as most, if not all, knowledge areas.

But project managers often do the work they like and are familiar with, rather than work that needs to be done. Even if it's work that contributes to a project's overall success, I find that many of us focus on tasks that we're familiar with or that we already know we're good at.

Regardless of how great I am with some tasks, I know that I must fill in my own knowledge gaps with team members' expertise. Because in addition to being a good project manager, the real trick to getting things done is surrounding myself with a capable, well-trained project team.

Instead of trying to learn everything and being everything to everyone, I accept that I won't always know it all. I ask for input from the team on a regular basis. This makes the team feel needed and appreciated for their contributions and makes the project execution more efficient.

Do you tackle the tasks you're good at rather than those that need to get done? How do you balance your own expertise with that of your team members?

Fact: A happy person is more creative, productive and engaged than an unhappy person.

As project managers and leaders, we are responsible for optimizing our teams' productivity. One effective way for you and your team to achieve great productivity is to create a happy workplace.

Creating a positive environment is your responsibility as a leader. As the saying goes, "There are no bad soldiers under a good general."  

In his book, Full Engagement, Brian Tracy outlines a simple series of actions any leader can take to encourage positive contributions from everyone. These ideas are not new. Aristotle believed the underlying motive for every human action was the desire to be happy.

The golden rule for creating happiness is to "do unto others as you would have them do unto you." But this requires a number of specific actions.

First, avoid destructive criticism. Destructive criticism sparks feelings of fear, rejection, anger and defensiveness. Leaders should resolve never to criticize, attack, insult or diminish another person -- including team members. Instead, look for good in everything that happens and learn to view problems as opportunities.

Second, stop complaining. When you complain about something you become a victim of the situation, diminish your self-confidence and open yourself to feeling inadequate. You hurt yourself much more than the target of your complaints.

Third, remove fear from the workplace. If you want people to be innovative and creative there has to be room for experimentation and failure. It is impossible to improve without risking failure. Remember: Fear of failure can prevent improvement.

Finally, do not condemn anyone for any reason. This can irreparably damage relationships.

Here are some positive actions you can take to develop a happy and productive project team:

1. Smile when you see someone for the first time each day.
2. Ask people how they're feeling. A genuine interest in your team members goes a long way.
3. Listen attentively to others and be polite and courteous.
4. Keep your team informed.
5. Design work assignments so that each team member can be successful. Then acknowledge their successes.

Project managers often travel a lot for work, but you don't have to disappear into some kind of black hole. It's a matter of claiming specific pockets of time based on what's most appropriate for that period.

When flying, for example, I might book myself for two hours of focused work on project documentation, like the project plan or strategy documents. If I'm stuck waiting for a connecting flight or in my hotel room, I use that time to catch up on emails.

Traveling is also a good way to network. Try to connect with people who might help you resolve project challenges or look at issues in a new way. You might even want to find out how they stay productive while on the go.

As a project manager or a team member, I can still be in action and engaged in the project -- no matter where I am. Is traveling a hindrance or a non-issue for you? How do you stay productive yet balanced during your business travels?

Whether I'm the project manager or a team member, I am completely in control of the way in which I interact with people on my team.

I regard my team members as powerful individuals, regardless of their knowledge, experience or personality. With this as the context for my interactions, they can achieve results, complete work on time, support their teammates and share their knowledge.

To foster this kind of environment, I ground myself in the project goal. I determine what's required to achieve results efficiently and with great collaborative effort. Then I translate that to find a way I can help the team by being supportive, open, connected, appreciative, or being someone who consistently celebrates the success of others.

Have you worked with someone closely and over time, and found you could support each other and contribute to each other's work, without doubts, worries or concerns? That's what happens when I create an environment that allows me to be with people that way right from the start.  

How do you elevate your team to the next level of performance?

I recently attended one of the most focused and efficient project review meetings I've ever been to. It was conducted as a workshop to review the project recommendations proposed to the team. I wanted to share why I thought it worked so well.

Picture this: There was a workshop organizer, who facilitated the meeting. We sat in a large room that could seat about 10-12 people. There were representatives from various suppliers. It was quiet and we were the only ones generating conversations in that space. No cell phones were allowed.

The rules for the review, which were developed and distributed beforehand by the organizer, outlined how we would share our ideas, record decisions and deal with issues that arose outside of the agenda. All participants were reminded that on-the-spot decision-making was required.

The purpose and the goal of the review were clarified. All participants had to either agree or disagree with each decision. If there was a disagreement, a discussion took place to clarify the requirements and bridge the gap to reach a final decision.

Having senior decision-makers present allowed us to get through all the points with velocity. We were able to not only review the proposed changes, but also make policy decisions on the spot and discuss relevant details without doubts or assumptions. We recorded anything that needed further work, like the identified gaps, as actions.

Project teams spend many hours in project meetings, especially when teams are not well connected in purpose, goals and operating as a group. As a result, these teams end up having multiple meetings before generating decisions. When sub teams within a project have their own meetings to work out their portion of a solution in a vacuum, for example, it's easy to spend a portion of a project time unproductively, without reaching important decisions.

In general, I find that many meetings are often not as productive as they could ultimately be. They take place more frequently than this type of a focused workshop. What can you take away from this? Before the meeting or workshop consider setting expectations, be clear on the rules and format, and have each participant agree on how the meeting or workshop is going to be structured and what is expected from each and every one of the participants.

What do you think is essential for a successful project solution or review meeting?

Editor's Note: Deputy Secretary for the U.S. Department of Energy, Daniel Poneman, also discusses a successful approach to project review meetings in the final portion of his February 2011 podcast for PM Network^® magazine.

On teams that work in creative services, like those found in advertising and in consulting agencies, often the person who serves as the project lead is not a project manager. 

This situation can be very tricky for a truly robust project manager who provides -- or wants to provide -- strong leadership and guidance to the team. It can lead to conflicts of interest and power struggles that can leave team morale in shreds.

When you see project managers in these environments, they've typically been relegated to a more administrative function. They essentially provide resource scheduling and reporting on data such as project profit and loss, rather than being empowered to provide much true leadership. (I discussed this in a little more detail in my first post.)

So should we eliminate the project management position and have the creative leads or account managers take on those responsibilities? Well, no.

Companies that attempt to eliminate the project management position from their ranks are ultimately just pushing this responsibility to other members of the existing team. Those members may believe they are able to take on the role of project manager, but more likely are too busy with their current responsibilities. Not to mention, they are nowhere near as knowledgeable or skilled in project management as they would like to believe.

The challenge lies in the perception of what it takes to manage and lead a project team from start to finish. If you were to ask your creative team or your account team, I'm willing to bet their description of leading teams would be inadequate. And much of the job they describe will be tasks they simply don't have an interest in performing.
 
So what do we do in these situations?

To me, the answer lies in accountability. If creative or account teams are going to claim leadership positions on projects, they need to be clearly identified by senior management as owning of the final, holistic project outcome. These project leaders must understand that their success -- and the project's success -- is tied directly to their ability to make all of the parts come together, even when many of the parts don't fall squarely in their functional purview.  

Have you experienced this kind of conflict? How was it resolved?

Young project managers are taking over senior management positions -- and some veteran project managers realize they're in for some changes, according to a recent article in PM Network^® ("The Young and the Restless," October 2010).

The "younger generation bosses" act entitled or like they know everything, say some of the veterans. They also complained the new upstarts didn't earn their position, they micromanage, play favorites with younger workers and don't give enough direction to the veterans.

But the younger generation has plenty to offer, too. They generate a healthy mix of ideas and are usually more willing to try new ways of doing things that some veterans might consider too risky.

At the same time, seasoned pros can show young project managers a few of their own tricks. What's the game about if not about leaving the best of yourself in the hands of the younger generation?

Imagine the power of teams that emerge from this kind of cooperation and collaboration!

Both seasoned veterans and their younger counterparts can learn from each other. It's good for the organization, the project -- and your own development as a project professional.

Have you looked outside your own generation for advice? What did you learn?

As a new project manager, you're probably not the boss of anyone.

But even though you don't have traditional authority over a team, that doesn't mean you can't get a team to follow you.

You've heard of the person who comes in with the official title, but crashes and burns when working with teams. You've heard of the person with no organizational status who flourishes in working with even the most difficult of team members. What's the difference between the two? The recognition of real power and its source.

Real power doesn't come from organizational charts, barking orders or threatening teams into obedience. Real power does come from giving and earning personal commitment.

In giving personal commitment, you must risk at least as much as do your project team members. It's up to you to be the first to show why the project is important. When team members see that you're sincerely committed to the project and processes, they're naturally more inclined to do the same.

The surest way to earn personal commitment is to include all team members in the project planning process. Your team is probably smarter than you when it comes to a few things. Recognize this and embrace it. Let team members own their areas of expertise and tell you what needs to happen, how and when.

Ownership quickly becomes an investment into the process. Use your influence as well as your leadership and negotiating skills to clear roadblocks, define requirements and refine expectations.

These back-and-forth conversations will ensure that team member investment becomes personal commitment and that projects get completed successfully -- whether you're the boss or not.

Making decisions is a central part of any project management role, but some decisions are tougher to make than others.

Problems have one right answer that can be reached by analyzing the information you have.

Dilemmas don't have one right answer. Any solution will be at least partially wrong, unfair or harmful to some stakeholders. But not making a decision will be harmful to all stakeholders. The challenge is to minimize the damage and, occasionally, to optimize the benefit.

Mysteries are often hidden within too much information. Understanding them is closely aligned to the ideas contained in complexity theory and risk management. Accepting your inability to know the answer to a mystery is critical: Make the best decision based on the limited information available while staying prepared for surprises.

Puzzles can often be resolved through measurement and research. Gather the right information and skills, and you reduce a puzzle to a problem and can then calculate the optimum answer. If there's insufficient time to gather and analyze all of the necessary information, though, you may be forced to deal with the decision as a mystery,

When confronted with a difficult decision, recognize the differences between the types of possible decisions and then use the best approach to reach your conclusion. Many issues around decision making stem from a false hope that we just need a little more information to reduce a complex decision to a problem with just one right answer. Yet in many cases, this is just not possible.

All project managers make decisions. The difference between good project managers and great ones is the percentage of decisions they get right.

One of the attendees at the Fifth PMI National Congress held recently in Brazil said something that really resonated with me: "I want people on my team who truly believe in the project." That statement is so simple and yet so elegant. It made me think of the project that my company is working on now: International Project Management Day 2010.

A senior consultant at IIL, Frank P. Saladis, PMP, created the idea for this day of recognition and acknowledgment of project managers worldwide.

Now in its seventh year, the event brings together project management thought-leaders in a virtual conference accessible to anyone and everyone around the world.

Gregory Balestrero, president and CEO of PMI, and Harold Kerzner, PhD, will each deliver a keynote address. The event launches on 4 November, and attendees can earn up to 11 free professional development units (PDUs) for participating. There will also be a virtual recognition booth where you can name people you think are great project managers.

This project is a joy, but often a challenge, for all of us to pull together and make it happen. We do it to help realize the goal and intention of the special day: to make sure that all of you are being celebrated. It's certainly a project that every one of us truly believes in and is proud to be a part of.

Head over now -- it's not too late for you to join in the celebration. If you can't make it, the content will be up for three months and you can still earn those precious (and price-less) PDUs.

We often talk about keeping our word -- making a commitment and sticking to it, no matter what.

But we don't often talk about honoring our word -- acknowledging when we can't meet a commitment.

There will inevitably be times when we can't keep our word as circumstances change for one reason or another.

Say you've committed to meeting a milestone on a specific date, for example. To keep your word, you have to do whatever it takes to make that date. But to honor your word, you only need to follow up with the person you made the commitment to and clarify why you can't meet the deadline. I'd also recommend recommitting to a different date, time or scope.

This way, you're not simply hiding and hoping that things will work out, or that you won't be asked about a deliverable. Be confident enough to raise the issue directly, knowing that it will maintain a workable relationship.

Even if you're unable to deliver as promised, you can at least be relied upon to raise red flags early enough, without downplaying the severity, to allow the client or team time to align their activities accordingly. And that saves time and money.

To maintain a healthy relationship on your team, you must honor your word. It impacts the results of your work, your reputation, and your ability to earn a renewed trust from your clients and project team members.

Honoring your word restores your integrity and creates workability. But the better you assess estimated target dates for the project tasks and milestones and your ability to manage your day-to-day activities per your own commitments to others, the easier it will to keep your word and "do it right the first time."

Apart from the challenge of letting go of my 18-year-old "baby," I was thrilled and proud to bring my son to the Rochester Institute of Technology, a university in Rochester, New York, USA last week. At orientation for first year students, James Miller, PhD, senior vice president for career services, invited the 2,650 new students gathered there to create an education and a life that included three critical elements: balance, passion and making a difference.

What better message could there be for these young people, and for the rest of us as well?

Ultimately, project managers are committed to making a difference. It doesn't matter whether the project is solving a problem or filling a need, building a bridge, or creating new software that will do a job better, faster and easier. The goal of project management is always to make things work and work well. And that makes a difference -- in people's lives, communities, schools and environment.

Passion is another element that we love to see in our profession. Who among us wouldn't prefer to work on a team with people who won't stop until things get done and get done right? These are the people who are profoundly connected to, and engaged in, the outcome of the project. They keep the big picture in mind, too, and know that what they do is valued, important and worthwhile.

And then there's balance, the ultimate key to self-actualization and satisfaction in life and in work. Giving back -- when many of us have so much -- is a key part of a balanced existence. I love the way more and more organizations in the United States are excusing their people from work to do community service. I'm also inspired by the way many project managers serve as mentors to those entering the profession or in the process of earning a Project Management Professional (PMP^®) credential.

Balance, passion and making a difference. These three elements can and should be a project manager's call to action. What we wake up for, what we see as our purpose in life, and what we keep in front of us as a guidepost will continually challenge and inspire us -- as well as those around us. I hope my son will learn this as his first academic lesson. And may it last a lifetime.

You and your team must have a project objective in mind at all times. Everything should revolve around it: all the team's activities, status reports, meetings, impromptu discussions, research and engagements of other outside resources.

Having a clear and focused game plan can help. It's not a forced management plan that dictates the rules, but an agreement between all the members on how the team will work together. The plan is like glue that keeps the team together, focused on the key objectives of the project and makes the environment workable and pleasant.

The game plan is therefore an agreement between the team members on how they will maintain such alignment through:

Communication: The team agrees on the basics: method, frequency, media and levels of urgency. How will they update one another with the latest status? What upcoming milestones, changes or issues may affect the progress of the project? Are there any interpersonal issues team members may encounter?

Goal setting: The team defines the goals of the plan, whether it is being customer-centric or meeting deadlines. Having these goals at the forefront keeps the team focused throughout the project as a commitment to the team. The customer gets the added value due to the enhanced quality of the project delivery, and by extension, this leads to the overall success of the project completion.

Team play: This is the actual method of alignment, making sure the team has agreed on the parameters of the game and understands how it will relate to their day-to-day activities.

We're often put on a team based on our experience and technical expertise, rather than soft skills. We are simply expected to be professional and do what we can to work well together.

Having a game plan is simply a tool for all team members to reach an agreement on overall goals, without making assumptions or trying to force an outcome. It adds the missing layer that strengthens the team and adds assurance of alignment among all the team members.

When working in teams, what approach or method have you used as a contributing factor to reaching agreements and working well together?

Program management refers to the process of integrated governance of several related projects to achieve an aggregate result that cannot be delivered by conducting these projects separately.

It may not seem like it, but you can learn a lot about the synergy available through effective program management from The Lord of the Rings.

In the novels and films, the characters of Gandalf, Theoden and Aragorn inspire and command others to be courageous and achieve great feats. Even before a battle starts, these mythical leaders inspire confidence in their men, carefully positioning them in accordance with their skills. Each man has tasks for each stage of the upcoming battle. But they are only effective when coordinated with an understanding of their individual strengths and weaknesses, and knowledge of how they can be used to support and protect each other.

Under a wise leader -- acting as a program manager -- the power of these warriors can be multiplied when coordinated properly. This synergy ensures that every battle they engage in, and every war they fight, victory is at hand. Yet if badly coordinated, the strength and courage of these bands of cavalry, archers, spearmen or swordsmen -- the leader's resources -- is wasted, despite whatever heroic skills they possess individually.

Program management is mainly concerned with managing stakeholders, which in the case of an entire program is a larger, more diverse and more complicated group of than is involved in an individual project. Their interests are different, sometimes contradictory, and their individual impacts -- whether big or small, for good or bad -- may be very significant to the success or failure of the entire program.

The daunting scale of such programs are often not fantasy -- but may appear to demand wizards and heroes to manage them, let alone manage them so that a proper synergy takes place from the different projects involved.

What kind of projects can be managed through a program?
 

• Projects with a common outcome, that can create collective capability and share the same resources
  

• Projects that have the same tasks, that serve the same customer 
  

• Projects where their risks can be reduced when managed together
  

In such cases, "One Ring (Program) To Rule Them All" can bring advantages, not hordes of rampaging orcs and trolls.

On page 229 of A Guide to the Project Management Body of Knowledge (PMBOK^® Guide)--Fourth Edition, under "Project Human Resource Management," I'm happy to see the following:

"Project managers should continually motivate their team by providing challenges and opportunities, by providing timely feedback and support as needed, and by recognizing and rewarding good performance."

I salute and encourage this. Yet I would advocate taking this statement one step further. Teamwork is based on validating all members for their contributions and making sure they feel valued.

Rewards and recognition let people feel special and know that what they do is appreciated. Acknowledgment, however, goes right to the heart. It lets people know that they make a difference, that the success of a project would not be as great without them.

A heartfelt and authentic acknowledgment can be spontaneous or it can be planned. Send an e-mail to a team member's manager about what a great job the person is doing -- and copy that person on the message. Or just look the person in the eye and tell them how much you value his or her continuous contribution.

If you feel moved when you do it and see the person light up as you communicate, you'll know you're on the right track. You don't need to order a plaque or buy a gift card when you're overcome with gratitude to have that person on your team. Just let them know -- from your heart, in a truthful way -- and the impact will be phenomenal. They won't be able to do enough to make the project a success!

So, in the PMBOK® Guide--Fifth Edition, I hope to see a reference to the power of acknowledgment. I will even help draft it, if invited!

Consider a team in which all members are performing at the optimal level.

You would see them engaging internal and external staff members only when necessary. They would deliver on requirements without having to consult you every step of the way, allowing you to be the chief who oversees a big project from a higher level rather than micromanages.

When team members aren't performing at their optimal level they are often constrained by blind spots. These are the internal roadblocks specific to each team member that we often label as communication issues, team dynamics, management style, and cultural and organizational biases.

Having a blind spot means not being able to see the complete picture. When we can't see the complete picture, we make up what is hidden by using context such as our knowledge, experience, goals and motivation.

Blind spots limit us because we lack the runway length required to let our ideas take off; we impose constraints that prevent us from understanding the goal, coming up with solutions and choosing the one that works best.

To expand your runway requires a well-integrated framework of communication and teamwork based on two main principles: clearing those blind spots by empowering the team to help each other and owning your enterprise.

In part two, I will expand on the power of ownership and how to tie these principles together.

Can you think of the blind spots that you were faced with in any of your previous or current projects? What was your way of dealing with them, and what was the impact on the results you produced?

In March I introduced you to Sebastian, a highly competent, upwardly mobile executive who happens to be your boss. A very detailed person, Sebastian works from 6 a.m. to 10 p.m.

That post sparked quite a discussion and prompted some ideas for building a relationship with him. Now it's time to put these skills to use!

This time around, we're focusing on Sebastian's habit of proofreading. While it's a fact some people can see mistakes in documents that others just miss, his copious corrections are starting to cause issues.

Sebastian can and does act strategically. But his habit of correcting everything is causing the project managers and project management office staff in his division to spend an excessive amount of time focusing on the documents' presentation (style, font, grammar, spelling) to the detriment of the more important issues of content and strategy.

How do you advise him that his ability to see and correct minor errors might be counterproductive? And what is an acceptable standard for internal project documentation?  

Post your comments and ideas, and we'll review and consolidate the answers in a few weeks.

Last June, I blogged about a presentation on acknowledgment that I gave to 800 project managers at a conference in Helsinki, Finland. Afterward, Agoston Nagy, a participant, shared with me a conversation he had with a senior project executive of an Indian power company.

Mr. Nagy's colleague asked the senior project executive what the most important competence of a project manager is.

"He answered: 'A project manager must have the courage to acknowledge when somebody does a good job,'" Mr. Nagy recalls.

We must consider that this executive was responsible for 16 simultaneous power plant construction projects and many other projects in his company. The team took in accolades: One project won an international award for excellence in 2005, two others were finalists in the same competition in 2006 and another project won in 2008.

I really appreciate how Mr. Nagy's example illustrated the need for courage when acknowledging a co-worker.

Why courage? Isn't it a simple thing to let someone know how much you appreciate them, how their being part of your team makes you certain you will complete the project successfully?

No, it isn't. Acknowledging others in a heartfelt and truthful way makes us feel at least somewhat vulnerable. We are not certain that they will accept the acknowledgment in the right way: What if they think we are trying to manipulate them? What if they think we are not being sincere?

That's why we need to be courageous and take the risk -- at all times. It is worth it, no matter how vulnerable it makes us feel!

I think the mark of a good project manager starts with how they manage projects.

In April, the Institute of Taiwanese Project Management gave out its first 10 Outstanding Chinese Project Managers awards. The winners and candidates were examples of what defines a good project manager.
 
In general, most of the project managers who caught the selection board's attention managed efforts that were:

•    Completed within budget and on time, sticking to their scope and quality
•    In line with the client company's business objectives or ambitions
•    A benefit to the economy, society or local community

Good project managers also have commitment and determination -- a common characteristic of the 10 award winners. Their background, education and work history all showed they were individuals who, when they committed to doing something, would do all that was possible to get the work completed, even when others wanted to give up.

I also realized during the award-selection process that good project managers are a driving force in our society. Their constant, ongoing completion of projects keeps our economy active and competitive.

Whether these are large telecom projects (such as the installation of China's countrywide broadband network) or smaller ecology projects (such as reducing the carbon emissions of homes or businesses), the project managers leading these efforts are all doing important work that improves our society and our economy.

It is only through their planning, execution and management skills, as well as their commitment and determination, that any project can be completed efficiently and effectively.

If you know excellent project managers who deserve to be recognized, consider nominating them in next year's PMI Professional Awards.

To all you project managers silently toiling away -- possibly thinking "these awards have nothing to do with me!" -- I would like to praise your work: You are the real driving force in society. Never underestimate how important your contribution is!
 

My last post posed the question, How do you manage trust with a new team? Some suggested taking a cautious approach to building respect and rapport. Others addressed the long-term nature of trust developed in a traditional framework.

These are valid, but there's a different form of trust that can also be highly beneficial to project teams: swift trust.

Swift trust occurs when a diverse group of experts are brought together in a temporary organization such as a virtual team created for an urgent project.

It's especially prevalent when the team is required to deliver a result that requires interdependent working and there are significant external pressures. The team has to work out their differences on the fly and "blindly" trust one another to do their jobs simply because there is no alternative.

In these circumstances, team members tend to exhibit behaviors that presuppose trust. Each person knows they're trustworthy and assumes they can trust the others. Therefore, the team simply acts as if trust is present even though there has been no opportunity to develop the more traditional forms of trust.

This is swift trust, and although it can be a powerful force, it is also fragile and easily broken. Activity contributing to the team's common goal, professional behavior and an effective team leader allow swift trust to develop. But it will only last as long as everyone behaves in a trustworthy way.

One aspect of developing swift trust is the presence of recognized expertise. We tend to trust modern medicine and therefore tend to trust doctors. Very few people when rushed into hospital in an emergency want to check the credentials and track record of the doctors working to save their life. They trust the hospital to provide competent doctors to help solve their problem.

Another aspect is a clearly defined objective and clearly defined roles and responsibilities. The key to developing swift trust is interdependent work focused on a common objective. Each member of the team needs the other's particular expertise for the team as a whole to be successful.

Swift trust is not a random occurrence. By understanding the criteria that encourage its development, a manager can create a favorable environment. Then the act of trusting tends to become a self-fulfilling prophecy.

By trusting others we encourage both trustworthy behaviors and engender trust in return. However, as with traditional trust, swift trust can easily be destroyed by untrustworthy behavior. It needs nurturing and support.

The concept of swift trust is not new. There have been papers and books on the subject for at least a decade. But making pragmatic use of the concept on project teams has not been widespread.

If you've been involved in a temporary team under pressure, did you notice swift trust between you and your colleagues, or was it missing altogether? Please share your experiences to help build a better understanding of this interesting phenomenon.

This is a guest post from Roger Chou, PgMP, of the Institute of Taiwan Project Management

Five years ago in Taiwan, there was a general lack of awareness about project management.

This led all of us in the project management community to some basic questions: How could we prove the value of professional project management teaching and qualifications to the country's leading opinion-makers? And how could we show that having as many qualified managers as possible would be good for business and therefore for society?

We decided to provide free project management training to business leaders, company managers, politicians and other influential people. All of these people knew enough about management skills and practices to take such an invitation seriously--and if it was free, how could they refuse?

In this way they would understand what all the Project Management Professional (PMP)® education providers were trying to achieve.

This became our strategy: influence the influential.

After getting first-hand experience of what it meant to be trained and to work as a professional project manager, participants started to endorse project management education and qualifications.

At the same time, we also facilitated numerous newspaper reports on major successful projects, including Taipei's Tower 101.

We also managed to get over 2,000 people--many of whom participated in the free training--to sign the petition for proper project management training sent to our main forum of elected politicians, the Legislative Yuan. Following this petition, we wrote an open letter to Taiwan's president about the importance of project management teaching and qualification.

One of the hardest places to introduce new ideas, practices, technology or anything that requires rethinking convention is within government departments. They see their main responsibility as implementing policy--discussions about or changes to working practices could be potentially costly distractions from an already sensitive process.

Despite the challenges, our efforts have paid off. As of January, all civil servants are now required to have professional project management training and qualifications.

While "influencing the influential" was a business plan specifically tailored to Taiwan's situation and needs at that time, we were nevertheless following our own professional management training.

As the A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) indicates, identifying your stakeholders and satisfying their needs would be the first step to successfully managing change, regardless or how big or small that change.

The last hypothetical I posted, Is This Your Project Stakeholder? attracted a wide cross section of responses.

It made me wonder what you think of this real life experience (only the names have been changed):

Sebastian is a highly competent, upwardly mobile executive and your boss. He works 6 a.m. to 10 p.m., and is a very detailed person. He proofreads everything, making copious corrections and is also studying for his second master's degree.

You have found the best time to approach Sebastian to discuss anything is after 8 p.m. when the office is quiet and he is working on his studies. In fact, at this time of night he seems to appreciate a brief chat.

The problem is you have a "life" outside of the office and feel 8 a.m. to 6 p.m. is a very fair day's work.

How would you approach building rapport with Sebastian to allow the discussion of important project issues and enhance your career prospects without waiting until after 8 p.m.?

I will review all comments and based on your feedback I will suggest some solutions in my next post.

In the book Peopleware by Tom DeMarco and Timothy Lister, there's a humorous story about a project manager who--seeing the progress her team was making--knew she would deliver her project on time. With confidence, this project manager told management that she could guarantee the project would come in, as scheduled, by 1 March.

Management chewed over this unexpected good news and summoned her the next day. They told her that since she was on target for 1 March, they were moving up the deadline to 15 January.
 
I had a similar experience when I presented an initial update for a recent software project. I confidently explained to our stakeholders that the software enhancements for the common process tool would be delivered on time.

Sheepishly believing the stakeholders would be impressed, I waited for a compliment. 

Instead, the stakeholders proceeded to hand down a "schedule challenge" for the team to deliver three weeks early. Their rationale was that they wanted to capitalize on the team's productivity and wow the senior leadership team.
 
So, care to share your productivity war stories? 

My last post received a wide range of comments and I wanted to draw some conclusions based on those comments and my thoughts.

The majority of those that left a response said they would choose "option one." If you selected "option one" and well managed your relationship development and engagement processes, then helping "Mary"--the stakeholder in question--and her team contribute to the change should be beneficial. Why?

The first thing to consider is that Mary would be a key stakeholder at several different levels in the overall change management program.

As a long-term employee leading a group of workers, she is a stakeholder in the overall organization and is likely to have many unofficial contacts and significant influence.

As the leader of a group of workers who will be disadvantaged by a planned reorganization, she and her team are critically important stakeholders for the change manager. The group will never like the consequences of the change, but they need to be included so they at least cooperate for the good of the overall organization.

Because they can contribute knowledge and support, Mary and her team are also stakeholders of the program and particularly your project. The assumption that your team has enough knowledge to bypass her people is risky. You don't know everything that happens in Mary's section on a day-to-day basis.

The second important consideration is where the value is created. Ultimately, there is no value to the organization unless the change is successfully implemented.

Your project may deliver a key component needed for the reorganization but if it is not used, there is no value. This is something IT people in particular need to remember; 99 percent of IT projects require changes to business processes and are a complete waste of time if the business people reject the new processes.

If you selected "option two" and chose to ignore Mary, she is likely to become an active opponent of the change (no involvement equals no commitment and no support). This puts your most important stakeholder at a disadvantage: the overall change manager.

Imagine for a moment your organization has decided on a major restructure, and as a consequence has initiated a change-management process and appointed a change
manager.

The change manager develops the business case for a major program of work. The executives responsible for the organization's portfolio management approve the business case and agree to fund and resource the program.

The program manager sets up the program management team, establishes the program
management office and charters a series of projects to develop the various deliverables needed to implement the change. And you have been appointed project manager for one of the projects.

In this situation, your life as a project manager would be fairly straightforward; you have direct-line management responsibility to the program manager, and the change manager is your project sponsor. The program management office looks after most of the issues of sourcing adequate funds and resources.

All you have to do is deliver the project's outputs as defined in the project charter.

However, part of your project ideally needs the cooperative input from a group of people
who will be significantly disadvantaged by the overall reorganization. This group is led by a 20-year veteran of the organization, whom we will call Mary. At the moment, Mary's loyalties are divided--at one level she wants what's best for the organization she has worked for all her life, but she also wants to preserve her team and keep the status quo.

Fortunately, you have enough domain knowledge in your team to bypass her input and produce the deliverables anyway. So what should you do?

Option one is to work to get Mary and her team's input--if not their positive cooperation--but risk delaying your project's completion and overspending the budget.

Option two is to use the knowledge you already have in the team to produce the deliverable and bypass the problem, thereby ensuring on-time and on-budget delivery. This option also minimizes the chance of Mary interfering in the overall work of the project and program.

What would be your recommendation to the program manager? Option one, two or something different? Post your thoughts in the "comments" section and we shall draw some conclusions in my next post.

I like coffee. The smell of the freshly brewed morning cup of coffee invigorates me. Just this morning I met with my mentor and I prepared as usual by getting to the cafeteria early with my cup of coffee in hand.

Our conversations usually range from project war stories to best practices and lessons learned. This time around, the discussion centered on a "must-win" proposal effort. You feel confident about the current proposal, but the day before the submission, you're called into the executive office and told the final cost must be reduced by another 20 percent.

Thoughts swirl through your head. Given that you're the project manager, you'll have to update the basis of the estimation so it supports this new, lower cost.

Many times a must-win proposal means being the lowest bidder, hoping to make up the difference from future change requests. If this is the case, then the direction from the executive office borders on unethical conduct.

Why? Because within defense contracting, a firm fixed price contract is the preferred choice for the government because any overrun would come out of the contractors' profit margin. Imagine that you know it would really take you US$100 to do the job but you bid US$80 knowing that you're the lowest bidder in order to win the contract in the first place. Once you are awarded the contract, you employ various strategies to bring to light that the customer really needs additional "enhancements" in order to fully execute their missions. Magically, the total cost of the enhancements seem to add up to another US$20, plus additional margin.

All bids must provide basis of estimation (BOE) to justify the dollar amount. On the day before the proposal submission if you are directed to lower the final bid number by 20 percent and there is no way you can revise the basis of estimation in time and you signature is on the proposal, then you are lying to get the business.

So what do you do? 

I think that if the original basis is sound and was validated through independent review, then it's the job of the project manager to say no and explain why that can't be done without compromising the integrity of the submission.

Before I could for a response, my mentor said it was okay not to have an answer right then. When that day comes, my action will be rooted in principle and on doing what's right.

Does the end justify the means?

On a personal note, I'll be taking December off in anticipation of a new addition to our family. Best wishes to you for the various holidays coming up.

Recently I had the opportunity to put together a "sales pitch" presentation to inform a potential customer about a latest and greatest widget. The audience included a vice president, a manager, some end users and a finance analyst. Since this presentation could potentially bring in a sizable amount of work for our team, I was nervous from the start.

Throughout the briefing, there were a healthy amount of discussions going back and forth between our team and our potential customer. Momentum was high after I concluded a few live demonstrations.

However, toward the end of the presentation, the infamous question came up, "How much is this going to cost?" My manager was the intended receiver of the question. There were some initial unintelligible hums followed by a long pause.

Then I interjected and started to describe a comparably scoped project that we'd done and how much resourcing it took to complete. I pointed out the similarities and proceeded to work with the audience in flushing out a detailed project scope. We concluded the briefing with a favorable impression and an agreement to continue our engagement.

As we traveled back to our office, I realized in answering for my manager that I'd decided to act on the notion that it's easier to ask forgiveness than to request permission. I am curious to know what my fellow project managers thing of this idea ...

In my case, my manger made a comment later that he would need to add "Pitch Man" to my current title. To my relief, he was smiling.  

Reporting project status can be exciting--or can be one of those things you'd do anything to avoid.

By conducting frequent, but relevant and appropriate status reviews, including the stakeholders in the process and presenting fact-based information, you will help to avoid any unpleasant project surprises.

To make the reporting process run smoother, project managers should consider these elements when preparing their reports:

Timeliness: This is all about the reporting cycle, the aspects of "when" and "how often" you report. Pick times that will most benefit the stakeholders.

Fact-Based Information: Validate information before it's reported to the stakeholders and produce trustworthy reports that others can base critical decisions on. These steps help gain stakeholder confidence and contributes to the overall success of the project.

Relevance: Know whom you are reporting to and what information is relevant to that stakeholder.

Appropriateness: Be aware of any sensitive information that should be presented only to specific individuals.

Presentation: Spend a little time identifying the medium - such as handouts, e-mail, verbal, telephone -- as well as the method -- free form, discussion-based or single-person, etc -- for the report.

Knowledge: When you don't have the full details on information to be presented, invite a direct resource that produced the result to the presentation.

Audience: Focusing on specific individuals or groups allows you to provide relevant and appropriate information.

By considering all of these elements, you can present a clear picture of the project's status to the necessary attendees.

Acknowledging people for the contribution they make to a project team or to their organization is such a simple matter. It's something I say repeatedly wherever I can get on my "soapbox": We can acknowledge people at any time, at no cost, without having to buy anything, install software or study an instruction manual.

Last night my soapbox was a live webinar attended primarily by project managers from all over the world, including Hong Kong, China, India, Brazil and the United States.

During the seminar I asked participants, "How do you feel when you complete a project that you put your whole heart, soul, body, mind and spirit into for the past several months, the users love the end result and your manager gives you nothing more than a quick 'thank you?"

This was the response via text chat:

Thomas: discouraged
Tanya: feel used
Srikrithiga: not interested to work
James: discouraged
Suganthi: Discouraged
James: feel indifferent
Sanjib: feeling of being empty--what was I doing all the time?
Ravindra: No motivation
Tanya: I won't give my best effort
Linda: lack of loyalty
Linda: feeling insecure, not as interested in working so hard
Fabricio: lack of motivation
Jade: feel not being valued, lack of respect

Then I asked, "How do you feel if your manager tells you what a difference your work made to the project team, how your contribution made the project a success, how much the users loved it, that she was getting wonderful feedback on it, and that the next time you would get more resources so you didn't have to work so many nights and weekends?"

And they answered:
 
James: I would feel appreciated; that motivates me
Shelley: Motivated...willing to give an even greater effort
Linda: enthusiastic
Ravindra: I would make extra efforts
Mariano: I would feel like a giant
Jade: more loyalty
Linda Benedict: my confidence would be boosted by the acknowledgement
Srikrithiga: I would give 200% for work

Performance, loyalty, engagement, confidence, motivation, self-worth are all functions of acknowledgment rather than compensation.

Especially during these challenging economic times--when everyone is working harder and having to do more--let's do our best to create a culture of appreciation in which people know their value and their worth.

There could be nothing simpler and more satisfying and with greater results.

In my last post I said "conflicting leadership initiatives" was one of the factors leading to current overhead reductions at my company. Let me explain. Conflicting initiatives arise from the fact that senior managers do not want to trade off anything from the cost-performance-schedule iron triangle (low resource commitment with high payoff expectation which is to be delivered right now).

A decade ago, senior management got excited about agile methodologies. Instead of rushing out to do a complete makeover and implementation, the company started with small but safe pilot programs, and the results were promising.

Based on these early successes, agile methodologies were then mandated to several large key programs. But this agile mandate failed to account for the scalability of the results and project size, and these large programs soon ran into issues. (Our large projects have geographically dispersed teams including various tiers of sub-contractors and suppliers and the initial pilot programs did not model this type of project profile.)

Significant problems began to affect the company bottom line. And as soon as that happened, program managers dropped the agile mandate like a sack of potatoes and focused on fixing issues and steering their programs back to some level of stability.

Now we are in the middle of CMMI level 3 certification. Much money had to be diverted into fixing many of the gaps caused by the decades-long agile experiment. For instance, our program portfolio consists of a mixture of traditional waterfall, agile and even ad hoc projects that would prevent our business unit from reaching level 3--and not reaching it that level is simply not an option.

Portfolio direction is how an organization decides to invest its resources in different types of activities. Portfolio direction sits above the project portfolio--covering all the organization's activities.

The first step in portfolio direction is to identify the organization's main activities.

Here are the three main types:
•    Change actions (for example strategic programs, change projects)
•    Incremental actions (for example improvement projects, systems updating, continuous improvement)
•    Ongoing actions (for example administration, operations and maintenance)

Many organizations also consider mandatory actions (such as conformity projects or regulatory requirements) as a distinct type of activity. However the organization divides its activities, it is important that there be no overlap between activities and that every area is covered.

The decision to invest in a portfolio direction is highly dependent on the organization's corporate strategy. For example, if the organization is in a turbulent environment and needs to be highly responsive, it will invest more in change activities. If, on the opposite end of the spectrum, it is in a stable environment and occupies a good market position, it will invest more in ongoing activities. If the investment strategy is not clear from the start, the organization will invest its resources in activities that will not support its strategy.

Once the organization has decided which percentage of its resources it should invest in changes--incremental and ongoing--it must develop selection criteria that these actions should fulfill. For example, criteria might indicate that change actions must support market penetration, a strategic initiative or help resolve a significant issue.

In general, every investment decision of the portfolio direction should ultimately increase the organization's responsiveness and competitiveness.

How do you make good decisions? While we don't usually ask ourselves this question in our day-to-day activities, it becomes critical when we are faced with tough situations as project managers.

Several factors contribute to making good project decisions:

Experience: Experience is usually associated with time spend within the industry/domain. But while a project manager gains invaluable wisdom over time, I am a firm believer that training with hands on simulations and role-play scenarios can fast track our ability to effectively tackle challenging situations.

Process: Process refers to the training--on the job and/or formal methods--that a project manager has internalized according to their personal strengths. When I approach or encounter difficult decisions, I typically:
•    Identify the root problem by asking why multiple times
•    Prioritize options with pros and cons
•    Seek to learn from my decisions

Guiding principle(s): Guiding principle is the wisdom that project managers gain from understanding past mistakes. The principle that guides me as a project management professional is the 80/20 rule (Pareto's Law). The 80/20 rule is often observed in real life (or systems) to show that approximately 80% of the work seems to come from 20% of the sources.

When I am faced with 100 items on my to do list, I have a couple of options to tackle the workload:

•    Spread my effort evenly across all 100 items and hope for the best (meet project deadline that is)
•    Utilize the 80/20 rule--Prioritize and work on 20% tasks that when completed would bring the most value to my project.
 
In other fields such as software development, Pareto's Law is often applied to the case that 80% of the defects seem to originate from 20% of the software modules. 
 
Keep in mind that this is approximation, yet a lot of empirical data seems to point to a variation between 10% to 30%, but the name 80/20 stuck as what we the project professionals refer to in today's world.

Courage: While everyone may know the right thing, it takes courage to actually follow through in the face of adversity.

I am writing after having just finished conducting a seminar in Bahrain and am preparing to fly back to London tomorrow morning.

For the third year in a row, CIOs identified project alignment with the strategy as the number one management priority in a CIO magazine survey. And for the first time, CEOs rated "meeting other strategic objectives (e.g., reputation of your business, entering a new market, securing access to natural resources)" as more important than "maximizing financial or shareholder return" or "meeting or exceeding a specific financial return" (e.g., return on invested capital).

In most organizations, business heads select the majority of projects. Those projects are then submitted as part of an annual budget allocation process, with the selection often based on these functional managers' needs, not as a response to an aligned strategy.

Often these initial proposals have to be cut back when budgets are reduced. And because the current organizational focus is on short-term results, the projects that are cut are mostly those that would produce long-term results. But the recent economic downturn has brought into light the failure of the short-term financial profit approach and the need to look for longer-term sustainable value. Recent surveys show the interests of top management are shifting; increasing competitive advantage and the ability to adapt to change have become foremost in their priorities.

The key to delivering this value is in the development of an integrated portfolio-program-project approach supported by a sound governance system. Typically, executive stakeholders agree on the strategic objectives that will produce competitive advantage. At the program level, they are translated into business benefits. Project deliverables are then defined to produce new capabilities that will enable the realization of these benefits.

As project results are measured and benefits are assessed, the program and the strategy are modified to adapt to changing circumstances. This, in turn, gives the organization the necessary agility to stay competitive in a challenging environment and to realize value consistently.

Picture yourself coming to work one morning only to find a scathing e-mail from a client, supervisor or stakeholder, detailing in painful, angry detail how you messed up. What do you do?
    First, keep calm. Then, consider these points:

1. Control your emotions: Chances are that emotion is at an all-time high so your natural instinct is fight or flight. But that will only make things worse. Fighting would be like adding fuel to a burning fire. Withdrawing would make the other party more frustrated at the situation--forcing them to act on emotion rather than logic. Instead, apologize as your opening response; this is a tool for diffusing the emotion and for keeping all parties sane.
2. Establish rapport: Clarify what misconception or misunderstanding your customer may have about your role as anything other than an advocate for them.
3. Express understanding: While it may be impossible to predict the future, provide a plan on what you will do to help mitigate surprises. Even though this time your only option may be to offer an apology, it still signals that someone cares.  
4. Ensure success: Promise what you will do and do what you promise. Nothing reassures your customer more than seeing for herself that you follow through on your plan--even if this means lots of caffeine, late nights and weekends.  
   
    Good luck!

Are you failing to rake in the respect, admiration and monetary recompense that are consistent with your advanced level of project management expertise? If so, you need your own business or management model, complete with its own slick-sounding acronym, in order to truly set you apart and make you stand out in a crowd of (otherwise) management equals.
    This is easier than it looks. For example, someone can, say, set up a traditional Responsibility/Accountability Matrix (RAM), deconstruct them into detailed instructions with lot's of fuzzy terms like "strategic," "engage" and "implement", slap an acronym on it--like RACI (Responsible, Accountable, Consulted, Informed)--and voila! They've developed their very own management model.
    I love reading the synopses in the management course catalogues I get in the mail (yeah, I know, I need to get out more). You can almost track the entire debate among the Agile management practitioners, the Scrum advocates and the more traditional Waterfall Model believers just by reading what the instructors or paper presenters believe they are bringing to the table.
    I know: I'm inviting a truckload of comments questioning my intelligence. But Agile management strikes me as little more than the practice of loosening up baseline change control parameters to the point of almost begging scope creep to hit your software project in a bid to acquire the kind of managerial latitude needed to deliver software faster. Throw in some trendy tactics, like re-arranging the desks in the office and bring along the ever-present admonition to achieve better communications (especially with stakeholders), and then you can profoundly influence the conversation on management theory around the globe.
    I first became aware of the practice of deconstructing already-existing management practices and trotting them back onstage re-packaged during the 1980s, when "Activity Based Costing" was suddenly a hot topic. For you gen-exers out there, Activity-Based Costing (note how easily the acronym falls off the tongue: ABC) was the idea that a project's basis of estimate should be created at the lowest level of the Work Breakdown Structure, or activity level, and "rolled up" to total project cost. Problem was, this was the way that valid estimates had been created since the dawn of project management. Besides, what's the alternative? Estimating based on the availability of the organization's resources? For manufacturing, process or asset management, that might be a workable approach, but it was never so in the realm of project manager. Nevertheless, a plethora of ABC-themed paper presentations' titles started appearing in project management and cost engineering seminars. True to form, of the ones I attended, the content was made up of deconstructing the act of generating the basis of estimate into some sort of process guide--almost like a recipe--and then sprinkling in vague but trendy management-speak terms to make it appear new, or more sophisticated.
    To engage in a bit of deconstruction myself, at the end of the day all management models are nothing more than formulaic attempts at telling other people how they should be managing their projects. I can see why such models are appealing to consultants. But, for the rest of us, do they really merit all of the books, articles and presentations devoted to them?

Taking over a software project in mid-stream can be difficult depending on how well the transition is handled. I should know, I was recently in this position when my current employer hired me as project manager about one year ago. It was my first position as a project manager. I was ready for the challenge, but anxious as to how I would best hit the road running ...
   In the first 100 days of the job, my top priority was establishing trust between myself and my team members. I needed to trust my team to execute the plan and they needed to believe that I would get them what they needed to accomplish the plan. To gain their trust, I used the following strategies:

Listening: One of the qualities of being a great project manager is communication. In my situation as someone new to the team, I practiced active listening. This is important because each project team is unique in terms of its culture, strengths and problems. And I listened to the answer. I was able to quickly diagnose the issues to start plotting the right course.

Learning: When one of the five projects that I inherited was behind schedule, I asked the crucial question "Why?" By asking this question, I began to see how best to adjust the current plan.
   I also took the time to understand past project decisions, team members' strengths, as well as stakeholder expectations. Being able to understand our stakeholder allowed me to better communicate/manage expectations for the path forward. Knowing my team members' strengths enabled me to effectively align the planned tasks with the right individuals. With good working relationships and a view of the big picture, I had one more piece to the puzzle to put into place.

Leading: I truly believed that in order to earn my team's trust and the stakeholders' confidence I must act with highest integrity and transparency. How do I accomplish this in my day-to-day activities? By consistently communicating what I plan to do and doing what I planned.
  
   There were bumps and bruises along the way, but by the end of the first 100 days, my team and I trusted each other to accomplish the goals we set forth.
   Questions to my fellow project professionals: What was your early project management experience like? And what was challenging about the experience?  

Why do we require project managers? For delivering the project on time and within the current budget. But the project manager doesn't do anything on the project--it's the team or team leads who work hard to deliver the project.
    The project manager is the white elephant that sits on top of the team and does nothing. But, if a project fails, no one in the organization complains (except the project manager) about the team. Instead, everybody runs after the project manager since he or she was responsible for the delivery (without doing anything).
    But, is there a structure in which someone else capable among the team would be responsible for the delivery? The reason I ask is because in Asia many of the small-to-medium-size IT companies are more inclined to technology rather than project management. Their success or failure depends on the technology competence and project management has little to do with it. So should the technology manager be responsible for the success or failure of the project? It seems to make more sense, to me at least, that the project manager should just help him out on process implementation, preparing the plan, providing resources, etc.

In his article Intelligent Disobedience: The Difference Between Good and Great Project Managers, author Robert McGannon, PMP, says sometimes a project manager needs to be able to "protect the organisation from itself." He suggests using intelligent disobedience.
    But what is intelligent disobedience? To explain this quality, the author used an example of the program that certifies guide dogs for blind people. During the certification process, the trainer must determine whether or not the subject dog has been able to demonstrate the ability to disregard commands issued by its master under particular circumstances. An example is the guide dog refusing to cross the street when a car is coming.
    In the context of project management, there may be times when obstacles are formidable, which prompts the project manager to pursue the following tasks as stated by the author:

•    Proposing unpopular option/opinion
•    Standing up to senior management
•    Crafting compelling arguments/justifications to garner business support
•    "Bending" rules and processes when appropriate
•    Applying non-traditional techniques to create "unexpected" impressions as a means to change stakeholder perception
•    Using communication and influencing skills to protect the organization from itself

    When might a project manager break from the norm for the good of the project? The author suggests the following situations:

•    Dealing with unresponsive sponsors or key customers
•    Managing culture clashes that inhibit project progress
•    Needing to shake-up lagging teams
•    Overcoming resistance to changing processes
•    Challenging time versus quality decisions
•    Considering intuitive versus fact-based decision making

    What is interesting is that the author points out many times we avoid engaging in difficult conversation or "sugar coat" the bad news to "preserve the current relationship with stakeholders."  We don't realize that "the conversation IS the relationship." Possible benefits from the risk of using intelligent disobedience include, engaged project teams, loyal team members and a reputation for "telling it like it is."
    My question to my fellow project management professionals is, are you a risk taker?

Editor's Note: Members can learn more about intelligent disobedience by reading the Best of Congress feature in April 2006 issue of PM Network.

Friends and colleagues, I hope 2008 was a productive year for you. No doubt some of us are already feeling the need to take another break.
    With the pressure of the economic downturn, many companies are looking for leaders who can see the big picture and motivate the mass with clear visions. I want to share a story with you. Ten months ago in a large defense company, the vice president of engineering declared that the focus for the year was going to be on defect prevention. Everyone was to do their part to ensure that quality is priority number one when products are delivered to the customers.
    The strategies to enable the vision included:
1. Adhering to rigorous formal inspection process for all product development
2. Following an extensive automated test regimen
3. Implementing additional gate reviews to ensure product quality
    Project managers soon found themselves guiding/mentoring teams on following processes, ramping up quickly on expensive software tools, and spending more time conducting "mission assurance" activities.
    All would have been well except that in the same timeframe, the vice president of the product line also announced the vision for the year: "First to market; driven business with agility." And to meet the challenging business climate, everyone needed to be focused on generating value.
    The strategies to enable the vision included:
1. Adopting the use of lean Six Sigma to increase efficiency for all product development,
2. Relying on the use of rapid prototyping--which requires early customer/stakeholder feedback--to ensure customer satisfaction
3. Less gating reviews.
    The end result was disastrous. Project teams created sophisticated enterprise applications that are still waiting to be used. Employee morale suffered because there was a constant tug-of-war between the mandates to implement more processes versus generating revenue faster.
    Sensing the frustration of their team members, project managers united to present their case to senior management on why a new direction is needed. Heeding the wise counsel of the project managers, the vice presidents made changes.
    This year, the vice president of engineering shared her vision of business success through innovation where everyone plays an important role in contributing to the bottom line of the company. Ironically, the vice president of product line decided to share his vision as well. Due to poor ratings from customers in the previous year the vision is defect prevention.