Voices on Project Management

> Back to Voices Home

December 2010 Archives

Implementing Difficult Decisions

| | Comments (1) | TrackBacks (0)
In my last post, I asked what you would do as a project manager if, hypothetically, two key team members could no longer work together after ending their romantic relationship.

Some suggested avoiding the issue, but while that may buy you some time, it doesn't get to the root cause.

Others suggested confronting the problem. Using a proactive problem-solving approach reframes the issues, engages others in the solution and creates opportunities for an all-around positive outcome. Yet unfortunately some conflicts are virtually unsolvable and an important part of a problem solver's role is to recognize this.

I can't tell you what to do, but I can suggest how to handle this. Most dilemmas involve deciding which is the least damaging of the alternatives. But the nasty thing with dilemmas is that making no decision is almost always worse than the most terrible outcome from any of the other options. You have to decide something to minimize the overall damage.

So first, make a call and then seek support of your decision from your senior managers. When you're "advising upward," you must succinctly lay out the facts, your interpretation of the facts and the steps leading to the decision. Then your managers can make an informed decision to support you or to suggest alternatives.

After gaining the necessary support, you have to implement the decision. It will be unpleasant and stressful, but such is the nature of the situation. As an ethical leader, you need to take responsibility for the bad and the good in your project.  

If you handle a situation like this decisively, but also with empathy and consideration for others, you'll find your team's respect and support for you as a leader will be enhanced.

Power Without Authority

| | Comments (7) | TrackBacks (0)

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.

How Do You Define a Successful Project Management Career?

| | Comments (2) | TrackBacks (0)
The criteria for what constitutes a successful project are pretty clear: full scope delivered on time and within budget.

Consider how a "failed" project is characterized: Press reports of conspicuous project failures declare "the project was several years late." Or, "the project overspent by so many millions of dollars."

But what does it mean to say that a project was late? Late with respect to what, some arbitrary date by which all such projects are supposed to be completed?

And what does it mean to say that a project overspent? Overspent with respect to what? Some arbitrary amount that all such projects are supposed to spend?

The fact is that both of these values -- project completion dates and the budget -- are not arbitrary in the least. These values are determined by the same person who is responsible to not exceed them: the project manager.

Let's look at that. The project manager determines the project completion date and the budget. The project manager then manages the project so as to not exceed those values.

Why, then, should a project ever be late or over budget? Think about it. We have it made! We get to say when and how much -- we simply have to meet those commitments. Our destiny is in our own hands. How can we fail?

And yet ... we fail.

I can hear the rebuttal now: "The schedule and budget were imposed by management, or the client or the sponsor." No they were not. You were given "targets." If you accept those "targets" as your budget and schedule commitments, you are setting yourself up for failure.

As the project manager, you are responsible for determining the schedule and the budget. If you cannot bring them both in line with targets, the sooner you say so, the better.

Success also means not failing. Quickly killing a project that will never meet targets is a good way to avoid failure. Alternatively, you can negotiate changes in targets for scope, schedule and budget so that it's possible to succeed.

Regardless of your personal criteria for a successful career, success as a project manager implies success in managing projects -- and that means meeting commitments that you make.

How do you define a successful project management career?

A New Take on Standup Meetings

| | Comments (5) | TrackBacks (0)
Short daily meetings are a cornerstone of agile project management.

Team members usually address three questions:

1.    What did they do yesterday?
2.    What will they do today?
3.    What roadblocks stand in their way?

Some teams use an alternate format with a quicker flow. Looking at a task board, an appropriate team member says how many hours are left on each task. Once a task is complete, it's moved to the next state (test or done).

If the team has capacity to take on more tasks, another one is pulled from the queue. At the end of the meeting, the team can see if someone needs work, can help another person or determine if there are any hindrances.

This meeting format emphasizes little wins as tasks are moved from state to state. People get some positive feedback and congratulate each other -- which is important to the long-term functionality of the team.

This type of meeting also keeps people from discussing work not related to the teams' tasks. It still allows space to discuss impediments and team utilization -- but only if necessary.

Teams using this approach can complete their daily 15-minute standup meeting in 10 minutes. More importantly, there's a feel of energy and drive in such meetings. 

The three-question format is tried and true. If you find your meetings feel sluggish, give this format a try. You may find it turbo-charges your meetings.

Which approach do you prefer?

Managing Projects and Teams with Velocity

| | Comments (3) | TrackBacks (0)
Velocity measures the rate of motion. In the context of projects, velocity is about teams accomplishing work faster, with less resources, better quality and greater satisfaction.

As project teams get used to each other and adjust to the organization's processes, culture and communication methodology, team members' potential for contribution increases. As team engagement increases and members align themselves toward the goals and objectives of the project, overall performance increases.

Velocity is achieved when team interactions are completely in sync with the project goals, the rationality behind the target dates and the planning it takes to meet those dates.

In a project environment conducive to velocity:

•    There's a clear direction, everyone's roles are clarified and there's flexibility for team members to contribute in other parts as appropriate.

•    Members manage their own time, guided by their mandates or objectives.

•    Teams choose their own method of communication. It could be acquired from other similar projects or specifically designed for the given team.

•    Team interactions -- phone calls, meetings, workshops, etc.-- are managed as the needs arise, rather than "boxing" teams into preset parameters.

On a project with velocity, the force behind the team executing the work gets to be so powerful that it's not the project manager who ends up giving the power to the team. The team itself generates that power and project execution moves with subsequent velocity.

Are you managing with velocity?

Project Management: An Organizational Competency

