Voices on Project Management

> Back to Voices Home

June 2011 Archives

Your Project Stakeholders are Biased!

| | Comments (0) | TrackBacks (0)
Have you ever wondered why communication with senior stakeholders so often breaks down? It's because of the deeply embedded cognitive biases innate to all of us.

Research by behavioral economists has demonstrated people are naturally irrational. The challenge is to accept people as they are and then work rationally within our innate biases.

When your project has an issue that has already caused a cost overrun and needs more expenditure in the short term to potentially recover some of the losses later, you and your stakeholders may experience a bias called loss aversion. Most people will make risky decisions to avoid a loss, but are reluctant to make a decision of exactly equal to achieve an exactly equal gain. And most people also tend to prefer short-term gratification to long-term benefits.

Therefore our natural instinct is a strong bias towards not losing more money -- even if the short-term loss is significantly outweighed by a longer-term gain. The best antidote is a credible communication process that outlines the issues and risks, supported with additional reference materials such as the PMBOK® Guide.

Proximity bias is to prefer our own creations to other people's creations. This tendency is reinforced by what behavioral economists call the "IKEA Effect." The more labor we expend on a project, the more we love the result -- regardless of its quality.
Before your manager expends too much effort on her own solution the problem, you should communicate in a way that allows a jointly crafted solution to develop.

When communicating with senior stakeholders, try to help them resist these biases while working to avoid them yourself. Rather than provide your solution, offer a range of ideas that allows stakeholders to own the solution (with your help). Aim to shift their thinking to a viable benefits-focused solution.
How do you cope with biases among stakeholders?

Read more from Lynda.

Read more on stakeholder management.

Avoiding Friction through Project Management

| | Comments (2) | TrackBacks (0)
It can be an obstacle when project teams encounter friction among members, as it impacts their ability to work together and finish a project successfully. Often, that friction can come from a team member's experience in project management -- or lack thereof.

In my opinion, a great deal of control over the project and its outcome depends on how well a project manager or team member is trained in a well-structured project management environment, whether through formal or on-the-job training.

Truly understanding project management practices and how all the components of it can work and integrate together can save a lot of grief and reduce or avoid friction among the team members. It provides the tools for "winning the game."

Project management provides a pathway to successfully managing a project and its components toward its completion. Any given practice of it is regularly fine-tuned and updated based on the experiences of various project managers and their teams.

Equipped with that understanding, project managers must pay attention when there's friction among team members. Project managers can get team members back on track with the project management practice they use, while allowing the team members to focus on the goal: to deliver results in the area for which they are responsible.

Do you think project management training can impact friction among team members? Why or why not?

See more posts from Dmitri.
See more about professional development.

Project Communications: A Visual Understanding

| | Comments (2) | TrackBacks (0)
The purpose of communicating with any stakeholder is to build his or her understanding of a project. But there is a huge gap between looking at a written message and understanding its contents.

The PMBOK® Guide differentiates between the:

•    Message -- what you want to communicate
•    Medium -- the way you send the message and
•    Noise -- things that interfere with comprehension.

The concept of noise disrupting communication is easy to appreciate when you are talking with a stakeholder, either face-to-face or on the phone. But what many project managers fail to realize is that the same principles apply to written communication.

A significant body of research suggests a well-designed document can communicate up to 80 percent more information to your stakeholder than one that is poorly designed.

Consider these elements when designing your next project document:

Page layout: In most cases, the eye starts naturally at the top left of a page and flows down to the bottom right. Ignoring this flow disrupts the natural reading pattern and reduces comprehension.  

Clutter: Multiple fonts, font sizes and colors may create a great visual impression but fail the communication test. The best combination for text color is a black font on white background.

I find that serif fonts, like Times New Roman, are easiest to read in the body of a document. Sans serif fonts like Ariel look cleaner in headlines. Use one of each with minimal embellishment to reduce noise.

Page design: Leave plenty of white space at the margins, between paragraphs and around images. Place key messages in headlines, use diagrams wisely and caption them effectively.

Designing an effective document layout is an art -- you need to balance creating an attractive document with making the information inside easy to read and understand.

Do you think document design can impact your project's communications with your stakeholders? Why or why not? Tell us about your experience.

