Strategic Project Management

Project management has too many acronyms.

PM, PPM, PMBOK, SCRUM, PMP, ACWP, BAC, BCWP, BOM, CPF, CFF, PDM, PMO, WBS, SWOT, TQM... you get the picture. We even have a unique way of using terms like "resource" or "resources" that doesn't make sense to many people outside of the profession. Is it any wonder people don't get what project managers do?

Whenever I talk to someone who isn't a "PM" or doesn't work in the "PMO" about what it is we do, I have to choose my words carefully or they don't even have a chance of understanding what I'm talking about. Take "resource management" for example. "What is resource management?" they might ask.

As I explain that we consider the people who work on project teams part of the "resources" associated with getting the work done. The response is usually something like, "So you call people resources? People aren't things."

They're right.

Steven Covey would argue that people can't be managed—only things can be managed. "The greatest tragedy of our time is that many so-called business leaders confuse management with leadership. Business schools have been excellent at equipping would-be business leaders to completely manage costs, cash flows, stocks, machinery, and so on. This is very correct. Things lend themselves to management because they can be controlled. 'Things' do not have choices. Extending the principles of managing costs, cash flows and stocks to people yields disastrous results. That's why many so-called business leaders resort to 'turning people into things' so they can manage them."

As project leaders, I think it's important to remember that words have meanings, and how we use our words really does make a difference in how we are perceived, the words we use form the way we perceive the world around us and even how we perceive others. If we de-humanize the people we work with by the language we use, I think that has a subconscious effect on how we ultimately relate to them.

I'm not sure what term would be better than resource management, but I know that I try to avoid calling the members of my team "resources" as much as I can. In project environments (or any work environment for that matter) we rely on people to actually get things done. Empowering people to maximize their contribution to something worthwhile, to create and invent, should be our goal. I know that many of you might be saying, "What difference does it make if we call them resources?"

Except for the fact that they are people, I guess it doesn't make any difference at all. Or does it?
 

Before I started my ride on Saturday, I washed and polished  my bike and prepared for a few hours in the saddle. Taking time to clean the motorcycle gives me an opportunity to inspect it and make sure that there are no glaring issues in need of attention. One of the things I like to keep a pretty close eye on are my tires. Tire condition is a pretty important indicator of the safety of your next ride. I can think of few things worse than a blow-out at 70 mph going around a corner on the highway. After Saturday morning's inspection, it looks like I'll be setting up an appointment for a new rear tire this week.

As project leaders, there are also subtle indicators that can give a savvy project manager an idea of how the team is performing—before a blow-out. Last spring I wrote about some of the early warning signs of a project in trouble, the equivalent of checking the tires and inspecting the bike before a ride. Although I think this list applies to almost every project, I'm sure there are some warning signs that are unique to your team. As a project leader, you should identify what they are and regularly monitor them to make sure that everyone is operating at peak performance.

Please feel to share some of the early warning signs you watch out for.
 

The Russian writer and physician Anton Pavlovich Chekhov once said, "One must be a god to be able to tell successes from failures without making a mistake."

Where projects are concerned that is often the case. Recently, a colleague and I were discussing the Standish Group's Chaos report and debating whether or not their definition of project failure is really accurate. Although I agree that if a project fails to deliver the anticipated value, takes longer than expected or costs more than is budgeted I think it's safe to say that it wasn't a success—but does that also make it a failure?

Sometimes.

Yeah, I'm weaseling a little bit here. However there have been some pretty high-profile failures that turned out to be anything but failures. Take Columbus for instance, he was looking for a quick route to India and found the New World. Was he successful at finding India by going West, no. Was it a failure?

Sometimes I think projects are doomed to meet the Standish Group's definition of failure from the start. Stakeholders and sponsors aren't clear with their expectations, project leaders are handicapped with unrealistic time-lines and project teams are woefully understaffed. When these conditions exist, is it any wonder that a project team struggles to hit a moving target with a broken bow and arrow?

