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.

Lessons from My Winding Path to Project Management

When you query a group of second graders about what they want to be when they grow up, they’ll say an astronaut, doctor, firefighter, scientist or some other cool job. By the time they’ve started college, the list has expanded to include engineers, teachers, nurses, and other perfectly reasonable jobs.

But no one picks their college because of its top-rated project management program. We are all accidental project managers.

My journey is a bit more unusual than most. I started college wanting to be a scientist and got the education to match—a PhD in Physics from MIT. But I then decided to follow another path, which has led me to project management.

From the beginning, I knew I was following an unconventional path, so I needed to keep my eyes open to the side paths that became part of my journey. It’s a journey that I’m still on and the path to its end (i.e., a comfortable retirement) remains murky, but I believe the tools and lessons that have carried me this far will carry me forward.

I hope some of my lessons can help you in your journey, as well.

Always be open.

In 1996, I had decided to move from academia to industry, but I had no experience, the wrong degrees, no connections, and really no clue on how to make that move. I took the summer off to visit family, spend a week pretending to be an oceanography graduate student, and travel around the Alaskan panhandle by ferry and foot.

On the flight home from Juneau, I started chatting with the person next to me. He was a headhunter who specialized in hiring mathematicians and physicists for Wall Street. I had no interest in moving to New York, but he was happy to share advice working with headhunters. As soon as I got back to Seattle, I followed his advice, which directly resulted in finding a perfect job. How different my life would be if I hadn’t started chatting with him!

Most people are happy to talk about what they do and offer advice. Look for people who have your dream job and reach out to them. Offer to take them out for coffee. Make it easy for them by being flexible about time and meeting near their office. Don’t ask for a job; ask for advice. If they have a job for you, they’ll let you know.

When networking, you should have an interest in what others have to offer. It’s not about you impressing them as much as learning from them. And Karma is a big part of networking: always be on the lookout for opportunities to help others.

It’s much easier today than it was in 1996, which was two years before Google was founded and six years before LinkedIn. Build your LinkedIn profile. If you ask someone to meet for coffee, you can be sure they’ll look you up there before they say yes. Just like your resume, don’t lie or exaggerate, but put your best foot forward.

Always be learning.

In the movie Paycheck, Ben Affleck starred as an engineer who has his memory wiped after every project. I found that premise absurd. Engineers (and project managers) improve by doing the work and learning from their successes and failures. If your memory was wiped after each project, you would stagnate while others kept getting better.

My first job was at Neopath, a company that made an automated microscope that diagnosed cervical cancer. I worked on a host of projects across the company, including optics, electronics, root-cause analysis, and manufacturing. What I didn’t work on was image processing, which was our core technology. But over the course of three years I learned enough to develop image processing algorithms for an automated microscope in my next job.

This happened again when I was at Calypso Medical, a company that developed an amazing technology to target radiation therapy for cancer treatment. I developed a camera system to determine the location of a sensor array, but our core technology used AC magnetic fields to determine the location of the prostate. My next job at Digital Control was developing industrial equipment using AC magnetic fields to determine the location of a underground drill.

My role at Calypso started as very technical, but once I had built a prototype and demonstrated my concept would meet our requirements, I was tasked with selecting a vendor and managing them to deliver a solution using my concept. My role became that of a project manager.

My next role at Digital Control also started out as technical, but I found my newly developed project management skills were more important to a project’s success than my technical ones.

As I found myself doing more project management at companies with no project managers, I looked elsewhere for help. I considered getting an MBA. But I couldn’t carve out the time to make that happen, so I enrolled in a certificate program for “Management in the Technology Sector.” The program included classes in project management, team leadership, and business strategy.

If you’re not learning new skills at work, it might be time for a change. Talk to your manager about taking on new responsibilities or moving to a new group. If that’s not an option, take a class or look for opportunities outside of work that will challenge you. Find a non-profit that you care about and offer to help. Before you know it, you’ll be drowning in learning opportunities.

Always be positive.

