In project management, loaded questions can cause massive problems on project teams.  As the project manager, it's your job to keep things under control.

Loaded questions usually carry some form of presumed fault. Here's an example: "Why didn't so-and-so provide us a project update on time?"

When someone -- project team member, stakeholder or client -- asks you such a question, how do you react? Do you answer it directly or do you try to defend yourself or your team, escalating the situation further?

In my opinion, the fastest and most effective way to respond to a loaded question is to address its underlying concern. When you address the issue rather than what is being asked on the surface, you create a safe environment where a person is understood.

Recently, I was in a situation where my first reaction was to defend myself and completely bash the opposing view. I stepped back and looked for their concern about the incident that occurred rather than jumping into defense mode.

As a result, I was able to see more clearly why in this situation, the project process was defined the way it was, without pushing my own agenda. Instead of seeing holes in the process, I started seeing what actions I needed to take. When I acknowledged this to the person that raised the question, the original concern disappeared for both of us.

The next time someone asks you a loaded question, answer the concern and not the question. The original issue may simply disappear.

Think about a recent encounter with a project team member or stakeholder where you may have gotten a bit defensive. What would be different in that situation if you listened for the concern behind what they were saying?

Read more posts from Dmitri.

Kinesthetic intelligence is one strength of people's minds, according to "7 Kinds of Smart," a book by Dr. Thomas Armstrong. Essentially, people who have kinesthetic intelligence learn better by using movement -- like getting up and moving around, for example.

But when agile meetings focus on logic, numbers or charts, our kinesthetic aptitude may not get used.

Certain agile techniques use body language for visual cues, which exercises this kinetic intelligence. And leveraging it can help engage members of your agile team who don't like to be outspoken.

"Big visible indicators," is an agile term for a technique that often includes a large whiteboard or wall divided into columns. Tasks and stories are moved between the columns as they progress to completion. With a wall covered with colored Post-it^® notes, not only is progress more visible, but physically walking up to the board in front of the team to move your item to the completed column makes everyone keenly aware of the progress.

In a recent stand-up meeting, there were a lot of people attending -- many who were just interested observers. As a coach assisting the Scrum Master, I found it hard to know who to call on next. We used a second body language technique, which allowed the observers to sit during the meeting and the participants stood. Suddenly, our meetings went faster.

A third kinesthetic agile technique is "Fist of Five." Team members indicate approval of a plan or decision by holding up anywhere from one to five fingers to vote, five being the most approval.
 
All of these techniques better engage team members who aren't as comfortable being outspoken on a project team. And as teams become more and more dispersed, recognizing and leveraging kinetic intelligence can lead to stronger agile meetings  -- especially if people can use these techniques while seeing their teammates. This can be done with video or other virtual representation technology.

Do you use any of these techniques? If so, which ones? Do they work? What other techniques do you use?

Read more posts on agile.

Read more posts from Bill.

Best practices in project management are tried and tested processes collected from experiences and lessons learned. They've been repeated and improved to produce consistent outcomes. They are documented as examples, baselines and measures.

Project managers who favor best practices and processes believe it's unnecessary to "reinvent the wheel." They believe using best practices in projects has many advantages:

1. Project managers have access to tools, techniques, metrics and templates to use on their projects at any time.
2. Best practices provide consistency of expectation, activities and communication for the team.
3. They're generally driven by values and results, and can improve customer confidence.
4. Construction, infrastructure and power projects have best practices as industry norms to standardize quality, safety and other requirements.
   

Not everyone agrees with using best practices, however. Some argue against the blanket use of best practices because, frankly -- times change.

Best practices for projects from 10 to 20 years ago are outdated as technology and real time communications continue to evolve, for instance. More customers are aware of project management, resulting in changed expectations. And definitions of acceptability, constraints and assumptions may differ from the environment where these best practices originated.

I agree that we shouldn't reinvent the wheel. However, I do stress that the wheel should fit properly in order to fulfill its purpose.  

Best practices are excellent if there is cooperation and consistency in an organization from top to bottom. Rigidly imposed processes that are unwanted and misunderstood cause problems and restrict new thinking.

