Author: Andy Silber

Andy Silber

About Andy Silber

Andy Silber has been an astrophysicist, an engineer, project manager, and author of Adaptive Project Management: Leading Complex and Uncertain Projects. He has worked throughout the Puget Sound region in everything from small startups to Fortune 100 companies. He has been an environmental activist and that passion is responsible for first bringing out his desire to write. More of his writing on project management, energy policy, and politics can be found at his blog A Silber Lining.

In an Information Desert, Rumors Are a Mirage, Not an Oasis

Working in an office where leadership doesn’t communicate about the critical issues affecting the company is like wandering a desert without a canteen. You wander the office seeking to quench your thirst for information, but all you find are rumors. Everyone is gossiping about possible layoffs or project cancelations.

These conversations happen when change and uncertainty are in the air, but clear communication from leadership is absent. A couple of things to understand about these conversations:

  • They’re the natural outcome of team members being kept in the dark.
  • They add little or no value since no decisions are made.
  • They can reduce morale, by spreading fear, uncertainty, and doubt (FUD).
  • They are completely preventable with good leadership that trusts the team with critical information.

The Mirage

Rumors fly around a nervous office like buzzards around a caravan lost in the desert. These rumors are just a mirage, and they will not slake your thirst for understanding: you’re just drinking sand.

Imagine all the time that’s been spent speculating with no data around the coffee pots of Seattle since Amazon announced its desire to open HQ2 somewhere else.

Where will it be? If my manager wants to move, will I have to? Will it be somewhere I want to move?

Amazon managed the process in a way that maximized speculation in city halls and newsrooms across North America as well as within the hallways throughout South Lake Union (Amazon’s HQ1). How much did these conversations distract from work or reduce morale? Did people look for jobs elsewhere due to FUD? I don’t know; this is just more speculation in the absence of knowledge.

I once worked at a small company where engineering and manufacturing were on one side of a road and sales, marketing, and the executives were on the other, but we might as well have been on opposite sides of the moon. We could tell the sales were poor only because we could count the number of devices shipping per month on one hand. When I first started, we had “all-hands” meetings about once a year, and it was obvious that the information was out-of-date two weeks later. Priorities were changed; however, the rationale was never explained, and it didn’t matter as the priorities would change again six months later.

Then, the death spiral started. An all-hands meeting meant layoffs. Time spent developing features that might have saved the company was spent wondering who would be cut. By the time it was my turn, I was glad to be gone and out of the death spiral.

Funnily, I came back seven weeks later to work on a special project funded by a large pharmaceutical company. It was a great project; we were meeting or beating all of our deadlines, but Phase 2 wasn’t getting signed. Not wanting to be let go twice from the same company, I left. If there had been some communication about why the second phase wasn’t getting signed, I might have stayed on to complete the project.

The Oasis

Even in the driest desert, there is a pocket of water and shade, an oasis. How do you turn your office full of FUD into an oasis? I’m guessing you already know the answer: better and clearer communication. When leadership has a poor communication style, gossip will spread quickly throughout an office.

Sometimes leadership doesn’t communicate because the company has sensitive information that it doesn’t want to become public. Benjamin Franklin said, “Three may keep a secret if two of them are dead” (though I think it would sound better coming from Don Corleone), so it’s understandable why not everything is shared. For instance, Amazon clearly didn’t want a high level of transparency around the HQ2 search, so how could they minimize the gossip? One way is to communicate as much as possible. For instance, if they had already decided which teams would be relocated, they could share this information. Those teams that weren’t relocating would relax. The teams that will be moving would gossip as much as before, so the total amount of gossip would be reduced. Having a communication strategy that shares as much information as possible reduces gossip.

Another approach is to get input from the affected teams. If the team knows their concerns are part of the discussions, the FUD is greatly reduced, which reduces the useless chatter. This only works if leadership has earned the trust of the team and if the team members are confident their concerns will be factored into the decisions. Leadership earns that trust by making good, informed decisions consistently. Without that history and trust, gathering input doesn’t help as much as it will once trust is earned.

Most companies will experience tough times in their lives and will have great distances of fear, uncertainty, and doubt to cross. Communication and trust are the foundations of turning your office space from a desert to an oasis, and your team can pass from oasis to oasis and emerge on the other side stronger for the effort.

People Are Not Cogs: How to Manage a Project with People, not Resources

In a factory, people are managed like a piece of equipment, a resource that is applied to a well-described task. Anyone who has been trained in this task can be assigned and the same result is expected. If not, the fault is in the process or training, not in the person performing the task. The goal in this environment is to minimize the variation in how the task is done regardless of who is doing it.

Jimmy Jia, founder and CEO of Distributed Energy Management, once told me, “One increases variation to increase innovation.” In other words, if you create tight processes that are very predictable (as in a factory), then you are guaranteed to get a predictable outcome and limit your possibilities for innovation.

So, how do you manage your resources to increase innovation?

You treat them like the people they are rather than the lifeless cogs in a machine that the term “resources” makes them seem to be. Without the diversity of approaches, skills, viewpoints, and personal history that people can bring to your team, innovation won’t happen.

Planning with People

One of the fundamental assumptions of project management is that resources are fungible—that if you need an electrical engineer, then anyone in a pool of electrical engineers will do. You might need to break your pool into smaller groups with specialized experience (e.g., antenna design, FCC certification, high-voltage electronics, low-voltage electronics), but within the group, anyone will do. You build your work breakdown structure, make your duration estimates, and calculate your delivery dates with a generic resource. When the time comes, the functional manager provides you with an actual person from the pool. For good or for ill, that person is not a cog, but an actual human being with strengths and weaknesses.

Imagine you have a team called “Desert Residents” that has two members: Road Runner and Wile E. Coyote. Both team members can manage the basics of the role (i.e., survive in a hot, dry environment), but they have different strengths and weaknesses. Road Runner does two things very well: run and go beep-beep. She runs fast and far and beep-beeps at just the right time to startled Wile E. Coyote. Road Runner will probably get your tasks completed faster than expected if they just require what she can do well. If you get Coyote, he’s going to take longer completing these basic tasks of running and beeping, but if you need someone who can carefully dissect a problem and create a solution that didn’t exist before solely out of parts from the ACME catalog, Coyote will complete those tasks and Road Runner won’t. Of course, most of Coyote’s ideas are overly complex and don’t work well, but that’s a subject for a different blog post.

