Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Coach Your Project Teams by Example
| Have you ever thought that as a project or program manager, you indirectly set a precedent on managerial style, behavior, competencies and professionalism. Unconsciously, we are showing our team members how to manage crises, deal with stakeholders and so on. There are many ways that we can unknowingly coach our team members. When dealing with stakeholders, for example, project managers have the authority to set limits and control the discussion to stay on the subject. To be able to do this, we need to know the business process at both a high level and in terms of the customer's business goals. In dealing with stakeholders, we indirectly coach our project team members to do the following things:
How have you indirectly coached your team members in your projects? What examples do you set for your team members to follow? Read more posts on coaching teams. |
Technology Helps with Project Lessons Learned
Categories:
Lessons Learned
Categories: Lessons Learned
| Conducting lessons learned and project reviews has been a practice that many organizations have used over the years to help their next projects be successful. It's a continuous cycle of retrieving and assessing your project information. As the project manager, you should call a meeting and discuss any issues or tasks that went wrong and what could have been done to improve the project. The improvements should be incorporated into the processes of the next project, which typically have a better outcome. Then that project will have its own challenges that will also need to be addressed. And so it goes. If you aren't doing some type of project review or lessons learned, you will most likely repeat actions that have caused the project failures, budget overruns, scope creep, inadequate stakeholder involvement, technology mishaps and other problems that plague your projects. Yet some project managers find excuses not to host these valuable meetings. One such excuse is a geographically dispersed team. There's no need for a dinosaur mentality to achieve a project review. Use today's advanced technology to your advantage when conducting a lessons learned meeting:
Do you use technology or traditional methods in your lessons learned? |
Project Management Adds Value to Operational IT Departments
Categories:
Information Technology
Categories: Information Technology
| The structured approach of project management can add value to operational IT departments. What makes this work is the approach that the project management office (PMO) or the project management team defines in its project management methodology for release of the systems into production environments. Operational departments should execute with a process often referred to as "steady state transfer." This process gives the project team the opportunity to validate all the key production processes such as the support, maintenance cycle, systems restore and sanity testing, which is the basic testing of the system functionality. Project teams launch the steady state transfer after successful tests show the systems are ready to be released into the production environment. This validation step -- to ensure that the system processes are well mapped between various support departments -- adds value to the operations teams. The validation step is done during project execution using the steady state transfer process -- and without generating special projects. This validation step in the project management practice guarantees process interface manuals are updated with any changes to the processes and the test results. The operational departments work with the project team to complete this task and thus make a smooth transition into the "steady state" of operation. What processes does your organization use to achieve the same results? See more posts on IT. Read more from Dmitri. |
Project Change Challenges
| Who should lead the change challenge: organization management or project management? The project team probably has a better idea of the technical aspects of the changes required. But, the organization's management initiates the project and has overall responsibility for achieving the intended benefits after the project is complete. In my opinion, change management is an organizational responsibility. The role of project management is to focus on creating the deliverable effectively and supporting the organizational change effort. In short, the project management team works for the organizational change management team. However, I have seen many situations where managing the change is treated as a project responsibility. For those project teams undertaking change management, the change challenge is getting the necessary buy-in from organizational stakeholders who have to make effective use of the project's deliverables to get the expected value from the project. There is no point in the project team being happy with its work if no one uses it. The way the organization works has to change if the deliverable is going to be used effectively to create value for the organization and generate a ROI on the investment in the project. Effective communication with the affected stakeholders is a must when addressing the change challenge. These communications follow a fairly standard pattern:
See more posts from Lynda. See more on stakeholder management. |
Use a Framework to Plan Project Requirements
Categories:
Project Planning
Categories: Project Planning
| Project requirements are rarely collected and made available in a final form to a project team. Instead, requirements are often collected through an elicitation process, which involves a discovery, analysis, understanding and validation endeavor. Usually, a business or requirements analyst carries out the requirements elicitation process. The project manager is typically responsible for planning and setting up the requirements elicitation and management framework. Well-planned and well-managed project requirements are common characteristics of successful projects. This simplified framework can be a guiding requirements checklist for project managers: Organizational assets: Identify the available organizational process assets for planning and managing project requirements. The organization or project management office might already have standards, guidelines and templates that can or should be used as a starting point. Stakeholders: Use the stakeholder register to identify the stakeholders who will help provide, collect, analyze and document the project requirements. Categories: Identify and categorize the requirements types that are to be elicited, such as:
Documentation: Identify how requirements will be documented, whether it's textual form, graphically or using a formal requirements language. Identify the way requirements will be tracked -- through requirement tools, Word documents or spreadsheets. Maturity Index: Establish the criteria by which requirements are validated and qualified. Is it clear? Does it make sense? Is the criteria aligned to the project vision and goals? Prioritization: Identify the criteria on how requirements will be prioritized and scoped. For instance, list the must-haves first. Then come the "quick wins," requirements based on the owner prioritization, complexity and costs, the project phase, etc. Risks: One of the main inputs for the project risk management plan are the scoped requirements. Identify the requirements posing a risk to the project. Develop risk mitigation, response and tracking plans. Change management: Establish the criteria for detecting scope creep and basic rules for handling requirements changes for applying the change management process. How are you planning and managing your project requirements? See more posts from Marian. See more on project planning. |