How to unfail at cross-functional projects

Hey Ambassadors!

I’m writing an experiential piece on cross-functional projects — a project that requires voluntary effort from people across organizational functions to achieve its objective — and I need your help.

I’m looking to understand your first experience being a leader on a cross functional project.

I’d like to know what you believe were the things that contributed to success and what you thought the lessons learnt were.

If you’ve ever been a leader of a cross-functional project you can really help me out by thinking about the time you were leading your first cross functional project. Take yourself back in time to when you were first starting the project and answer the following questions:

  1. How did you feel when you were given the responsibility to lead the project?

a. What were you most excited about?
b. What were you most anxious about?

  1. What did you already know about what was required of you?
  2. What did you want to happen for the project, and what was the outcome you wanted for yourself?

Then, think about the end of the project, imagine you’re having a retrospective and complete the following statements:

  1. Wow, having ________________ really helped the success of the project. (Add as many things as you can in the space.)

a. How did having those things make you feel at the time?

  1. Next time I’ll make sure to ______________. (Again, add as many things that come to mind.)

a. How did not having those things make you feel at the time?

  1. If I could pass on one piece of advice to someone running their first cross functional project it would be, ________________.

I’m hoping this will either validate my own experience or offer up gaps in my thinking and writing that I could explore more.

Thanks for your help.

Michael.

At the moment I can’t recall a time when I’ve led such a project; however, I’ve certainly participated in my fair share of them, and that experience provides at least enough perspective to respond to a few of your prompts, Michael.

Wow, having ________________ really helped the success of the project.

  • A common vocabulary: Cross-functional teams often speak different, domain-specific languages, so simply making time to ensure that everyone knows they can (and should) interrupt a conversation at any time to ask for clarification of a term or acronym is important. (See below for more on this.)

  • Clarity on the problem under discussion and open for collaborative solutions: This is true of any collaborative project, I’ve found, regardless of whether the team tasked with solving it is truly “cross-functional.” I’ve found that being explicit about the problem under discussion, the constraints impacting eventual discussions, and the process that led to the identification of this problem as a problem are critical. When problem-solving or decision-making gets opened up, people like to jump into “help mode” at varying … “levels of abstraction,” I’ll call it. A stakeholder asks a group for feedback on a proposed solution only to hear something like “But why would you want to do that in the first place?” or “You should be doing X” or “be considering X instead,” when that’s not what the stakeholder was asking for (they’ve already gone through the work of arriving at and articulating a specific problem in need of solving; they don’t need someone asking them to back up and reflect on various meta-levels of decision making that brought this particular collaborative moment together). Trust is critical here. People asked for input need to trust that the people asking them for their input have already done the work of arriving at an adequate framing of the problem that’s useful for them.

Next time I’ll make sure to ______________.

  • Kick off the project with a slide or “glossary” of jargon and/or project-specific parlance! Just setting the stage up front would have saved lots of time here.

  • Kick off the project with a clear statement about roles, responsibilties, and decision-making rights: Just making all this clear from the beginning would also work wonders.

Thank you Brian, exactly the type of response I’m looking for to help move the article forward.

I keep forgetting to get back here! Give me another day and I will provide insight. One of my first projects and a recent one.

Thanks Jen, would love to have your contribution here.

[quote=“mdoyle.info, post:1, topic:71”]

[This experience was about 12 years ago]

  1. I was incredibly excited to stretch myself and showcase my skills. I think I was most excited that I was given the opportunity to take on a larger task and facilitate a cross-functional initiative. My anxiety was really more about stretching myself to do it well. At Deloitte, you’re considered average once you get in the door and then expected to excel at a higher standard. So the bar set was already pretty high before I was handed this opportunity.

  2. I only was given the general landscape of what was needed. Here’s where we are. Here is where you need to go. These are your deadlines. Figure it out.

  3. I wanted to exceed expectations, but more importantly, wanted to make an impact. This office I was in was known for its history of difficulty with people. I was in a field of land mines from the get-go.

Then, think about the end of the project, imagine you’re having a retrospective and complete the following statements:

  1. Having peer support was crucial. My peers knew the landscape of people better than I did and were able to give me clues on the “land mines” as well as check my communications before rolling them out publicly. It made all the difference.

I didn’t have anything from my direct manager - she was pretty intent on me failing. My own staff was working against me half the time as well.

  1. As this has been so long ago and I do cross-functional work all the time now, this one is tougher to answer. Looking back I would say, not having my staff and manager support was hard in those moments. I was in the middle of an office politics nightmare that really had nothing to do with me other than I was rocking the boat (pushing them to be better). At times I felt defeated and like I was the problem. This is where peer support was crucial for me. They helped me see what all was at play on the office chessboard and encouraged me on what I was doing well.

Figuring out how to do the work on the fly was the easiest part of the job as it turned out!

  1. Seek out a trusted source in a peer (if possible) to be your sounding board and find one or two trusted sources who can help you navigate the cross-functional landscape. Knowing where the potential landmines and pitfalls are with politics or people will be crucial to your sanity and success.

The only other comment I wanted to throw in for you @mdoyle.info is that my most recent large scale project was interesting. Having been in an open environment for the last 3+ years, working with a very closed team was excruciating. Trying to get work done in an efficient and timely manner was near impossible.

Access to a stakeholders emails
Access to information
Freedom to contact stakeholders directly was a no-no
There was a barrier between the top leadership and “everyone else”

It was like stepping back in time and made work efforts near impossible in order to meet expected outcomes.

The results were the people on one side learned open is a way to go and were onboard. The leadership teams were too tired to care and remain super closed and in control.

:frowning:

Thanks for your input here Jen and sharing your experience openly. It certainly sounds like you ‘earned your stripes’ on that project.

Peer support was something I hadn’t identified. Thanks for that input, I’ll be putting in the article.

Thanks for reinforcing problem clarity, I had already noted it but what you wrote will bolster my thoughts. I never thought about a common vocab though, so I’ll add that in.

Common vocabulary is CRUCIAL!!! I actually think it is the #1 hindrance to collaboration and understanding each other in general. +1 Bryan

There’s something about the way you typed ‘crucial’ Jen that makes me want to ask, what was the experience that made you aware that common vocab was so important?

So the biggest thing I find is each “function” (in the org/community/etc) has its own definition of a word – especially in open, agile environments. Take the open org principles and definition: there is a very specific connotation to how each word is understood from an engineer / developer to people ops.

Example: Talk about collaboration with Group A and they will tell you about tools, applications and processes. Talk to Group B and they will tell you about the people behaviors and performance related outcomes.

Also keep in mind that each of the functions and departments have their own “culture”, set of artifacts, and language used.

So to create a common language or shared lexicon for reference is CRUCIAL :slight_smile: :slight_smile: :slight_smile:

Also - why I think this is the #1 issue never addressed…

People (everyone does this) tend to hear a word and they stop their brain from critical thinking once they assume they know what the other party is talking about. The problem is they switched their brain to the next thought without listening for context or asking for context/clarity. My personal belief is this is why we have so many disagreements. We don’t take the time to actually listen, understand and ask meaningful questions so we can fully gain perspective and engage inclusively and effectively.

Hope this helps.

Thanks for taking the time to expand on this Jen, it’s really helpful.

1 Like

Welcome!