As a project manager, you should understand the details of the tasks and the skills the team members have, and you should work with the functional manager to make sure that you get the right person on the team. During the planning stage, you need to identify the constraints of “We need Coyote on this project, and we’ll wait for him” or “I’m scheduling assuming I get Roadrunner, and I’ll be late if I get Coyote.” If you need to get a particular person, make sure to include some wait time in your schedule because you might not be the only one waiting for that particular person.

Understanding Team Dynamics

As a PM, you need to understand more than just the capabilities and efficiency of your team members, but also their work styles. Some hate to be micromanaged; tell them what they need to accomplish and by when, and then leave them alone. For others, you might need to explain the big picture in detail and how their tasks fit into it. Still, others want to be micromanaged and be told what to do every step of the way.

I once worked with an engineer at an off-site vendor who loved nothing more than a challenge. I would just say, “It would be great if the software could do XYZ.” Then, I wouldn’t contact him for a week or two. My patience was always rewarded when a solution to my challenge would just show up in my email box. He hated being “managed” but loved being challenged. It was hard for my management to understand that asking for updates and commitments was counterproductive.

Imagine one of your teams has three members: Moe, Curly, and Larry.

  • Moe is technically capable and a bully. He gets things done and occasionally has brilliant ideas, but he’s not nearly as smart as he thinks he is.
  • Curly is funny and is constantly getting off topic. He sees problems differently than others, which sometimes leads to creative solutions.
  • Larry is quiet and gets his work done. His solutions aren’t very creative, and he’s not very fast; however, he is diligent.

You can’t manage these three “resources”; you need to manage three people, and they need different support from the PM. Here are some possible approaches:

  • With Moe, set rules on how to behave and how decisions are made. You need to stress that other ideas may be better than his, and even if they aren’t, they need to be respectfully considered. Quietly keep notes for HR and the functional manager, but hopefully, by setting clear boundaries and modeling proper team behavior, things will be okay. If the bullying persists be prepared to escalate. I strongly agree with Robert I. Sutton’s The No Asshole Rule, and regardless of Moe’s brilliance, if the bullying persists he needs to go.
  • For Curly, I would let his funny flag fly. Work can be overly serious, and someone having fun is worth the distraction, up to a point. Before it gets to that point, gently guide him and the team back to agenda. If he has an out-of-the-box idea, explore it enough to see if it’s valid or might lead to an interesting, unexpected solution.
  • For Larry, make sure he has appropriate work to do and knows when you need it. Update your schedule so that Larry has enough time to complete the tasks. If changes need to be made to the plan, implement them in the beginning before you’re running late with few options.

Having a team with three Moes, three Curlys, or three Larrys would be terrible. Without a Moe, you’re unlikely to get the complex solution you might need. Without a Curly, work just wouldn’t be as much fun, and you’d miss his distinct perspective. Without Larry, it would be difficult to get the critical, but mundane, work done. An innovative team is stronger with a variation in strengths and styles.

Embracing Diversity

Having a diverse team can be seen as a challenge when it’s actually a strength. Without a variety of viewpoints and experiences, it’s very hard to come up with something truly new. As you build your team, it’s much better to have people who can constructively disagree than having everyone on the same page. It’s your job as a team leader to make sure the energy is productive and the direction is towards a solution, without zooming past Curly’s crazy idea that just might work while quickly eliminating Coyote’s overly-complex solution that won’t work.

A Project Manager is a Superhero (or, their Mild-Mannered Alter Ego)

If one reads the Project Management Institute’s Project Management Body of Knowledge (or as the cognoscenti call it, PMI’s PMBOK) you’d think there was just one way to be a project manager; a heavily waterfall approach that the cool kids think is old fashion. In the latest edition, they’ve added some information about agile approaches, but it reminds me of the parents in a mid-1960’s movie trying to sound cool to their hippie children. They just don’t quite get it.

If you talk to fans of an agile approach, you’d think everything can be broken down into sprints and that requirements documents are a waste of time. For them, an engaged stakeholder is assumed but—news flash—some stakeholders just want to be left alone until you’re done.

Fans of Kanban like to break everything into a queue.

As a fan of an adaptive approach, I like to talk about constant replanning based on learnings and risk reduction.

There are many ways to be a project manager, and none of them are perfect. The experienced project manager needs to have a variety of tools to manage a variety of situations.

Build your toolkit like a Superhero

In 1966 Abraham Maslow said, “If all you have is a hammer, everything looks like a nail.” To be an effective project manager you need to be Batman with his utility belt, not Spider-Man with just a web shooter. Maybe if you have super strength and spidey senses you can get by with just one tool, but most of us are mere mortals and need some options.

Speaking of spidey sense, what a great tool to have for risk planning! Experienced PMs develop spidey sense by seeing projects go sideways again and again. Even without the scars of experience, a structured approach to risk analysis can reduce the tingles of an unrecognized risk leading to problems down the road.

One of the challenges of a PM is to get the truth out of your team, so Wonder Woman’s lasso is a great tool. The team may know that the stakeholders want something in two weeks that will take them three and might be tempted to tell you what you want to hear, not the truth. You need to know up front how long the tasks will take in the beginning, not when you’re a week behind schedule. When things go wrong, team members sometimes try and fix it before the PM (or even worse, the stakeholders) find out. This is as helpful as a bad guy hiding the location of a bomb. The magic of the lasso is to never punish the messenger. Thank the bringer of bad news and work with the team to figure out how to proceed.

One does not need to travel to the Himalayas and seek out The Ancient One like Dr. Strange: your local PMI chapter probably has seminars that are more convenient and certainly more welcoming.  You can also read books and blogs (like the LiquidPlanner blog!), talk to colleagues, experiment on your team (obviously, you need to be careful about this one). There’s no shortcut and it’s a process you should be following throughout your career.

If you start a new job and they do project management differently than you have (as they probably will), think of it as a learning opportunity. Think about what this new paradigm does better than how you’ve practiced the art in the past, and what it does worse. (If it does everything worse, that’s the topic for another blog post on change management.)

A senior PM should be as flexible as Mr. Fantastic. “We’re going to do agile with the software team, waterfall with the hardware team, and Kanban with the test team.” shouldn’t pose a problem. There are structural challenges with multi-paradigm approaches but one of the problems shouldn’t be, “The PM doesn’t know how to manage an agile team” or, “The PM hates waterfall”. (There’s a great blog post on how LiquidPlanner can help.)

Choosing the right paradigm

