These days I work primarily with startups and small businesses on product development and project management efforts, but I honed many skills by managing substantial large-scale, multi-year projects.

Even though those days are behind me, all of those skills are still applicable, no matter the project type or size. Here are the top five lessons I learned from the mistakes I made in the past — I hope they can help prevent you from repeating them.

1. Don’t Hide the Truth

I’m a big Star Wars nerd, and one of my favorite quotes from The Force Awakens is when Han Solo counsels Finn, “You got another problem. Women always figure out the truth. Always.” So do project stakeholders!

One of the big breaks early in my project management career was managing a team tasked with creating a set of standard control system functions to minimize control system design and implementation time across multiple engineering groups. It was a high-profile project, with technical experts selected from across the organization to serve on the project team.

The project technical lead had envisioned the entire project in his head. Unfortunately, the rest of the team struggled to understand the vision. So, I prepared a project plan that was in line with management expectations. After sharing it with the team and missing the initial deadlines, it was clear that we were way off track.

With the absolute best of intentions (surely we’ll get back on track soon!), I talked around the issues when presenting to management and painted the rosiest picture I could. I felt like I was protecting my team and giving them the space to figure things out. But in hindsight, I was doing them a disservice by pushing them toward unrealistic goals and making all of us look bad when we couldn’t hide from the truth.

Management “figured out the truth,” as they always do. They brought in a more senior project manager to continue the work. I learned a valuable lesson: Don’t be afraid to share bad news. Since then, I’ve received my share of reprimands from project stakeholders who were not pleased with the results. But I’ve always walked away with my head held high, knowing that I did the right thing.

2. You Can’t Force a Solution

Did I “force” another Star Wars reference into another section? Maybe. Anyway, I was working in a heavily regulated industry that was about to face new federal rules that fell under the scope of our product line. We knew the law was changing and worked with industry partners (customers, fellow vendors, industry working groups) to prepare.

The impact would be far-reaching — touching almost every other product line in the company. Fortunately, we had highly experienced technical expertise in this field and had spent months preparing a great plan. I was responsible for introducing the proposed changes to the rest of the program, project, and technical management team.

I presented the regulatory background, general requirements, source of funding, project phases -- everything the team could possibly need to succeed with this change order. I was sure that a slow-clap leading into a standing ovation was to follow the presentation. Boy, was I wrong.

Instead, I was met with a barrage of objections from the wider team. “That’s not what the regulation says!” (It was.) “Our customer won’t pay for that!” (They would.) “It’s too late to implement all of this!” (It wasn’t.) And on and on.

Where did we go wrong?

It’s obvious now — we did not include the rest of the organization in our planning. There had not been enough inclusion to secure their buy-in. As great as the plan may have been, the team did not feel like they were a part of it. It took weeks of meeting with each product line to review and update the plan. A painful reminder that in addition to wearing a project manager hat, we are also change managers.

3. Do Not Underestimate the Importance of a Strong Technical Lead

Many project organization charts place the project sponsor on top, then the project manager, then the rest of the project team. However, my preference has shifted over time to place the project manager side-by-side with a technical lead.

When I look back at my most successful projects, they ALWAYS had an effective technical lead. Why? Because we were able to build a relationship that reinforces the project in three ways:

• Decision-making: In addition to high-level project objectives, technical impacts (both short- and long-term) were considered. When working in a product line, they were able to identify areas where we could improve the product while also enhancing project outcomes for a specific customer project.
  

• Influence: Whether internal or external, I can’t always explain the technical reasons behind a Work Breakdown Structure item deep in the hardware realm or why the software team chose one technology over another. If I am meeting with a customer or executive, I would rather give the nod to the technical lead instead of saying, “the engineers said so.”
  

• Team cohesiveness: In my experience, engineers, developers, analysts, scientists, etc., want to feel like they are working on a project that will do some good in the world and that their voices are being heard and valued. I always try to treat them this way and having a side-by-side tech lead puts some teeth to it and amplifies their voices.

