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.

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

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

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

Fans of Kanban like to break everything into a queue.

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

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

Build your toolkit like a Superhero

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

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

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

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

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

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

Choosing the right paradigm

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

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

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

1. What is your project like?

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

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

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

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

2. What is your team prepared for?

Next, look at your team.

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

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

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

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

Be the mild-mannered Superhero your projects need

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



eBook: How to Manage Chaos

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

We’ve compiled our favorite columns in this eBook:

DOWNLOAD NOW

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

How to Write Status Reports that are Worth Reading

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

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

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

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

Be Empathic

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

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

Related: The Two Styles of Project Leadership

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

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

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

Be Actionable

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

Related: How to Create More Powerful Reports with LiquidPlanner

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

Separate out the Critical from the Deep Dive

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

Related: How to Write a Killer Status Report

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

Consistency

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

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

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

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

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

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

Why Do Silos Exist?

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

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

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

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

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

What Are the Pitfalls?

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

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

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

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

How Do I Make Silos Work to My Advantage?

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

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

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

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

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

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

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

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

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

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

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

Wheat Isn’t the Only Thing That’s Golden

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

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

How to Conduct a Risk Assessment for Your Project

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

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

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

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

There are four stages to building your FMEA:

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

What are the risks that might arise during the project?

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

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

Related: How to Use LiquidPlanner Data to Find Project Risks

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

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

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

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

Table 1: List of risks from brainstorming session

How important are these risks?

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

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

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

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

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

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

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

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

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

Related: Reducing Risk and Uncertainty in Your Project

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

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

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

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

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

How and when should we respond to these risks?

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

Temperature exceeds material limits

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

Pressure vessel fails

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

Power demand exceed requirements

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

Weight exceeds requirement

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

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

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

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

Mitigate and Monitor

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

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

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

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

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

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

Kobayashi Maru

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

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

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

 

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

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

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

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

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

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

Change the Rules

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

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

Never Give Up—or At Least Not Right Away

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

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

Be a Mensch

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

 

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

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

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

4 Guiding Principles for Leading Remote Project Teams

Today I received an email from a recruiter, reading:

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

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

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

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

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

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

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

Break It Down

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

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

Related: The Skills Project Managers Will Need in 2025

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

Put Everything in Writing

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

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

“Is the project going well?”

“Yes.”

“Will it be delivered on time?”

“I don’t know.”

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

But some questions are explorations.

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

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

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

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

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

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

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

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

Set High Expectations for Communication

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

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

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

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

Related: The New Face of Project Leadership

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

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

Things Won’t Always Go Smoothly

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

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

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

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

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

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

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

Practice Beats Uncertainty

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

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

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

Running the World Series has an incredible amount of uncertainty.

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

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

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

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

Plan for Every Challenge

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

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

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

Field Your Team Strategically

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

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

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

Say What You’ll Do; Do What You Say

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

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

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

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

Set Everyone Up for Success

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

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

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

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

Don’t Just Chase the Ball; Think Strategically

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

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

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

Lessons Learned as a First Time Medical Device Project Manager

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

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

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

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

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

Walk a mile in your users’ shoes.

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

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

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

Build prototypes to simulate products in real-world settings.

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

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

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

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

Choose your partners carefully.

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

The perfect partner would have certain features:

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

Not surprisingly, no such company existed.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Take pride in your work.

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

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

Project Management Monsters Around Us

Monsters aren’t just for Halloween. The undead walk among us all year round. Only on Halloween do they show their true faces. If you know what to look for, you can recognize vampires, ghosts, zombies, and Frankenstein’s creation (he’s not really a monster, just misunderstood).

In this article, I will teach you not only how to spot these undead creatures, but also how to vanquish those who haunt your nights and bring life back to those who suffered an untimely demise.

This doesn’t take the skills of a slayer, just a disciplined product development process.

Zombies

Zombies are the most common undead creature you’ll see walking the halls of your office. (We’re talking about the slow George A. Romero style zombies, not the fast variety of 28 Days Later or World War Z.)

They continue moving and sucking up resources, but they have no life in them and they never will. They produce nothing, and all they want to do is eat your brain. They need a shotgun blast in the face to put them out of your misery.

I once worked in an R&D group of about a dozen engineers, with about 20 active projects. On average, these projects would have required a couple of engineers to move forward at a reasonable pace. There were no clear priorities, so everyone worked on whatever they felt like or responded to the most recent request. The team’s effort was so diffuse that practically no projects were ever completed.

The way to deal with zombies is having a product development process that includes stage gates. As a project moves from one stage to the next, a review with the stakeholders is held. If the project isn’t on a path to success, this is the time to either rescope to something that can be successful or kill the project.