My career has had more than its share of bumps in the road. The worst was in 2008, when I was laid-off at the beginning of the Great Recession. Over 10 months, I had one phone interview.  Every day I would look for open positions and networking opportunities.

Finally I got a job running an energy efficiency project funded by the federal stimulus act. I was offered the job because of my volunteer experience founding the energy committee at the Sierra Club and my work as a project manager. Though it wasn’t my dream job, I involved myself in every aspect of the project, including marketing, training, and quality control. I met some great people and the project exceeded our targets. When the high-tech sector recovered, I moved back into product development, now with even more project management experience.

It’s great to have a vision of where you’d like your career to go and to get the experience and training you need to get there, but in the fast-moving world of technology that’s unlikely to be sufficient. So many interesting industries of today didn’t exist twenty years ago. Just in the Seattle area we have Facebook/Oculus doing virtual reality, Amazon in eCommerce, and Blue Origin in space tourism.

No one starting their career in 1997 would have thought to create the perfect path for a job working at any of these places. But if you are always learning, watching for new opportunities, and keeping a positive outlook, you might just find you’re the perfect person for the dream job you couldn’t have imagined five years earlier.

It’s fine for your journey to follow a circuitous route; sometimes that’s the only way to get to where you’re going.

When You’re the Company’s First Project Manager

In the beginning, project management was formless and empty, and darkness was over the work breakdown structure. The Founders looked over the face of the startup and said all is good. And there was evening, and there was morning—the first day (metaphorically).

Then the company grew and its teams were fruitful and multiplied.

Projects competed for resources, and everything was late. The Founders looked upon the chaos and were not pleased. They looked upon the multitudes and chose one who was more organized or less busy than the others and said, “It is up to you to be a prophet, bringing order to the chaos and leading the projects to the promised land of on-time delivery within budget. You must quiet the babel of squabbling the offends our ears.”

So you have now been appointed to be your company’s first project manager.

You may have never been a project manager. You may have never worked with a project manager. Your company has no templates, no resources, no software, and, most importantly, no culture of project management.

Where do you start?

Have a clear mandate from the leadership.

I once worked at a small company without project management and was struggling because of that, so I just started doing project management without any training or buy-in from the company leadership.

This did not go well!

I wrote the company’s first requirements document. As we reviewed the document, one of the stakeholders said, “I’m used to just complaining when engineering delivered something that isn’t what the market wants.”

I explained it was easier to build things right in the first place, which made a lot of sense to him. Having a requirements document reduced the constant churn of the product definition and helped the engineers focus on what they should be delivering.

Delivery dates were based on when someone wanted a product and not a detailed plan. I was sick one day, and on my return the scope of a project I was leading had changed significantly, but leadership expected no schedule slip nor did they allocate additional resources. When delivery dates aren’t based on real plans, then management can’t make the cost-benefit trade-offs that they should.

People were moved on and off projects with no warning or notification. No one set priorities among the large number of active projects. Not surprisingly, every project was late.

Without a mandate from the top, I was unable to control how resources were allocated or expected completion dates were set. I could change things around the margins, but not fix the underlying . Quoting from Reinhold Niebuhr’s Serenity Prayer:

God grant me the serenity
to accept the things I cannot change;
courage to change the things I can;
and wisdom to know the difference.

Do what you can, make the case to do what you should, but if there’s no buy in, accept that and hope that your example of good management over time will change things.

Always be adding value.

For a salesman, the key is to Always Be Closing. For a project manager, you need to always be adding value, or at least not subtracting value.

Before you were anointed as your company’s first PM, things were done a certain way and it probably gave the individual contributors a lot of autonomy. They probably “knew” what needed to be done (and were probably right most of the time). They won’t appreciate you coming in, setting priorities, and “getting in the way”.

For you to do your work (e.g. building schedules and writing status reports), they’ll need to spend time sharing their expertise and knowledge. If they don’t see the value project management adds, they’ll see this as “wasting” their time that should be spent doing valuable work.

