Strategic Project Management

I think most project leaders would agree that a big part of managing work is making decisions. Like most of you, I've worked with great decision-makers as well as some really bad decision-makers. Scott Adams, the creator of the Dilbert comic strip once said, "Informed decision-making comes from a long tradition of guessing and then blaming others for inadequate results."

Adams description of how decisions are made might be accurate for many organizations. Over the years of my career I've noticed that many organizations don't foster good decision-making practices—handicapping project leaders, project teams, and their organizations. The answers to the following three questions will help your organization foster a workable decision-making process:

1. Who? Prior to the beginning of any project, determining who has decision-making power is the first step. Of course, on most projects there will likely be several decision makers.
2. What? Different members of the team will probably have different decision-making responsibilities based upon their role. Identifying the scope of everyone's responsibility regarding the type of decisions they can and can't make avoids confusion and makes it possible to streamline the process. Nobody wants to "Mother, may I?" every move they make, nor should the project manager or stakeholder be expected to make every decision.
3. How? Identifying how decisions are made and how they are shared with project team members is almost as important as the decision itself.

Regardless of your work management methods or the project management tools you use, making project decisions is part of a project leader's job. What's more, it's been said that in-decisions becomes decision with time.

The Chinese philosopher Confucius suggested, "By three methods we may learn wisdom: First, by reflection, which is the noblest; Second: by imitation, which is the easiest; and Third, by experience which is the bitterest."

I don't think there's anyone who has to make decisions on a regular basis that wouldn't agree with Mr. Confucius. What are you doing to foster a good decision-making environment?

Research Participants Needed:

The @task product management team is currently looking for working Project Managers (both PMP certified and "accidental" project managers) who would be willing to participate in a 30-45 minute interview. Topics of discussion will cover general project management activities such as: project monitoring, communicating status, managing personal work, and managing ad hoc or lightweight initiatives. @task will use this information to create a new generation of project management tools to actually solve the core business problems faced by PMs. If you are interested in sharing your input, confidentially comment to the blog with your contact information (we won't publish the comment).

When I was a kid, whenever my sister and I would argue, my mother would say, "If you can't say anything nice, don't say anything at all." Although that was probably good advice for keeping two young siblings from killing each other, I wonder if that's the best way to keep projects on track.

Sometimes there are things that need to be said, even if they're painful to hear.

One of my favorite blogs to read is The Critical Path by Derek Huether. Derek provides a great perspective and is an interesting and informative writer. In his blog yesterday he shared that he would be writing an article for PM Network magazine, to which he was asked not to write anything about the current program he is advising. "I was asked not to write anything disparaging about the program I'm advising," he said. "I was told it would be bad if anything I said or wrote cast an unfavorable light on the project."

Like Derek, I think we need to honestly ask ourselves, "How many of you out there in the industry have perfect projects, where nothing goes wrong?"

I have to admit, that I can't even think of the last project that I was a part of that didn't at least have a hic-up or two. Adapting to challenges and overcoming obstacles is what managing projects is all about. With that in mind, Derek has decided to call his current program, "Project Voldemort," the project "that-must-not-be-named." It made me smile—and frown.

Until organizations are willing to face the challenges (and warts) of their projects and allow project leaders to acknowledge what's broken and work to fix it, we will continue to have failed projects and shot messengers. In the trenches, at the project level, I think we all realize that perfect projects just don't exist. What's more, I don't think that negatively reflects on project teams. I think it's the nature of the beast. In my opinion, every organization has to deal with a "Project Voldemort" or two. However, the more the project "that-must-not-be-named" stays in the shadows, the more powerful and dangerous it becomes.

Thanks for the great post Derek. So if the project is "Voldemort" what does that make you?
 

I call them "drive-by" projects.

Basically, "drive-by" projects are all those ad-hoc tasks or initiatives that get dropped in your lap at random intervals every day. They suck up time, they suck up resources, they distract project teams, and have the potential to push active projects behind schedule. Often they are emergency projects that have no strategic initiative attached to them, which is critical for organizations that rely on project-based work to keep teams focused on the right projects.

Don't get me wrong. I'm not suggesting that they are of no value. In fact, it's not always about separating the good projects from the bad projects. It's usually a matter of choosing the best projects, the projects that will provide the most business value from a list of good potential projects. Unfortunately, when project teams are faced with dealing with a "drive-by" project, all the work to keep teams focused on those initiatives that drive the most business value gets thrown out the window.

I believe that's why the "get'er done" or "drive-by" project is such a problem. They may be worthy, but if they don't measure up to the "does this provide the most value" test, they ultimately limit an organization's capacity to work on the things that do. And that negatively impacts productivity—and ultimately profitability.

In theory, everyone agrees with this, however, practice is something different. In the heat of the moment, it's difficult for decision-makers to step back and ask the question, "Will this "drive-by" project provide enough value that someone should drop what he or she is doing to work on it?" Sometimes the answer is definitely yes, but there are times when the answer should be NO. If nobody asks the question, project teams can be chasing around working on projects of minimal value (at least projects that haven't be vetted to make sure they are the best projects for teams to be working on).

