Voices on Project Management

By Mario Trentim

As I am writing this article, the COVID-19 crisis is reaching a global scale, impacting projects and portfolios at different levels. Unfortunately, there’s a lot of noise and misinformation out there—people panicking and organizations reacting without deliberate rational thinking. Here are my thoughts from a project risk management perspective:

Should Project Risk Management Take the Pandemic into Consideration?

Considering we’ve endured pandemics before, this is, in theory, a known risk. But you likely did not include it in your project risk register, as it is very unlikely. In this case, the risk is unknown to you, because you and your team didn’t identify this risk.

Whether you agree or not, I believe that no one in the world was able to accurately assess the impact of COVID-19 before it happened—and there is still uncertainty about its impact moving forward. Consequently, in my opinion, this shouldn’t be part of project risk management. So what can we do?

Portfolio Risk Management

I’ve always maintained that risk management at the portfolio level should take into consideration events with a potential impact on the portfolio’s overall results. For example, if only one project depends heavily on vendor XYZ, then there is a risk to that project. However, if 80 percent of the projects in your portfolio depends heavily on vendor XYZ, this is a risk to the portfolio—and the threat should be treated as such.

We can add up management reserves at the portfolio level to rescue troubled projects. This is more effective than adding multiple reserves to individual projects, which makes them less attractive to the organization and to potential clients.

Contingencies, reserves and risk responses need to be evaluated according to effectiveness, cost, and benefit. In other words, it does not make sense to pay more for the risk response than the amount of risk exposure. Too much padding will destroy a competitive advantage.

The PMO’s Role in Risk Management

Now that we’ve differentiated project risk management from portfolio risk management, let’s talk about the role of the Project Management Office (PMO). A PMO is responsible for continuously monitoring the enterprise environmental factors that might impact the projects and the portfolios of the organization. On top of that, a PMO is responsible for creating a business continuity plan for projects and portfolios.

Working in coordination with other areas, including corporate risk management, the PMO must assess threats and opportunities, and develop a solid fallback plan. Some organizations have done really well during the COVID-19 crisis because their PMOs acted boldly and quickly.

Taking it a step further, many PMOs reevaluated all the projects and portfolios according to changes in the organizational strategy to minimize adverse effects.

Over the last two weeks, I attended various meetings and workshops with PMOs. Some were very innovative in their approaches. Others were more conservative. At the end of the day, the PMO is uniquely positioned to tackle issues that the project managers cannot solve themselves. And COVID-19 is a one-of-a-kind challenge.

How to Conduct a Risk Assessment on the Impact of COVID-19

We can divide the risk assessment into external factors and internal factors. For the external factors, you must assess your country’s or region’s exposure to the threat. According to the simulations, it seems that everyone will be impacted. A lot of people will become infected. And there are economic impacts on a global scale. On the other hand, some countries are better prepared to handle the situation, which means they will be able to recover faster.

Here are the key external factors you should consider:

• Is health infrastructure adequate?
• How strong is the economy in your country and region?
• Is your country heavily dependent on imports or exports?
• Also, pay attention to currency exchange rates, the supply chain and other factors.

You might also apply and combine SWOT analysis (Strengths, Weaknesses, Opportunities, Threats) and PESTEL analysis (Political, Economic, Social, Technological, Environmental, Legal). Once you understand the external environment, it’s time to assess your organization.

Here are the key aspects you should evaluate within your organization:

• What is your industry? How is it impacted by the COVID-19 crisis?
• Does your organization have solid corporate risk practices?
• Is there a business continuity plan in place? Is it effective?
• Also, take into consideration profit/loss, flexibility, agility, organizational health and more.

Organizational assessment is already going on at all levels. Does your organization seem to be lost and confused? If people in your organization are seriously concerned, but still working diligently to evaluate and to create responses, you are on the right path. If people are panicking and confusion is growing, this is a bad sign.

Finally, let’s focus on individual portfolios and projects. It is possible that many projects will be terminated, canceled or at least paused as the organization tries to figure out how to survive.

Here are the key aspects by which you can evaluate your own projects:

• Is your project based in high-risk areas?
• Do you need a lot of people working in person, co-located (such as construction work)?
• Can your team work remotely with similar results?
• Also, reassess stakeholders carefully. And evaluate vendors, as they might be severely impacted by the crisis.

