A Solid Launch Consulting

Successful Leadership Comes From Leaning Into Your Own Style

Communication

Include Your Whole Value Chain from the Start

by

We need to gather input from the teams down the length of the entire value chain.

As an IT/IS project manager, I am often involved in the selection of business software. The RFP is a key component of any large purchase, as it allows us to compare several systems against a set of common requirements, including business, technical, cost, and support.

But it doesn’t go far enough.

It’s easy to focus on marketing, finance, and the end user requirements. But what about infrastructure, manufacturing, or field technicians? How about quality control or customer service? We need to gather input from the teams down the length of the entire value chain.

I’ve been in situations where two systems look great: functionality, front end, and cost all are where we need them to be. Vendors, of course, talk a good game. Their RFP responses look similar. On the surface they’re both shiny new sportscars with all the latest gadgets.

But then the technical folks get in there and check under the hood. They find one still has an engine circa 1980! There’s no way this will work in your organization. You don’t have the resources to maintain the servers or update the desktop-based application. And it makes no sense to revert your users to 32-bit!

Good thing you included the tech folks before you signed the contract.

But not all projects involve software.

Years ago, our company was struggling because our manufacturing costs were consistently high. A review of our new product development process revealed that the problem wasn’t our product, and it wasn’t the skill of our manufacturing team. It was the NPD process itself.

R&D would design a product, test it in their small, flexible lab, and hand it over as a defined product. They weren’t aware of the constraints of large-scale manufacturing. No one asked them how long it would take to change over a line.

Manufacturing was not involved in the process until the very end. They had no input! The result was a product that worked as designed but could have been made at half the cost if only someone had checked with them first.

In the software example, it is wise to plan for a technical deep dive with the vendor finalists. We don’t want to bring them in too early, before we’ve finished analysis on other areas. But adding this tech review as a normal part of our software selection process can eliminate years of headaches for end users, IT, and you!

For product development, we want to make sure all areas of the value chain are involved in the NPD process. That doesn’t mean Support has equal say in the design as R&D, of course, but reviewing early and keeping them in the loop can keep you from launching a product that’s unsupportable.

All projects rely on communication through the whole value chain, at each phase of a project. Pull in the experts when it makes sense and plan to make adjustments. Reach out to teams you don’t traditionally include. And be prepared for a better outcome!

Riding the Waves of a Project

by

Projects can be like riding the crest of a wave—super fast and exciting, but stressful. But along with the swells, there are troughs where suddenly there’s “nothing to do.” Take advantage of the troughs!

Projects can be crazy busy. Long days, back-to-back meetings, milestones, updates, and endless decisions to make. My stress level climbs just typing it out!

But there is a flip side that we don’t often acknowledge, and one that we should take advantage of.

While much of our project maintains hectic pace, there are also periods where we’re simply waiting. We may be in the midst of testing, or waiting for a contract to be signed. Or there’s no one around during the holidays so you hear, “We’ll pick it back up in January.”

I think of it as ocean crests and troughs.

While the surge of activity can be overwhelming, it is also exciting. We feel a sense of accomplishment when we solve a challenging issue or reach a milestone. We can even look back on a full day of meetings and be proud (and amazed) that we lived through it all! These wave crests are the reason they hired us, a professional Project Manager. No one handles it better.

But what about the troughs?

For me, this downtime can be more stressful than the crests. Too little to do is worse than too much!

Waiting is not my strong suit, I’ll admit. A day with no meetings is fantastic if I’m in the middle of creating a complex project schedule or preparing for a Launch decision. The rest of the time, however, I’m just about ready to jump out the window if there’s nothing else on deck. Which is why, over the years, I’ve learned how to take advantage of the slow times on a project.

I find these to be most useful during this “down time”:

  • Create a Project Plan. I’m not talking about a schedule but a Word document with a section for different project areas like testing, documentation, project strategy, and special considerations. Use this document to write out ideas, decisions, and plans. Allow your mind to flip between areas without the need to keep focused on one. You will likely never need to present this document, but I find that going back and updating it helps me retain the project thread when my schedule get crazy again.
  • Catch Up on Documentation. Not the ones you’re simply behind on, though yes, do those first! Take this time to start the next few documents you know you’ll need. (And having a Project Plan handy is a great jumpstart.) You may be months away from your launch date, but starting your Launch Plan (aka Cutover Plan, Go Live Preparation Plan, etc.) will take the pressure off later when things are busy—you won’t have to start from scratch.
  • Rest. It’s easy to say but so hard to do! Take time off if you can. Actually take a break for lunch instead of eating at your desk. Put in eight hours and go home (or shut down your laptop). I consciously try to slow down my typing speed so I’m more thoughtful in my chats and emails. And, as I work from home, I take a minute to step outside and breathe some fresh air.

