Strategic Project Management

The blizzard warnings for Salt Lake and Utah Counties were all over the radio and television yesterday. The stories of a huge cold front followed by sub-freezing temperatures reminded me of the five-hour commute home I was stuck in about three years ago. I left work a little early, fired up the home office to continue working on the project or two I was in the middle of before I left, figured I'd be working from home today, and patiently waited for the blizzard to hit.

It wasn't what I expected. Yes, it was a little colder than usual for a November storm. Yes, it was very windy. And yes, it snowed in Salt Lake County where I live ... but it wasn't really much more than a typical snowstorm I drive to work in every winter. In fact, when I pulled into the parking lot in Orem, there wasn't much more than a skiff of snow on the ground (and I really had to look for that).

I've been involved in projects that were like this too.

Managing risk is an important part of managing projects. Although I'm not an "expect the worse case scenario" sort of guy, it's important to go into a new project aware of the potential problems and have some kind of plan to mitigate damages should they happen. Like yesterday's "blizzard," I was prepared for the worst, but when I woke up the world hadn't come crashing to an end and I jumped in the Jeep and drove to work. I guess sometimes stuff doesn't happen.

Experienced project leaders plan for problems and breath a sigh of relief when the blizzard doesn't hit.
 

We talk a lot about the skills a good project leader needs. Is certification one of them?

I was reading a post written by Derek Huether of The Critical Path blog titled, Failing the Exam. He cites an example of a known problem with the PMP certification which he and I talked about a couple of weeks ago. First the example, then my comments:

"I was approached a while back by someone looking for assistance in prepping for his PMP," writes Huether. "He is not a project manager (never was; never will be) and does not want to be. But, his company told him to get the certification."

Having never managed a project made the application problematic for this person. He obviously didn't want to be audited by the PMI, but he needed to fabricate a body of experience so he could take the test and obtain the certification. After attending some training, he sat for the test and fortunately failed it. I say fortunately because the guy has no business having the certification in the first place.

Speaking with Derek, I think we both agree that certification, although a potentially valuable measure of whether or not a person is prepared to manage projects, is being misused by companies, hiring managers, and even some project managers. Why do I say that?