You need to be gentle but firm with this pushback. Make sure you get what you need to be successful, but be as accommodating as possible. Maybe you put together a starting point work breakdown structure and ask, “Where is this wrong?”

Listen more than you speak. Before sending a status report to stakeholders, send it to the team. This provides the team with an opportunity to check it for accuracy, helps them understand why you’re asking for their updates, and shows them that their concerns are being communicated up the chain.

Whenever possible, be a resource to make their job easier. One of the best ways to help the contributors is to create schedules based on input and logic, rather than management’s hopes and dreams. Having clear requirements can be a great help to the individual contributors as can going to battle getting resources (e.g. software upgrades, test equipment).

You could volunteer to take on vendor logistics and management. Everyone should know that you want to help and nothing is beneath you. Be careful not to take on tasks that the team doesn’t want you to do.

Methodically build your infrastructure.

You’re starting with a blank slate, which is a wonderful opportunity and a daunting task. You’ll need a task management tool (like LiquidPlanner), bug tracking system, standard-operating procedures, document control, and the list goes on and on and on.

Where to start?

Pick the biggest project management related problem you currently suffer from, and work on solving that. Maybe managing resource conflicts is the biggest problem, in which case I’d start with a list of every project in priority order, which can help manage conflicts.

If that doesn’t solve the problem, try creating a matrix with every project on one axis and all resources on the other. Add how much time each team member is expected to spend on that project over the next two weeks, and work with the managers to update this sheet regularly. If any person is loaded by over 85 percent, gather the impacted managers and negotiate.

If that doesn’t solve the problem, then implement a tool like LiquidPlanner that can balance resources automatically across multiple projects. In every case, implement the simplest solution that solves the problem.

Be a problem solver.

As you help your company eliminate barriers to success, the team will see the value you’re adding and be more eager to help you build strong plans.

When they see delivery dates based on detailed schedules they helped create rather than when somebody wants something delivered, they’ll be happy to contribute to the planning processes.  When engineers no longer feel pulled in five directions by three people, they’ll understand why you’re not just “overhead”.

Every time you solve a problem it makes the next one easier.

May the Fourth Be With You: Project Management Lessons from the Star Wars Rebel Alliance

In honor of today’s celebration of all things Star Wars, I thought it would be worthwhile to mine this epic tale for project management lessons. While many have written about the Empire’s challenges constructing the Death Star, I’m interested in what can be learned from the victors, the Rebel Alliance.

Build a Diverse Team

The project team in A New Hope was fairly diverse. (Okay, not great gender diversity, considering everyone but Leia was male). Their ages varied, ranging from 19-year-old Luke and Leia to 200-year-old Chewbacca. Some were biological; others droids. Some were experienced; others less so. Some thoughtful, others prone to action.

Obi-wan was a Jedi master and military commander. Leia, despite her young age, was an experienced diplomat. Han and Chewie had extracted themselves from many a tough situation. And Luke was courageous, enthusiastic, hardworking, and force-sensitive. R2-D2 was a veritable Swiss Army knife of capabilities. His tools and skillset included the ability to communicate with main frame computers, a fire extinguisher, spaceship repair, and data storage. C-3PO was good for comic relief without being too annoying (see Binks, Jar Jar). Everyone brought their unique gifts to the team, and gave 100% (except C-3PO).

Better to have diversity than a team who are all very good at the same thing. Diversity brings different approaches, which makes innovative solutions more likely.

I once worked with a team of smart, young engineers. They were great about asking the experienced engineers for design reviews or brainstorming sessions. They were open about trying new ideas and quickly built prototypes to test their ideas. In a few weeks, they had a working proof-of-concept for a problem that our client had worked months on without progress. A team of just the “grey hairs” or just the young’uns would not have been as effective.

Work the Problem