Once you have a tool belt filled with cool gadgets, which one do you grab? Imagine how embarrassed Batman would be if he pulled out the grappling hook when he really needs shark repellant.

Or, using the hammer metaphor, before you get started on a project you need to recognize that the problem is installing a screw, that the right tool is a screwdriver, and that you know how to use it.

Leaving the metaphors and getting back to project management, let’s start with understanding the situation.

1. What is your project like?

I think the most important questions you can ask about the project are:

  • How complex is it?
    • task dependencies
    • multiple teams not co-located
  • How much uncertainty is there?
    • new tools
    • requirements undefined
    • solution not currently known

As a rule, waterfall handles complexity better. If your project has lots of tasks that must be completed in a particular order you’ll want to use waterfall or something the resembles it. If having a realistic schedule of when things will be completed is important, then you’ll also want to go with waterfall.

Agile and it’s fellow travelers (e.g. Kanban) handle uncertainty better. You can’t put together a work-breakdown structure if you don’t know how you’re going to meet your challenges. If you don’t have clear requirements or an architecture, you’ll want to avoid waterfall and use something in the agile space.

2. What is your team prepared for?

Next, look at your team.

  • What do your stakeholders need and what can they provide?
  • In what paradigms is your team experienced?
  • What paradigms do your process, procedures, and tools support?

Remember that your stakeholders are part of your team and you should start with their needs and capabilities. If they’ve provided you with a full and stable Product Requirements Document (PRD), then waterfall might be a good approach. If they’ve only provided you with a vague vision of the finish line, then agile might be the right way. If your stakeholder has never been the stakeholder in an agile project, make sure they understand what’s needed of them and that they are willing and able to do it before you go down that path.

The best path might just be to do whatever the team has strength in. If you’re Aquaman, you try and figure out how to use your ability to communicate with fish helpful.  I worked at one place that was so waterfall, they used it even when it made no sense because it was the only process the executives understood. Introducing a new project management paradigm would be harder than getting the US to go metric. I’ve worked at other places where a discussion of a PRD might as well be held in Klingon, because only a few people understood what the word “requirement” meant. Just like Aquaman fighting in space, you often find your tools are not optimal, but you do the best with what you have.

Some tools (like LiquidPlanner) are flexible and can support multiple paradigms. Others (like MS Project, post-it notes on the wall) are specifically designed for a particular approach. If your desired approach doesn’t align well with your tools and procedures, you need to decide if you can make do with what you have. Otherwise, it’s time for your company to invest in introducing new ways to work. Not a task to be taken lightly, rolling out a new approach is typically a major effort that will only pay off in the long term across multiple projects. It’s definitely not worth doing for just one project.

Be the mild-mannered Superhero your projects need

A project manager is in the “Batman” category of superheroes, people who have honed their mastery through dedication and experience, not the “Superman” ones who were born into it or bitten by radioactive spiders. I’ve always preferred these types of heroes, since their accomplishments are more impressive for the relative normalness of these people. And remember to always act as the mild-mannered alter ego; the best PMs are the quiet heroes who let the credit go where it belongs, to the team.



eBook: How to Manage Chaos

Every month, project management expert Elizabeth Harrin fields readers’ questions about the challenges, risks, and rewards of project work on the LiquidPlanner blog.

We’ve compiled our favorite columns in this eBook:

DOWNLOAD NOW

Icons made by Freepik from www.flaticon.com is licensed by CC 3.0 BY

How to Write Status Reports that are Worth Reading

Status reports are a critical part of project management. We all write them, but hardly anyone reads them. I don’t know how many times I’ve had a stakeholder claim to not know something that was in a status report…on the front page…in bold…with arrows pointing at it saying, “This is very important.

Okay, that last bit was an exaggeration, but the rest wasn’t.

I once had a client who refused to pay a bill because he “didn’t know what we were doing.” After reviewing months of status reports, he agreed to pay the bill.

I wrote these reports not to cover-my-tuchus, but so that the client would know what we’re doing and be aligned with it. How do we do project reporting in a way that increases project success? And how do we communicate appropriately to different types of stakeholders?

Be Empathic

There are some stakeholders who want to be involved in every decision, to know what everyone is doing and why. There are others who just want to know what, but don’t care about why. Some are obsessed with dates; others with dollars.  Some like written reports; others prefer phone calls. You can’t do meaningful project reporting without understanding what motivates your stakeholders.

In your meetings with the stakeholders, listen to what they care about and make sure your reports cover those issues. Asking is useful but listening to their questions often gives a better indication of their concerns than their answers. And be prepared for their focus to change.

Related: The Two Styles of Project Leadership

I once had a customer that started out caring only about schedule and halfway through shifted their focus to cost, possibly because someone above them on the food-chain started caring about that.

If your stakeholders prefer verbal updates, that’s fine, but you still need to put something in writing in case there’s a disagreement later. That might be a full written report that you review over the phone (preferred) or it can be meeting minutes that you send to your stakeholder immediately afterwards.

Tools like LiquidPlanner can help by providing easy access to which tasks have been complete, what tasks have been added, how much budget you’ve consumed, and how recent discoveries have changed the plan.

Be Actionable

One reason status reports are often not valued is that they sometimes aren’t actionable. As a PM reporting on the state of your project, think about the actions you think should be taken and what information your stakeholders will need to justify that action.

Related: How to Create More Powerful Reports with LiquidPlanner

For instance, if you’ve discovered a new risk, and you’re considering your mitigation options, your stakeholder might need to approve these mitigations. You’ll want them to understand well what’s going on before you approve it. If you need support from another team that will require re-assigning resources, the stakeholders should be alerted to the when and why of that in advance.

Separate out the Critical from the Deep Dive

This is probably the most important part of project reporting. There’s lots of information that you might want included, but you need to separate what your stakeholder has to know, from what you want them to know or what they want to know.

Related: How to Write a Killer Status Report

There should be a section that’s above the fold on the front page that if they just read that, they would know everything that’s critical. The rest of the report can contain more details or less important issues. If you’re emailing out your status reports as a separate document, then paste this critical information into the email. That way they can see the most important information even if they don’t open the document (as unfortunately will often be the case).

Consistency

Delivering your reports on the same day of the week that look the same every time helps your stakeholders efficiently absorb the information. You don’t want them to scratch their heads ever week to figure out “what does this mean” or “where is the budget status that I care about.” A good status report will not solve the problem of an unengaged stakeholder, but if you’re doing your job well they might start to look forward to your weekly updates!

