Voices on Project Management

by , , , , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.

About this Blog

RSS

View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Roberto Toledo
Vivek Prakash
Cyndee Miller
Shobhna Raghupathy
Wanda Curlee
Rex Holmlin
Christian Bisson
Taralyn Frasqueri-Molina

Recent Posts

Authoritarian vs. Participatory Project Management

4 Reasons I Love Portfolio Management

My Favorite Research Tools

The Impact of Unforeseen Risks

The Reality Behind a Deadline

My Favorite Research Tools

Categories: search, Tools, tools

By Wanda Curlee

Do project and program managers need to be experts in the industry or sector they work in? While many would say yes, others argue that a competent and experienced project or program manager can lead initiatives in any area.

I would agree with the latter—with one caveat. Project and program managers who lack experience in a given field must be willing to do research and fill any knowledge gaps to make their efforts successful.

Research is the key to staying current. As a program or project manager, you must be able to ask subject matter experts smart, targeted questions. By arming yourself with the right information, you’ll be able to challenge assumptions and better navigate schedules, risks and other issues. And raising these questions will also drive creativity and innovation.

There are several online tools that I often use to conduct project–related research, including:

Google Scholar: This is a good tool for Boolean, or combined keyword, searches. It returns a list of reputable articles, books, abstracts and court opinions from academic publishers, professional societies, online repositories, universities and other websites. For most results, the title, author's name and abstract can be seen, but the full piece is behind a paywall.

Semantic Scholar: This engine—still in beta—has artificial intelligence built into the search, which is amazing. For those who have used EBSCOhost or ProQuest as a student or an academic, Semantic Scholar will look somewhat familiar. It’s based on Boolean searches as well, but, unlike Google Scholar, 99 percent of the returned articles are available as PDFs.

Semantic Scholar also lets you narrow your search. For example, you can search based on author(s), limit the search to a certain publication timeframe and only review articles in certain journals.

Depending on the search, some articles can also be sliced and diced by topic. For example, when I did a search on neuroscience and leadership, I was able to pick articles on certain areas of the brain. Even more fascinating, I could filter down to the type of brain cell discussed.

These are two of my go-to tools. Where do you turn when conducting project research and preparing to lead an effort in a new field?  

Posted by Wanda Curlee on: February 08, 2017 10:23 AM | Permalink | Comments (8)

How Does OPM Fit In?

by Taralyn Frasqueri-Molina

In a small business, like a startup, organizational project management (OPM) may seem too big. At a large blue chip, layers of OPM may be standard operating procedure. But what if your org is somewhere in between? On one hand, you're past the days of moving furniture yourself, on the other hand, you're not yet cutting paychecks for 2000+ employees.

First, let's establish that OPM is a good thing. Linking strategy with implementation across an organization to deliver on portfolio promises and realize value is, trust me on this one, a good thing. But OPM at scale is even better. And that is because if you don't scale OPM to where your org is right now, it may seem that OPM is too complex to even attempt at all.

And if OPM is a good thing, then no OPM is probably not so good.

I've seen what happens to a business that doesn't have an OPM strategy in place. The business is moving along successfully but then the stumbling starts, and then maybe stops, but then it starts up again and continues unabated. Teams are frustrated that progress has halted and find they're taking the blame or blaming each other. Leadership pushes the same answers to newly arisen problems—work harder, faster, longer.

The Benefits of Scaling

OPM at scale ensures the strategy that your entire enterprise is about to adopt is the right fit.

Too light (but it may work for a startup), and your undertaking becomes inconsistent, priorities become ever-changing because there's no clear focus. The entire system is not reliable enough to deliver.

Too rigid (but it may work for a Fortune 500), and you may get in your own way with bottle-necking processes, decision-making by committee, waiting for an approval exit gate that never arrives, wasting time because the system is not flexible enough to deliver.

Where too much process is a hindrance (but may work for a large org) and too little is volatile (but may work for a fledgling company), start with some core principles that are key for your org and build from there.

