So okay, Microsoft Project is a super flexible tool in helping you as a project manager define your project tasks, dependencies, and resources.  Quite frankly, though, the workplan you define in MS Project is only as good as the thought that goes into it.  Too often I've seen savvy MS Project users completely bungle a project because, while the tool was being used appropriately, the workplan didn't make sense to the project team and didn't reflect what really needed to be done.  The team consistently expressed confusion about what needed to be done by when because the project workplan wasn't reflective of the actual work which needed to be done.  Great exercise in using MS Project, but poor execution of the project.  Blech.

I’m a huge baseball fan. I love the strategy behind the game and how teams adapt their play to fit the need of a game. I especially enjoy how the role of a pitcher is used. Simply put, there are three basic categories of pitchers:

• Starting pitcher: The pitcher who starts the game and can last anywhere from less than an inning to a complete game.
• Relief pitcher: A pitcher who enters the game after the starting pitcher is removed for whatever reason, such as injury or fatigue. A relief pitcher can fulfill one or more roles, such as long relief, middle relief, setup, or left/right specialist.
• Closing pitcher: A specialized relief pitcher who typically pitches the last inning of a game to secure (or save) a win.

Throughout history, there have been many outstanding starting pitchers, such as Randy Johnson, Nolan Ryan and Tom Seaver, who are measured by stats such as earned run average, wins/losses, innings pitched, and strikeouts.
Since about the 1970s, the closing pitcher role has gained in prominence with notable players like Mariano Rivera, Rich “Goose” Gossage, and Trevor Hoffman. A key stat for closers is the number of games saved.

Relief pitchers, while not as notable as starters or closers, are typically comprised of career relievers or may also consist of former starters and closers. There are also some players, most notably John Smoltz and Dennis Eckersley, who began their careers as starting pitchers, but then found themselves being premier closing pitchers. Some closing pitchers even have songs that are played as they enter a game. (Any time Rivera entered a home game in Yankee Stadium, “Enter Sandman” by Metallica would be played through the PA system.)

All the players described above are baseball pitchers; it’s their role, or branding, that distinguishes how and when they are used in a game.

The pitcher analogy also applies to a project manager’s branding.

Read more at ProjectManagement.com.

So check this out.

Recently I received an email from someone who found me on LinkedIn. The person wasn’t a connection of mine, so I had no idea who he was or where he worked.

Let’s go through some of the items on the email (indicated by red letters A-F) and how it influenced my impression of this person. I changed personally identifiable information and will call him John Doe.

Hal was a new leader over a team of six followers. He committed to his manager that he would be a “learning leader,” and read leadership books to improve his skills. Almost every month in team meetings Hal included a book report on his latest book and the leadership techniques he wanted to put into practice. At first the team was receptive, but after the first few books a pattern emerged. Hal would talk about what he learned and implement the new methods . . . until he read the newest book on his list, making the previous book’s approach yesterday’s news—pushed aside. The team grew exasperated with Hal’s technique du jour only to have it replaced with a newer model. Even worse, the theory stayed just that, theory. Hal evaluated himself based on his knowledge; the team evaluated him based on his actions. Hal ultimately lost his team leader role; all that theory never making its way to reality.

A sad tale of a how a sponsor/PM relationship killed a project...

Exec identifies a need for a project and nominates self as sponsor.  PM gets assigned to project and assembles project team.  Sponsor is vague about problem to be solved other than "we need a new system".  PM can't communicate problem to be solved to the team because he doesn't understand what the problem is.  Sponsor continues to ask for more and more things to be included in project, PM doesn't have courage to say no.  PM treats sponsor as "that person in the corner office" and doesn't know how to ask for help, so he escalates everything.  Sponsor has to make some tough decisions but is unwilling to do so because of the political fallout.  PM provides bad information about decision alternatives so sponsor ignores him.  Due to changing priorities project no longer makes sense to do, but PM lobbies to keep the project going.  Sponsor loses interest because there are bigger fish to fry.  PM and team are disillusioned because sponsor doesn't care.  Project dies a slow death.  R.I.P.

While this is a fictional story, you can undoubtedly relate to most of these things happening on one project or another in your career.  The sponsor/PM partnership on a project is one of those "soft skill" factors that gets frequently overlooked when assessing a PM's skills but is a key determinant in the success or failure of a project.  Under a healthy partnership, the sponsor and PM work as a singular unit to ensure the project gets what it needs to be as successful as possible using only as many resources as absolutely necessary to secure success.  Under a less than healthy relationship the project will undoubtedly cost more in time and money assuming it even gets completed at all. 

