A Solid Launch Consulting

Successful Leadership Comes From Leaning Into Your Own Style

abuttiglieri

How Is A School Year Like A Project?

by

f it has beginning and end dates, a goal, resources, and a budget, anything can be viewed as a project…so it can also benefit from project management.

Over the years, one of my most consistent readers has been my father (thanks, Pop!). He was a very successful public school Principal, Assistant Superintendent, and, in later years, Mentor to new Administrators.

He often comments on the connection between project leadership and school administration. But the vocabulary of project management is not something he’s familiar with. He’ll wonder if my readers understand what a “Launch” or “process owner” is without a vocabulary list.

Even though language may differ, the principles of project management cross industry boundaries. Most anything can be thought of as a project if you swap out the wording. So with that in mind, here’s my take on how the school year can be seen as a project, with clear project stages.

Initiate

  • Check your Charter: What’s the vision for the year? Do you have clear goals and an idea of how to reach them, from planting a third-grade flower garden to the annual school musical? And is this reviewed by anyone outside the staff (the team) like the School Committee or the Superintendent?
  • Just like all projects, receive your budget and start planning and tracking against it.
  • Gather dates of important milestones, such as first day, last day, vacation weeks, and holidays.
  • Nail down resource requirements and make adjustments (teachers, custodians, office staff). If they’re not already on board, hiring personnel and setting up contracts may be in order.

Plan

  • Schools don’t shut down when kids aren’t there. During the summer months it’s busy preparing for the students’ return with facility upkeep, supply orders, curriculum planning meetings, and special program proposals.
  • Lists of children are matched with classes, bus routes are worked through, and adjustments are made in all areas.
  • Communication planning is important here to let parents know the important calendar dates, their child’s teacher, class schedule, supply needs, bus pick up time, etc.
  • Risks are assessed, small and large. If the school is located somewhere cold, the risk is mitigated by adding snow days into the schedule. Teachers have sick days, just like the kids, and need to stay home from school. Both a substitute list and a way to contact them need to be in place before the beginning of the year.

Execution

  • Kickoff, of course, means the first day of school! Sometimes there’s even an assembly with everyone there, including the Principal and all the teachers, with presentations, instructions, special activities, and a building anticipation of the year to come.  
  • The “work gets done” during the school year—classes, testing, grading, gym class, music lessons, lunchtime, recess for the little ones, and those special programs you planned during the summer (like the third-grade garden and school musical)!
  • Risks are mitigated as they occur (such as unexpected maintenance issues), and additional risks are identified and handled accordingly.
  • Communication is constant—notices about Parents’ Night, homework, upcoming standardized testing, etc. Status updates are given to the School Committee or Central Administration, and individual meetings are held with parents.
  • Team meetings and workshops are held within the school for teachers and administrators to level up their skills or learn how to handle a new issue that’s come up.
  • Documentation is completed throughout the year, such as annual reporting to the state or updates to a grant that’s been given.
  • Launch is the last day of school. The staff has prepared the kids as much as possible but now it’s time for them to move on to the next level, whether that’s Third Grade, College, or a trade. There’s usually anticipation, a flurry of activity as the date approaches, and excitement when it finally arrives.

Close

  • After the frenzy of the last day of school, things start to slow back down and everyone has time to take a deep breath as they bring everything to a close.
  • There is always a period of clean up—physical (someone forgot their backpack), putting to bed documentation (recording the final records), and follow-on training (some students will attend summer school).
  • Schools will hold teacher meetings and talk through ways to improve for next year, a literal “lessons learned.”
  • Finally, resources are released and hopefully take some well-deserved time off…before it all starts again with next year’s Initiate and Planning stages.

This was only a glance through the lens to the school year as a project. So much more could be said, and I’m sure there are even greater parallels and examples.

For those of you outside the education system, I hope this helps you see how to adapt the principles of project management outside of the corporate world. No matter what we run, a project mindset can help us plan and execute with greater confidence. And it provides an simple but effective framework to communicate with our stakeholders.

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!

Is your role sliding from PM to BA?

by

It’s easy to slip into doing BA work. Is it taking away from your PM role?

I started my career as a Business Analyst at a software company (we were called “Application Consultants” back then). I loved my job! Nothing better than poking into a new company and figuring out what they do and how they do it…and then making the software sing to help make life easier for the users.

As time went on and I moved into Project Management, I never lost my interest in the process…or digging around in the software.

The PM’s role is not the same as the BA’s. I think of the PM role as broad and shallow vs. the BA’s as narrow and deep. That’s an oversimplification, of course, but here’s what I mean:

Unlike a BA, as a PM you don’t need to understand the nuts and bolts of the solution, and your job isn’t to sit with the users to gather requirements and set up test cases to make sure all requirements are sufficiently met. Likewise, unlike a PM, a BA isn’t focused on cross-department communication and how the project fits into corporate strategy. And a BA won’t be staring at a 6-month project plan, trying to find those 2 weeks we can use as cushion when things start to get off track.

One of the biggest risks we personally face on a project is being told, “We’re assigning you a BA…but she’s a shared resource.”

