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.

Viewing Posts 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.

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:

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.

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.

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.

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:

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.

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.

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:

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 manager, your 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.