Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Viewing Posts by Dmitri Ivanenko PMP ITIL
Hierarchy of Team Needs
Categories:
Teams
Categories: Teams
| In Abraham Maslow's hierarchy of needs, the lowest level consists of basic needs we all have, like air, food and sleep. Once those are met, we begin to move up the hierarchy to higher-level needs, such as safety and esteem. The same hierarchy applies to the project teams, which are comprised of people with various levels of needs. We often assume everyone is at a level comparable to ours and our remarks or comments will simply be understood the same way we would understand them. This is not to say the age or experience of project team members is directly related to these needs, as even most experienced members of the team may have gaps in fulfilling their needs. Whether it's the need of a job or of recognition, all of these needs influence behavior and it's important to be attentive to them. They can influence various project activities and their outcomes, such as meetings, conversations, use of resources, vendor relations, compliance, ethics and fraud. When organizations recruit project talent, they look at skills and experience as well as personality and cultural fit. But attention should also be paid to team member needs, including those of the project manager, director and sponsor. Doing so can contribute to better understanding of the project environment and the elements that will require special attention. |
Visualize Your Success
Categories:
Career Development
Categories: Career Development
| Many years ago, I recall being in an interview where the recruiter asked me if I knew what visualization was. I didn't. She explained to me that it's all about forming a mental picture of something you want to achieve as if you've already achieved it. For instance, imagine a standing ovation for excellent project performance or a big increase in pay or a promotion. It makes the future seem clearer and it tells your brain that you can do it, you can achieve it--because you've seen yourself do it successfully before. So how does it work? Simply do the following: 1. Choose an object and really focus on it. Then close your eyes and in your mind, tell yourself what you just saw--the colors, shapes, details. Open your eyes and confirm. 2. Close your eyes again and see yourself performing activities tomorrow, simply replaying in your mind what you know you will be doing tomorrow. 3. Identify one thing that you want to achieve. Let's say you have a meeting to present a project status report to the stakeholder community and you want to ace it. Close your eyes and visualize yourself standing in front of all the people attending your meeting, confident of the material and how you presented it. See yourself reporting with confidence, referring to documentation on slides or handouts, seeing everyone around understanding what you are presenting and being pleased with your results. 4. Do that a few times until you know exactly what you need to do to obtain that success. I would go as far as spending 20-30 minutes a day to do this exercise. Your mind will become conditioned to visualize the future the way you want to see it and, sometimes intuitively, that will lead you toward the envisioned success. So my question is: What do you want to achieve now? |
Working With Risk
Categories:
Risk Management
Categories: Risk Management
| Risk exists at all times. The less planning we do for it, the higher the chance of failure or uncertainty of results. I am a strong believer in integration. Therefore, risk management must be an integral part of any organization's project management methodology. Risks are generally identified, assessed and quantified. Risk is then monitored until it is no longer a risk or to ensure that any events identified as a risk do not actually go unanswered. That's where risk response comes into the picture. Response to risks comes in the form of: - Acceptance - Rejection - Mitigation Organizations must ensure they: - Identify key risk-management processes to map them out to the organization's processes for project delivery - Identify risk factors (i.e., elements that cause probability of risk occurrence to increase) - Standardize risk identification, assessment and quantification, and documentation across the organization Think of it this way: Risk equals money. It's the amount of money we are going to spend (or not spend) on either activity A or B. If we identify a risk of executing activity A for a price of X, but have a moderate to high level of confidence in success of this activity, we may choose to forgo doing anything else or delay the activity to remove or reduce the risks. If risks end up being realized and we end up facing the results of it, the cost of it would be linked to loss of revenue and added support to resolve the issue that was created by unresolved (but accepted) risk. And if it is less expensive for an organization to actually accept the risk and deal with its impacts rather than continuously applying resources to making things perfect, then the justification of taking risk from financial standpoint can be very convincing. How do you work with risk? |
Are You Really Ready for a PMO?
Categories:
PMO
Categories: PMO
| Organizations that have a project management office (PMO) show they are moving toward a centralized management of project resources and strategic alignment to business goals. But I find a certain level of readiness has to exist in an organization for it to create the platform for a worthwhile and cost-effective PMO--the type of PMO that contributes to the business not by simply being an extension that offers extra resources, but that works and evolves with the business. There are key issues in organizations that usually hinder this: • Senior teams do not understand the PMO or its purpose • Senior management teams do not understand what project management is all about and how it can help them lower the costs of implementing projects • The PMO is viewed as something you install without careful and business-aligned planning In my mind, PMO implementation must be viewed and managed as a project. A company should know why it's seeking to implement a PMO in their organization, what business issues it's trying to fix and what inefficiencies it's trying to improve. A company has to consider: 1. Organizational Readiness Organizational processes will require changes to ensure the process flows into and out of the PMO are integrated into the organization. 2. Cultural Readiness The organization has to assess its readiness based on current resource pools, whether the resources can be migrated to PMO teams, and how other members of community will be able to align with PMO requirements based on their knowledge, experience, skills and mindset. 3. Strategic Alignment The goal is not just to have another department, but to have a team of people agile enough to act quickly and in a focused manner. And planning of the PMO has to include reasons that align with direct impacts on strategic goals of the organization. |
Lessons Learned
Categories:
Teams
Categories: Teams
| Recently I had a team meeting to discuss lessons learned from a project and how we could document them to help reinforce the positive experiences and avoid the negative ones. As expected, we had a template to document the lessons. We had one team in the room and other teams on a conference bridge and two hours to get it done. Of course, that came with pizza and drinks. How do you manage to collect, assess, validate and populate data in a two-hour window? You have to have this data already present and entered into the system of some kind (whether it's electronic or paper), with such parameters as experience rating, failure points, links to deliverables each item refers to, impacts etc. And you have to have this information ready and available for this special meeting that simply reviews the results of what you've gathered over the course of the life of the project. A system of lessons learned would include or require the following: 1. Lessons learned as one of the deliverables of the project 2. Method/forum for submitting lessons learned to the project management office or senior management overlooking the project or running the functional areas that require changes based on lessons learned 3. Method or process for integrating those lessons into the organization 4. Method of entering the information, such as electronic lessons learned system (web- or network-based) or collection of documents, spreadsheets etc. 5. Method of accessing lessons learned information from past projects, relating to specific areas of the project or organization 6. System to have these items as required components of milestones on the project plan 7. Contribution to the lessons learned from issue reviews in a semi-automated way, so that at the end of the issue review or steering committee meeting you could use the data to post it to the lessons learned system Success of a lessons learned system depends on a buy-in from the sponsor, the steering committee and the organization to all the items above. Have you implemented a lessons learned system recently or participated in a lessons learned review? What was your experience? |