Project and portfolio management best practices revolve around the concept of identifying those projects that meet certain criteria, creating a plan, and then executing on the plan. Project management software does a pretty good job of helping do that. However, sometimes we need to ask ourselves, "How does my work management methodology address 'drive-by' tasks and projects that come up every day?"

It doesn't have to be a catastrophic failure that causes an organization to falter. Sometimes it's the accumulated weight of a thousand insignificant inefficiencies that cause the most damage. How does your work management methodology address the "drive-by" project? Even if your software doesn't, feel free to share what you do to keep your project teams focused on the right projects.


 

In his book Shop Class as Soulcraft, Matthew Crawford cites a classic psychology experiment that I think is worth considering:
 

I'm not suggesting (nor do I believe that Crawford is suggesting) that the only way for people to be fully engaged in what they are doing is for them to be "recreating" all the time. However, I am suggesting that money (although important to all of us) isn't the only thing that keeps people motivated and engaged. In fact, I've observed that those who enter any particular profession strictly for its income potential eventually become discouraged and dis-engaged.

So what are we to do? Specifically, what are we to do concerning project teams?

In my opinion, how people are compensated for what they do says a couple of things:

1. Your contribution is valued by the organization, and
2. I, as your manager, value what you do

That being said, I believe that is only half of the equation. As project leaders, I think it's important to create an environment where people can acquire the sense that what they do has value beyond the particular tasks that they may be involved in. I'm a big proponent of making sure that everyone has visibility into organizational goals and objectives. Part of the reason I feel that way is because I believe most people (at least engaged people) want to feel like they are contributing to something bigger than themselves. When organizations fail to share the "big picture" with everyone, it's difficult for anyone to feel a part of something bigger than themselves.

I also believe that people need to be given a little autonomy in how they organize, prioritize, and accomplish their work. Now, I'm not naive enough to believe that every employee is ready to be pushed out into the world to figure it out for themselves. This is where leadership style and the project manager's ability to work with the team become important. Every individual is different, with different abilities and experiences. It's up to the project manager to objectively determine how much autonomy any given team member is ready for, and work to train and mentor everyone to reach a level where they can make decisions for themselves (and that includes mistakes). If you need to instruct the team in every move they need to make, I hope you enjoy doing it, because you are about to spend your entire career holding everyone's hand to make work happen.

I'm not suggesting that I have all the answers. In fact, this is something that I'm really just trying to figure out for myself. Over the coming months, I'll probably bring this topic up from time to time because I believe that as the workforce changes, we will need to change to keep up with it. I believe the days of employees doing their jobs because we pay them and because we tell them to do it are gone. I've observed that today's workforce is looking for something more than a paycheck, which might be one reason why the workforce jumps from one job to another every couple of years. As project leaders (at least in the microcosm of projects), we need to figure this out.

What do you think? Do you think it's possible that we can actually figure out how to tap into that internal "something" that not only motivates the workforce, but enables them to enjoy some intrinsic satisfaction in what they do?