Voices on Project Management

Editor's note: The title of this post was changed on 9 December 2011.

Do you make time to identify your requirements for managing a project? Sure, you plan and manage the project, but as a program or project manager do you also identify your needs for running the project and the team?

It's important to know what we require of our team and stakeholders. When these needs are clearly identified and communicated, it's easier to track and manage the related project tasks and variables.

For example, I recommend that you require your stakeholders to attend meetings and give input during the change management process. You'll need the decision makers to assist you in evaluating the need for change.

When you set and express this participation as a requirement, your stakeholders understand your requirements and their own importance. Further, when a change is requested during the project, it doesn't come as a surprise that you expect stakeholders to be involved in the process.

When it comes to your project team, maybe you require team members to be on time for meetings and to submit progress updates. Communicating this as a need and setting the expectation helps ensure that team members give timely feedback when needed. When team members meet this particular need, you're able to meet your own deadlines with the customer.

Setting and communicating project management requirements are nothing new. For the most part, these needs are automatically expected from everyone involved in the project. But failure to pen down and communicate each need usually leads to more project challenges. For example, team members may start to argue, finger-point or shake off their responsibilities. There's also the possibility of missing a milestone -- and that's something to avoid.

Take time as the project manager to set your requirements for running the project. And do so as a high priority.

What requirements do you establish for managing a project? Do you communicate these to the project team and stakeholders?

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?

I'm sure many of you heard about the Boeing 787 Dreamliner that made its first commercial journey on 26 October. It is the most technologically advanced commercial airplane and enables air travel that is cheaper, faster and more comfortable.

Perhaps you also heard about the process, communications and quality issues that delayed the project by three years and cost the company close to US$10 billion in overrun charges, according to the business news outlet Bloomberg.

As a project manager, what jumps out to me is the fortitude of Boeing's management to ensure a quality product -- despite extraordinary pressure.

I have no doubt that if it had wanted to, Boeing could have completed this project earlier. But rather than take shortcuts and risk potential issues, it held out for a product that met its standards.

Much attention has focused on Boeing's attempts to save money and to secure global accounts by outsourcing a large portion of its component manufacturing and design. The idea was that assembly and time to market would be accelerated by allowing various parts of the plane to be flown to Boeing's facility in Seattle, Washington, USA. There, they could be pieced together in order. According to news reports, the move initially netted Boeing nearly 1,000 orders and helped keep its prime competitor, Airbus, at bay.

But it marked a big change in Boeing's existing process to keep almost all of its engineering design in-house. The company typically delivers very specific "build-to-order" instructions to its manufacturing partners, outlining specifications and direction, and then collaboratively designing the parts.

There were many challenges associated with a project as complex and pioneering as the Dreamliner project. One example is the process for oversight and quality control of multiple, globally based contractors. Issues arose, such as contractors subcontracting to suppliers who couldn't meet deadlines or quotas. In other cases, contractors shipped parts that wouldn't fit together correctly.

Think about it: In my opinion, Boeing realized that it was more important to get the project done right versus done fast. And while the company has faced criticism, suffered some embarrassment and, yes, spent more than it anticipated, these are all short-term issues. 

In the long run, I believe the project will bolster Boeing's reputation for quality. It will also have finely tuned a project management process that should bring the company much higher returns in the future.

See more posts from Geoff.