For more on what makes an effective tech lead, check out this article, and make sure you have one to support your next project!

4. Listen and Adjust to Balance Stakeholder Needs

On my most extensive project, I almost could have turned the list of stakeholders into the “Twelve Days of Christmas”: 10 internal product lines, 6 group team members, 4 engineering directors, 2 major utility customers, and 1 giant prime contractor!

You might be thinking, the lesson is to communicate with them. Maybe even throw in the phrase over-communicate. And yes, that is true. But the real trick is to understand each stakeholder’s specific motivations and incorporate them into your communications. Two different project stakeholders could receive the same piece of information and understand its meaning in two different ways.

For example, to meet a section of the project’s regulatory requirements, we had to update the corporate IT infrastructure. Because it was a project requirement, we planned on charging the customer for a portion of the upgrade costs. The stakeholders viewed this one change in the following ways:

• Customers: Another change order I have to pay for! Boo!
  

• Internal product lines: Another change to the way I have to work! Boo!
  

• Engineering directors: Funding source for an internal upgrade! Yay!

So our communications to each group had to be customized:

• Customers: This change will help you to satisfy your regulators and provide a baseline for your future procurement efforts with other vendors. You, us, and our other customers will share the costs.
  

• Internal product lines: Impacts on your day-to-day work will be minimal, and we’d like to work with you to explore ways actually to improve your standard workflow via this change.
  

• Engineering directors: While the funding will be helpful, this is not a blank check to use however you wish.

Don’t just think about your stakeholders in terms of power and influence, dig deeper into how you would expect them to react to an email, a project deliverable, a change notice, etc., and adjust your communications appropriately.

5. Your Project Team is the Project

Imagine the perfect project manager. An experienced Project Management Professional (PMP) should have years of delivering successful projects, be familiar with multiple methodologies, have a high degree of emotional intelligence, etc. Now imagine handing them a new project with an inexperienced or incomplete project team. Will they still succeed?

Well of course not! We don’t always get to pick our project team members. And even when you do, it is rare to get every one of your selections. The best project team members are always in high demand.

It is risky to assume your project team has everything it needs to succeed. I once made this mistake, and it took me months before acknowledging the issue. Here are some of the signs I missed:

• I didn’t get much input or feedback while building out the project plan.
  

• Some early tasks were either misunderstood or delivered late.
  

• I could sense the occasional lack of confidence while discussing project tasks and deliverables.
  

• I started to take on more technical work than I should have to fill in the gaps.

In hindsight, the clues and problems seem obvious. But at the time, I was trying to impress a new organization. I was excited about the challenge of dusting off some of my technical skills and working with a really well-intentioned project team.

The bottom line is that I was too slow to act on my instincts. I should have raised my concerns to the organizational lead and saved everyone time and money by requesting additional support or making the difficult decision to abandon the project. And it did eventually end up getting scrapped, but only after wasting too many resources.

Do your homework to ensure your team has the manpower and resources it needs to deliver on all primary project objectives. Talk to them one-on-one and look for any hesitancies in their scope of work. Make sure they have a say and actively contribute to building the project plan. Find an effective technical lead. If you see a gap, some potential solutions include:

• Bring additional team members to either provide some mentoring or perform a few project tasks even on a part-time basis.
  

• Add training time to the beginning of the project.
  

• Outsource whatever skill set the team lacks.
  

• Partner with another organization to fill the skills gap and find a way to share the project benefits (since they are reducing your risk).

Learning how to lead a team successfully doesn’t happen overnight. As you can see in these examples, it has taken me years of strikes and gutters to hone in on what makes a project truly great. Sharing my mistakes and passing on these lessons is all part of the process!

If you’re managing a project and your instincts tell you that disaster is near, take a lesson from me and step back. Start with the first lesson by telling the truth and raising your concerns to your project sponsor or organization lead. You’ll be glad you did!