To conclude, I would like to remind you that it is important to be proactive. People expect you to lead during a crisis. Use solid judgment, engage your team, document assumptions, constraints and risks and take action. Taking action is paramount.

Let me know your thoughts. How is your project performing during the COVID-19 crisis? Do you have any advice or lessons learned to share?

By Mario Trentim

There's an old saying: "A fool with a tool is still a fool.” And I’ve heard many project management professionals say that best practices and good methodology are more important than project management tools and software.

Do you agree? By the end of this article, you might change your mind.

A Brief Story of a Failed Methodology

I've been working as a project manager since 2001. In my early days, as an engineer, I was responsible for the technical and managerial aspects of projects. In 2010, as I moved up the ladder in my organization (the Air Force), I was assigned to implement and operate a Project Management Office (PMO). Considering that we didn't want to make large investments up front, my focus was on creating a methodology, developing templates and designing and delivering training. To my surprise, only a few of my recommendations were implemented, even though abiding by the PMO guidelines was mandatory.

I started investigating the reasons. It turned out that it was not that people didn't know the methodology, nor that they did not want to follow it. It was just too much work.

You know the drill: A project manager is assigned to a project, searches the intranet, finds the PMO site, then reads the "project management manual" and any other supporting documents for the methodology. Finally, the project manager copies and pastes files from a shared folder, and starts filling in all the templates (scattered in different files and different formats).

Truth be told, the project managers usually started on the right foot. The problems appeared as the project progressed, because it was a huge effort to keep all files updated and integrated in a coherent fashion.

Although I am talking about experiences from 2010 to 2014, many organizations unfortunately still find themselves in a similar situation today.

Productivity goes down. Project failure rates go up. And as the organization demands more training, it creates more controlling processes, auditing and extra reports—resulting in even more work.

The Solution

When I first came across Project Portfolio Management (PPM) and Enterprise Project Management (EPM) software in 2003, I didn't think it would be a big deal. By 2010, I was convinced that you cannot increase portfolio and project management maturity without software.

To be able to implement a standard toolset across projects, the PMO usually starts with paper-based or Excel-based approaches. The risk is that they settle for less by not evolving into using enterprise-level business applications.

Is adopting a particular tool or software a requirement to project management success? No. But the use of project management tools increases maturity.

People often say that they will acquire a corporate project management tool once their organization is "mature enough." Going back to the beginning of this article, I am very aware of the fact that a tool is useless if you don't know how to use it. However, once you already have basic knowledge and processes, a tool can speed up the learning process—skyrocketing productivity.

As an analogy, imagine that you already have basic knowledge in math and finance. When should you buy a financial calculator, such as HP-12C? Only after five years of calculation amortization by hand? I doubt this would be the smartest choice. After all, you don’t have to become an expert bike runner before you can buy a bicycle.

In project management, some of the foundational concepts can be taught by using flip-charts, sticky notes and simple Excel spreadsheets. But you cannot teach people how to create a solid and realistic schedule and cost baselines without project management software. It is just not feasible. It is not that it is impossible. Actually, in the 1960s and 1970s, the Polaris and Apollo projects were planned without the help of software tools (nonexistent at the time). But planning for those projects took a long time.

Today, we live in a modern world in which the project life cycle is shorter. We manage multiple projects at the same time, and there is more volatility and uncertainty. Project managers have to evolve as well.

How to Implement PPM and EPM Tools

Project Portfolio Management or Enterprise Project Management is a corporate platform to manage portfolios, programs, projects and resources enterprise-wide. The PMO is ideally positioned to lead project management tool selection because it understands the big picture from different project managers, team members and business units. When assessing specific project management tools, take into consideration:

1. Functions and features
2. Implementation requirements and interfaces
3. Application maintenance, support and upgrades
4. Availability of vendors
5. Cost (including customization, licenses and more)

Depending on the size of the organization, you might prefer to execute a pilot before rolling out the tool to the entire organization. It is important to keep stakeholders engaged and informed by sharing:

• Advance announcements
• Senior management sponsorship and endorsement
• The implementation schedule
• User training

A word of caution: Do not underestimate the effort needed to implement a project management tool enterprise-wide.

In the meantime, please leave your comments and questions below.

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.

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.

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.