When presented with a problem, our heroes never gave up. They continued to work whatever problem they were presented with. When Han, Chewbacca, Luke, and Lela were trapped in the cell block on the Death Star, they just kept working the problem:

  • Escape the attacking storm troopers by shooting open the garbage chute and jumping into the trash compactor
  • Shoot the door, which was magnetically sealed, so that it would not open
  • Save Luke from the monster
  • Use material in the compactor to keep from being crushed
  • Call C-3PO and R2-D2, who stopped the compactor and opened the door by talking to the main frame computer

Sure, there was some insults hurled and not every idea worked. But they kept at it until they had a solution.

Often when working on a project, things don’t go as you planned: one of your risks becomes an issue, a requirement changes, or a key contributor leaves the team. Focus on the problem that you need to solve, not the one you planned to solve.

It’s also important that your stakeholders know how things have changed. It’s possible that the proper response to the new situation is to cancel the project, and the stakeholders must be given an opportunity to recommit to the new plan or cancel the project.

Share Your Plan

For project managers, creating a plan and not sharing it with the entire team is a common mistake.

In the beginning of A New Hope, the construction plans of the Death Star are uploaded by Leia into R2-D2, and no one else sees the plans until the team arrives at Yavin IV. Until then, R2-D2 is a single point of failure. If he’s destroyed, the project fails. [Spoiler Alert] The Rebel Alliance does not learn of the weakness designed into the Death Star. And, thus, Luke cannot destroy the Death Star.

Why not give everyone a copy, so that if anyone gets to the Rebel base, the project will succeed?

Have you ever worked on a project where the PM has created a detailed plan in MS Project, and the only copy of the plan is on the PM’s computer?

Even if everyone had a copy of the .MPP file, most engineers don’t have MS Project on their computer. Maybe the PM converted the plan to MS Excel. But now the plan doesn’t have the dependencies and critical path clearly labeled. The team can’t interact with the plan and point out where it’s out-of-date.

That’s why I prefer using web-based tools, like LiquidPlanner. It’s easy to share the plan with the entire team and easily get their input in the creation of the plan.

Use the Force (Go with Your Gut)

The most important lesson from the rebels is that sometimes you need to “use the force” to make decisions with incomplete information.

I’m not suggesting we go through our project with the blast shield down, unable to see what’s is right in front of your face. But there are times, especially early in a project when there’s a lot of uncertainty, that even with your eyes wide open there’s no way to be certain what the right path is.

That’s when you use the force to understand what is that best path through the asteroid field.

As project managers, it’s nice to be able to look at a plan, focus on the work breakdown structure and critical path, and know what the most important tasks are. But sometimes things aren’t that clear, and you’ll have to fall back on experience to provide direction. Tools like a risk register can help, but they don’t stand in for being force-sensitive.

Your mission may not be “vital to the survival of the Rebellion”, but that doesn’t mean it’s not important.

Every project deserves a solid team with the needed skills and a “work the problem” attitude. Every project manager needs to share their plan and communicate to meet their stakeholders’ needs.

And sometimes, you just need to set the flight computer aside and pull the trigger like you’re shooting womp rats back on Tatooine. Maybe you won’t get a medal at the end, but neither did Chewie or R2-D2. They understood that success is its own reward.

Is Your Team Wasting Everyone’s Time?

Learn how to ensure your team is working on the right task at the right time.

What happens when uncertainty and risk are poorly handled during a project? Almost always, it results in missed deadlines, wasted time, and unhappy stakeholders.

I once took over a project that did not have requirements documents. The developers were writing code without a solid vision of what it should do. When they shared their results, the stakeholders would complain and send them back to rework the code, which wasted everyone’s time. Later, we discovered the hardware would not work, requiring them to start over with a new architecture. That wasted even more time, and the project took twice as long to complete.

That’s what happens when uncertainty and risk are poorly handled.

For projects like hardware product development, where there is a lot of uncertainty and complexity, it’s critical to understand which tasks are most important. Otherwise, your team will find much of their effort is wasted. Successfully managing these projects requires a delicate balancing act between removing uncertainty, reducing risk, and progressing along your critical path. I call this approach “adaptive project management”, which takes elements from both waterfall/standard project management (which handles complexity well and uncertainty poorly) and agile project management (which handles uncertainty well, but complexity poorly).