Read more posts from Lynda.

Read more posts about project communications.
It's usually up to the sales representatives and executives to pique the interest of potential investors or partners in a project. But program managers are in a prime position to offer unique insights into project proposals:

  • They deal with all the different stakeholders
  • They guide and advise their project managers.
  • They talk with senior management.
Still, many program managers only concern themselves with their immediate work. They don't think about the bigger picture. There's no discussion on what this project may lead to or what future business benefits it will bring to the organization.

But program managers should also be justifying and arguing the long-term benefits of their new projects -- not relying on others to do that for them. 

Program managers have a duty to do more than ensure projects under their supervision are completed on time and on budget. Program managers have a lot more authority and opportunity -- and therefore responsibility -- to further the strategic objectives of their organization than a project manager. 

Program managers need to realize they're a catalyst -- someone who should be open to new opportunities, ready to explore new business ideas and enable their organization to move forward. From this viewpoint, program managers resemble salespeople. They have a duty to sell a vision for the future to their senior management and all their stakeholders.

What do you think? Should program managers act as salespeople, too?

Read more posts from Roger.

Find out more about the Program Management Professional (PgMP)®credential.

Project Management at Work -- And in Life

| | Comments (6) | TrackBacks (0)
Let's face it -- although we may not see ourselves as the great organizers we'd like to be, we are often more organized in our projects in the workplace than we are at home in our own lives.

Of course we're trained to do what we do at work, which isn't always the case for everyday life. We seek out specialized training for our field, and then we get to obtain certifications and credentials, continue our education and earn professional development units (PDUs) to maintain our designation. Meanwhile, there's no training for how to live an organized life.

Having project management knowledge allows us to be better project managers in our lives -- not just in our workplace. Indeed, project management processes can be applied to life's personal projects and activities.  

When I was studying for my Certified Associate in Project Management (CAPM)® certification, for example, I realized that my knowledge of the PMBOK® Guide applied to everything I was up to -- not just the management of projects at work. I became more organized. I worked on more projects of my own and had structure that allowed me to progress faster, and with better concrete results and more confidence.

All that came from this preparation. When I obtained my CAPM®, I was convinced that every single person that worked in the office could benefit from this education and certification, including project managers, project team members or department members that don't even work on large projects.

How do you apply project management principles to your life?

See more on PMI certifications.

See more posts from Dmitri.

The Value of Project Team Rituals

| | Comments (7) | TrackBacks (0)
A couple of small projects happening in my neighborhood of South Melbourne, Australia have me wondering about the value of many of the trappings and rituals we use in our projects. Do they contribute value to the stakeholder community or not?

One project involved resurfacing a small section of road. The crew turned up with their trucks and road-making equipment, finished the job and left. For the two days needed to complete the job, the workers brought their own lunches or went to a local café.

On the next corner, a production company was doing a shoot for a segment of a TV cop show. They spent a day setting up tents, canteens and support vehicles. They brought a cast of hundreds, including security and canteen staff. Over two days, the cast and crew rehearsed and shot the segment.

The difference between the two worksites had far more to do with ritual-based traditions and stakeholder expectations than actual needs. The facilities provided for road crew were lean. By comparison, the facilities provided for the TV crew were luxurious but possibly necessary to attract the right "talent."

Rituals can certainly be very powerful ways to build identity and cohesiveness in a team. Many rituals, however, may have simply become time-consuming habits.

A good example is the monthly executive review of all projects that has never resulted in a single canceled a project. Another is the Thursday morning team meeting that is called for no other reason than because it's Thursday.

Take a look at the rituals associated with your projects and ask how many of the meetings and processes add real value to the stakeholders involved.

How many should be refined, redefined or altogether abandoned?

What are the most valuable rituals for you and your stakeholders?

See more posts from Lynda Bourne.

See more posts on project teams.

Project Managers in the C-Suite

| | Comments (13) | TrackBacks (0)
I've seen some articles and heard some commentary lately that lament the fact that there doesn't seem to be a clear career path that leads from project management to the so-called C-suite, also known as the "executive suite."

Where I work, there is no direct path that leads from project management to the executive ranks. Occasionally, a person who has worked as a project manager becomes an executive, but it's certainly not the norm.

