By Stephen Alfano, CSM

Who doesn’t have problems? Now, a real question: Is there a simple, surefire, and quick way to break problems down?

Answer: Problem statements.

A problem statement is basically a short, yet compelling description of an issue, or set of issues, that must be resolved. It’s used by problem-solvers of all stripes—from research scientists to project managers to postgraduate students—to drive an effort from beginning to end to ensure and validate an anticipated outcome (not a problem with a well-written problem statement!).

How do you write a problem statement?

I recommend carefully breaking the problem—and the undesirable world it lives in—into three basic components:

• Vision – This is the description of the anticipated (desired) outcome. Think of it as a view of the future with the changes that will result from the issue(s) being resolved.
• Issue(s) – This is the description of the problem using a narrative derived from real-world experience (e.g., use cases or test results). It’s usually only a couple of sentences in length and straightforward and concise in tone and manner.
• Method – This is the description of how the problem (and issues therein) will be resolved. It’s often prescriptive language—sometimes filled with jargon—that helps the problem-solvers map out their path to success.

Of course, there’s a great deal of background detail and mitigating factors that must be condensed to create those three basic components. (We’re talking about scaling down a small mountain of data and accompanying data analysis into a couple of paragraphs.)

Truth be told, problem statements can be problematic. The input isn’t always neatly packaged. It often comes from structured and unstructured sources that need to be identified, categorized, prioritized and, in some cases, synthesized to establish the following:

1. the root cause of the problem
2. the known consequences of the issues that users (and key stakeholders) both up and downstream face
3. the ill-effects associated with the known consequences
4. the myriad assumptions and constraints (the pros and cons) within the method used to resolve the issues

Above all, problem statements require persistence and patience. Distilling and editing the content to be clear and concise takes rigorous work—and lots of practice using a tried and true template.

Below, you’ll find links to some of my favorite problem statement templates and best practices:

• How to Write a Problem Statement via Ceptara Corp.

• Writing Tips: Thesis Statements via Center for Writing Studies: University of Illinois Board of Trustees
• How to Write a Problem Statement for SIX SIGMA via dummies.com
• “A good problem statement will…” via Plumas County, California (CivicPlus)

How do you think problem statements could help your project mitigate issues and achieve success?

About the Author: Stephen Alfano is an Organizational Change Management Consultant and Communications Expert. He has 30 years of experience leading and managing internal and external marketing initiatives for both private and public-sector clients. His résumé includes providing both new business and business process improvement services to Apple, American Express, AT&T, California Department of Transportation, Chevron, Entergy, Levi Strauss & Co., Louisiana Office of Tourism, Mattel, Microsoft, Novell, SONY, Sutter Health, and Wells Fargo. Stephen currently works as an Executive Consultant with KAI Partners, Inc., spearheading business development and leading the firm’s marketing and communications practice and line of business.

By Stephen Alfano, CSM

Full disclosure, I made three assumptions before I wrote this blog post:

1. I assumed that project management mavens (and groupies) would overlook my obviously self-serving gambit and give me the professional courtesy to read beyond the first sentence.
2. I assumed that even the most courteous reader would grow impatient (bolt!) if I didn’t pen something provocative about an intentionally rigid project management subroutine that at times can seem mind-numbingly pedantic.
3. I assumed that only a handful of the readers would read all the way through the opening paragraph; while most of the readers who remained engaged beyond the gambit would have skipped down to the links leading to additional insight on the prescriptive and didactic data science behind validating assumptions.

If you are still reading this blog post (thank you!), you probably figured out my stratagem quickly and decided to chalk it up to a level-setting parlor trick used to underscore the “tricky” nature of assumptions. (You saw what I did: That statement is an assumption.) So, let’s move on, starting with an official, textbook definition of an assumption.

An assumption is, “a thing that is accepted as true or as certain to happen, without proof.” Of course, how would you know this definition is the definition you seek? How could you be sure it comes from a legitimate and “official” source? (Tricky, right?) In short, an assumption needs to be validated.

Validating Assumptions 101

• To properly validate an assumption, you need to start by capturing it into a database tool called an assumption log.
  • The assumption log lists assumptions by date.
  • The log is usually created and maintained by a project manager. However, everyone on the project team will have access to the log. More important, specific individuals or groups on the project team will be assigned assumptions to validate throughout the project lifecycle.
• Not all assumptions are equal, which is why the validation process begins by determining the level of impact or affect an assumption has on the project outcome.
  • Moreover, assumptions may also be project risks—either now or in the future. So, in addition to creating an assumption log, a project manager will produce an overlapping or supporting database called a risk register. The risk register is used to identify, manage, and mitigate risks.
  • The continuous alignment (interdependence) of the assumption log and the risk register is central to a project management plan.