Removing Uncertainty

Early in an adaptive project, your focus must be on removing uncertainty. How can you write code if you don’t understand the needs of your end-users or build prototypes if you don’t know what technology best meets your needs? At this point your focus will be engaging with stakeholder or end-users, exploring the capabilities of technologies you’re considering, and understanding resource and budget constraints.

This effort will continue throughout the project, but can drop off once you understand the project well enough to build a work breakdown structure (WBS). The WBS will include tasks to remove the remaining uncertainty. The nature of adaptive projects is that you march on with some uncertainties rather than drive them all to zero in the beginning, as you would in a waterfall project. As your uncertainties drop, your plan should start looking more waterfall.

Reducing Risk

Risks are set in the future; issues are happening now. The problem with risks is that they can develop into issues. Solving issues takes time, which can lead to delays and increased costs. The sooner you can turn risks into issues or make them go away, the better.

Once you have a reasonable understanding of your project, you need to build a risk register. Make a list of what might go wrong, how likely it is (probability), how bad it will be if it happens (severity), and what you can do if the risk occurs (mitigation). I prefer a ranking from 1 to 5. For probability, 1 corresponds to a likelihood of < 20 percent, while a 5 corresponds to a likelihood of greater than 80 percent. For severity, 1 corresponds to a small impact on the project that is unlikely to put any milestones dates or budget constraints at risk. A 5 means that the entire project might need to be canceled, possibly because a critical feature is not possible or our cost-of-goods sold will be significantly higher than expected.

I also include a column for importance, which is the product of probability and severity, and rank the risks in order of importance (see Table 1). Some of your effort should always be spent on reducing the most important risks, either by testing to see if they’re real issues or building the mitigation. This effort should be part of your work breakdown structure.  I also build the mitigations of high-probability risks into the plan, with the goal of reducing surprises down the road.

Risk Probability Severity Importance Mitigation
Unit fails electro-compatibility testing 4 3 12 Build Faraday cage around electronics
Passive cooling isn’t sufficient 3 2 6 Add a fan

Table 1: This is a simple risk register. More complex versions include things like discoverability (how likely it is the risk will happen, but you won’t be able to detect the failure) and contingency (what you will do if the mitigation doesn’t solve the problem). I find a simple risk register sufficient and easier to keep current, which is more important.

Progressing Along the Critical Path

Once you have organized your tasks and time estimates into a work breakdown structure, you can use project management software like LiquidPlanner to build your schedule and a Gantt chart. You can then select a milestone and filter to those tasks that are on the critical path (i.e. tasks that will cause delays if they slip by a day). While all tasks need to be completed, those not on the critical path can slip without impacting deliverables.

Use your tool to determine if deliverables will be completed in time to meet stakeholders’ needs. If not, work with your stakeholders to understand how important this deliverable is and whether it can be descoped. Another possibility is to transfer resources from risk reduction to critical path tasks. If you go this route, explain to your stakeholder that this increases the chance of an issue appearing late in the project, when it’s harder to fix.

A Good PM is a Tightrope Walker

The job of the PM is to balance these three areas. Overtime the critical path will become more important and reducing risk and uncertainty less so. But there’s no formula to answer what you should do. A tool like LiquidPlanner is like the pole that helps the walker maintain his balance.

In the end, it’s up to you and your team to understand if: you’ve reduced uncertainty enough that you can start to focus on risks; that you’ve reduced risks enough that you can focus on your critical path; and that everyone is working on the most important task at that moment. When you get it wrong (e.g. a low probability risk turns into an ugly issue late in the project), just smile and focus the team on what are now the most important tasks.

Looking for more tips to help you save time, increase productivity and motivate your team? Check out our guide, “5 Practical Habits for Today’s Project Manager.”
5 Practical Habits for Today's Project Manager

How Project Management Accelerates Product Development