1. Certification is basically an indication that a project manager understands the fundamentals of managing projects according to the certification body (the PMI in Derek's example), it is not an indication of expertise. Organizations and hiring managers who use certification as go-no-go indication of a project managers fitness are misusing the certification. It is a reasonable criteria when considering a potential project manager for hire or advancement, but there are other criteria (like experience) which should probably be weighted as more important.
2. Project managers who misrepresent their expertise to achieve certification are misusing same. Apparently fear of a random audit is not enough as Derek's example demonstrates. I realize that a mandatory audit of every application might be difficult, but could be necessary. For example, Derek and I talked about recent college graduates who couldn't possibly have the requisite experience, yet have their PMP. How does that work?

Don't misunderstand, I am not trying to bash certification in general or any certification body in particular. I'm suggesting that organizations, hiring managers, project managers, and the industry at large should take a look at the process with fresh eyes to determine how we can repair what is obviously broken. Maybe there should be some kind of apprenticeship associated with certification for example. However, as long as certification is misinterpreted as an indication of expertise rather than fundamental knowledge, the system isn't working.

"When I asked him if he thought the exam was hard he gave me a very good answer," continued Huether. "He admitted he didn't even understand half of the terminology or formulas, let alone when and why he would use them."

In my opinion, that is an excellent example of a weakness in the current system. Now, what do we do as an industry to fix it?

 

I must admit, I am a mediocre fly-fisherman, but I do enjoy occasionally thrashing about in the stream, river, or occasionally one of the high mountain lakes that dot the Uintah mountains of Utah. Since the incident with my shoulder a few months ago, I have spent what little off time I have tying flies or reading. A week or so ago, I picked up an anthology of one of my favorite outdoors authors, Death, Taxes, and Leaky Waders by John Gierach. Some of the stories I've read before, but they're still enjoyable to read when it's difficult to cast a fly-rod, pull the starter on the lawn mower, or otherwise be very useful with a recuperating right arm.

In one of his essays, he describes setting up camp with a long-time fishing partner: "We now set up camps with such wordless efficiency that spectators sometimes think we're mad at each other. I've learned a lot from him, from the nuts and bolts of fly tying and casting—both of which he's damned good at—to philosophy. It was while fishing with A.K. that I discovered you could tell the plain truth about fly-fishing and still be a humorist."

I seem to spend a lot more time with my team at work than I do with my fly-rod—or even my wife for that matter, yet we haven't reached the point where we are able to work together with "wordless efficiency." It's probably because project teams change, people come and go, and we are often so "heads-down" and hard at it that we don't pay much attention to what other members of the team are doing or how they are doing it at any given time.

Several years ago I read that the best air force in the world (at that time) was the U.S. Air National Guard. Surprised? I was. However, what made them such a powerful fighting force really makes sense:

1. Most (if not all) of them were combat veterans
2. They had worked together for a long time (in some cases almost 20 years)
3. They could anticipate each others reactions to different situations because they had shared so many of the same experiences together

The author suggested that most fighter squadrons don't fly together for years at a time. Whether it's the Air Force or they Navy, fighter jocks tend to be shipped around from squadron to squadron (or team to team for that matter). I don't think it says anything about their skill level that the old farts in the National Guard are so good, they just haven't shared as many of the same experiences together.

As I think about it, it's probably unreasonable to expect project teams to "wordlessly" go through the day getting stuff done. I suppose that's why it's so important that as project leaders, we step away from the computer once an a while to actually communicate with the members of our project teams. I know that I would much rather have a face-to-face discussion about upcoming projects and assignments before I start seeing tasks dropped into my projects list. I don't think I'm all that unique. After all, one of the most important skills a good project leader has is the ability to communicate and facilitate effective collaboration.

What do you do to force yourself away from the computer and out with the team?

 

Whether you know them as the Seven Deadly Sins, the Capital Vices, or the Cardinal Sins, the final version of the list consists of wrath, greed, sloth, pride, lust, envy, and gluttony. The "Deadly Sins" are not seen as a separate category of sin, but rather the origin of the other sins. The same could be said of the Seven Deadly Project Management Sins—most of the struggles we face as project leaders originate with them.

Here's the list:

1. The Squeaky Wheel: I like to call this the, "stakeholder who screams the loudest gets what they want just because they are a noisy stakeholder" sin. Projects should focus on initiatives that provide the greatest value to the organization, not the personal or pet projects of powerful stakeholders. Organizations who spend valuable resources on projects of limited or suspect value tend to struggle.
2. Dogma Dominance: The "My dogma is better than your dogma" sin makes it difficult for project teams to approach project planning with the "best" methodology for any "particular" project. There are times when a waterfall approach to managing projects might not be the best approach. The same can be said for Agile. When a project manager's personal preference for any particular approach dominates how he or she creates a project plan—time and resources can be wasted. The simplest approach, depending upon the requirements, is often the best. The best project managers I know are able to function in any environment, depending on what's needed to deliver the most value to their customer.
3. Lack of Vision: It's important that everyone involved in the project have an understanding of the ultimate goal of the project. When the vision of a project is not communicated to everyone or worse, non existent, it's difficult for project teams to become engaged. If project leaders expect the team to treat their project like something more than "just another project," the team needs to understand why the project is valuable to their organization. (Refer to Deadly Sin #1)
4. The focus group of "one": As a project leader you may be smart and may really know your stuff, but let's face it, those closest to the work understand it the best. Ignoring the input of individual project teams members is NOT a good idea. I am not advocating making decisions by committee, but I am suggesting that it's easy to make a stupid decision by yourself. The old saw about how two heads are better than one, is really good advice.
5. Seagull Supervision: I've seen this type of management style in numerous organizations. Have you ever had a boss who swooped in, made a big mess, and swooped out, leaving you to clean up the mess. I sure have. It's a real morale killer for project teams who are head-down trying to get stuff done.
6. Crappy Communication: Project leaders need to be exceptional communicators. They need to effectively collaborate with project teams, stakeholders, and other executives in a style that is adaptable to each group. A one-size-fits-all approach to project communication doesn't work. Giving a detailed project plan to the executive team is neither appreciated nor appropriate. And in reality, the project team doesn't care about what the Gantt chart looks like either. They need to know what their contribution is and how what they are doing fits into the context of the overall project goals. Effective project leaders are exceptional communicators.
7. Forgetting Value: Ultimately the goal of every project is to provide value. In terms of either making money, saving money, or providing some other value. For some organizations ROI might not be as important as governance issues—depending on the organization and what they want to accomplish. If we forget that projects provide value, we've lost before we've begun.

I'm on a roll now and could probably keep going, but I'm going to stop at seven. What other project management sins would you call "deadly?"

Although money is important, it's probably not the primary measure of whether or not someone is happy and satisfied in their chosen profession.

Most people, whether they are able to articulate it or not, want to add maximum value to whatever they do. I must admit, those days when I go home after accomplishing something worthwhile are very satisfying. I like what I do, I feel like I am contributing to something worthwhile, and that my time is not wasted.

I don't think I'm that unique. What's more, I believe the members of our project teams feel the same way. How often have you said, or heard someone else on the team say, "I hate wasting time on this," or "This is a waste of time," or "I don't feel like I've contributed anything worthwhile today."?

Sound familiar?

Regardless of the particular project management tools you use or the work management methodologies you employ, anything that can better align people to the right work at the right time will help your teams enjoy their job, gain satisfaction from whatever they are doing, and allow them to feel like they are really contributing to something bigger than themselves.

I don't think anyone likes to waste their time, even if they are being paid to do it. We spend so much energy trying to conserve our natural resource, it's puzzling to me why so many organizations insist on wasting their most precious resource—their people. Here are six tips to help you avoid wasting team members:

1. Make sure everyone has a clear understanding of what they should be doing: I know this sounds simple, but sometimes it's easier said than done. When people have to spend time figuring out what they should be doing, people are wasted.
2. Don't make it difficult for people to find documents or other project resources: When people have to hunt for the document or other project asset they should be working on, people are wasted.
3. Don't make it difficult for managers to see what their people are doing: When team leaders and managers have to spend time trying to figure out what their people are doing, people are wasted.
4. Don't spend entire days in meetings simply talking about work: If all you do is talk about work and never get around to doing the work, people are wasted.
5. Keep people focused on those initiatives that provide the most business value: When people spend time working on initiatives that don't provide the most value to the organization, people are wasted.
6. Streamline repetitive processes: When people spend time in repetitive process that could be streamlined or automated, people are wasted.

Project management practices and tools that don't help avoid these wasteful behaviors won't help organizations maximize the value of their employees. As project leaders, we should all be looking at the processes and methods we employ to manage work to see if we are contributing to frustration and waste or encouraging efficiency and empowering team members.

What are you doing to say no to getting wasted at work?