• Once the level of impact or affect an assumption has on a project outcome is determined, project team members or groups are given the responsibility to validate assumptions by a specific date to keep the project on track.
  • Validation at its core is scientific probing—asking lots of “why” and “how” questions until the assumption can become a proof point. This probing supports the decision-making process towards delivering or realizing project goals. (At this point, I’ll assume you now know how important that is.)

For more insight on validating assumptions, check out these links below:

ASSUMPTIONS ARE MADE TO BE VALIDATED via Leading Agile

The Need to Validate Project Assumptionss via Business 2 Community

5 Tips to Make Sure You Are Validating Early and Often via Kissmetrics

Case Study: Using the 5 Whys to Validate Assumptions via iSixSigma

Identifying and Validating Assumptions and Mitigating Biases in User Research via UX Matters

Build Better Products: How to Identify and Validate Assumptions via Users Know / SlideShare

Now it’s your turn—what are some of your best practices to validate assumptions and reduce risk on your projects? Or, what other trouble spots does your project have—we’d love to cover some mitigation techniques in a future blog post!

About the Author: Stephen Alfano is Certified ScrumMaster® (CSM), Organizational Change Management Consultant and Communications Expert. He has 30 years of experience leading and managing internal and external program initiatives for both private and public-sector clients. His résumé includes providing both new business and business process improvement services to Apple, American Express, AT&T, California Department of Transportation, Chevron, Entergy, Levi Strauss & Co., Louisiana Office of Tourism, Mattel, Microsoft, Novell, SONY, Sutter Health, and Wells Fargo. Stephen currently works as Marketing and Communications Manager for KAI Partners, Inc., spearheading business development and leading the firm’s marketing and communications practice and line of business.

By Guest Blogger Tony Oliver, Penny Wise Consulting Group

This blog post first appeared on the Penny Wise Consulting Group’s blog and was posted here with permission. The original post can be found here.

Ah, flying. The friendly skies. The luxury aboard the plane. The jet-set and the glamour. All gone.

Nowadays, few experiences elicit the same sort of hatred as commercial aviation. Beyond the vitriol, the stale pretzels, and the harsh treatment from flight attendants, though, there are many project management tactics at play.

According to USA Today, an average day has 1,000 commercial flights over the U.S., mostly distributed across the major ~9 domestic airlines. Major carriers like American Airlines, United Airlines, and Delta Airlines each boast over 200 regularly-scheduled segments, each replete with its own challenges and intricacies.

Despite the obvious similarities (fly a large metal bird from point A to point B), each flight should be seen as a stand-alone project. Though it may be regularly-scheduled and often repeated daily, each one represents a specific, time-boxed instance.

While it does share various elements with its predecessors and successors (such as origin, destination, expected route, etc.) it is very much a different iteration every day. Much like publishing a daily newspaper, a monthly newsmagazine, or hosting a yearly event like the Super Bowl or the Oscars, the blueprint may exist, but its execution may be wholly different. Here’s how:

• The “project team.” Some pilots, co-pilots, and flight attendants may be assigned routes that repeat themselves every week, as circuits begin and end. To paraphrase Jon Bon Jovi, “it’s all the same, only the names have changed.” Much like a professional sports team or even an award-winning theater ensemble, the composition of the crew may carry over to a large degree, but rarely does it reach 100%. Nevertheless, the accumulated knowledge, captured as best known methods, checklists, or even desk manuals, can be reused to the benefit of would-be successors or apprentices.
• The passengers are different. With an average plane carrying 200 souls, things are bound to go awry. Babies, first-time fliers, and stranded connecting passengers can all wreak havoc on the best-laid plans. Much like a project has contingency and risk management plans to address what could “feasibly” go wrong, a plane’s crew has multiple ways to address—and ideally remedy— any misalignments between the project plan and reality.
• The conditions may be different. Yes, point A to point B is typically best served in a straight line…but does it always go that way? Turbulence, traffic, and unforeseen circumstances like airspace closures can make plans just another example of wishful thinking.
• Risks from associated processes, Part 1. A snafu with catering, unexpected downtime by the TSA screening machines, or a broken luggage conveyor belt can prevent the loading and unloading of the passengers. These are shared risks not “owned” by the airline, but with a strong direct dependency. Contingency plans show their value here, shedding any would-be “luxury” label to rightfully claim the “necessity” one.
• Risks from associated processes, Part 2. The above are somewhat related to the airport, but what happens if the issue stems from outside of it? A massive accident on the freeway or the spontaneous protests against President Trump’s immigration order would deter thousands of would-be passengers from boarding their flights. Deciding what degree of delay is acceptable (flying without the passengers seems silly, but affecting subsequent flights from destination cities may affect a much larger portion of the customer base) is part finesse and part analytics— but 100% necessary for proper project management.