Face It: Silos Exist. Here’s How to Make the Most of Them

If you Google the phrase “breaking down silos”, you get over 100,000 results. If you search for “building silos”, you get about one-fifth as many. The first result is “The Silo Mentality: How to Break Down The Barriers.”

There’s an assumption that silos are a bad thing. But, generally, if something exists, there’s a reason for it.

So rather than breaking down silos, I’d like to take a different point of view and ask:

  • Why do silos exist?
  • What are the pitfalls?
  • How do I make silos work to my advantage?

Why Do Silos Exist?

Silos exist because we have limited time and attention and need to focus on what’s important to do our job. Silos allow you to ignore a whole host of real issues and just solve “your” problems.

For instance, in product development, the mechanical engineers don’t need to sit in on schematic reviews with the electrical engineers or code reviews with the software developers. They need to focus on the mechanical parts of the design and trust that the other engineers are doing their jobs well. This doesn’t mean that the electrical, mechanical, and software engineers don’t have to coordinate, but that their communication focuses on the interfaces between the fields, and not every detail.

When I started the energy committee for the local chapter of the Sierra Club, I became an active advocate of silos. I had a limited number of hours I could devote to the committee (my wife referred to herself as “a Sierra Club widow”). The club had a century of history of protecting forests, rivers, and wildlife, and I was trying to do something different: encouraging the development of wind farms, solar power, and energy conservation. I promised the executive committee that I wouldn’t do anything that was at cross purposes to their other efforts, but I was going to operate as a silo.

There was an issue where there might be conflict: removing the Snake River dams. This was a long-standing priority of the Sierra Club, but would not help reduce greenhouse gas emission, my primary concern. I promised my committee would stay out of that issue and put our effort into taking down coal power plants.

I kept the leadership informed of major issues and, when appropriate, we worked with other committees. But I didn’t have time to follow everything that was going on or inform everyone regarding everything we did. They had to trust me, and I had to trust them. This committee has now been around for over a decade and is still largely independent and successful.

What Are the Pitfalls?

The most common pitfall of silos is generally referred to as: “the right hand doesn’t know what the left hand is doing.”

The frustration is enormous when you see two parts of an organization working at cross purposes. This is so common and so gumption-sucking that it’s assumed that anything that will make this happen less often is worth doing.

Almost all the problems with silos have to do with information not getting to where it’s needed.

For example, imagine you’re running a factory. If you haven’t gotten complete design documents from the engineers and forecasts from the sales team, there’s no way to make a sound decisions. You may find when you start up the manufacturing line that you are missing a screw that wasn’t in your bill-of-materials or insufficient parts to keep up with higher than expected demand.

How Do I Make Silos Work to My Advantage?

We think of real silos as isolated towers of grain surrounded by fields, but they aren’t really isolated. Grain goes in and grain comes out. Workers come and go. Information comes in about the price of wheat and the railroad schedule. A silo operator who doesn’t know the price of grain or if there’s room on the next train for his product will fail.

A well-structured silo is like well structured software: each component has well defined inputs and outputs and performs a well-defined task. If you’re in charge of a silo (we’re back to the metaphor), ask yourself what information you need to be successful. You then need to setup a process where you can get that information.

Imagine you’re running a sales team. There’s lots of information you need:

  • When new products are launching
  • How much it costs to make and your target margins
  • The capabilities of each product

There’s also lots of information you don’t need:

  • The name of the factory where it’s built
  • The names of the team members who designed it
  • The production methods (unless it’s novel and interesting to the consumer)

Basically, if it doesn’t help you sell the product, you don’t need to know.

You often hear engineers say things like, “I don’t care about sales or marketing.” But that’s not the right way to operate in a silo.

You need to care enough about the rest of the team to get the information you need for your project to be successful. If you’re designing something that’s very capable and expensive for a market that’s concerned about price, you’ll fail.

The engineers need to know what features the end-users care about and how much they’re willing to spend. They don’t need to read the notes from the focus groups that came to that conclusion (though they’re often worth reading for insight).

The marketing people don’t need to understand the technical details about product development, but they do need to understand if there’s an overlap between what people want and what they’re willing to pay for that’s big enough to make the product development effort worthwhile.

Wheat Isn’t the Only Thing That’s Golden

Remember you’re not the only one in a silo and your job is not just to be a customer of information, but also a provider. When you’re asked for information, use the golden rule and ask, “If I was them, would I want to know what they are asking?”

The answer is probably yes (otherwise, why are they asking?), so be generous with your precious time and help a fellow farmer get her grain to market.

How to Conduct a Risk Assessment for Your Project

One of the biggest challenges of project management is dealing with risks and opportunities. How do I build a work breakdown structure if I don’t know what’s going to be a problem down the road?

How do I build my team if the challenges are unknown? How do I effectively leverage good news? The difference between success and failure can come down to proper management of your risks and opportunities.

First, it’s important to understand the difference between an issue and a risk. A risk is something that might happen, while an issue is something that has happened. For example, climate change is an issue; an extinction-level asteroid strike in the next 100 years is a risk.

The first step to managing risks is to identify them early and take actions that reduce them, known as mitigations. A key tool to help you manage risk is a Failure Mode Effects Analysis (FMEA). You use this to find and prioritize your risks.

There are four stages to building your FMEA:

  1. What are the risks that might arise during the project?
  2. How important are these risks?
  3. How should we respond to these risks?
  4. Mitigate

What are the risks that might arise during the project?

Gather a group of people, some who understand the project well, but also a couple pairs of fresh eyes. All the disciplines that are involved in the project should be represented, possibly including engineering, manufacturing, sales, support, and marketing.

Once you’ve gathered the group, it’s time for some brainstorming. Just ask, “How could something go wrong (or right) that is a deviation from our plan?”

Related: How to Use LiquidPlanner Data to Find Project Risks

I like to break the problem into categories, like mechanical and electrical, to help make sure every area of the project is touched upon. No risk is too small, and everything is added to the list without filtering. There’s just enough discussion that the team agrees what the risk is and the text is unambiguous.

Let everything sit for a few days. It’s not unusual for someone to email you with more ideas after the meeting. That’s great, it’s a sign that the team is taking the exercise seriously. Just add everything to the list.

As an example, if you’re building an electrically powered device with a pressure vessel, your risks might include:

Area Risk/Opportunity
Mechanical Pressure vessel fails
Electrical Power demand exceed requirements
Thermal Temperature exceeds material limits
Mechanical Weight exceeds requirement

Table 1: List of risks from brainstorming session

How important are these risks?

After a few days, convene the group again. Add any ideas for risks that have occurred to people since the last meeting, but don’t restart the brainstorming.

Then it’s time to get to the hard part, quantifying the risks for severity and probability. First, set the ground rules. Each risk should be rated on a 1 to 5 scale for severity and probability. Some teams like a 1 to 3 or 1 to 10 scale, but I find 1 to 5 provides the right amount of precision.

The exact definitions can vary, so it’s important to define them for the project you’re scoring. You should have something like this:

Severity Impact
1 Minor impact to lifespan of product or functionality. Probably not noticed by end-user.
2 Some impact to lifespan of product or functionality. May be noticed by end-user, but not sufficient to create a poor impression.
3 Impacts the lifespan of product or functionality. Will be noticed by end-user and may lead to poor reviews.
4 Significant impact to the lifespan of product or functionality. Will lead to warranty returns and poor reviews.
5 Creates a safety hazard to the end-user.

Table 2: Severity will be different if the worst case is triggering a Richter 7 Earthquake or having to reboot your computer. Severity 5 is the worst thing that can happen and scale down from there.