Project managers should use best practices but they should build, fine-tune and improve them to fit an organization. Should best practices become better practices or best-fit practices so they become molded, enhanced and understood by the organization and the people who will benefit from them?

How do you enhance best practices for your projects? Do you think best practices are near perfect? Do you agree or disagree that extra effort should be applied to mold best practices?

How many of your project team members aspire to become project managers? Do you see promise in some of them for this role? How can you impart some of your knowledge and skills to help them be successful?

There are elements of project management in everything that we do. It's your responsibility as the team leader or project manager to point this out to your team members and guide them to see the connections.



A programmer might manage her time and communication, while also helping to develop a module, for example. A junior analyst may manage budget and scope while discussing the change request with the client. Show your team members how the tasks they are performing are also project management practices.

This way, team members can appreciate that the work that they are doing is impacting the project as a whole. If team morale is often low, perhaps members don't see the significance of their work. You can help change their perspective by coaching them to view their contributions differently. 



Not all of your team members will appreciate your efforts. Some of them will feel that it's an interruption of their productive time or that you're meddling in the actual work being done. But by showing the team members how their tasks relate to project management, they will see that project management is present in everything that we do.

And who knows? That skeptical team member could become your organization's next high performing project manager -- thanks to you.

What do you think? Are project team members already performing some tasks of a project manager? How do you coach your team members to become good project managers? 

In most projects, the issue of "advanced payment" vis-à-vis procurement management is very valuable. An advance payment is a prepaid expense from the client, paid to a vendor in advance for goods or services. The balance is paid after a successful project delivery.
 
Advance payments are meant to provide financial aid to the vendor by providing initial funding for jump-starting the project. It also shows financial commitment and project approval from the client.

Advanced payments are beneficial to the supplier, but are very risky for the client because the prepaid goods or services may not get delivered as planned. What if the vendor disappears with the advance payment? This would attack and distort the project's time and cost objectives.

In order to mitigate this project risk, the project manager may request a sort of surety before supplying the required advance payment. Most project managers would settle for an Advance Payment Guarantee (APG) from a reputable bank.

But banks often confuse the main goal of an APG on projects. Many times, the banks take care of operational risk while ignoring the aspirations of managing project risk.
 
For instance, banks in Nigeria, where I work, may request a 100 percent cash backed prerequisite for an APG. The insistence of 100 percent cash backup connotes seizure of the funds, which are meant for the project (as provided by the client).
 
It's good risk management on the bank's part. If the vendor flees with the advance payment, the bank would live up to its guarantees by taking the seized funds back to the client.

To a discerning mind, this antagonizes the essence of project risk management. The funds from an advance payment are primarily meant to be an inflow into the project to mitigate the initial funding challenges of the project. But the vendor would be exposed to sourcing the same funds that had been provided by the client, which would delay the project.

Any bank that is familiar with risk management should be willing to cater to the peculiar needs of the project objectives. There could be other ways of monitoring advance payment disbursement to the vendor as opposed to seizure of the entire funds while still expecting performance with the seized funds.

What do you think? Do you use APGs on your projects? What issues do you face? How do you mitigate the risks of advance payments?

Read more about risk management.

Check out PMI's Communities of Practice for more information about Financial Services Industry and Project Risk Management.

As a project management professional for 20 years, I've managed IT projects in a variety of industries and regions, including North America, Latin America and Europe. Most of the projects were regional or global, and the project teams included members from different nationalities, cultures and generations.

Although complexity was a common denominator in these projects, it wasn't because of technology. It was because the people had what I call the "multi" factor: multinational, multicultural or multigenerational project teams.

The "multi" factor plays an important role in projects, and project managers must be prepared to address team issues related to this phenomenon. I hope to do that here, starting with multigenerational teams.

The multigenerational work force has created what I call the "21st Century Organizational Ecosystem." Many organizations may find themselves dealing with generational clashes between a 60-something program manager, a 40-something project manager, a 30-something project team leader and a 20-something project team member. This could just be one facet of this ecosystem.