We all know the wave crests will come again soon, and we’ll wish we took advantage of the downtime that comes with a trough. Plan for it now so you can take advantage when it hits.

Three Truths About Praise

by

There are three truths of workplace praise. And all have their roots in communication style and human behavior.

The topic of workplace feedback is wide and deep. Maybe I will write a book about it someday, but to keep this article a reasonable length, I’m going to focus exclusively on praise.

There are three truths about praise:

  • Not many people take the direct path and say, “Good job.”
  • Most people are oblivious.
  • Not everyone likes to be praised.

Let’s look at each of these in more detail.

The Indirect Path

I was working with a client a while back who felt disconcerted because his manager never said, “Thank you.” He thought he was doing a good job at work, but never received direct positive feedback. When we took a closer look at the situation, the proof his manager valued him was right there all along.

Here are some clues that your manager is pleased with the job you’re doing:

  • You’re invited to meetings. Most people are so busy they think of another meeting as a punishment. But consider: Who else is at the meeting? Is it a topic that expands your current role? Will being involved create opportunities down the road or make your current job a bit easier? Most often, the invitation is a gesture of growing trust or belief in your abilities.
  • You’re called upon to present…again. Like attending more meetings, many people don’t enjoy presenting. But if you did a bad job the first time, your manager would hesitate to put you in front of an audience a second time. It’s actually a compliment to be asked to lead a meeting and share your knowledge.
  • Your manager stops attending your meetings or no longer wants to be copied on every communication. This isn’t a sign that they don’t care, but that they trust the work you’re doing. Just remember they expect you to keep them updated on the project’s progress, and to let them know if you need them to help resolve an issue.

Most People are Oblivious

Yes, it’s true. 😉

What seems like a monumental task to you, something you’re exceptionally proud of, your manager may never even mention. They’re not trying to ignore your good work. They just have a myriad of other things to do. (Hey, if they had time to do your work as well as their own, you wouldn’t have a job.)

A long time ago I had a friend who worked for a big supply company. He used to go in on the weekends when no one was around to inventory the warehouse, straighten the shelves, and basically do a ton of things that kept the place working efficiently during the week.

I’m sure you can guess what happened: his boss never noticed, and if he did, he didn’t say a word.

Don’t expect anyone to be focused on what you’re doing. Most managers expect you to do a good job—you were hired to do it, so just being competent won’t merit praise. There are no participation awards.

I gave my friend this advice and it is still relevant: either don’t do the extra work, or let your manager know the relevant outcome.

There was no reason for my friend to go in on his own time to clean the warehouse. He could do it, or assign someone to do it, during the workweek. If he wanted to show his initiative, he could have told his boss about a significant finding during his time the past weekend. Remember, fishing for compliments is unprofessional and will backfire. Better to focus on the outcome. And again, if there’s no benefit to the project or company, don’t do it.

If you have an “oblivious” manager, simply let them know a particular event or effort went well. Here are some tips to receive a positive reaction:

  • Keep your delivery in your normal communication style. You want your manager to focus on the event, not be distracted by your altered style.
  • Don’t tell them about every little thing; the big efforts won’t stand out.
  • Be consistent in your communication so sharing good news won’t come during a special meeting.

Not Everyone Likes to Be Praised

This may shock some people, while others will raise their hand and say, “Oh, yeah, right here!”

For those who can’t imagine anyone who doesn’t enjoy a good pat on the back (or bouquet of flowers), take a moment to think about your teams. You have many personalities and styles to manage every day. Your communication methods vary to make sure you reach everyone.

So if Brenda doesn’t speak during a meeting, or if Lonnie blathers on about everything he did last weekend, you will likely find they will receive praise very differently, too.

And there are more of these folks on our teams than we know. They usually just grin and bear it.

A few years ago, I worked with an amazing team lead. She was the lynchpin to success in her area. I wanted to let her know how much I appreciated her. But she told me that she hates (yes, hates) to be called out, even if it’s praise. And she didn’t just mean in the obvious, public way. Her name attached to a team thank-you email caused her discomfort.