Even if your next flight is for pleasure, keep your “project manager hat” on and count the many instances of project management. Like hidden Mickeys scattered throughout Disney World, you will be amazed at how much is in plain view when you are really looking for it!

 About the Author: Tony Oliver is a project manager by trade, a marketing guru by profession, and a lifelong learner from birth. His best trait is an inquisitive mind, which drives his desire to understand not just the “what” but also the “how” and more importantly, the “why” and “why not?” Tony is experienced in supply, pricing, demand, and consumption analysis and holds an MBA in marketing from a top 20 school (UNC Chapel Hill) and an undergraduate English Literature degree from Georgetown University. With 15+ years of experience with Intel and Cisco, Tony is fully bilingual (English, Spanish) with a working knowledge of French, as well as a seasoned public speaker and instructor of Project Management and Presentation Skills courses.

By Guest Blogger Tony Oliver, Penny Wise Consulting Group

This blog post first appeared on the Penny Wise Consulting Group’s blog and was posted here with permission. The original post can be found here.

Postmodernist Paul Virilio said, “When you invent the ship, you also invent the shipwreck.” This illustrates not sadism, fatalism, or pessimism, but rather a grasp of how technology can bring unintended consequences.

For example, as the debate over autonomous cars rages on, we run the risk of compartmentalizing technology into a fantasy “perfect world” in which nothing goes wrong. Most advances tend to be imperfect and improve upon successive iterations. However, inventors should at the very least ponder on the possible implications of their inventions, especially if they wish to bring them to market. While the aluminum can “pull-tab” (yes, I am old enough to remember these) eliminated the need for a can opener, it brought an increase in litter, and typically, finger cuts.

But, why does this matter to you, if you are not an inventor? First, it helps to remember the origin of the phrase “Devil’s advocate.” To many, it is a synonym for a “Debbie Downer” or someone who wishes to rain on a parade. To the Catholic Church, it is an important role when determining someone’s sainthood. The “Devil’s advocate” is tasked with poking holes in the canonization argument, in order to ensure that everything has been considered or vetted.

As project managers, we have to be careful not to look at things with rose-tinted glasses. Often, this means a long, hard look at risks, which is not a pleasant discussion with the customer. Creating a risk register should not be seen as a necessary evil, but rather as an important exercise for the entire team to brainstorm, collaborate, and prepare for a successful release.

Below are my tips on how to identify and address risks to help make sure you consider and vet all possible outcomes.

• Allow an open discussion on risks. A company focused on preventing a dialogue on risks is almost as bad as one that chooses to ignore them. Do not punish staff for calling out the possible challenges, but rather encourage them to work with others on finding ways to minimize, eliminate, or transfer risk. While this is a difficult task given today’s litigious society, it will strengthen the overall product, much like the level of competition improves one’s skills.

• Ask “what ifs.” Six Sigma strategy often calls for a repeated “Why” questioning to ensure the correct root cause has been identified. A similar strategy can be employed here, by asking “what if”—not just to statements, but also to answers given after a “what if” response has been given. The recent controversy surrounding Mylan’s Epi-Pen showcased a company ill-equipped to answer an irate public, likely due to not enough risk understanding and preparation. (Full disclosure: My wife and daughter both have Epi-Pen prescriptions.)

• Be open to suggestions.Perhaps you wanted to go into business alone, but the risk analysis shows a partnership or joint venture is a better option. Maybe a regional launch is preferable to a national one, or a test market does not fit as well as the initial review reflected. That is fine. Those are not dead ends, but rather curves on the road that will eventually lead to the destination.

In the end, some risks are unavoidable, but avoiding risk analysis is not. How do you analyze and mitigate risks on your projects?

About the Author: Tony Oliver is a project manager by trade, a marketing guru by profession, and a lifelong learner from birth. His best trait is an inquisitive mind, which drives his desire to understand not just the “what” but also the “how” and more importantly, the “why” and “why not?” Tony is experienced in supply, pricing, demand, and consumption analysis and holds an MBA in marketing from a top 20 school (UNC Chapel Hill) and an undergraduate English Literature degree from Georgetown University. With 15+ years of experience with Intel and Cisco, Tony is fully bilingual (English, Spanish) with a working knowledge of French, as well as a seasoned public speaker and instructor of Project Management and Presentation Skills courses.