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:
Examples of defined system engineer competencies include:
Examples of shared competencies include:
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:
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.
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.
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:
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:
2) Utilize various information-gathering techniques:
3) Try different diagramming techniques, such as:
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!
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.
Want to learn more? Check out the webinar Managing Stakeholders as Clients. And, please, leave your comments!