Long ago, in a city not far away, I worked for a very profitable company that got its start in the garage of one of its founders. We had grown to about 120 people with worldwide sales. Our products were the undisputed gold standard of the field. The employees were well paid and generally quite content. What’s not to like?

project management

But if you looked closer, there were some problems. Our product line had never been refreshed; 12-year old designs were getting harder and harder to build as components went end-of-life; the manufacturability and reliability of our flagship product was poor; new product development was sluggish and unfocused.

I joined the company as an engineer, but it was obvious that we didn’t need our twentieth engineer; we needed our first project manager. As such, I wrote the company’s first requirements document, and got the stakeholders to agree to the product definition. I did what I could to add rigor to the development effort.

When I took over the project to write the software for the refresh of our flagship product, I created a giant flowchart that showed every possible interaction that a user could have with the product.

This story almost had a happy ending

In the end, I couldn’t get any of the other project leads to follow my example and use a project management process. As a result, a redesign project that should have taken less than three years to complete took seven.  Sure, there were challenges getting the hardware to work, but these challenges paled in comparison to the delays caused by the lack of project management and a product development process.

My experience at this company served as both a motivating force and a warning for the importance of applying project management practices to the product development process.

If your team struggles to develop new products in a reasonable time, you could be missing a simple tool: project management.

Here are four ways to incorporate project management into your product development process.

1. Have a requirements document

Every project should have a requirements document that describes what the goals of the effort are and what “done” looks like. The flowchart I mentioned earlier served as our requirements document: If it was on the flowchart, we’d implement it, otherwise we wouldn’t.

Your requirements doc can be short and simple or long and detailed, depending on the situation. More importantly, it should be approved by all of the stakeholders.

By putting requirements in writing, you can avoid false consensus, where everyone thinks they know what the end product will look like, and someone has a different idea. You will also need a process to update this document, because there will be changes as you progress. All of the stakeholders should understand what these changes are and why the requirement is changing. In the end, it’s much easier to move an arrow on a flowchart than to change code and retest.

2. Have a process to start and stop projects

Just like people, healthy companies must grow and mature. They go through stages of development, and project management should grow along with the company. Too often, as companies grow, project management is one or two stages behind where it should be.

As you grow, you’ll need a process to green light new projects, making sure you have a requirements document and the resources to do the work. You also need a way to kill the projects that don’t make sense as soon as possible. Having a prioritized list of every project will help when there are resource conflicts.  Finally, have a list of pending projects, so that good ideas have a place to wait until you have the resources to start the effort.

3. Treat project management like your other disciplines

You want to grow your company’s project management maturity along with the size and number of the projects that are happening. If your company is big enough to have a director of mechanical engineering, it’s probably big enough for a director of project management who is responsible for mentoring the project managers and developing good process.

You should also make sure you have top quality tools. I’ve seen companies skimp on this one, and it just doesn’t make sense. If you’re paying your project managers and engineers a good salary, a tool that increases everyone’s productivity will have a positive ROI.

4. Always focus on adding value

You need to guard against process that doesn’t add value. To do this, update your old processes to make sure they fit the reality of what the company is and will become—not the company that was.

One process that always adds value is bug tracking. If you find a bug that you can’t fix right away, you need a proper database to store it. It’s better to ship a product with known bugs that you’ve decided are low enough risk than to ship with unknown issues. The truth is, there are always some unknown bugs. What’s unforgivable is when you ship with bugs that you’ve just forgotten about. All of the bugs in the database need to be prioritized. Prioritize them as compared to the other bugs, as well as to new features.


Proper process is critical to running a healthy company. If you just let everyone do what they want, a rogue trader may cost you two billion dollars. If you run a multinational corporation like a startup, there’s no way for management to say, “We need to focus on the internet” and make things happen. The key is to have the appropriate level of management that allows people with good ideas to bring value to their projects and the company while still allowing the management to set priorities and direction.

Is your project management process holding you back? Find out! This 9-question multiple-choice quiz will diagnose the health of your PM tool and process.

Take the assessment!

What’s the Most Important Job of a Project Manager?

