Strategic Project Management

Most successful project managers I know are able to think in terms of the details. I believe the ability to identify and coordinate the dozens, if not hundreds, of individual details associated with tasks and issues is a strength most of us probably wish we had more of. That being said, I think it's easy for those required to spend the lion's share of their time in the minutia of things to sometimes loose sight of the big picture.

For example, a painter I know once told me that he routinely needs to step back and look at his paintings from a distance in order to keep the right perspective. He told me it's easy for an artist to become so focused on the intricate details that they forget the rest of the painting. To avoid doing this, he makes himself step back, walk around the easel and look a the painting every few minutes.

In regards to projects, I think it's important to step back everyone once in a while and look at the big picture. Here are a few suggestions that might help:

1. Keep the business goals and objectives of the project front and center: It's sometimes easy to forget that projects are supposed to provide value. Keep them posted on the team white board, or someplace where the team will regularly see them. I know one project managerd that has created templates in their project management software with the goal of each individual project embedded into every task, issue and project page to remind the team why the project is important. This keeps everyone focused on the big picture, while working on the details.
2. As needed, meet with the project team to make sure everyone is still focused on the goal: We may not like it, but project teams are constantly bombarded with work that is unrelated to the project at hand. These distractions make it difficult for team members to stay focused on the project goal. Meeting with the team on a regular basis allows managers to help resolve impediments and keep the team focused. Often, the regular reminder of the project objective is all it takes to keep everyone on target.
3. Step back and look at the big picture: Software tools can help automate the management of many of the minutia associate with a project, so managers have time to step back and see the big picture. It's important to look at project progress from a broader perspective. Make sure your project management tools help free you from working head down, buried in the weeds that keep you from seeing the forest from the trees.

What are you doing to keep everyone focused on the big picture?

Few organizations have to struggle to keep people busy. The challenge is keeping people busy working on the right things—which means managing inbound requests and prioritizing work.

It's not always about separating the good initiatives from the bad. It's often choosing the best, the initiatives that provide the most business value, from a list of good potential projects. In a perfect world, there are many worthy initiatives that could, and maybe even should, be pursued. Unfortunately, this is not a perfect world.

That's why the "get'er done" mentality is such a problem. Particularly in light of the fact that most teams don't get to choose the projects they work on. That being said, there are many organizations that do project-based work that don't have formal processes in place to evaluate potential projects. In those organizations, it's up to project leaders to step up and ask some pointed questions, "Will this project provide the best value to our organization?" or "Does this 'drive-by' project provide enough value that someone should drop what he or she is doing to work on it?" Sometimes the answer will be a definite YES, but there are times when the answer should really be NO.