Throughout my career I've been both a sponsor and a PM and have first-hand experience in how this relationship needs to work from both sides of the desk. Through my experience, I've locked down on ten truths which I feel are crucial to securing a healthy sponsor/PM partnership.  See if these resonate with you:

Some time back, I took over a high-risk program from a client project manager. The program had a contractually-fixed due date with a material business impact if the date wasn’t met. There was a minimum-bar scope to which we had to adhere: no subtracting scope or adding to scope.

Budget was not an issue; we (fortunately) didn’t have to worry about how much the program cost. The marching orders were clear: hit the date, manage the scope, and don’t worry about money.

The problem was that there was too much scope to hit the date using conventional waterfall or agile methodologies. We had four months to deliver what in reality was eight schedule months of work. Going back and saying, “It can’t be done” wasn’t an option because of the contractual requirement. So we got creative.

We divided the work into four sprints consisting of one or more baseline meetings, development, integration testing, user acceptance testing, and a go-live meeting with our sponsors at the end of each of the four months.
We not only overlapped the sprints, we also overlapped steps within the sprints. In any given sprint, we had concurrent development and integration testing activities with users participating in integration testing to identify potential user acceptance issues earlier (something I refer to as “canary in the mine” testing).

It was very messy, and not something I would have designed at the outset of a program. But I didn’t have the luxury of designing a “right way to do it” approach. I am confident that if a project auditor did a post-mortem on the approach, I’d get called out as having created and managed a hot mess.

And it was a hot mess—but we got the work done to the minimum-bar scope and the contractually fixed date. Our leadership didn’t give a fig about whether or not we did something the “right” way. We got the job done, hot mess and all.

My purpose for this opening story is not to engage in a waterfall/agile debate. The truth is that we were very hybrid in how we worked. My focus is to talk about something PMs need to avoid in this AI age: long division syndrome. Let me explain.

Read more at ProjectManagement.com.

As a young manager, I was involved in a significant crisis which had the attention of not only the partners in the firm but also its CEO. I, like many of my cohorts, was nervous about the crisis, its impact on our clients, and my employment status at the firm. There was a very senior partner who was tasked by the CEO to assume responsibility for navigating the firm through the crisis. It took us a year to work our way out of the crisis; and we all learned some valuable nuggets. I thought I was a good leader before the crisis. Now I realize how naïve I was in my assessing my leadership skills. That experience, while excruciatingly painful, was an inflection point in putting me on the path to becoming a better leader.

Some time back, I worked as a project management consultant with a client on some of their large projects. This client had a dedicated change management (CM) organization that recently purchased a methodology from a CM service provider.

All the PMs in the organization were required to go through training on the methodology. The training itself was good in that it helped underscore concepts and level-set on terminology. Included in the methodology was an out-of-the-box project plan that the CM organization wanted the PMs to adopt.

It was very difficult to get the PMs to adopt the methodology because the stock plan didn’t align well with how PMs were used to planning projects. The stock plan tried to include non-CM tasks to be more standalone-like, which made adoption more difficult. The methodology got a bad rap because of the incongruency of the stock plan with how PMs planned out projects. Unfortunate.

Read more at ProjectManagement.com.

So the older I get the more I think about the lessons I’ve learned in my career. Oh, to go back in time and talk to my younger self about the boneheaded things I did. Sadly, my younger self probably wouldn’t have listened to any imparted wisdom (which I define as knowledge coupled with experience). I was recklessly confident—I didn’t think I would get burned by touching the stove, no matter how many before me got burnt.

Ah, the naivete of youth.

What I’ve come to realize is that learning hard lessons doesn’t mean I have to experience them first-hand. It’s far less physically, emotionally and financially painful to learn from others. This has led me to an important conclusion--there are two paths to wisdom. The first is experiential wisdom, where I know the stove is hot because I touched it. The second is inherited wisdom, where I believe someone with credibility when they tell me the stove is hot. I could have saved myself a lot of time, stress, and money if I understood and practiced inherited wisdom.

In my zeal to help those still climbing the career mountain, following are my 12 wisdom nuggets to help others avoid experiential wisdom and replace it with inherited wisdom.

As an individual contributor, Joe was praised by his management for his speed in delivering results. His management was so enamored with his ability to get things done quickly that he was promoted to a leader role over a team of ten. Joe’s speed in taking action carried over into his decision making. He saw making decisions fast as a sign of getting “real work done,” versus sitting around talking about things. “Great leaders don’t have all the facts,” he would say to his team, as justification for moving forward without a good understanding of a decision’s implications. Joe’s team learned to just say, “Yes, Sir,” and do their best to execute what Joe wanted done by the time expected. His impulsive decision making came to a head with a new hire named Greg.