Project Management

Strategic Project Management

by
As an "accidental" project manager, it's very satisfying to contribute to the project management community online with anecdotes and stories I've picked up from my own experience. I hope you enjoy our daily conversation.

About this Blog

RSS

Recent Posts

Tell Me You're Going to Get This Done

Quiting Isn't Easy if You Never Do It

Getting in the Way of Peak Performance

The Agony of Defeat?

Nobody Likes Being the Heavy

Categories

decision-making, empowering team members, project leadership, project management, project management fundamentals, project success, project teams, struggling projects, work management

Date

Is Being "Satisfied" Enough?

linkedin twitter facebook Request to reuse this  

Is a workforce that's "satisfied" with their jobs enough?

Not if you need an engaged workforce that takes ownership of what they do and is expected to consistently perform at a high level.

"A recent study by the Society of Human Resource Management (SHRM) found that even though employees may be satisfied with their jobs, it does not automatically translate into having an engaged workforce," writes Colleen Coates.

I found it interesting that 83 percent of employees interviewed said they were "satisfied" with their current positions, but only 68 percent said they felt passion and excitement in their work. What's more, only 53 percent felt tuned in at work. Not great statistics if your organization needs engaged employees to maximize their contribution to the enterprise.

The survey identified a couple of things that  were problematic (my word not theirs). "While employees reported being fairly satisfied with key attributes such as the work itself, relationships with co-workers and their immediate supervisor, areas where considerably less satisfaction was apparent included career advancement and development opportunities, job-specific training and management recognition of employee job performance."

These are all areas that we've talked about before as important to creating an engaged workforce. It was also interesting that "...54 percent of respondents said that the aspect of the work experience that was most lacking was communication between employees and management," writes Coates.

In project management terms, this sounds like a classic visibility problem to me. Typically we talk about visibility in terms of executive visibility into the work done by project teams. I think that falls short of creating a transparent work environment where people feel like they know what's going on. Along with advice to managers that suggests that they need to listen more, she identifies a few other areas that might help employees feel (and act) more engaged:

  1. Provide Information: "As the saying goes, information is power. In the absence of real information, employees could just make it up or pick it up on water-cooler gossip," says Coates. I have to admit, that's sometimes been the way that I've found out about things over the years. What's more, I've seen lots of employees just "make it up" when information about what we're doing and why isn't forthcoming. This can be disastrous when a critical project is at risk.
  2. Encourage Involvement: According to Coates, "It is this simple: Unless employees are involved and have a say in key changes that directly affect them, they will quickly tune out." I am convinced that the people closest to the work understand it the best and should have a voice in how they do their work and who they do it with. A command-and-control project management methodology just doesn't work—at least it doesn't work at fostering an environment where people feel engaged and motivated to perform at a high level.
  3. Listen, Really Listen: "Why is it that whenever there is a formal inquiry into an organizational catastrophe, it always seems that someone knew something was bound to go wrong," she asks. Many times it's a "shoot the messenger" mentality where the barer of bad news takes the fall for the bad news. Coates suggests that it might be as simple as "nobody asked." I couldn't agree more when she argues, "If employees feel listened to and believe they can speak up without fear of retribution, they are much more likely to point out problems before things get out of hand."
  4. Engage your managers first: Of course I'm probably speaking to the choir here, but an engaged workforce starts with engaged managers. "An engaged manager focuses on their people, enables them to get the job done, treats each team member as an individual and encourages them to stretch beyond their capabilities." I couldn't have said it better myself. Engaging the workforce requires that everyone feel that sense of engagement, from top to bottom and bottom to top.

Communication is the key to an engaged workforce. "This is actually good news," writes Coates, "because it's never too late to make strides toward improving communications."

What do you do to make sure there are no communication problems with your team?

Posted on: March 13, 2012 11:32 AM | Permalink | Comments (1)

Are You Creating an Environment of Curiosity and Creativity?

linkedin twitter facebook Request to reuse this  

Last Saturday was probably the first day of the year that really started to feel like spring to me. It was relatively warm, it was Saturday, and although I didn't feel confident enough in the warmth in the valley to cruise up one of the canyons, I did take the bike out for several hours and visited some of the quite towns in central Utah. It felt good to put some miles underneath me.