If a project just wanders around aimlessly without progressing to the next stage, you need to put it out of its misery and apply your resources to projects that can be successful. No project moves on to the next stage unless the resources needed are available.

Vampires and Ghosts

Vampires are projects that suck the lifeblood (i.e. resources) from other projects, preventing them from staying on schedule. Unlike zombies, vampires are worthy projects capable of being successful; they are just consuming more resources than they should.

Ghosts are the opposite, just a whisper of a project, starved of the resources they need to live. With sufficient resources, the ghosts can be resurrected.

I once worked for a company leading a critical project redesigning the flagship product. When I checked in with the engineers, I often found out they’d been redirected to work on a pet project (i.e. a vampire) of the CEO. I was unable to stay on schedule, and my project became a ghost.

Both of these monsters can be slain by agreeing to priorities and assigning your team based on these priorities.  If resources are to be reassigned, the leader of the project losing the resource needs to be engaged and the impact discussed.

Does it make sense to move the resource and delay a critical project? Leadership must understand the implication and make the tradeoffs based on the best-available information.

Frankenstein’s Creation

You’ve probably seen these creations: an arm left over from one project, a leg from another. These appendages don’t go together as part of any design. The result reminds you of what you wanted when you launched the project, just like Adam (the name of Frankenstein’s creation) reminds you of a human being.

When you’re trying to solve a problem similar to one you’ve solved before, it may seem like a good idea to reuse your early work. And sometimes it is. Other times, shoehorning an old solution into a new problem creates more problems than it solves.

To tame the creation, one needs only a solid design process with requirements. Start with the problem you’re solving and build up requirements from there.

If an existing solution meets the requirements, then by all means use it. If it doesn’t, can it be modified to meet the requirements? Whatever solution you use, it must meet the requirements.

Polyphemus, the Blind Cyclops

In Homer’s “The Odyssey”, Odysseus stabs the cyclops Polyphemus in the eye, blinding him. When Polyphemus lets his sheep out of the cave to graze, Odysseus and his men are then able to escape by hiding under them.

Similarly, we are often blind to what’s happening under the surface of our projects. We often don’t ask the right questions because we’re moving too quickly to take the time to pause and ask them. Or we don’t want to hear the answers, like “the customers want something different than what the product manager thinks they want”.

I once worked on a project where the laws of physics suggested that we would likely fail FCC certification testing due to high levels of emissions of radio frequency noise. So the experts in the team did a detailed analysis, which confirmed our initial fear, and they recommended putting the electronics in a Faraday cage, which would dampen the emissions.

Management didn’t want to slow down the project to allow a cage to be designed until we had actual measurements to prove that we needed a cage. Six months later, we were able to build a prototype that proved we needed a Faraday cage, but by this point the design was locked.

The resulting mitigation needed to fit within the space available, increasing cost and putting the schedule at risk. None of that would have been needed if management had looked carefully at the situation when the issue was first raised.

Once again, the weapon of choice is a solid product development process:

  • Risk assessments that force you to sit down and ask, “How can this project fail?”
  • Stage gate reviews, where the stakeholders come in and ask the tough questions before the project moves forward

Many Monsters, One Weapon

We are often in such a rush that we waste energy on a feeding vampires or zombies that are unworthy. We overlook that which is just beneath the surface. We settle for something that’s handy, rather than a solution that solves our problem.

A disciplined product development process can give sight to the blind, strength to the ghosts, and oblivion to zombies.

What is Little Data? And Why Do Project Managers Need It?

One of the fastest-growing technology trends today is Big Data, probably behind Internet of Things and ahead of Virtual Reality. For instance, a search on the job site Indeed for “Big Data” returned almost 20,000 entries.

But what about Little Data (which only gets four hits on Indeed)?

Big data is mining huge, heterogeneous data sets and pulling out subtle information that can inform all sorts of decisions.

Let’s look at climate change science as an example. Data comes from atmospheric measurements over Hawaii, temperature data across the globe, ice cores from Antarctica and Greenland, underwater measurements from all the world’s seas, and more. Some of the data were taken by satellite last week; others written in notebooks centuries ago.

[Further Reading: How to Be a Project Team of the Future: Preparing for Industry 4.0]

It’s been pored over by scientists from every country in the world. The data and analysis needed to predict how the climate is changing and will change is complicated. To really understand it requires a PhD. The details are so complex that we have been unable to decisively act on this critical issue.

What Is Little Data?

Little data is the opposite. It’s the 2+2=4 kind of things.