An OPM at scale strategy could look something like this:

  • Decide how projects in your portfolio are managed across your enterprise. That means an off-the-shelf OPM solution may not be where your answer lies—instead grow your solutions for areas like governance, change, prioritization and resource management, as organically as you can.
  • Implement a few standard workflows that support delivery throughout a team and between teams. Are some processes already working? Keep 'em. Notice a couple gap areas? Partner with teams to design a workflow that solves your specific problem.

  • Create consistency with standard, formal processes, but also allow project managers and teams the freedom to make good tactical choices.

  • Focus on picking a few benchmarking criteria.

  • Make space for continuous communication, provide visibility and support working toward improving the core you've got—not necessarily adding anything new.

At your next quarterly review, examine how your custom OPM framework is doing. Are you all still aligned on, not just the goal of your portfolio, but the goal of your OPM strategy? Ready to go bigger and start maturing your framework? Or instead do you need to scale back?

What experience do you have with implementing OPM to scale?

Want to see a fully baked standardized model, take a peek at PMI's Organizational Project Management Maturity Model (OPM3®).

Posted by Taralyn Frasqueri-Molina on: October 05, 2016 06:49 PM | Permalink | Comments (4)

Qualitative Risk Analysis: Don’t Lose Your Objectivity

Categories: PMOs, Risk Management, Tools

By Mario Trentim

In my last post, I discussed the importance of getting risk identification right. Now, it’s time to tackle the challenge of qualitative risk analysis—which project practitioners often tend to confuse with subjective analysis.

Objective vs. Subjective Analysis

Subjective analysis is based on personal opinions, interpretation, points of view, emotions and judgment. It is often ill-suited for decision making and, in particular, for risk analysis.

Objective analysis is fact-based, measurable and observable. For qualitative risk analysis that means using scales to evaluate risk, whether textual (low, medium, high), color-coded (green, yellow, red) or numeric (from 1 to 5), or some combination of these.

Getting Qualitative Risk Analysis Right

Consider this all-to-common scenario: In a project team meeting to assess risks, the only available information is the risk name and the words high, medium and low. Because there is no definition on what high, medium and low mean, and because there is not enough information about individual risks, the risk analysis is based on guesses.

So how can project practitioners stop the guessing game and ensure objectivity? Here are seven tips:

1. Consult tools and standards: Qualitative analysis tools are mentioned not only in PMI’s A Guide to the Project Management Body of Knowledge (PMBOK® Guide) but also in PMI’s Practice Standard for Risk Management. For more risk management reference material, check ISO 31000:2009 and ISO 17666:2003.

2. Define qualitative scales in the risk management plan: The Committee of Sponsoring Organizations of the Treadway Commission’s Risk Assessment in Practice has created some good examples of what impact and probability scales could look like. (See pages 4 and 5). You may also want to check the Project Risk Management Handbook: A Scalable Approach (page 20).

3. Gather and document information about identified risks: Interview and involve relevant stakeholders, review lessons learned, document assumptions and information for each risk.

4. Adopt expert opinion, whenever possible: Get a second opinion from more experienced project managers, project management office leaders and other internal experts. If you are not familiar enough with risk identification and analysis for a particular project, hire external experts or consultants.

5. Consider using a risk breakdown structure: Grouping risks in categories helps in identifying root causes and in developing effective responses.

6. Assess probability, impact and urgency for individual risks: Investigate the likelihood of occurrence for each specific risk and its potential effect on project objectives (scope, schedule, cost), documenting the results according to the predefined qualitative scale levels.

7. Prioritize risks using the probability and impact matrix: Rate risks and develop your final probability and impact matrix to determine the need for further quantitative analysis and to plan for risk responses.

Adopting a well-defined qualitative scale and carefully assessing risk data and information will help your team perform better risk analyses. Do you agree with that? Please share your comments and experience.

Posted by Mario Trentim on: August 31, 2016 09:39 AM | Permalink | Comments (9)

Getting Risk Identification Right

By Mario Trentim 

While uncertainty can influence project outcomes, contingency and proper risk response planning can decrease the potential sting. But, despite the rich theoretical background and defined best practices that have been developed for risk management, it remains a struggle for most organizations and project managers.