For team members like this, balloons aren’t going to be well received. Here are some low-key ways that, if they accept anything, may work:

  • Reply to all their email / DMs. That’s it. Just do them the courtesy of acknowledging their communication.
  • Use their data. They want to contribute and to know they’re doing a good job. When you actually use their work product, they’ll feel valued.
  • Do something for the whole team, but not together. A team gathering is probably not going to fly. But something non-personal will be more appreciated, like letting people know that next Friday you want everyone to take off at noontime (if within your power).

At the end of the day, the most important part of praise is paying attention to the communication style of the person on the other end of the line. When you’re seeking validation, you may want direct feedback but receive indirect signs of trust. On the other hand, you may feel uncomfortable with a public shout-out, but your manager loves to hand out awards.

And when showing appreciation to a team member, the best outcome happens when you focus on their most receptive communication style, not your own.

Narrow & Deep or Shallow & Wide—it’s a matter of perspective

by

view of river from high above is wide but shallow
While your vantage point is “wide & shallow” on your project, you’re seen as “narrow & deep” when you present to an executive.

I was talking with a client about communicating to the C-Suite. They were struggling with how to retain an executive’s attention, to make sure their points are heard…and remembered.

I’ll be honest, the higher you go the shorter their attention span seems to be. It’s easy to feel frustrated when you get cut off mid-sentence, or they take the conversation in a completely different direction, and you’re left with three minutes to make a case that needed a full ten.

There are several factors at play here, including your proximity to them (direct report vs. several layers down) and their own personality. But let’s focus on the main one: vantage point.

Think about the quantity of areas and topics they’re involved in. An executive needs to see and respond to dozens of different people, topics, projects, strategies, and issues. They can cut across the company, so their vantage point is one of standing on a mountain, watching a river twist across the landscape but not seeing the bear fishing in it. Their view is “wide & shallow.”

You’re on the ground. You notice the bear but can’t see beyond the next bend in the river. Your vantage point is “narrow & deep.”

Bringing this back to business, the CEO is responsible for many areas, but their role is to gather information and make decisions, rather than do the work in all these areas personally: “wide & shallow.” And the lower down the hierarchy, the more “narrow & deep” until an individual contributor is focused on accomplishing their daily tasks, like the bear fishing in the river.

This is natural…and relative.

Think about your own project. Your role here is considered “wide & shallow.” Your job is to understand, assess, schedule, and resolve, but as a PM, you don’t do the actual “building.” Your resources are “narrow & deep,” digging into the work itself, raising issues, and preparing information.

When your team member is faced with a challenge, you, as the leader, don’t need to understand every nuance; just enough to get to the heart of the matter and make a decision. While talking with your resource, you may realize the problem they’re facing is actually the symptom of a very different issue, and you’ll start asking them questions to understand how big that one is!

So while you are “wide & shallow” on your project, you’re seen as “narrow & deep” when you present to an executive.

Given this perspective, it doesn’t make sense for your executive meetings to focus on the details. Their vision is about a thousand feet up, and miles wider.

Even understanding why the higher up you go the less likely you are to have an executive’s full attention, how do you effectively communicate with them?

First, think carefully about what outcome you’re looking for. Is it advice? Help? Money? A “Go” decision? Maybe you want to convey confidence in your team/timeline/project?

Whatever your goal, the rest of your communication (meeting, email, phone call) should support that. I know it’s nice to tell the CEO how great your team is, but if the meeting is to get a decision to purchase new testing equipment, talking about your awesome team is just an opportunity to get sidetracked. (That’s not to say you shouldn’t ever praise your team, but in this circumstance, they’d probably appreciate the equipment more!)

If you’re having a 1:1 meeting, make sure to leave time for discussion. If you have a half hour, expect the first five minutes to be “How are you doing?” questions…if your executive is on time. Then you need a few minutes to set up the discussion. Remember that while you’re living and breathing your project, it’s only one of a dozen they’re following. So start with a status or reminder of where you are in the project schedule. (“As you probably know, we just finished training everyone on the new process and we’re getting ready to roll it out next month.”)

Plan some room for detours. (“How did the training go?”) If you load up the meeting with details, it will be tougher to know what to cut out when time runs short. The risk is you’ll rush through all your data, hoping you hit on the information they need to make a good decision.

I’ve mentioned it before: The more important the communication, the more time I spend preparing for it. If I need that purchase decision, and the CEO doesn’t know too much about it already, or I only get this one shot to ask, I can take hours…or days to prepare. Because the message and the outcome are too important to risk anything other than crystal clear communication.