Little data is the obvious observations and conclusions that those paying attention will catch and can use to their advantage. It’s looking outside, seeing it’s raining, and deciding to put on a jacket. It’s noticing that the prices and quality of the food is better at one store than another and using that information to decide where to shop. It’s noticing that if you drink coffee after 5 p.m., you have trouble going to sleep, so you stop drinking coffee after 5 p.m.

Little data has three steps:

  1. Gather data.
  2. Do some straightforward analysis of the data.
  3. Act based on your analysis.

To some extent, little data and big data are close to the same thing, it’s just a matter of degree. The biggest difference is that the analysis for little data is straightforward. If you’re looking for someone with a PhD in math to help with your analysis, that’s not little data. For little data, you should be able to do the analysis in Excel. The challenge is knowing how to respond to your results.

Improve Schedules with Little Data

Here’s a straightforward way to use little data to improve your schedules: record task estimates and actuals. The data should include who did the estimation and the work. Using a pivot table in Excel, you can see which estimators typically underestimate or overestimate. You can also see which of your team members take more or less time than was predicated. There are many ways this data can improve your organization, including:

  • Decrease the bias of future estimations
  • Identify team members who are not using best practices (and therefore take longer)
  • Identify team members who have practices you should transfer to other team members

As is often the case, data acquisition is straightforward, analysis simple, and the response requires further digging.

Measuring KPIs

Key Performance Indicators (KPIs) are a common little data management technique. Leadership decides that certain easily measurable metrics are key to the organization’s success, targets are set, and data acquired. If the performance does not reach the target, then some form of response is taken.

For example, you may be managing a manufacturing line. Your KPI is the number of units manufactured per hour. In creating the manufacturing process, you know you can build 100 units an hour, so you set your target at 80 units an hour to account for the normal hiccups (e.g. you’re training a new team member).

[Further Reading: AI, IoT, and the Future of Manufacturing]

Data collection and analysis are easy. If you’re meeting your target, you can move on to other issues or raise the target. Ideally, if you don’t meet your target, the response is agreed to prior to acquiring the data. Often it just indicates you need to dig deeper, as in this case. As is all small data analysis, the challenge is in the response, not acquiring or analyzing the data.

A Real-Life Example: Test Scores

One of the most controversial examples of little data are standardized school tests. The data is homogenous and straightforward (if time consuming) to collect. The naïve analysis is trivial (average score by grade and school). The response is complex and fraught with challenges.

In 2010, an elementary school near my house was labeled as failing according to the No Child Left Behind law. A majority of the students were from refugee and immigrant families. Many didn’t speak English at home, which certainly posed a challenge for the school.

The metric, test scores, didn’t determine what action was called for, but made clear there was a problem. The district responded by bringing in a new principal and new teachers, and a concerted effort was undertaken to improve performance.  After four years, the performance of the school went from one of the worst schools in the state to only a bit worse than the average school. The little data approach showed that by the metrics we use, the interventions improved the performance.

But this same metric can be misused. There are two middle schools near our house, and we choose to send our son to the one with lower test scores. The school our son goes to is incredibly diverse (including most of the kids who went to the formerly failing elementary school), with a great vibe and dedicated teachers. Test scores can tell you when a school is broken, but it’s not useful in comparing two functional schools. How a school fosters creativity, teamwork, and curiosity are not captured in any test.

This same data can also be used in a big data analysis. Throw in demographic data from the census, housing prices from the country, income data from the IRS, alcohol and cannabis consumption data from Washington State and some subtle correlations that aren’t immediately apparent might appear.

Of course, they might just be random chance; that’s why you need to be careful with big data in a way that you don’t with little data. If your school has the lowest test scores in the state, you know you have a problem. If there’s a weak positive correlation between playing sports and grades, that doesn’t mean every child needs to immediately join a league.

It can be hard to rally the troops to fix a broken team or process. When you come in with data showing how far you are from where you’re supposed to be, it’s much easier to drive changes.  That’s true whether it’s replacing a principal or fixing a broken manufacturing process.

Use Data Thoughtfully

Throughout your day, you’re inundated with data. The key to both little data and big data is to thoughtfully filter out what is unimportant and turn what is important into knowledge, which is data with context and meaning. Then you use that knowledge to inform your actions. If the data can’t lead to action, it’s worthless. An extreme example of this is Sherlock Holmes’s lack of interest in the fact that the Earth orbits the sun,

“What the deuce is it to me?” he interrupted impatiently: “you say that we go round the sun. If we went round the moon it would not make a pennyworth of difference to me or to my work.”

Though, as a former astronomer, I don’t encourage following Holmes’s example, it is important to focus our efforts on data, big or small, that help us make better decisions.

 

Ready for a new project management tool, but still need to get your boss’s buy-in? Learn how to build a compelling business case with this in-depth guide.