We rely on a lot of established best practice to help us manage projects and other work effectively. Many of those best practices revolve around the concept of identifying projects that meet certain criteria, creating a plan and then executing on the plan. Most of the time, our focus is centered on creating a plan and execution of the project. I wonder if we ignore the importance of evaluating projects based on merit, prioritizing those that provide the most value and aligning the available manpower to  tackle those at the top of the list (we need to realize that there will be some projects that aren't possible with the resources we have available).

My grandmother used to say, "Well begun is half done." I agree.

That critical evaluation stage of the project (that happens before it's ever assigned to a project manager or a project team) is probably the most important for organizations that want to maximize the value of limited resources and encourage profitability.

It isn't always the catastrophic failure that causes an organization to falter. It's often the accumulated weight of a thousand insignificant inefficiencies that cause the most damage. Many times it's wasting time working on marginally valuable work at the expense of incredibly valuable work. Does your organization spend time evaluating and prioritizing the work your teams do? If not, how do they know that what they are working on now and what's next is the right work?

Earlier this month Josh Nankivel wrote a great post on blame, Blame Failure on Your Project Stakeholders. With tongue firmly planted in cheek Josh suggests, "We all screw up from time to time. It's in those moments when the most important thing is to know who to blame."

Sometimes it feels that way.

Josh mentioned something I had read about recently in Eric Ries book, The Lean Startup. Ries talks about a technique for root cause analysis called The 5 Whys? The technique  suggests that you so start with the problem and ask why it happened. It's not about placing blame, it's about learning.

I'm not going to repeat Josh's 5 Whys? analysis here, but it's worth looking at his post.

Basically, asking why isn't enough.

"The core idea of the Five Whys is to tie investments directly to the prevention of the most problematic symptoms," writes Ries. "The system takes its name from the investigative method of asking the question 'Why?' five times to understand what has happened (the root cause). If you've ever had to answer a precocious child who wants to know 'Why is the sky blue?' and keeps asking 'Why?' after each answer, you're familiar with it. This technique was developed as a systematic problem-solving tool by Taiichi Ohno, the father of the Toyota Production System..."

When we let our natural tendency to place blame get in the way of solving problems, we aren't able to get at the root cause and sometimes the wrong event or person takes all the blame. It isn't very productive and it doesn't do anything to foster an environment where people learn from mistakes quickly.

"When confronted with a problem, have you ever asked why five times?" asks Ohno. "It is difficult to do even though it sounds easy. For example, suppose a machine stopped functioning:

1. Why did the machine stop? (There was an overload and the fuse blew.)
2. Why was there an overload? (The bearing was not sufficiently lubricated.)
3. Why was it not lubricated sufficiently? (The lubrication pump was not pumping sufficiently.)
4. Why was it not pumping sufficiently? (The shaft of the pump was worn and rattling.)
5. Why was the shaft worn out? (There was no strainer attached and metal scrap got in.)

"Repeating 'why' five times, like this, can help uncover the root problem and correct it. If this procedure were not carried through, one might simply replace the fuse or the pump shaft. In that case, the problem would recur within a few months. The Toyota production system has been build on the practice and evolution of this scientific approach. By asking and answering 'why' five times, we can get to the real cause of the problem, which is often hidden behind more obvious symptoms."

Placing blame when things go wrong isn't the answer to solving problems and avoiding them in the future—however, discovering the root cause of problems helps us improve processes, template and incorporate best practices and ultimately improve the likelihood of successful outcomes.

Thanks Josh.

I was one of the projected 117 million viewers who watched the Patriots and the Giants face off on Sunday night.

I'll admit that I'm pretty ambivalent about professional football generally and don't follow closely either the Patriots or the Giants. I do watch the Super Bowl every year and this game was one of the best in recent memory. It was an exciting game to watch. I found myself alternately rooting for the Giants and the Patriots during different quarters of the game. The outcome would have been very different were it not for an interception and a couple of dropped passes. But that's the nature of the game, right?

Like many of the people watching the game, the commercials were also of some interest—although most of them didn't inspire a desire to purchase their products. There were a couple that generated a chuckle though.

Clint Eastwood's ad about halftime in America got me thinking. Not necessarily about buying American cars (I already own two of them), but the whole concept of gathering the team together in the locker room, evaluating performance, creating a game plan for the second half based upon the mistakes and successes of the first half.

Whether it's the Super Bowl or the project you're working on right now, a lot depends upon the ability of the team to perform in crunch time. Sometimes during the course of a project, it makes sense to gather the team, review the game plan and make needed adjustments.

Learning from past experience doesn't always have to wait until halftime either. I'm convinced that we need to take a consistent approach that can be incorporated into any work management methodology. Here are a few suggestions to help any project team learn from experience:

1. Establish a venue for sharing lessons learned: It doesn't matter whether you call it a post-mortem, a project review or a halftime chat, most organizations don't do them—but they should. It's a real shame that many project teams move from one project to another without even taking a breath; let alone taking the oportunity to capture lessons learned from the last project.
2. Share what has been learned: Although many organizations don't take the time to do any kind of retrospective, very few of those that do share what they've learned. If lessons learned are captured and then tucked away in a file somewhere, the exercise doesn't do any good. Not only your own team, but other teams within the organization can benefit from a culture that freely shares lessons learned upon the completion of a project.
3. Don't make learning a one-time activity: Proper learning should be ongoing and interactive. Don't let it become an isolated activity that happens rarely.

Sometimes it makes sense to gather the team together for a halftime meeting to assess progress, address issues and establish a strategy for improving performance. No two organizations are exactly the same. Regardless of how you approach projects generally, it's important to foster a culture where project learning can take place. What does your company do to capture best practices and learn from experience?

I think everyone has experienced this at least once. The manager who feels the need to take personal credit for everything good that happens on the team or in the department. If anyone notices something the team has worked on as a success, he or she wants to take credit for it. "Yeah, that was my idea."

On the other had, if something goes wrong, that same manager is the first to throw the team under the bus. I've even had skid marks on my back because my manager had slammed on the brakes and backed the bus up for another pass.

Hopefully it goes without saying that it isn't long before those managers expose themselves as they frauds they are. Ultimately the team doesn't like that kind of manager, they don't give him or her their best work, their boss doesn't respect them and they get sent packing.

Any kind of leader (particularly a project leader) needs to consider how they promote the good work of the team. I think it's important to appropriately recognize achievements. In an article titled How to Build Trust When Your Team Doesn't Know Each Other, Wayne Turmel suggests, "There are many ways to show off the competence of team members. When you have message boards and social network tools, there are opportunities to answer questions, refer other team members and generally offer individuals a chance to shine they might not otherwise get. As the manager, take the chance to commend workers in ways that let the entire team know who did such great work."

In many organizations, the only time a team member is acknowledged is when there's something wrong. I really like the idea of making it a point to look for ways to show off the competence of my team—to share their accomplishments with my superiors. It creates an atmosphere where people aren't afraid to speak with me and makes it a lot easier to have those sometimes difficult conversations when there are problems.

There's nothing wrong with finding ways to shine the light on exceptional effort or an exceptional member of the team. What's more, although money is a motivator for performance, it's not the only motivator. Most people leave their employment for reasons other than money. Maybe their commute was too long, maybe they didn't like the job—but it's more than likely they didn't feel their contribution was recognized or appreciated as something valuable; or they didn't like their boss.

Over the course of my career, I've noticed the times when I've been the most successful have been the times when I've been able to facilitate an atmosphere where individual members of the team could shine and be recognized for what they bring to the effort. When my need to shine is superseded by the ability of individuals on my team to shine, projects have been more successful, the team is happier, and as a result it reflects well on me.

As a side note, in most cases, praise for a job well done should be specific and public. Vague platitudes aren't worth the wasted words. "Jones, the extra work you did to get the Acme project in on time made the difference," is much more effective than, "Good job everyone."

Specific and public is how I try to address praise to members on my team as opposed to reprimand, which should be handled privately—unless you want to do irreparable damage to personal relationships (which are the foundation of project leadership in a world where most of the time everyone on the project team is usually a dotted line on the org chart).

What do you do to recognize exceptional work or exceptional team members?