Does it Matter if you Hit your Launch Date?

by

Projects don’t always make their scheduled Launch date. More important than the date is how you approach the risk and your partnership with your sponsors.

Project management would be so easy if we could create a plan and simply follow it. Dates would be hit because we’d considered every risk, we had the correct number and type of resources, and the budget was unlimited.

Ever had a project like this? Me, neither. They’re as rare as a neon Pegasus.

Those of you new to project management may be looking at your more senior colleagues and wondering when you’ll be able to glide through a project like they do.

But the reality is, projects never get easier. With experience simply comes the ability to handle them with more grace (hopefully).

One of the toughest parts of project management is selecting a Go Live date and sticking to it.

When we start a project, the first thing management wants to know is “When will you be done?” Unless you really luck out with your execs, you’ll be required to throw out an estimated Launch date…which tends to stick in everyone’s mind, even though you made it before the basics are known—such as requirements and resources!

I get it, some projects have a date that can’t be missed for a very good reason—a divestiture is final, a service contract is up, or a major advertising campaign is counting on it.

But many times, when you do go Live is…a bit arbitrary.

As you move through your project, you may find hitting your chosen Launch date is going to be a stretch. You need to determine whether to drive super hard to make the date or push it out.

It’s not an easy decision. It comes down to the impact on your people, company culture, finances, risk tolerance, and stakeholder patience.

When faced with this situation, I first take a look at what exactly is being launched. Does any part of it need to hit a particular date? If so, what would happen if we missed it? If a month delay is fine, but 2 months is bad, I take that into consideration.

What about my team? Are they already maxed out? Am I just pouring more water into an already overflowing bucket? How great is the client’s pain (end users, business sponsor, other stakeholders)? Can they hold on for a little while longer or would that be devastating?

If we push out the date now, what’s the likelihood we’ll need to push it out again? One time may be tolerated, but pushing it out over and over erodes trust in you, your team, the project, and whatever it is you’re rolling out.

I always make sure to consider a third option: phased roll-out. This works in many organizations. If it’s an option where you are, consider whether launching pieces of your project over time will work. As an example, what about launching during a slow period so you can handle the volume of calls if something goes wrong. Or go Live with the base process and then pull in the less frequently used pieces later. You could also opt to open up into different geographical regions at different times (vs. a “big bang” approach).

When determining whether a phased launch will work, think through any additional communication needs. You’ll need answers when someone isn’t part of the initial Launch, and additional support if only part of the process is Live. Do you have resource time allocated to this?

So now you’ve done the research and you have a good idea of the impact of each option: strive for the original date, push out the date, or switch to a phased roll-out. It’s time to ask:

Who is responsible for making this decision?

You can make your recommendations and help work through the pros & cons, but the decision is up to the Sponsors or your Executive Committee.

How do you help ensure they’re making the “right” decision? Nothing fancy, nothing magic, just good, old-fashioned communication.

  1. Keep your execs informed throughout the project. Remind them that the timeline is a draft until it’s finalized. This is a great place for a visual. You likely have an update slide of some sort. A bold “DRAFT” text box is simple but effective, as are non-specific date formats (i.e. “Feb” for a milestone).
  2. Be transparent about the risks. This doesn’t mean complain every time you meet. But management needs to—wants to—know the risks so they can help mitigate them. (And, of course, mitigating them helps you hit the date!)
  3. Present the options with all the pros and cons of each. Even if they’re obvious, include them. It’s much easier to discuss if it’s all visible. And what’s obvious to you may not be to them—it’s a matter of perspective.
  4. Always treat your executives as if they’re important and have valuable insight…because they do. No matter how “in control” of our project we are, our point of view is narrow and deep. Theirs may be shallow, but it’s broad! They understand what’s going on in other parts of the company. They’ve been in strategy meetings and talk with their peers.

I’ve found that this level of communication helps my sponsors feel like part of the solution, not just a gatekeeper. If they have a personal connection, they’ll do whatever they can to make the project successful, whether it’s pushing out the date, bringing in resources, cutting scope, staging the roll-out, etc.

We can’t always avoid pushing the date. But coming up with a solution together gives us the best chance of success.

And speaking of success, no matter what happens with the Launch date, if you’re working with your sponsors all the way through, your reputation can still grow. You won’t be remembered as “that PM whose project didn’t go Live on time.” You’ll be recommended as “the PM who is always on top of things, no matter how challenging the project gets.”