| | Comments (7) | TrackBacks (0)
Competency-based management is a tactic that some organizations are using to recruit, hire, train, develop and manage employees.

Competencies are sorted out in three categories:

Organizational competencies combine the skills, information, performance measures and the corporate culture that an organization uses to achieve its mission. All employees must demonstrate these proficiencies.
 
Job role competencies include the abilities needed to perform a specific role in the organization. A field supervisor, for example, must have similar skills to supervisors in accounting, customer care or sales. Although they are in different department functions, they must exhibit a common set of supervising skills.
 
Position competencies are specific to the position you perform in your organization. An account manager, for example, must demonstrate capabilities that include proficiency in sales. An IT support engineer, for example, must be a master supporting the core systems an organization uses.
 
It's common for organizations to think project management is a skill at the position level and that it is just for project managers.

The reality is that project management is an organizational competency. If organizational strategy drives strategic changes and those changes are executed as projects, project management must be an organizational capability rather than a job skill.
 
If project management is an organizational competency, it's required to define a training program within the organization to develop everyone's project management knowledge and abilities.

I suggest starting with an awareness meeting for all employees. Once that's completed, host specific teaching sessions for executives who will support projects and then for people who participate in projects. Both must deliver non-technical project management knowledge.
 
What do you think? Is project management an organizational competency?

When Is Program Management the Right Choice?

| | Comments (6) | TrackBacks (0)
Project managers often ask me: When is a program needed? Under what circumstances is program management appropriate? What's the difference between running multiple projects at the same time and running a program? 
 
In terms of delivering a benefit or generating a synergistic outcome, program management can help. This is especially true when you're managing interdependent projects.
 
Say you're running four projects at the same time: a hardware development project, a 3-D character animation project, an exterior design project and a controller project for a game console.

You can indeed manage these four projects separately with shared resources and technologies. But if two of the projects come from the same client, you should have a program.

Or if your company plans to own the game console -- which requires you to produce a product by integrating the deliverables of each individual project -- you need a program.
 
Take Nintendo's Wii. Development of the console definitely calls for the centralized, coordinated management of a program, or at least, a program-like logic to run it.

Making the Wii requires coordinating the component supply, system coding, and exterior and hardware design, including the controller. There is also storyboard planning for plots and characters for Nintendo-owned licenses to help launch the console, layouts for different language versions, etc.

Of course, the design and production of each specialized component will have to be done through individual projects. Yet they end up being part of a wider program because they are interdependent with all the other components for the final console.

A program is also necessary because to deliver the final console on schedule, a greater degree of governance has to be used. It must ensure that the projects run as planned so individual delays do not hamper the overall output of the program: a finished, completed Wii console.   
 
What do you think? How do you know when program management is your best option?

When Project Decisions Get Difficult

| | Comments (12) | TrackBacks (0)
Two important members of your project team recently ended a six-year romantic relationship. While they're both trying to keep their domestic problems out of the workplace, the inevitable tensions between the two ex-partners are obvious and are causing the team to split into two camps.

The situation is affecting the team's ability to achieve a successful outcome on a high-stakes, high-pressure project to deliver critical capabilities to a customer.

You've tried working with both team members and sought assistance from the HR department to minimize the issues with limited success. Each of them is vital to the delivery of the project's objectives. However, you've suggested to both that perhaps the team would be better off if one of them moved onto another job. Unfortunately, neither have a viable option.  

Your analysis of the situation is as follows:

If either of the people leaves, the team's ability to deliver the project will be reduced by 10 percent.

If both of them leave, the team's ability to deliver the project will be reduced by 20 percent.

If both stay, the team's ability to deliver the project will be reduced by 25 percent and will get worse over time.

The customer cannot afford any reduction in the team's capability to deliver this business-critical outcome.

As the project manager, what would you do next? Post your comments below, and in my next blog, I'll summarize reader reactions and look at the options.

PMOs Shouldn't Forget the Project Manager

| | Comments (0) | TrackBacks (0)
A project management office (PMO) usually follows one of three styles:

  1. The directive PMO manages projects by using the project management team that's part of the PMO.
  2. The supportive PMO generally provides help in the form of on-demand expertise, templates, best practices and expertise.
  3. The controlling PMO offers guidance and discipline with an aim to improve by standardizing the process and method.
The reality is that very few PMOs are just one of these types -- they are a mix of two or three. In my own PMO, we blend a strong focus on support with an offering of control to those project managers who need our help.

We aim to avoid direct ownership of projects except in specific cases, such as when the project is located where local project capability is low or the project has gone badly wrong. In this latter case, we aim to "own" the project for as short a time as possible and always develop a transition plan back to the original project manager if possible.

The PMO should generally not be considered the "mother of all project managers." Rather, it should be seen as the body that helps develop the best project managers -- the ones who are facing stakeholders on a day-to-day basis, the ones experiencing the meeting of theory and practice.

A PMO can:
 

  • Replace a deficient project management process with a standard process and best practices

  • Save considerable costs against project management overheads, such as training and certification

  • Create a community of project managers and bring teams and processes together to maximize the shared knowledge and engender a spirit of cooperative working

  • Market its overall successes and spread the word about the great job its project managers are doing

  • Work closely with a business to align projects with strategy

  • Be a fantastic source of knowledge and a great safety net
A PMO can do many, many things -- and a PMO is a really good idea. But at the end of the day, project responsibility and ownership still lies with the person best equipped to do the job: the project manager.

Let's not forget the project manager.

About This Blog

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

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

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

Read blogger profiles

Voices Poll

Categories