Why? Here are three reasons I often see:

  • It is not always well understood what a risk is—that it is an uncertain event that impacts one or more of the project objectives. Risks must be specific. Economy, for example, is not a risk; it is a category of risks. Instead, a specific risk might be currency exchange rates if you are importing expensive equipment from abroad.
  • Most project managers perform risk management to comply with organizational standards—in other words, they execute it because they have to, not because their projects would benefit from doing so.
  • Risk identification demands proper tools but the most widely used tool for risk identification is the least effective: brainstorming.  Facing a blank flipchart and imagining what could possibly go wrong in the project is a huge waste of time if used alone because it is sure to leave many risks uncovered.

Effectively Identifying Risks

Risk identification demands effort and time. It is easy to overlook risks in the first pass. That’s why it should be reviewed periodically throughout the entire project life cycle.

According to Rita Mulcahy in her book Risk Management, Tricks of the Trade, if you identified less than 300 project risks, you did a poor identification. To identify more risks (and exceed Ms. Mulachy’s target) try these three tips:

1) Review all documentation, including:

  • Contracts, agreements, quotes and specifications
  • Project charter and project management plan
  • Project documentation (WBS, schedule, resources, etc.)
  • Assumptions and constraints analysis

2) Utilize various information-gathering techniques:

  • Delphi technique, facilitated workshops, interviews or questionnaires
  • SWOT Analysis
  • Benchmarking
  • Expert judgment
  • Risk Inspection
  • HAZOP: Hazard and Operability Studies
  • HAZAN: Hazard Analysis

3) Try different diagramming techniques, such as:

  • Cause and effect diagrams
  • Fault Tree Method
  • Flow charts (system or process)
  • FMEA: Failure mode and effects analysis
  • Influence diagrams (graphical representations of situations showing causal influences or time ordering)
  • Organizational process assets
  • Checklists and categories
  • Risk Breakdown Structure
  • Historical information
  • Lessons learned
  • Hazard indices

How familiar are you with these tools? Which do you find the most useful? Is there another you would recommend? I look forward to your comments!

Posted by Mario Trentim on: August 13, 2016 07:40 AM | Permalink | Comments (10)

Is Your Agile Communications Toolkit Up to Snuff?

By Taralyn Frasqueri-Molina

A lot of things change when moving from traditional project management frameworks to agile ones. But what doesn't change (or shouldn't!) is how much and how often teams communicate. 

Agile frameworks don't actually require daily stand-ups or regular retrospectives. But you should consider adding some new trade tools and a few other staples to your project management toolkit if you’ll be working in an agile context. You may find that they quickly become essential to keeping communication flowing through your team—and your project on track.

Here's a short list of tools I've used on all of my projects.  

Sync-ups/Planning Meetings: This helps me start a project off right by making sure the product owner and execution team are on the same page. We set expectations, talk requirements and the direction for deliverables in areas such as UX, design, marketing.  

Daily Stand-Ups: Quick check-ins with the entire team help gauge project health and bring roadblocks to the forefront sooner rather than later. This is also where we address scope creep, taking note of good ideas that need more exploration before being included in the backlog.

Retrospectives: After each sprint and after each project, a retro helps the team ensure processes are working— and decide if we want to carry over those processes to the next iteration.

Wiki: These often get a bad rap but can act as an excellent centralized location for real-time documentation editing and sharing. In my experience, it can serve as a digital asset management (DAM) system for sharing web copy and design assets. While not a perfect DAM solution, it will do in a pinch.

Instant Messaging: Whether collocated or remote, teams sometimes need quick answers to questions—and a meeting can be overkill as a way to get answers. The challenge with instant messaging, though, is to make sure teams are on the same page about how and when to use an IM tool.

Email: This tool still reigns supreme when it comes to quickly keeping a lot of people in the loop about what's going on. Even if it's an email directing people to a wiki, it's still one of the best tools for mass communication. But maybe not for decision-making!

What tools am I missing? And do you find any of the tools mentioned particularly good or bad for certain kinds of communications? Share your thoughts below.

Posted by Taralyn Frasqueri-Molina on: March 24, 2016 12:30 PM | Permalink | Comments (7)
ADVERTISEMENTS

When someone is lying, is it true that their pants are actually on fire?

- Jerry Seinfeld

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events