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.
The other night I was watching the pilot of Workin’ Moms, a Canadian sitcom about women who have just returned to work after maternity leave. One of the moms pulls a really jerky move on her first day back, making it seem that her executive assistant had screwed up. By the end of the episode, she had realized the error of her ways and apologized.
This reminded me of Robert I. Sutton’s The No Asshole Rule. In his excellent book, Sutton details why you should never hire or tolerate an asshole, no matter how capable they are. Even if they produce three times more than anyone else, the asshole is a force divider, making everyone around them less efficient.
I once worked at a company where the asshole was the CEO. He screamed, he swore, and he insulted. Six months after he decided that our division needed his attention, almost everyone had left for more pleasant pastures. The division floundered for a few years without releasing a significant product. Finally, they gave up and spun it off. If the asshole had left us alone, we could have continued to release new products and could have been a large and growing source of revenue for the company.
Hopefully, we rarely deal with full-blown assholes. However, we all have bad days, and we are all capable of being a jerk to someone who just rubs us the wrong way. These are the reasons we shouldn’t.
Don’t Be a Jerk to That Annoying Person
You’re in the zone, being productive, and trying to meet a deadline you’re not sure you’re going to meet when a coworker wants to chat about what he had for dinner last night. You really don’t care about how the chicken was prepared or what wine he was drinking. Even on a quiet day, you wouldn’t care, and today you’re already on the edge.
I think of dealing with annoying people like managing a dam on a river. Every annoying thing they do is water flowing into the reservoir. You can manage that by letting water pass over the dam, or you can let it build until the dam breaks. The dam breaking is you being a jerk and screaming, “I DON’T CARE ABOUT YOUR DINNER! CAN’T YOU SEE I’M BUSY?!” Better to listen for a minute or two and then gently let him know you need to focus on your work. Suggest talking about it at lunch or after you meet your deadline. Maybe all you need to do is take a deep breath. It’s important that you find a way that works for you to let water pass over the dam before you lose your top.
Don’t Be a Jerk to a Jerk
Here I’m not talking about the chronic jerk (or asshole) but just someone who is having a bad day. The key here is to be empathic. Why is she being a jerk today? Is it something at home, which might not be any of your business? Is it work related? Can you help? Are you part of the problem?
When presented with jerkish behavior, just take a deep breath and put yourself in their shoes. Your responding in kind just escalates whatever negative stuff that’s in the air. If you can help, do so. If you can’t, just move on. If this behavior is their normal mode, then see The No Asshole Rule for guidance.
Don’t Be a Jerk Because You’re Having a Bad Day
We all have bad days. Maybe your kid is sick, a project is late, or a supplier sent parts that were all damaged in transit. Stuff happens to all of us, but not everyone responds by being a jerk. If the bad thing is your fault, own it, and move on. The worst your employer can do is fire you, and I’d rather be fired for screwing up (as we all do from time to time) than for being a jerk. The people around you will see that you handled this setback with grace, and it will be remembered. If you handle stress by being a jerk, that will also be remembered.
Don’t Be a Jerk Because Being a Jerk Is Just No Fun
I wrote an email to a vendor who was late with a deliverable. I could have been a jerk about it; instead, I asked if there was anything I could do to help. It’s a bit passive-aggressive, but I’d rather he come back with a request for help than the delivery drag on. My note let him understand that I took his commitment seriously and care about what he’s producing. Berating him about being late would accomplish the same thing but would leave everyone feeling more stressed. If you spend too much of your day at work being a jerk, eventually it will become your new normal, and you will graduate into being an asshole.
I’ve just returned from a wonderful week in Ireland. Lots of great music, stout, and tea. The sky was blue and the grass green. We enjoyed wonderful hospitality across the island.
However, the only topic that was discussed more than the civil war of 1922 was Brexit and its impact on Ireland. Everyone I spoke with agreed that if the United Kingdom of Great Britain and Northern Ireland (UK) leaves the European Union (EU) it would be bad for Ireland.
For those too consumed with U.S. news to follow what’s happening across the pond, the citizens of the UK, after a contentious campaign, voted on June 23, 2016, to leave the EU in a process referred to as Brexit (a portmanteau of British Exit). The process is scheduled to come to a climax on March 29, 2019, when the UK leaves the trading block covering 44 percent of its international trade. With no rules governing this trade, it’s unclear what will happen next.
If you think Jeff Bezos is in for a difficult divorce, imagine the legal bill for a negotiation involving 28 countries, plus a government that includes all those countries. Regulations that involve goods, services, and people need to be worked out. Almost 3 million European citizens living in the UK might find they no longer have legal rights there and will have to leave.
So how could project management have made things better? I’m glad you asked. There are two fundamental aspects of running any project well that if they had been included here would have made an enormous difference. And, it’s not too late for one of them to save the day.
No significant project should be undertaken without a systemic look at how things can go wrong. If you’re designing a new car, might it perform worse in a crash than older cars? If you’re building a house, might it be destroyed in a landslide when the hill above it gives way? Keeping these types of questions in mind, if you’re pulling out of a decades’ old treaty, you can’t just talk about what value the change brings without considering the risks.
One risk was known but not focused on during the campaign: the impact on the island of Ireland.
Let me provide some history. The United Kingdom comprises four nations: England, Scotland, Wales, and Northern Ireland. After centuries of occupation most of Ireland won its independence and founded the Republic of Ireland, but six counties remained part of the UK. In Northern Ireland, the Irish Republican Army fought the occupation in what the Irish call “The Troubles.” In 1988, a peace treaty, known as The Good Friday Agreement, allowed for free movement of people and goods between Northern Ireland and the Republic, which was simple because both were in the EU. However, with Brexit, goods can’t enter the EU (the Republic) from a non-EU state (Northern Ireland) without going through customs. How this is managed has proven to be the biggest obstacle to forging an agreement between the UK and the EU: Ireland will not approve any agreement that violates the Good Friday agreement, and the UK won’t approve any agreement that keeps Northern Ireland in the customs union. Hence the impasse.
The Irish knew about this problem and raised it, but no one in England was listening. If they had done a proper Failure Mode Effects Analysis, they could not have ignored this risk. The process starts with brainstorming every way things can go wrong and continues with how likely the risk is to occur and how bad it would be if it happens. You then rank the issues from worst (bad and likely) to least bad (not that bad and not that likely).
Several risks rise out of Ireland:
A negotiated solution will be impossible. (high likelihood, high severity)
The Troubles return. (moderate likelihood, high severity)
Irish food destined for markets in the UK will be more expensive due to delays at the border. (high likelihood, low severity)
The problem of Brexit in Ireland would have quickly risen to the top. Seeing this was a big problem, the proponents of Brexit would be forced to include a mitigation strategy to convince voters that it wasn’t all that bad.
Prime Minister Teressa May has negotiated a treaty with the EU that few like. On the issue of Ireland, this new treaty has punted the resolution for a later date, keeping Northern Ireland in the customs union until a resolution is agreed to. This prevents the UK from negotiating independent trade deals with the rest of the world, which is what the proponents of Brexit want. As of this writing, Parliament has voted this deal down twice, with no resolution in sight.
Members of Parliament in London are acting like there are only two choices: ratify May’s treaty that doesn’t really resolve the issue or approve a “No Deal Brexit” in which trade between the UK and the EU stops until a new trade deal can be negotiated and ratified.
If the prime minister was a project manager, there would be a third option: a stage gate review that had the authority and responsibility to kill the project if it wasn’t viable. If one is managing a risky project with lots of unknowns, you break the project into phases. At the end of each phase, you should know a lot more about the risks, costs, and benefits of a project. You gather your stakeholders together, and the project team presents what they have learned as well as their updated risk register, costs, schedule, and features. The stakeholders challenge assumptions, weigh the cost, and decide whether to continue to move forward to the next phase or kill the project. In the context of Brexit, one phase would be the initial campaign. The vote was the first stage gate. The negotiations were the next phase. In a second “people’s vote,” the citizens of the UK, with a much better understanding of the real risks, costs, and benefits of Brexit, would decide whether to move to the next stage. I don’t know how that vote would go, but I do know that the British should be asking whether they should kill this project.
A new Independent Group, made up of pro-EU Members of Parliament from the Labour and Conservative parties, is calling for just this kind of revote, so there’s hope.
What Project Managers Are Doing
Despite the Brexit process ignoring proper risk analyses and stage gate reviews, thousands of project managers in Europe are working on risk mitigations and seeing how Brexit might affect their work. Project managers couldn’t prevent the mess, but I’m sure they’re working overtime to make sure grocery stores have food, pharmacies have medicine, and the road to Calais isn’t clogged with trucks trying to get through customs on their way to Dover, no matter what the politicians in London and Brussels decide.
Look at your email inbox. How many unread emails are there? A hundred? A thousand? My personal inbox has over 6,000 unread emails, which isn’t bad considering I’ve had this address for almost 15 years.
In 2007, Merlin Mann championed the idea of “inbox zero,” but now it’s become vogue to argue that inbox zero is impossible or not worth the effort. I don’t believe that, but how do you capture the unicorn of inbox zero without spending your life tied to a keyboard?
Every Email Has Value, but It Might Be Negative
A personal note from a friend or a job offer is a valuable email. The monthly notice regarding your frequent flyer account might be worth checking. A scam from a Nigerian Prince has a negative value (unless you’re comedian James Veitch whose replies to scam emails are the basis of some great comedy). Every unread email cluttering up your inbox has a small negative value.
For me, inbox zero means all your emails have been triaged into one of four categories:
Emails with zero or negative value (e.g., junk)
Those of low value that have been categorized (e.g., notifications from LiquidPlanner, coupons from a store you like)
Something that can be quickly resolved (e.g., an event to be added to your calendar, a straightforward question)
Something that needs a thoughtful response
It doesn’t mean that you’ve read every email or written a thoughtful response, it just means you know which ones are worth reading.
Why Is Inbox Zero Important?
Imagine you work in an organization where your team doesn’t practice inbox zero and you have a simple question to ask:
You send an email to Bill asking, “Who is the stakeholder is on project XYZ?”
You wait a day with no answer.
You go see Bill and ask who the stakeholder is. He tells you it’s Betsy.
You go back to your desk, look for Betsy, and find three, but you’re not sure which is the right one.
You go see Bill again, and he lets you know which Betsy.
You email Betsy, hoping she responds.
This process might take several days. Twice you interrupt Bill, reducing his efficiency. If he just answered the email in the first place at a convenient time the amount of work and disruption for everyone is reduced. By not answering the email, Bill increased his workload.
Inbox Zero Reduces Email Noise
It’s a lot easier to read all your emails if they’re worth reading. You can make it easier to read all your emails by following these steps:
Get a spam filter.
Unsubscribe from as many email lists as you can.
If you can’t unsubscribe, create a “rule.”
These days almost everyone has a spam filter, but many people don’t take the 30 seconds it takes to get off an email list that you never read. My goal is once a day to remove myself from an unwanted list.
For the automatic emails, like notifications from your project management software, that you might occasionally want to read or search it’s best to create a rule that will place all those emails into their own mailbox (each rule should have its own folder). I consider mail in a well-defined folder as triaged, even if you’ve never read them. When you do decide to look at them, you can easily go through a large number quickly since they’re grouped together, and your brain is in “notifications” mode.
Some dreck will still make it through, but you can pretty quickly delete these messages. If you find yourself regularly deleting similar emails, you know it’s time to create a rule or unsubscribe for a list.
For emails that can quickly be dealt with (less than 2 minutes), just knock those out. If you can’t answer the question, take a moment and forward the email to someone who might be able to help. I find that a quick reply resolves most emails and you get a reputation as a team player.
I flag emails that require investigation before they can be resolved, that way they don’t get lost in a sea of emails. When I have the time to dig into an issue, I look at my flagged emails and deal with the oldest one. Sometimes these flagged emails are for a complex topic that is poorly handled by email, so pick up the phone or arrange a meeting if that’s what’s needed.
What If That’s Not Enough?
What happens if you’re doing everything right, but you still can’t keep up?
Email is a very efficient method to resolve some types of queries, but if you’re too busy to answer your emails, then no communication approach will create more time. The people who argue for inbox infinity are just saying, “I’m too busy to answer your questions, so I’m going to make it hard for you to ask them.” Obviously, if you’re Jeff Bezos or Elon Musk, you can’t manage emails from every person who wants to complain about a late delivery or why they can’t go to Mars tomorrow, but for most of us, our emails are coming from colleagues who have legitimate questions.
If you can’t keep up with your email, you probably have more work than you can manage. Look to see what you can delegate or if there are projects that can be put on hold. If you can’t, things will fall through the cracks, but not keeping your inbox triaged will just make things worse.
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.
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.
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.
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.
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.
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?
multiple teams not co-located
How much uncertainty is there?
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:
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?
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.
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.
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.
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 youwant them to know or whattheywant to know.
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).
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!
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.
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:
What are the risks that might arise during the project?
How important are these risks?
How should we respond to these risks?
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?”
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:
Pressure vessel fails
Power demand exceed requirements
Temperature exceeds material limits
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:
Minor impact to lifespan of product or functionality. Probably not noticed by end-user.
Some impact to lifespan of product or functionality. May be noticed by end-user, but not sufficient to create a poor impression.
Impacts the lifespan of product or functionality. Will be noticed by end-user and may lead to poor reviews.
Significant impact to the lifespan of product or functionality. Will lead to warranty returns and poor reviews.
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.
Happens 1/1,000,000 per unit per year
Happens 1/100,000 per unit per year
Happens 1/10,000 per unit per year
Happens 1/1,000 per unit per year
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.
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.
Temperature exceeds material limits
Pressure vessel fails
Power demand exceed requirements
Weight exceeds requirement
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:
Temperature exceeds material limits
Explore material choice and mechanism to limit maximum temperature
Pressure vessel fails
Power demand exceed requirements
Increase power requirement
Weight exceeds requirement
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 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?
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.