With that in mind, let me make a couple of suggestions that might help keep your projects out of the "failed" category (at least according to the Standish Group's definition):

1. Define Success: This sounds pretty simple, maybe even too simple. Nonetheless, how many projects have you been a part of that didn't have a clear definition of what success was before it started? Imagine shooting a basketball at a hoop that randomly moved during the game. It's tough for project teams to hit a moving target.
2. If the Scope Changes, So Should the Definition of Success: I'm not a big fan of willy-nilly changes in the scope of a project, but if there are compelling reasons (other than the team is trying to reduce requirements to meet a deadline—which would indicate "failure" in my opinion) to change the scope or requirements, it's not accurate to call the project a failure if it costs more or takes longer to finish.
3. Be Honest and Engage the Team in Resource Estimates: Arbitrary deadlines just don't make sense and should be avoided at all costs. One of the things I like about the SCRUM methodology is the Sprint Planning Meeting. The team estimates resource requirements and takes ownership of their estimates. For project managers, this type of approach makes sense to me. Those closest to the work understand it the best and should be involved in making decisions about the time-line. What's more, giving the boss the time-line he or she wants because he or she wants it isn't a good idea if it's not realistic—and sets the team up for failure.
4. Build the Right Team: Just because someone is available doesn't mean that they are the person for the team. I know that many project managers don't have the luxury of picking their team, but can exert influence over who is or isn't part of the group.

Of course there is no silver bullet to avoiding the "failure" category. I've participated in discussions that suggest (for a number of reasons) that the Chaos information is inaccurate. Even if the actually results are 50 percent better than reported, it's still too many failures. As project leaders, our job is to help get things done—successfully. That being said, what do you do to ensure project success?

Over the last several months (if not the last year) I've expressed my concerns about the potential for a mass talent migration from organizations who have compelled the workforce to work and produce more for less. Anecdotally, I know of a number of people who are very frustrated at the hamster wheel the feel they are on. They complain that every day there is another crisis that requires them to work extra hours and feel extra stress. Although I agree (and support the notion) that there are times when it's important to put in some extra effort, when crunch time becomes all the time—I think there is something wrong.

In an article published on the Grapevine, Owen Morgan asks, "So why are so many employees currently thinking about changing employers—and at a time of such economic uncertainty?"

I don't know if you are seeing this in your organization or among the members of your project teams, but I predict that this could become a pretty big problem for many organizations who depend on their people to create and innovate. Which is why I ask the question, "Does it really matter if it's not your career?"

I think it does.

I work with a colleague who is a very talented and capable manager. One night last week as we were getting ready to leave the office, he commented that he felt like part of his responsibility as a leader was to help advance the career of those who worked on his team. Although I have never articulated it that way, I have to agree. In fact, some of the accomplishments I'm most proud of involve helping individuals on my team advance and succeed in their careers.

"Development is the key word here—while many employees will claim that another role offers greater rewards," writes Morgan. "In many cases these are unlikely to be solely of a financial nature. It's well known that people move roles for a variety of reasons, but the search for new experiences and challenges is often foremost among them—doubly so for those who are driven, innovate and unprepared to accept the status-quo—just the sort of people that organizations cannot afford to lose and who will be able to help their employer through the challenging times that lie ahead."

I'm convinced that people are less motivated by money than we might think. However, that doesn't mean that we can get away with poor pay and poor benefits. What it does mean is that if you're not the New York Yankees, you can still build a championship baseball team (without buying it).

In other words, according to Morgan, "Most forward-thinking organizations have identified their talent and even though some development opportunities are likely to have fallen along the wayside, effective and open conversations between line managers and their teams, articulating the importance of an individual to the future success of the organization can work wonders. Truly effective managers rise to the challenge here, and at the same time as ensuring that the team is deployed to achieve the short and medium-term organizational objectives that are set, they never lose sight of the longer term and how their individual team members might play a part in it."

Unfortunately, this type of behavior seems to the be the exception rather than the rule. Do the members of your project team know that you value what they do and that their contributions to the team are important to the success of your organization? If they don't, it might be time to do something about it.

In a nutshell, Morgan sums it up this way, "So telling people they have a career with their current employer and not just a job can reduce the instances of those looking to leave."

This doesn't mean that I'm advocating that we tell our team members that we expect them to treat what they do as more than a job. That will happen naturally when we treat them as something more than mindless employees compelled to do mindless tasks.

Does it matter if it's not your career? It absolutely does.
 

From April 3, 1860 to October of 1861 the Pony Express carried mail from St. Joseph, Missouri to Sacramento, California. Before the telegraph, the Pony Express was the most direct means to send a message to points west. During the 18 months the the Pony Express operated, it reduced the time it took for mail to reach California from weeks or months to about ten days. It was state of the art for its day. However, I don't think anyone uses the Pony Express anymore.

Over the Labor Day weekend, I spent a little time on the bike and one of my rides crossed the old Pony Express route. It is a pretty lonely road now, I can only imagine what it must have been like in 1861. I also thought about how communication technology has developed since the days of mounted couriers racing across the desert.

Needless to say, email, text messaging, and instant messaging (and don't forget telecommunications) have changed the way we communicate with each other. Although I didn't check, I'm sure when I was out on the old Pony Express route, I could have taken my cell phone out of my pocket and called home—what a difference 140 some odd years makes.

The big question for us now is, "What's the best way to communicate and collaborate with our project teams?"

I wish I had the magic bullet answer.

If you're like me, email is a very big part of your day. I probably spend about as much time in email as I do any other application on my computer. I also have a text messenger up all the time and my desk phone and cell phone are right next to my computer—not to mention the opportunity to walk over to the next desk and have a conversation. Needless to say, I am very connected (there are also a number of people I communicate with regularly through my project management software, Facebook, Google+ and Twitter). I have found that depending upon the type of communication, what I'm communicating about and who I'm communicating with, I tend to choose the most appropriate method for sending and receiving messages.

As project leaders, we have a lot of communication tools at our fingertips (we also have teams spread around the world). Choosing the right communication and collaboration methods to help our project teams get work done is critical to project success. How do you determine the best way to share information and collaborate with your team?