Project managers should understand the generational gaps in their project teams at the outset of a project. Identifying those gaps at the beginning enables the project manager to discern the preferred communication methods, interpretation of hierarchy and authority, as well as the perception of personal and work time.

Leading a multigenerational project team can be like riding a roller coaster or a day at the beach. It depends on how quickly project managers can enhance their multigenerational behaviors and values to creating the synergy required to have a successful project team.

How have you experienced the multigenerational factor in project teams? How has working with different generations affected your projects?

See more posts about teams.

This post was updated from its original version, published on 8 July 2011.

I've been employed by the same multinational corporation for the past 27 years. About 15 years ago, I decided that I didn't like feeling like an employee, and decided to adopt the mindset of an independent consultant. Strictly speaking, I was and am still an employee. What changed was my mindset.

I decided to think and behave like an independent consultant while continuing to be an employee of the same corporation.

It's a nice arrangement. I treat my employer as if they were a client, my main client. With a couple of notable exceptions, they've given me steady work.

Since I see myself as an independent project management consultant (even though I am really an employee), I have to think about marketing. If I don't keep the pipeline full, business could dry up. I make sure people know who I am, what my capabilities are and that I stand ready to help them.

I do a lot of business development. I help people "on my own time" so they'll know what I can do for them should they have a need.

I get to know who the decision makers are, who holds the budgets and who has influence.

I keep myself sharp. Sometimes, my client/employer pays for my training and pays me when I take training. Sometimes they cover any travel expenses to take the training. Or, I may take training on my own time and expense to increase skills and my value proposition as an independent consultant.

I interact with others in my profession apart from my client/employer. I belong to a professional organization (PMI) and volunteer with them as a speaker and writer.

When I begin a new project, I approach it as a consultant, looking not only at how I can satisfy the immediate need, but also looking at the potential for follow-on work.

When people I deal with are unpleasant or difficult to work with, I remind myself that they are my client, and will be paying me for my work. It helps keep things in perspective.

I do the occasional "side job" for other clients, but only to the extent that it doesn't result in a conflict of interest.

I don't think I would have the courage to make the career switch to truly be "independent." At least not yet.

I have the utmost respect for those who really are independent. I understand that I don't face the same risks they do, which is why I have such respect for them. I've learned a lot from them and hope to learn more.

But this works for me and seems to combine the best of both worlds. I have the satisfaction of doing work for people who seek me out as a professional, and doing so at a level of risk that I find tolerable.

What do you think? Do you think working as an employee and behaving like a consultant would work for you? Why or why not?

See more posts from Jim.

Get more career help.

You may think that a change control board (CCB) has to be some official project governing body, but it's not so.

A CCB can be a small group of project team members who are willing to review and approve or reject change requests. Even if your projects are small, it's better to have some semblance of a CCB than to have none at all.
 
A CCB can help you manage the myriad changes that will come your way as a project kicks off. Your sponsors, stakeholders and project delivery team may all have agreed on scope, cost and schedule -- but it's inevitable that something will change before the project closes. 

Those changes come in many shapes and will impact your project positively and/or negatively. A CCB helps you figure out which changes are acceptable to undertake, which aren't and which can be shelved.
 
Instead of shunning change or accepting every idea without examination, use the CCB to determine the best course of action for the project. 

There will be times when members of your project delivery team have great ideas for the project, for example. After all, they're right in the mix during the execution phase and can clearly see where things could be improved. If you always shoot those ideas down, you will create strife between yourself and your team.

You may find no one comes to you with great ideas anymore. Part of a CCB's job is to listen to all ideas, carefully consider the merits, and explain to the project team (or stakeholder or sponsor) why an idea was approved, rejected or held until more favorable conditions arise to implement it. 

A CCB can be more than just a repository for tracking changes and a governance tool. A CCB can show team members and stakeholders that their ideas are worthwhile and innovative, and can help foster those ideas that most positively impact a project.

What kind of CCB do you use? What do you have them help you with?

See more posts from Taralyn.

See more posts for new project managers.