From my own point of view, this isn't a problem -- on the contrary. Had I wanted to be a "line" executive, I would have stayed in line management. I chose project management because I saw it as a means to manage the kind of work that I really enjoy most: the realization of ideas.

For me, career growth means managing projects that are more important, more valuable, more interesting or just more fun. Often, this can mean bigger teams and bigger budgets, but for me, that doesn't necessarily translate into bigger thrills. Career growth does not mean at all that I need to become an executive to feel fulfilled.

I see project management and executive management as complementary, but very different, skills. To me, that means that the two fields will appeal to two very different kinds of people, depending on individual temperament.

Project management is very tactically focused. It's all about defining the job and getting it done. It seems reasonable to me that the kind of person who manages projects is also tactically focused, and temperamentally oriented toward the realization of ideas.

On the other hand, I see executive management as more strategically focused, more about defining a strategic vision and deciding which projects to undertake to realize that vision. It seems reasonable to me that the kind of person who becomes an executive is also strategically focused, and temperamentally oriented toward defining strategy and how to achieve it.

What do you think?

Are project managers under-represented in the executive ranks? If this is true, do you see this as a problem, generally speaking? Personally speaking?

Do you have aspirations to become an executive? If so, do you see being a project manager as an obstacle to those aspirations?

Do you believe that project managers are temperamentally different than line managers? Why or why not?

Read more posts from Jim De Piante.
Read more posts about improving your career.

What Do You Look for in a Collaboration Tool?

| | Comments (3) | TrackBacks (0)
With so many project management collaboration tools out there, what is a useful, intuitive and inexpensive tool to use? It all depends on what you look for in a tool.

I look for the ability to assign tasks to team members or teams. I also like to be able to add notes and collaborate with team members through the tool, specific to the tasks they're assigned or the work they are doing. These capabilities cut through many unnecessary meetings and allow you to see real-time progress of the assigned work.

I use a web-based software called IntervalsTM. I create my projects and tasks, and then add my team to the projects and assign each of them their respective tasks. While I may create an MS Project-based project plan, I would use Intervals to manage the actual tasks, time and budget.

It's also a great tool for assessing how much time various tasks take and getting a more accurate measure of the time spent on the tasks. This tool has built-in timers for each task and general timers that make it easy to track your time.

Timesheet management is quite easy as well. I get my team to submit the hours they spent on a regular basis. At the end of the week, they submit their timesheet, which I either approve or reject -- it all happens online.

Another great feature is the executive role, which allows an executive or sponsor to see the latest progress on a project without having to be involved in any other details. The progress can be seen at any time online, by anyone provided such access.

What are your favorite collaboration tools? Are there any tools you use that achieve all these abilities?

The views expressed within the PMI Voices on Project Management blog are contributed from external sources and do not necessarily reflect the views and opinions of PMI.

Avoid the Agile Logjam

| | Comments (3) | TrackBacks (0)
Not all Agile teams are created equal.

Some commit to their work and complete requirements throughout -- not just at the end.

Other teams struggle. Their sub-tasks may make progress, but their overall requirements or "stories," which express requirements in ways that customers can relate to, seem to get stuck. They finish on the last day of the iteration, if at all.

What makes these teams different?

Often requirements haven't been sub-divided. Queuing theory teaches that the same amount of work divided into smaller pieces flows faster. Teams with stories divided into work durations of one to three days see their work fly through the system. They can finish some requirements and then pick more.
Teams with stories that take a week or more are at risk of a traffic jam. Moreover, we're less aware of the delay until later -- when it's harder to take corrective action.
One correction is to refocus on a smaller number of requirements, but dedicate to finishing those. Another method is to split a story, even though the iteration is underway. Or, remove a story from the current iteration so it can be fully completed in another.
If none of these ideas seem enough, make sure the team is committed. Per the principles in the Agile Manifesto, team members need to self-organize to dedicate themselves to finishing whatever work is planned.

How have you avoided Agile traffic jams in your projects? Has splitting stories to a manageable size helped avoid bottlenecks?

About This Blog

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

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

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

Read blogger profiles

Voices Poll