Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Project Management Knowledge Versus Technical Knowledge
Categories:
Leadership
Categories: Leadership
| As project managers, we have to manage various tasks in multiple lines of work. At times, we operate from our technical background and impart that knowledge and expertise more than our project management knowledge. There needs to be the distinction of when we use our "project manager hat" versus our "technical specialist hat." Many project managers work in two common extremes: process focus or technical detail focus. This is common for junior project managers and for project managers who are new to an organization. That often happens, in my opinion, because those project managers haven't developed their management style yet or haven't adjusted to the organizational culture. When the project manager thinks something is going wrong on a project, either with how someone is performing a task or the results of a deliverable, we often try to fix it. We do that with our strongest toolkit -- usually, that's our technical background. We often take over and hijack the task just to do it "our way," based on our experience. Remind yourself that as a project manager, you have a different role as a leader. You also can't be a technical skills expert for your team. Realign yourself to the deliverables. Gain a clarity of the project goal, the project management approach you are using and your role in managing the given project resources. Project managers can be quite connected and attached to the project outcome. But when you see an opportunity to improve something based on your technical expertise or what you would do differently, stay focused on your role, which is to deliver the project according to the business requirements, aligning with the business sponsor and the organization. Let your team handle their tasks according to their experience and expertise. Do you ever rely too heavily on your technical expertise? Read more from Dmitri. |
Fill in the Blanks for Junior Project Team Members
Categories:
Generational PM
Categories: Generational PM
| The other day, a member of my project team e-mailed me and proposed that we consider starting a new project. The new project would complement a project we are currently working on. Eventually, I learned that the project board had rejected this proposed project before. I discovered that a stakeholder who had pushed to start the project several times -- despite the fact that the board discarded it -- approached my team member, who happened to be a junior member and new graduate. As a new member to our team, I had to explain the project selection process of our organization. The board selects projects from a business-oriented approach. Under this direction, projects produce business benefits that will contribute to achieve organization's strategic objectives. The proposed project did not fit this mindset, but as a new project team member, how could he have known? I explained further to this project team member that in this mindset, project professionals must wear a business and technical hat. Depending on the situation, project managers must ensure that their project teams deliver projects that will produce the benefits and results that the organization is looking for. This is just one example of how project professionals will need to be able to coach "multi" teams, especially those made up of new and young project members. You can't assume that everyone on the team shares your same knowledge. Eventually, the junior team member understood why only projects that will help the organization fulfill its intended purpose should be selected. A few days later, we met with the stakeholder to ask for specifics about the project with regard to the organizational benefits. How do you coach junior project team members when they are less knowledgeable? |
Tailor Your Coaching Style to Project Team Members
Categories:
Education
Categories: Education
| In coaching project team members, project managers may forget that each person is different. Thus, the approach to engage them will be different. It is imperative to remember you are not creating a clone of yourself and that your team members may have a different working style than you. You must have a game plan when coaching individual team members. It does not need to be written down; you just need to pay attention. Focus on the way your team members prefer to work, listen and learn. Some people like to draw when they talk or explain. Some people write everything down. Others just stare blankly but give good responses when requested to. When you have an idea of how your team members operate, try these tips to coach them further:
How well do you know your team members? How do you engage their interest in learning new things? |
Plan and Facilitate a Requirements Workshop
Categories:
Project Planning
Categories: Project Planning
| Every project manager knows that there is no single best way to collect project requirements. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) -- Fourth Edition identifies several tools and approaches for collecting requirements. They include interviews and focus groups, facilitated workshops, group creativity and group decision-making techniques. Combining some of these tools and techniques with a requirements workshop can be the most efficient and effective requirements elicitation approach. But only if the workshop is planned and facilitated well. Planning a requirements workshop is no different than planning any meeting or event. Some simple steps to follow: 1. Define the scope and establish an agenda The scope and agenda should make it clear to all participants the reasons why they are attending the workshop. 2. Invite the right people Generally, you want to keep the guest list short, but make sure to invite key stakeholders. These include representatives from teams or user groups that will benefit from the project's outcome, project sponsors, product or system owners, and business and technical consultants. 3. Plan the logistics To facilitate an open and constructive working session, make sure that the workshop's location and environment has sufficient capacity and appropriate equipment for hosting the workshop. Now that we have a good plan, how do we facilitate the workshop? 1. Lay ground rules Establish basic ground rules. For example, start on time, stay in scope, and respect and build on other people's ideas. 2. Gather requirements Get everyone involved through questioning and individual interviewing. Apply group creativity techniques, such as brainstorming and mind mapping. And for topics that require in-depth and focused discussions, organize dedicated breakout sessions. 3. Record the workshop Make sure that someone attends the workshop solely to write the protocol during the workshop. He or she should capture all requirements, ideas, assumptions, risks and open items. 4. Pre-qualify and pre-prioritize requirements To facilitate the scoping process at a later stage, try to leave a requirements workshop with pre-qualified and pre-prioritized requirements. 5. Review the protocol and develop a follow-up plan At the end of the workshop, plan sufficient time to review the written protocol and the derived action items. Develop a follow-up plan to address the open items. Identify the owner of each item, and establish deadlines and next-steps. Do you hold requirements workshops? If so, how do you plan and facilitate them? |
A Project With No Project Charter?
| Also known as the project initiation document, the project charter is a high-level document created at the start of a project and referred to throughout the project's duration. It is the foundation of the project, a basis for how the project can evolve. The charter should state the purpose, main objectives and vision for a project. Many project professionals may consider the project charter as 'more documentation' or a 'mere formality.' But the truth is that if they start to consider creating a charter as a best practice, many problems or issues can be eliminated. However, I regularly meet project managers that manage their projects without referring to or even knowing the existence of their project's charter. Why? Here are some reasons a charter is left out, based on my experience:
Risk of diminished value and importance of a project, if its purpose and strategic benefit are not documented, agreed and formally recognized. Delayed decision-making. Getting management and sponsors to sign off on things becomes difficult. There is no one to champion for the project and responsibility for it is passed around. Difficulty managing expectations. Without a collectively agreed to charter, there may be frequent disruptions and disagreements from stakeholders. They will have differing intentions, opinions and understanding of the project's outcomes. Risk of failure. When there is no clear, recorded statement of a project's goals, it's more prone to fail. The project charter includes the business case and other additions, which serves as a constant reminder of the project's vision, mission and critical success factors. Lack of authority. The project manager will be plagued with problems from lack of authority to spend the budget, the ability to acquire and assign resources, and a general power needed to make day-to-day decisions and actions. This will also make it harder for the project manager to attract good suppliers, vendors and resources to work on the project. This can create a culture of dissatisfaction and apathy within the existing project team. Subject to scrutiny, delay and bureaucracy. The project can expect numerous changes and deviations, which increase the risk of not delivering and reaching the projects goal. It could eventually become a financial burden to the organization. Do you know of any other reasons why a project charter would not be created? How can the lack of a charter plague a project? |