I've discovered that on the motorcycle I'm content to ride on roads that I typically don't in a car. On the bike I'm usually not in the mood to quickly get from one place to another and am often in the mood to explore. Once you get off the highway, you discover some pretty interesting things. It made me wonder if sometimes we spend too much time on the freeway at work trying to quickly get from one place to another—or from one task to the next.

Walt Disney once said, "We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths."

I think the curiosity Disney was talking about is important, whether your talking about a process, your career or a new project. Part of staying engaged in the work is discovering, exploring new ideas, and stretching. Doing the same things day in and day out is a recipe for boredom and burnout.

Have you ever switched roles around on your project team? Given members of the team the opportunity to participate in a different way or try something new? You might be surprised at how energizing that can be. Sometimes it's easy to fall into a rut if we're doing the same tasks day in and day out. Taking the time to explore often provides breakthroughs that allow us to move forward or innovate.

I recently spoke with a project leader who gave an opportunity to try something new to a long-time member of the team. He went from an average, even mediocre, member of the team to a star performer. All it took was a chance to get off the superhighway for a minute and try something new.

Of course there are some roles and team members who have such specialized skill sets that  it might not be practical, but think about it—you might be surprised.

I know for me, climbing on the bike allows me to slow down and enjoy a change of scenery (even if it's only for a few hours). What do you do with your project team to foster an environment of curiosity and creativity?

Posted on: March 12, 2012 10:24 AM | Permalink | Comments (1)

Do "Franchise-Making" Players Matter?

linkedin twitter facebook Request to reuse this  

After fourteen years as quarterback for the Indianapolis Colts, Payton Manning says good-bye. Arguably one of the greatest quarterbacks of all time, I have to admit it's sad to see that he won't be finishing his career in Indy. Granted, his neck injury has forced the Colts organization to ask a lot of tough questions about whether or not he'd be able to contribute at the same level as in past years, but without him, last year was a dismal season.

It got me thinking, "What about the key players on a project team?"

Of course no project team can be built around one player, we expect everyone on the team to step up and perform at their best (not unlike a football team). Nevertheless, most teams have one or two key players who are the "go to" people during crunch time or continually tend to perform at a higher-than-average level.

I don't think there's any question that it's important to create the type of environment where they would want to stay on the team. However, that's not what I want to talk about today. I'd rather talk about how we capture and share the successful actions and behaviors of the most successful members of the team, making everyone on the team "key" players.

I once spoke with a project leader who's team visited hospitals installing hardware and software that tracked surgical instruments to ensure that everything on a surgeon's kit was sterile and prepared for the operation. The software also tracked all the instruments at the conclusion of an operation to ensure that everything made it back into its rightful place.

His concern was that the implementations were very dependent upon the skill of the individual installers—those with the most experience were far more successful than those with less experience. His approach was to capture all the best practices his senior people used in successful implementations, share them with everyone on the team via a template and improve the success of every implementation.

He continues to monitor those successful behaviors and practices and implements them into his project templates as they become apparent. Kind of a lather, rinse and repeat approach.

My comments today are not to imply that projects are the same thing as repetitive work, they aren't. However, those elements within a project that are repeatable (and there are often a number of them) can and should be templated to capture and implement best practice. This has the potential of elevating the performance of everyone on the team, not just the "Payton Mannings."

If you apply templates to aspects of your project management process, I'd love to hear about what you're doing, any successes you might be experiencing, as well as any challenges.

In the mean time, your a class act Payton Manning.

Posted on: March 09, 2012 11:13 AM | Permalink | Comments (1)

I admit it, I like Star Trek

linkedin twitter facebook Request to reuse this  

I grew up watching Captain Kirk regularly save the day. When I read Alex Knapp's article this morning about the Five Leadership Lessons From James T. Kirk, I couldn't help but smile.

According to Knapp, "Kirk's success was no fluke, either. His style of command demonstrates a keen understanding of leadership and how to maintain a team that succeeds time and time again, regardless of the dangers faced."

It made me wonder if he'd be a good project leader. Let's look at the five leadership traits and see if they apply within the project environment (The quotes are Kirk's):

  1. Never Stop Learning: "You know the greatest danger facing us is ourselves, an irrational fear of the unknown. But there's no such thing as the unknown—only things temporarily hidden, temporarily understood." This regularly applies in a project environment. We're often taking calculated risks and making decisions based upon incomplete data. Sure, the fate of Starfleet isn't at risk and the world isn't in danger, but a drive to continually learn new things is critical to being successful in a project environment. Knapp sums it up pretty well, "...no matter what  your organization does, it helps to never stop learning. The more knowledge you have, the more creative you can be."
  2. Have Advisors With Different Worldviews: "One of the advantages of being a captain, Doctor, is being able to ask for advice without necessarily having to take it." I've worked with and observed many leaders over the years who surround themselves with only those who agree with them. It's not a stretch to see how that could lead a project leader down the primrose path to project disaster. Of course, someone needs to be the final arbiter of decisions—sometimes it's the project manager, other times it might be the project sponsor. Nonetheless, building a team where a spirit of collaboration thrives, doesn't mean everyone has to agree. I used to work with a colleague who looked at the world differently than I did. Although we wanted the same outcomes, we would often discuss different approaches to getting there. Depending upon whether or not I was helping him with his project or he was helping me with mine, the dialog helped make those projects more successful—even though we didn't always see things the same way.
  3. Be Part Of The Away Team: "Risk is our business. That's what a starship is all about. That's why we're aboard her." Sometimes a project leader needs to step away from the comfort of the computer and into the fray. The most successful project leaders I've ever known aren't afraid to roll up their sleeves and help the team accomplish tasks (often they even end up doing the dirty jobs that help everyone else get done what they need to get done). I'm convinced the job of the project leader is do whatever he or she needs to do to ensure the successful completion of a project. That often means doing a lot more than writing reports and capturing data.
  4. Play Poker, Not Chess: "Not chess, Mr. Spock. Poker. Do you know the game?" Life, and projects, are all about probabilities, not defined rules. Otherwise we wouldn't treat them like projects. Kirk was famous for bluffing his way out of many situations. Although that's not what I would recommend within a project environment, sometimes you have to play the odds because projects act more like poker than chess.
  5. Blow Up The Enterprise: "'All I ask is a tall ship and a star to steer her by.' You could feel the wind at your back in those days. The sounds of the sea beneath you, and even if you take away the wind and the water, it's still the same. The ship is  yours. You can feel her. And the stars are still there, Bones." There's no question that Kirk loved his ship. Nevertheless, "...there came a point in Star Trek III: The Search for Spock, where Captain Kirk made a decision that must have pained him enormously—in order to defeat the Klingons attacking him and save his crew," writes Knapp, "James Kirk destroyed the Enterprise." There are times when it makes more sense to kill a project than it does to complete the project (particularly if it isn't going to provide the value it was intended to provide or the need has gone). I hate doing that, but sometimes you do have to blow up the Enterprise.

What do you think? Would Kirk be a good project leader?

Posted on: March 08, 2012 10:50 AM | Permalink | Comments (1)

Does your car have wheels?

linkedin twitter facebook Request to reuse this  

Of course it does. So does mine and so does your neighbor's.

Whenever the conversation about project management tools come up, it's really easy to get derailed by the features of individual solutions. Because we've become accustomed to comparing tools that way (not unlike "Does it have wheels? Check.") most of the time we tend to move down a punch-list of features—which hasn't helped us much over the last fifty years. In my opinion, any conversation about project management tools shouldn't revolve around Gantt charts or how they address capacity planning—those are basic features that are included in any project management solution.

Don't get me wrong. Any software that doesn't offer the fundamental feature set required to actively manage a project portfolio shouldn't even be considered. However, when we start talking about collaborative work management (which I believe is the next evolution in project management) determining whether or not your solution provides real business value boils down to a few very important considerations:

  1. Does the solution help me capture, prioritize and execute on project requests that emanate from throughout the organization?
  2. Does it help me ensure that every potential project is evaluated by the same criteria so only those that meet the criteria will be pushed forward?
  3. Will I be able to drill down into real-time data to validate that the business initiatives worked on by teams are those that have been determined to provide the greatest value?
  4. Does it make the process accessible to everyone on the project team? If it's easy for teams to use, project leaders will have the timely and accurate information they need to inform decisions.
  5. Does it facilitate collaboration among everyone on the team?
  6. Will it successfully integrate with my other business-critical systems?

Add these criteria to your evaluation and you might be surprised at how you will look at things a little differently. Does it have wheels? Check. Will it get me where I need to go? Now that's another question entirely.

Posted on: March 06, 2012 10:21 AM | Permalink | Comments (1)
ADVERTISEMENTS

"A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools."

- Douglas Adams

ADVERTISEMENT

Sponsors