What does Archaeology have to do with Knowledge Transfer?

by

Providing documentation is important. But what happens when you’re gone and no one can find it?

When you start a project, what’s one of the first things you do? Before creating a schedule, before planning out what needs to be done, you look for evidence of what happened in the past.

It’s like an archaeological dig.

What are they doing now, why, what happened to make it that way? If your client is in pain, how did it get this bad?

Once you have a few hints, you start to dig a little deeper. The greater your discovery, the more you treat your “find” with care, asking questions that might be sensitive. 

Sometimes you’ll hit the jackpot—that evidence that helps you understand the why and how.

Most of the time, unfortunately, you won’t find much of anything. A pottery shard letting you know something was done, but you don’t have enough evidence to piece it together.

You’re still in the dark, for the most part, trying to help solve the puzzle with most of the pieces missing. If only someone had left documentation behind. Trained the right Super Users and left a note about why the quirky process is the way it is!

I was talking with a new Project Manager at a client. Mike had a ton of experience and was hired to pick up where the old PM left off. I asked him how things were coming along and he expressed his frustration that there was no documentation—no requirements, no meeting notes, nothing! I was taken aback because I’d received some very nice templates from the former PM. We hunted around the system a bit and as it turns out, all the documentation was complete, but no one showed the new Project Manager where to find it. He was digging in the wrong place!

It’s a good thing Mike expressed his frustration to the right person. Pure coincidence that I knew where all the documentation existed. What a waste of effort if Mike had to start over from scratch, figuring out what decisions were made and asking endless questions about the current process. Not to mention the old PM’s extensive documentation would have gone to waste. (Hey, they do call it “artifacts” for a reason!)

When we close our project and roll off, not only is proper documentation important, but so is Knowledge Transfer. KT includes much more than training end users. Anyone who is impacted by the project can benefit from a proper hand-off.

Here are a few groups that benefit from a solid KT:

  • The Support Team. Most projects these days include some type of software. If a user has a question or problem, they’ll call the Help Desk or their favorite IT source. Make sure they are looped into what you’re doing, when you’re going Live, the type of system it is or may impact, and, if appropriate, give them a list of people they should inform if they get a call.
  • Super Users. Your Super Users require more than extra user training. These folks will collect comments, questions, and requests for changes to the process. The more you arm them with what, why and how, the more they can keep the “clean” process you’ve designed from getting messy and inefficient. Super Users stand between a well defined & documented process and the quicksand of “tribal knowledge.”
  • End User Managers. The end users will have the most to say about the new process. Talk with their managers about the new process and the impact to their team. Don’t leave them in the dark. No manager wants to hear their team’s role has shifted after the fact. And remember to loop them into the other groups receiving KT, especially the Support Team and Super Users.
  • The Process Owner / Sponsor. This person doesn’t need to know the nuts and bolts. They may never even use the process themselves. But they’re likely to own the budget for the area, and they need to understand the impact of the project on the end users and other processes. They may also be responsible for future enhancements, so show them where to find the original requirements and hand them a simple process for gathering future requests.
  • Owners of process on the front and back end of yours. Everything in business is interrelated. What happens before your process begins? (An order is placed? A call is made? Something is shipped?) What happens after? (A bill is paid? A shipment is made? Something is produced?) You likely talked with these process owners back when you were gathering requirements. Close the loop and let them know how it all turned out. Make sure they understand who to go to with questions or issues in the future.

As you are planning your Knowledge Transfer, remember that not everyone requires the same information or the same level of knowledge. For example, a Help Desk will benefit from a high-level overview so they can pass along issues to the right person, but they probably won’t need to be trained to fix issues themselves.

Consider a KT plan as part of your overall documentation strategy. Start thinking through the groups who need to be informed before you start planning your Go Live and Close, and leave time for it in your overall schedule. You don’t want to skimp on this vital area of communication!

Take heart, though. Knowledge Transfer doesn’t need to take long, and the documentation you’ve written along the way contains most of the information required. If you can’t hand over a document as-is, it’s usually a matter of cut & paste or simply reformatting it.

Finally, make sure part of your KT is telling people where to go for the information. Is it a Team Room?  A shared drive? A department site? Wherever it is, leave a map, or at least some breadcrumbs. The next Project Manager will be looking for it. Don’t let them dig in the wrong place!