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
Jess Tayel
Ramiro Rodrigues
Linda Agyapong
Joanna Newman

Past Contributers:

Jorge Valdés Garciatorres
Hajar Hamid
Dan Goldfischer
Saira Karim
Jim De Piante
sanjay saini
Judy Umlas
Abdiel Ledesma
Michael Hatfield
Deanna Landers
Alfonso Bucero
Kelley Hunsberger
William Krebs
Peter Taylor
Rebecca Braglio
Geoff Mattie
Dmitri Ivanenko PMP ITIL

Recent Posts

Are We Done Disrupting Yet?

Go Ahead and Fail—It Could Be the Way to Succeed

3 Tips for Building a Strong Project Team

3 Skills Project Managers Will Need In The Future

Creativity Is for Project Managers, Too

Viewing Posts by Mario Trentim

A Balanced Competency Model

By Mario Trentim

A successful project requires a combination of technical and managerial activities at every stage to jointly deliver the final result and its benefits.

If you have high levels of maturity in project management without the equivalent technical knowledge, your project is doomed to deliver a poor solution. On the other hand, when you have best-in-class technical knowledge without project management maturity, your project is also doomed to be inefficient and maybe even inefficacious.

Many organizations have already developed competency models to encompass technical and managerial aspects of projects, describing overlapping areas and highlighting essential project management and systems engineering foundations of successful projects.

Consider the U.S.’ National Aeronautics and Space Administration’s (NASA) competency model, which “outlines distinct competency areas for project managers and systems engineers, as well as shared competencies that encompass both disciplines.”

Examples of defined project management competencies include:

  • Stakeholder management
  • Safety and mission assurance
  • Cost estimating
  • Risk management
  • Project control

Examples of defined system engineer competencies include:

  • Technical requirements definition
  • Product verification
  • Configuration management
  • Technical data management
  • Interface management

Examples of shared competencies include:

  • Workplace safety
  • Communication
  • Team dynamics and management
  • Safety and mission assurance
  • Knowledge capture and transfer

You might be asking yourself what does NASA have to do with your own daily projects? Most of us are working in projects and programs far simpler than building space systems. However, my objective here is to call attention to the best in class so that we can contextualize and tailor their model to our own reality.

Of course, in order to achieve a proper balance in your projects, thoughtful tailoring is essential. Take the International Council on Systems Engineering’s handbook, A Guide for System Life Cycle Processes and Activities:

“On smaller projects, where the span of required communications is small (few people and short project life cycle) and the cost of rework is low, Systems Engineering activities can be conducted very informally (and thus at low cost). On larger projects, where the cost of failure or rework is high, increased formality can significantly help in achieving project opportunities and in mitigating project risk.”

Even small and medium projects can benefit a lot from the proper combination of project management and systems engineering. Systems engineering is helpful not only in developing complex products and services, such as a spaceship or an air traffic control system, but also in less sophisticated products such as a bicycle or an alarm system. In fact, systems engineering is even helpful when you are designing your new house.

 

What product development approaches are you using today? Please share your thoughts in the comments below.

Posted by Mario Trentim on: April 03, 2018 01:00 PM | Permalink | Comments (19)

Are Best Practices Really Possible?

By Mario Trentim

 

A project is a planned and coordinated piece of work that requires considerable effort to deliver a specific result.

According to PMI’s A Guide to the Project Management Body of Knowledge (PMBOK® Guide), a project is a temporary endeavor to create a unique result. And it is performed by people, constrained by limited resources, planned, executed and controlled.

Project management is an interdisciplinary approach to balance the conflicting interests and constraints of a project: well done (scope), fast (time) and cheap (cost).

Although there are other important aspects of managing a project that will be covered in subsequent posts here, the triple constraint (scope, time and cost) implies that a project, large or small, addresses at least the following areas:

  • Specific outcomes and results: requirements and deliverables (scope);
  • Definite tasks, start and end dates: schedule (time);
  • Established resources: people, materials and budget (cost)

Project managers perform four primary management functions:

1. Planning: This encompasses project initiation and detailed planning, involving processes to identify needs and requirements, define deliverables and tasks, estimate resources and develop the project management plan.

2. Organizing: This function prepares for execution, it is a supporting and administrative function to provide project structure and governance. Most of the time, organizing involves staffing and procurement, but other preparation activities might be included here.

3. Directing: This is the management function of getting the work done, managing execution according to the plan. It encompasses stakeholder engagement, team management and communications management.

4. Controlling: This function takes care of project performance monitoring, preventive and corrective actions and the integrated change control.

These functions might be performed in parallel and should not be understood as sequential.

Outside of these functions, project managers should also focus on managerial aspects of the project, including leadership. Although it is desirable that the project manager possess some knowledge in general business management, business analysis and the technical aspects of the project, they are usually supported by other experts in a number of project management related disciplines including systems engineering, requirements engineering and specialist engineering disciplines, quality assurance, integrated logistic support and more depending on the project and industry.

But, are these best practices really universal given all these factors? Please leave your comments below. We’ll be looking further into this question in subsequent posts.

Posted by Mario Trentim on: March 27, 2018 03:36 PM | Permalink | Comments (17)

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)

Every Project Disrupts the Status Quo. So Show Stakeholders Why Change Is Worth It.

By Mario Trentim

Ever heard this joke? “You don’t need superpowers to change an organization. You only need one project manager—but the stakeholders must want to change.”

In this post, I want to remind you to put yourself in your stakeholders’ shoes. As you think about the changes to be delivered by your project, take their different perspectives seriously.

If you ask most people about their attitude toward change, they give answers trying to show how flexible and adaptable they are. After all, nobody wants to play the naysayer role. We don't want to be seen as resistors.

For example, I once asked my MBA students if they like change. They cheerfully answered "Yes!", to which I promptly answered "Fine, let's extend our class by five hours. Moreover, I want you to read seven papers and two books by the end of next week so that you can take a four-hour exam."

It’s easy to prove the point that we don't like bad changes. But what about good changes, the ones that benefit us? Do we really even want a change that’s good for us?

In reality, our behavior and attitudes often contradict what we believe. Why? Because we are afraid, and our expectations and interests are different and changing. Our relationship to specific changes isn’t static.

The biggest issue is that organizations (and project leaders) don’t always present planned changes in ways that makes it easy for people to answer the most important question: “What’s in it for me?”

I sometimes hear project managers complaining about their stakeholders. They say, “stakeholder X always changes his mind,” or “stakeholder Y creates obstacles to my project,” and so on.

Wake up! Stakeholders are not the problem. The truth is that your project is the problem. After all, what is a project?

From its definition, a project is a temporary endeavor to create a unique result. So, your project will create something that didn't exist before, something that wasn't there.

A project is a disturbance in the environment.

As a functional manager, for example, I will have to give up my status quo. I would be “forced” by your project to learn how to use the new enterprise resource planning system that you want to install. Do you really think I would help you? Is the functional manager the problem? No.

As a project manageryour job is to convince stakeholders they are going to benefit from the outcome. Show them what they will earn. If you fail, they won't help. As long as your stakeholders are not happy, your project is doomed to fail.

Want to learn more? Check out the webinar Managing Stakeholders as Clients. And, please, leave your comments!

Posted by Mario Trentim on: June 15, 2016 07:18 AM | Permalink | Comments (12)
ADVERTISEMENTS

"In the real world, the right thing never happens in the right place and the right time. It is the job of journalists and historians to make it appear that it has."

- Mark Twain

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events