project manager

A lot of people think that the most important contribution of a project manager is building the plan. That’s what a project manager does—breaks work structures into tasks; identifies the dependencies; feeds tasks into a project management tool; works with the functional managers to build the right team, and assigns tasks to team members. And then from here, the team just implements the plan and the project manager monitors the work to make sure the team is on schedule.

Think again. Building the plan is not a project manager’s most important job—especially for projects that need to innovate among a lot of uncertainties.

If innovation is required to be successful, the most important job of a PM is to nurture an environment where the team can innovate. To do this, the PM must communicate with team and stakeholders throughout the project; focus on solving problems, and create space for failure.

Here’s a closer look at what project managers need to do to keep innovation thriving.

Communicate: Ask Questions, Understand Goals, Engage Daily

When creating a plan for building a skyscraper, an experienced construction project manager will know how long it takes to perform routine tasks like pouring concrete or wiring the lights. This PM will also be able to build the plan without talking to the people who will actually do the work. But when innovation is involved, few tasks are routine, so the PM must work with the entire team to create the plan.

The role of the PM in this process is not to answer all of the questions needed to create the plan, but to make sure the correct questions are asked and answered. To do this, the PM must understand the goals and concerns of the stakeholders well enough to represent them throughout the project. The PM then works with the team to create a work breakdown structure and initial time estimates for the tasks. The goal of this plan is to be accurate, not precise.

Once the project is launched, the PM needs to engage the team daily, possibly through scrum style stand-up meetings, so that the plan can be updated and the stakeholders informed of changes as the plan evolves. At any moment a stakeholder should be able to call the PM and get status on the biggest risks, the latest learnings, how the plan has changed, and progress towards the next deliverable. Regular reports must be shared with the stakeholders describing the status of the project, especially any major lessons learned or departures from expectations.

Focus on Solving Problems, Not Completing Tasks

One way that the project manager builds a culture of innovation is to focus on problems to solve as the core activity, as opposed to tasks to perform. This gives the team the flexibility to go where their expertise and discoveries lead them.

I once worked with a client who assigned us a task to measure the electronic noise of a system, but the question they were trying to answer was whether shielding would be needed. The team discovered that other parts of the system were designed in a way that made the answer obvious—the noise would be unacceptably high. Our suggestion was to improve the filtering before we measured the noise. If the team had just performed the task of measuring, we would have wasted a lot of time and money and not gotten any closer to a solution.

Failure Is Not Only an Option, It’s a Requirement

If your team feels that failure is not an option, I can guarantee you they will not take the risks necessary to find an innovative solution. Your stakeholder may be concerned with wasted time and effort if a concept doesn’t pan out, but an effort is only wasted if you learned nothing from it. As an example, if you spent three days building a prototype that you should have known wouldn’t work based on reading a Wikipedia article, that’s wasted effort. But if the reason that the concept didn’t work was not obvious without spending the three days building and testing the prototype, then it was a success.

As a PM, it’s your job to build a plan that doesn’t assume that the project follows the happy path, where everything goes right. If you do, then ideas that don’t pan out lead to delay and disappointment. This creates stress on the stakeholders and the team, leading to a future of risk aversion. It’s hard to build “failure” into your plan because your stakeholders want you to move fast, but it’s even harder to build invention.

Be Part of Something Vital

It’s critical that everyone on the team feels protected, so they will have the confidence to innovate. Learning and intelligent risk-taking must always be rewarded, even if all you learn is that the project isn’t feasible.

In an innovative culture, the distinction between the people manager and the project manager becomes blurred. The PM can’t treat the practitioners as cogs. Your team members will often be crossing disciplines to invent their way out of a problem. This requires much more communication and trust. It’s your job as the PM to nurture a team where this innovation can happen.

Great things happen on projects when those common hurdles don’t sideline your team. Lead your team to be the best thinkers and doers in the biz. Download our eBook, “How to Solve the Top 9 Project Management Challenges.”

Solve the Top 9 PM Challenges