Probability Impact
1 Happens 1/1,000,000 per unit per year
2 Happens 1/100,000 per unit per year
3 Happens 1/10,000 per unit per year
4 Happens 1/1,000 per unit per year
5 Happens 1/100 per unit per year (if you have 100 units in the field, you’d expect to see this once per year

Table 3: The probability should be scaled based on the number of units you expect to deploy. A probability of 1 should be rare, but not never, while a probability of 5 should be often, but not all the time. The above example would be appropriate for a device that sells about 100,000 per year.

Some teams include Discoverability (i.e. the difficulty of determining if the risk has happened). I find that adds more complexity, but not a lot of value. It also lowers the relative RPN of risks that are easy to discover, which might lower the priority of a critical risk.

You now go through each risk and rate how likely you think it is to happen and the severity (positive or negative) if it does.

Related: Reducing Risk and Uncertainty in Your Project

Everyone needs to understand that these are Scientific Wild-Ass Guesses (not to be confused with a Stupid Wild-Ass Guess): Don’t spend a lot of time arguing whether it should be a 3 or a 4. Just put down a consensus number and keep moving forward.

When in doubt, go with the higher number. You also need to calculate the Risk Priority Number (RPN), which is the Severity x Probability, for each risk. When you’re done you should sort the risks by RPN.

Do not discuss how to solve the problems at this meeting.

Area Risk/Opportunity Severity Prob RPN
Thermal Temperature exceeds material limits 5 2 10
Mechanical Pressure vessel fails 5 2 10
Electrical Power demand exceed requirements 2 3 6
Mechanical Weight exceeds requirement 3 1 3

Table 4: The list of risks after you’ve rated the Severity and Probability of each one. The RPN is a measure of how important each risk is.

How and when should we respond to these risks?

After a few more days of letting things settle, bring the group together again. Your rules should state a threshold and all risks with an RPN above that number must have a mitigation that should move the RPN below the threshold. Looking at our example we’ll create mitigations for risks with an RPN more than 5.

Temperature exceeds material limits

It’s hard to imagine a situation where the temperature of the device exceeding your material limit not being very bad, so we’re better off attacking probability than severity. A solution to this might be to select a material that can tolerate very high temperatures or add a design element that effectively limits the maximum temperature.

Pressure vessel fails

Like the temperature risk, we’re better off going for probability. One possible approach is to do a finite-element analysis (FAE), which is a computer simulation of the forces on the device. If the FEA says our design is safe with a margin of 100%, we can set the probability to 1.

Power demand exceed requirements

Our initial calculations suggest that the power demand is likely to exceed what our marketing team wants by 20%. The marketing team says that 97% of the market can provide 30% more power than the current requirement and they’re okay with changing the requirement. Often the mitigation is changing a requirement, not the design.

Weight exceeds requirement

The RPN here is below our threshold, so there’s no need to create a mitigation plan.

When you’re done, you should have something like this:

Area Risk/Opportunity Sev Prob RPN Mitigation
Thermal Temperature exceeds material limits 5 2 10 Explore material choice and mechanism to limit maximum temperature
Mechanical Pressure vessel fails 5 2 10 FEA
Electrical Power demand exceed requirements 2 3 6 Increase power requirement
Mechanical Weight exceeds requirement 3 1 3

Table 5: It’s common to include the Sev and Prob numbers you expect after mitigation in this chart.

Mitigate and Monitor

It’s now time for the team to implement the mitigations. After an agreed amount of time the same team should meet and review the situation.

  • Have we selected a material or a control mechanism to lower the maximum temperature?
  • What did the FAE show about the forces on the pressure vessel?
  • Have we updated the requirements document with the new power requirements?
  • Have we learned of any new risks that we neglected previously?

In my example, I’ve focused on how things can unexpectedly go wrong, but the same process can be used on how sometimes things go better than expected. Capturing opportunities is almost as important as resolving risks.

The intention is to reduce risks and uncertainty early, because some of the mitigations might force a significant redesign, which is a lot easier early in the project. The FMEA is just the starting point. Go forth and reduce uncertainty and successfully deliver to your stakeholders’ delight!

We Learn More From Failure Than Success: Lessons from the Kobayashi Maru

We have many words to describe a project in trouble—from “things have gone sideways” or “off-the-rails” to more graphic descriptions like “crash and burn.” The military has been a source of some lovely descriptions like FUBAR and SNAFU. The reason we have so many terms for projects not meeting the stakeholders’ expectations is because it happens so often. So, what do you do when your project goes off-the-rails?

Kobayashi Maru

The Kobayashi Maru is a no-win scenario at Starfleet academy to see how cadets deal with failure (see The Wrath of Kahn). As a project manager trying to develop cutting-edge products, I’ve seen my share of setbacks (and outright failures) and have learned much more from things going wrong then when things go smoothly.

If you take on challenging projects, you will eventually fail; probably several times. The key is not to never fail (though wouldn’t that be nice), but to always learn from your missteps and outright failures.

Kirk said he reprogrammed the computer that allowed him to successfully rescue the Kobayashi Maru because he doesn’t believe in a “no-win situation.”

 

I also believe that there is no such thing as a no-win situation: as long as you keep learning (and no one dies) then that has value. For instance, if a project fails, but the stakeholder learned that what they wanted to do is not possible given the current technology, then that’s a win. They can monitor the situation and restart the effort when technology can enable their vision.

Don’t Set Your Team Up for Failure Because of Someone Else’s Mistake

During an interview I was once asked what I’d do if the development team estimated a project would cost $1.5 million and then the sales team sold the project fixed-bid for $1 million.

I responded, “Oh, you’re asking me the Kobayashi Maru question.”

Luckily, I was being interviewed by a fellow Star Trek fan. She smiled and said yes. My response was to let the leadership know my goal would be to only lose $500,000.

Don’t let someone else’s failure (the sales team in this case) cause your failure. If I had tried to manage the team to the budget they didn’t set, it would have created an incredible amount of stress and a low chance of success.

Change the Rules

Kirk succeeded in the Kobayashi Maru challenge by changing the rules. In project management, that might look like working with stakeholders to change requirements, delivery dates, cost, or other constraints.

What you don’t do is release something that’s unsafe or violates the law. My rule is not to do anything you couldn’t justify to a reporter, a judge, or my mother. If you follow that guidance, you’re unlikely to change a rule in a way that you regret down the road.

Never Give Up—or At Least Not Right Away

If you’re trying to do something that hasn’t been done before, there’s a good chance that, at least once in the project, it will feel like your project is out-of-control. A risk became an issue; a critical team member gave notice; a requirement was added that will require a complete restart.

Investigate the challenge and focus on what success looks like now and make a new plan toward the new success. Always focus on the way things are, not the way they were or the way you want them to be, and the path forward will be clear.

Be a Mensch

When you screw up, own it. I’ve seen lots of examples of a minor mistake leading to larger problems because someone tried to hide or deflect an issue.  And if you’re going to learn from your mistakes, you first have to acknowledge that they happened.

 

When your project is going poorly, the stress on the entire team can go through the roof. The pressures to meet commitments you wish you hadn’t made are real and they aren’t going to go away.

But just because your project is FUBAR is no reason to be a jerk. Focus not on why the mistake happened, but how to make the situation better. Always be solution-focused.

You learn more from failure than success. The lesson may be expensive, so you might as well pay attention.

4 Guiding Principles for Leading Remote Project Teams

Today I received an email from a recruiter, reading:

Client seeking Project Manager to be the main liaison between the Technology group in the US and Offshore teams in India.

More and more, part of our job as project managers is not just herding sheep, but herding sheep located on farms located across the globe.

I once had a team that was literally spread across half the planet:

  • Firmware developers in Ukraine
  • Stakeholders and management in California
  • Stakeholders, firmware developers, and testing in Washington State
  • Semiconductor packaging management in Oregon
  • Semiconductor packaging factory in the Philippines
  • Semiconductor manufacturing in China

Other than the people in Washington (where I was based), I never met anyone on this team face-to-face.

Finding a time for phone conversations was onerous. Even if you got everyone on a conference call, you had to deal with poor sound quality, accents, and that half the team was speaking in a second language (if they knew English at all).

So how does one manage a project where you can’t walk up to the desk of your team members and understand what they have to offer, as well as their challenges?

Break It Down

Break down your problem into components and understand what communication is needed between the different components. For instance, the packaging (putting the semiconductor die into a plastic package) team doesn’t need to talk to the firmware developers, but the testing group does.

Organize your communication around issues, not around locations or teams. Issues will vary by project, but they should be as small as possible. Putting the requirements together might be too big, but physical requirements (driven by stakeholder and packaging) and functional requirements (driven by stakeholders, firmware, and testing) might be okay.  Your communications should include everyone that needs to be part of that chain, but no one who doesn’t.

Related: The Skills Project Managers Will Need in 2025

A standard management structure is also critical. There were eight Ukrainian developers on the project, but only two were part of the communication effort. Those two were responsible for representing their entire team, simplifying communication and giving the developers more bandwidth to write code.

Put Everything in Writing

“Precise questions and precise answers” was part of the company culture. You should ask questions that can be answered in one of three ways: yes, no, I don’t know.

This made conversations with the executives like talking with a teenager:

“Is the project going well?”

“Yes.”

“Will it be delivered on time?”

“I don’t know.”

These questions are great for email, and if every inquiry can be answered in this way, a disperse team isn’t burdensome.

But some questions are explorations.

“How do we address 85 lines with limited memory stretched across two dies?” was the fundamental question of this project. The answer “I don’t know” is accurate, but not helpful. Addressing this challenge requires brainstorming, testing of ideas, and a thoughtful exchange of ideas.

A common way to approach working together on this type of effort is over conference calls: long, inconveniently scheduled, hard to follow, conference calls. Some participants might be in a car or bus heading to or from the office. Many will be operating in their second language or on a low-quality VOIP line. My experience is these calls are expensive and ineffective.

Related: 6 Simple Ways Project Managers Can Improve Their Writing Today

Structured written communication is always a good thing, but in a dispersed project, it’s critical. For people working in their second language, it’s easier to take the time to craft an email than to explain their thoughts over the phone. Everyone has the chance to think about their response, to gather data, to mull it over with their local team, before they respond.

Decisions will take longer because you may only get one call-and-response sequence a day. But it’s more likely to be well-informed, and you’ll have a trail not only of what was decided, but why.

Make sure you account for this extra time when putting together your project plan. And sometimes, a conference call will make sense, if you need to quickly go through many cycles of give and take.

A few things can make the written communication a bit easier:

  • New questions should be broken off into a new chain to reduce confusion. Ever see an email chain go on so long that the subject line doesn’t match the conversation?
  • Emails are not structured communication. They have their place, but you might consider a more modern tool like Slack or LiquidPlanner. Long discussions with multiple people chiming in can be confusing on email, but Slack brings a modicum of order to rambling discussions. LiquidPlanner is nice because you can attach the conversation to a deliverable or task, making it easier to find what you’re looking for weeks or months later.
  • Everyone needs to respond as quickly as possible. It’s bad enough when you have to wait until the next day for an answer. Things quickly grind to a halt if you need to wait several days. I’ve been on projects where the 7 p.m. phone call happens just because the remote team just isn’t answering emails.
  • Sometimes the geography can work to your advantage. For instance, at the end of the day the software team releases code for test to a team that’s just showing up for work. When the software team shows up in the morning they can review the results of that testing.
  • Build your plan and share it. As the PM, the schedule is your responsibility. But, if everyone on the team doesn’t know what’s expected of them, the perfectly lovely .mpp file on your computer doesn’t do much good. I prefer a web-based PM tool (like LiquidPlanner), so that everyone can interact with the plan and understand the importance of their contribution.

Set High Expectations for Communication

I’m one of those people that sends an email to someone in the same room if it’s a precise question, because it’s less disruptive than interrupting the person and it creates a paper trail.

But that only works if everyone reads and responds to their email. For a collocated team, it’s easy to just walk over to someone’s desk if I don’t have an answer after a while. But what to do if they’re in a different country?

It’s critical that there’s a culture throughout the company of engaged communication: reading all your email, responding quickly to requests, and providing information needed without being asked.

I once worked at a small company with one person who worked remotely. He would engage directly with our clients without letting anyone else know the outcome of the discussion.

Related: The New Face of Project Leadership

He ignored email requests for information. He wouldn’t even fill-in his timesheet. When I spoke to his manager, the response I got was,“Yeah, that’s how he’s always been.”

There was no expectation from his manager or the CEO that he keep the team appraised of what he was doing. He was a talented engineer, but his inability to communicate coupled with the distance made him a net drain on any but the simplest of projects. I made it known that he was not to be assigned to any project I managed.

Things Won’t Always Go Smoothly

Running a team that’s spread across the time zones with people who speak multiple languages is inherently hard and is unlikely to go without a hitch.

If you and your team do a great job communicating, you’ll only occasionally find bumps in the road due to misunderstandings. When that happens, learn from what went wrong and move forward. Unfortunately, you won’t be able to all go for a beer as a team building exercise and celebrate your victories or lament your mishaps.

But you can raise a glass together at a video conference, but for some it might be a morning cup of tea.

Super Bowl vs World Series: A Project Manager’s Point of View

The great George Carlin did a classic routine about the differences between baseball and football that shows a comic at the top of his game without using any of the seven words you can’t say on TV.

Inspired by Carlin, I thought it would be interesting to compare the championships of the top two American sports from a project management perspective.

To fully appreciate this piece, imagine the bullet points being read by George Carlin.

Practice Beats Uncertainty

  • In football, the championship is a single game played at a time and location determined years in advance.
  • In baseball, the championship might be four, five, six, or seven games and the locations are determined just a week in advance.

Imagine the project management challenge of organizing an event with tens of thousands of spectators, most coming from out of town.

Flights and hotels must be booked; camera crews, food vendors, ticket takers, and security staff arranged. Now imagine that the event may or may not happen, and you might not know until the day before.

Running the World Series has an incredible amount of uncertainty.

I can’t imagine how difficult it is to run the World Series. The only thing that makes it possible is that the hosting team has lots of practice. The team (including the food vendors, ticket takers, and assorted staff) have practiced hosting over the 80 home games of the regular season, plus the post-season games. No one is being asked to do something new. It’s just that more people are watching on TV.

We’re used to thinking about the scope-cost-schedule triangle, but there’s also a complex-uncertain-novel triangle.

Imagine you’ve built a brand-new baseball park, and the first game to be played there is the World Series! You have complexity and uncertainty (like every other World Series game), but also have something new.

This is why running the Olympics is so hard. There is an enormous amount of complexity coupled with the uncertainty of every large or outdoor event. Plus, a majority of the people working the event have never actually attended the Olympics, much less worked at one. The Superbowl is a walk-in-the-park by comparison.

Plan for Every Challenge

  • In football, the game lasts between three and four hours.
  • In baseball, the game last between two and a half and five and a half hours.

The uncertainty in baseball isn’t just how where and when, but how long. Imagine telling your staff they might get off work at 10 p.m.… or maybe 1 a.m. The game could run so late that the transit system might close, so you need to have a mitigation in place to deal with that.

But again, that’s just normal for baseball. The mitigations needed for a long game need to be in place for every game. Even the television networks are prepared for a late game and schedules reruns or the news afterwards, so it’s OK if the game runs late.

Field Your Team Strategically

  • In football, you put your best players on the field for every game.
  • In baseball, your best pitcher might only play 20 percent of the games.

The Super Bowl is like a single project company. You put your best team on the field. The World Series is like a matrix environment where you’re building seven teams that can succeed at least four times. Several of these projects may never launch, but you need a team ready for them, regardless.

Building a team from the resources available is often a challenge. Paraphrasing Donald Rumsfeld, you launch the project with the team you have, not the team you want. Just like you can’t start every game with your star pitcher, you can’t include your best contributors in every project.

Say What You’ll Do; Do What You Say

  • In football, you play in any weather.
  • In baseball, the game can be called due to weather.

In any project where weather is a factor (e.g., construction, transportation, outdoor events), it always adds uncertainty and requires mitigation plans. Football and baseball deal with this uncertainty very differently.

Baseball cancels the game, which means people go home and come back another day or ask for refunds. This complicates everyone’s schedules and can lead to unhappy spectators. Football just plays on, so you need to have plans for the athletes and spectators in cold weather. When you see fans clutching their thermoses, wrapped in snow covered blankets, you’ve got to imagine that the concession stands are selling a lot more coffee and blankets. If they run out, there could be a riot.

Both approaches are valid, and spectators understand the consequences of bad weather. When running projects, you need to have mitigation plans that everyone understands. If you expect to have the game called due to rain, you’re not going to bring foul weather gear.

Set Everyone Up for Success

  • In football, the rules are the same for the championship as the rest of the games.
  • In baseball, sometimes the pitcher goes to bat and sometimes he doesn’t.

Pity the National League player who is facing a MLB pitcher for the first time at what is the highest stake game he’s ever played. Everyone else is doing the job they do all year, just with extra pressure and attention. He’s doing something he hasn’t done in a game since college.

Sometimes when we’re running a project, we need a contributor to step out of their comfort zone. Maybe they need to make a presentation to a client or executive. Maybe resolve a challenge that requires them to stretch their technical skills. Maybe they’re a meat and potatoes kind of person who needs to travel to China.

We as project managers need to recognize the challenge, acknowledge it, and set the contributor up for success. Metaphorically, we need to have some serious batting practice with a real pitcher throwing real fastballs.

Don’t Just Chase the Ball; Think Strategically

  • In Football, some people watch the championship just for the ads.
  • In Baseball, the ads during the championship aren’t particularly interesting.

People focus more on things that last for three hours than something that lasts 30 hours. We are easily distracted, more so now in the age of smart phones. Project managers and our stakeholders are no different. It’s easy to get distracted and focusing on what’s in front of us like a herd of 5-year-old soccer players chasing the ball.. But we also need to pull back and look at the big picture.

So, sit back, crack open an American macro-brew, grab some chips and salsa, join with some friends, and enjoy the Super Bowl. Just appreciate that in addition to some world class athletes, the game is brought to you by some hardworking project managers.

Lessons Learned as a First Time Medical Device Project Manager

In 2001, I joined Calypso Medical as employee number 18. Our goal was to create a remarkable medical device that could track the location of the prostate to a millimeter of accuracy during prostate cancer treatments.

This level of accuracy is important because the prostate has a tendency to move unpredictably during normal bodily functions, like coughing, going to the bathroom, or passing gas. This makes it difficult to direct the radiation to the correct spot. Healthy tissue may accidentally receive the radiation, which can lead to increased side effects.

We called it GPS for the body. Rather than satellites whizzing around the earth to pinpoint your phone’s location, a sensor array the size of a pizza box hovers directly over the patient’s abdomen. This sensor communicates with three transponders, about the size of a grain of rice, that had been implanted in the prostate in an earlier procedure.

During treatment, the radiation technologist (RT) monitors the location of these transponders. If the prostate moves outside of the radiation beam, the RT is immediately alerted and can reposition the beam so that it is once again focused squarely on the tumor. If you know where the device is, you know where to target the radiation.

For this to work, we needed another system that could determine the location of the sensor array. Figuring out the best way to solve that problem was my job.

Walk a mile in your users’ shoes.

As is typical in small companies, everyone wore multiple hats.  If I wanted to understand what was happening during treatment and how it would constrain my system, I would need to figure that out myself.

[Further Reading: A Look Inside Project Management at StarFish Medical]

Luckily, a local hospital was very helpful and let me hang out with the RTs as they did their job. I watched how they aligned the patients and moved about the room and spoke with the medical physicists about how they calibrated and aligned the equipment. I needed to design my system to work with what was already happening. Ideally, it would be invisible to the RTs and patient.

Build prototypes to simulate products in real-world settings.

After exploring several options, I settled on a ceiling mounted camera system that would see the array and could figure out its location. I used three cameras, even though two would be enough, so that the RTs could move about the room and not worry if they were blocking one of the cameras.

I developed simulations and was confident the system would work. But a prototype is much more convincing and can test errors in your assumptions that a simulation might miss.

I built the prototype with commercial-off-the-shelf tripods and cameras and software that I wrote. In testing we showed the concept worked even if you blocked a camera or the targets.

I then installed my prototype in an unused treatment space at the hospital, and we were able to simulate realistic usage. This work convinced the company leadership that I was on the right track.

Choose your partners carefully.

Once everyone agreed that my concept would work, I was directed to select a partner to implement my concept in a way that would pass muster with the FDA.

The perfect partner would have certain features:

  • An existing solution that could be leveraged for our needs
  • Their team had the desire and ability to customize their solution
  • Their solution had been through the FDA regulatory approval process
  • Geographically close to our office in Seattle
  • Reasonable business terms
  • A team that would be easy to work with over the long-term
  • A company that was stable enough that we didn’t have to worry about them going out of business

Not surprisingly, no such company existed.

One company had an FDA-approved camera-based solution, but the solution didn’t have the resolution we needed and wouldn’t work if someone walked in front of a camera. Any solution they created would have to be built from scratch.

Another company was a spin-off of a university in Munich, Germany. Their solution was technically solid, but they were a startup with no other customers and definitely not geographically desirable.

A third company had a technically solid solution and several customers in the movie business. They were a leading company for motion capture and had worked on movies like “The Hobbit”. Their location in California was not ideal, but at least they were in the same time zone and a single flight away.

The only missing element was that their device hadn’t been through an FDA approval process. We worked with a regulatory consultant and the company to develop an approach that worked for everyone. It’s been over 15 years, and this partner is still providing the camera system for the Calypso tracking system.

Anticipate and prevent product failures using failure mode and effects analysis.

When designing a medical device, it’s critical that it works as it’s supposed to. The alternative can be the death of the patient. One of the tools that we used to accomplish this was failure mode and effects analysis (FMEA), a structured way to analyze how a product might fail and what you can do to prevent it. In this context, failure means the product doesn’t deliver the required performance, not that it stops working.

For instance, if your requirement is accuracy no worse than 1.0 mm and a condition results in a location error of 1.1 mm, that’s a failure.

FMEA typically starts with a brainstorming session where you identify ways that failure might happen. Our failure modes included:

  • Changes in the room temperature causing the camera mounts to move, pushing the system out of calibration.
  • The radiation environment in the treatment vault (both gamma rays and neutrons) causes cameras to fail.
  • Partial obscuration of the targets on the array, leading to an inaccurate location solution that doesn’t trigger an error condition.

For every failure mode we stated a severity (how bad would it be if this happened) and an occurrence (how likely would it be to happen). For example, a failure mode that shuts down the system (like a dead camera) would be high, but not the worst. The most severe failure mode is one that could lead to accidentally targeting radiation to the bowel or bladder, resulting in serious side effects.

[Further Reading: Ask a PM: School vs the Real World]

An interesting failure mode that we discovered was exposure to neutrons, sub-atomic particles with no charge.  The process of creating the beam of radiation used to kill the cancer cells also created a flood of free neutrons that might damage our electronics.  I flew our cameras to one of the only two neutron test sites in the U.S. and exposed our camera to 10 years’ worth of neutrons in a few hours.

From that test, we learned that one component was sensitive to neutrons and needed to be replaced.

If we hadn’t done the FMEA work, our cameras would have started failing in the field. Until we figured out the pattern of failures, the cameras would have just been replaced. Once the root caused was determined, we would have needed to replace the part and recertify the cameras, delaying new installations. This would have hurt our reputation, which can be the death knell for a small company.

Take pride in your work.

There’s a special satisfaction of playing on a game system I helped design or seeing drilling equipment I worked on in action.  But nothing matches the satisfaction of talking to someone whose father’s cancer treatment was improved by a product that I worked on.

It’s even gratifying that the photos of the system never include my camera system. It’s a sign that I accomplished my goal of making my part of the system invisible. That helped prepare me to become a project manager, where our contributions are typically critical, but invisible.