Why is it a risk for us? Because it’s very easy to slide, ever so subtly, into doing both roles. And one day you find yourself overwhelmed, trying to do it all, not being able to give your full attention to anything!

A friend of mine had the opportunity to step into a recently vacated PM position. He was currently performing a BA role on the project, so he gave the client the choice: He could be a PM or a BA, but not both because the project was too big and the timeline too short. I admire my friend for being clear with the client and sticking to his guns. He knew the dual role would set him (and the project) up for failure.  In the end, the company moved him to Project Manager and got another BA—smart move!

When you are considering a job change, a new consulting opportunity, or even a new project, make sure to ask questions about your resources: Will you be sharing your BA? Do you even have a BA? If it is a large project, will there be several Business Analysts, or is one person assigned—and how much experience do they have? 

If there is no BA, are you expected to cover that role? Does the company even understand the responsibilities and importance of the Business Analyst role? Red warning lights should be flashing if the answer is, “Oh, the Subject Matter Experts will write all the requirements and stuff.”

Now, sometimes it is possible to be both PM and BA. I am happy to take on BA responsibilities (see the first paragraph above!), but I do so with eyes wide open. When reviewing a new opportunity, I make sure the dual role is discussed up front so we can set some expectations and ground rules. I make an assessment of the company and the project, and if I believe they’re asking way too much of one person, I decline the opportunity.

Finally, there are many PMs who want to stick to straight Project Management. Asking questions about the project’s BA resources is key, as well as setting those ground rules around responsibility, so you have something to refer to when you find you’re the only one around who knows how to write test scripts.

If you’re thinking, “Oh, yeah, we need a RACI,” then you’re exactly right. We don’t usually have a RACI built before we start a new job or project, but it should be high on your priority list once you do. A simple chart of “who is responsible for what” gives you a solid foundation when things start to get crazy.

There Really Is Such a Thing as Over-Communication

by

Information Overload!
If we’re not careful, we can overwhelm our people with information!

There once was a fantastic manager whose performance critique from their boss consisted of only one word: brevity.

No, that manager wasn’t me. But it is a true story and certainly wouldn’t be a surprise to find on my annual review.

We all understand how critical it is to communicate with our stakeholders. We want our team to feel important and included, and to have all the information so they are empowered to make good decisions. Our sponsors and other executives should have the critical information at the right time. And our end users and extended team? Let them know what’s happening so they’re “with us” all the way.

But sometimes it’s hard to know when we’re going overboard.

Do any of these sound familiar?

  • A five-minute update can regularly take twenty-five.
  • A meeting that “shouldn’t take too long” goes the entire hour…plus a few minutes.
  • There are five main slides stuffed with content in your presentation…and fourteen back-up slides.
  • You put everything they need to know in your email…and get the most basic questions in response.

I am guilty of all of these. And I can name a dozen colleagues who do it, too.

So really, if we’re making sure we’re giving people all the information; how could there be any harm in it?

To answer that, let’s look again at the above cases:

  • If you say an update will take five minutes, not only is your audience expecting five minutes, they may have re-scheduled if they knew it was going to take longer. But they’re trapped in the middle of the conversation and need to see it through.
  • The same goes for a meeting. It’s hard to leave a meeting in the middle of a conversation. And if they do leave, they take with them a sense of frustration and unfinished business. And if you tell everyone the meeting will run short, they will be expecting some of their time back, even if it’s just five minutes to grab a water before their next meeting begins.
  • A jam-packed slide deck is deadly. Each slide should contain useful information, but ask yourself: do you want your team to spend time reading a slide or listening to you? And what is in those fourteen backup slides? If your audience needs the data, should it be in the main presentation?
  • Most emails don’t need a ton of background to evoke the intended response. It’s easy to miss the main point of a long, involved email.

Our teams (core, executive, extended) trust us to be respectful of their time and to deliver what we promise. In each of the above cases, we are wasting someone else’s time. More than that, we’re setting expectations and then not living up to them. But combine both—and do it repeatedly—then we’re starting to erode their trust.

How Do We Tell We’re Over-Communicating?

The result of over-communicating can be subtle. You’ll notice people start declining your meetings or aren’t available when you ping them for a quick update. They may stop reading your emails and instead send you a DM asking about the exact the subject you emailed them yesterday.

Let’s take a final look at our cases. A bit of review is usually all you need to dial it back to where it needs to be:

  • Take a few extra minutes to craft a more succinct message in email—or preparing for that five-minute update.
  • Unless there’s a very good reason for a meeting to run over, cut it off and make sure you do a better job estimating the time needed for each topic.
  • Check your slides for the 3-5 bullet rule. More information than that and your audience can’t absorb the information. Be critical in your review: does your overall point get lost because there’s so much context?
  • Read your email before you send it. If it requires a lot of explanation, maybe a phone call or meeting would be better—that way they can ask for additional information if they need it.

The focus on communicating the right amount of information helps you and your team get the job done. And it builds that foundation of trust so when you do find a meeting running over, they know it won’t become a pattern.