Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Lessons Learned: The Key to Project Success
Categories:
Teams
Categories: Teams
| What lessons do we learn from projects? What do we look for from the lessons, both as individuals and organizations? What value do lessons learned deliver in future projects? Lessons that we choose to learn from our projects are based on the purpose that is set for the project. Purpose is the key. In the project postmortem review, we need to focus on what was or wasn't met as a goal. What worked or didn't work in the use of the methodology and resources? What worked and didn't work within the project team and its members? To understand what can be improved on a project, it's essential to always look at the original goal or objective, the initial assumptions and the project management plan. Looking solely at the end result with a narrow view of the cause-and-effect elements can lead to a long report with no actionable improvements to positively impact the organization's future. A lessons-learned review is effective based on the questions asked about the project results, the purpose for the postmortem and the implementation of the review findings into the organization. An effectual review could be the key factor to the success of future projects and organizational improvements. How do you successfully use a lessons-learned review? |
PMOs Aren't Just for Project Managers
Categories:
PMO
Categories: PMO
| The project management office (PMO) is one of the fastest-growing concepts in project management today, but it's not the only answer. The PMO was born to aid the project manager. Surely then, the PMO (and, as a direct result, you) would benefit if there were a parallel organization for the technical managers, consultants, architects, design specialists, gurus of the world of application configuration and so on. The PMO is not and should not be an isolated body talking only to the project managers. It should be one of many business units leading the delivery of company strategy. Align the PMO to a single technical body, no matter what it is, and then align the two through a common process or methodology. Think about your own in-house project methodology for a moment. Is it just for project managers or does it extend to integrate the technical tasks? Does it recognize the non-project management roles and responsibilities? Does it involve the technical deliveries and control mechanisms? It should. If you have a common method, have you trained each team in a way that they both respect and understand each other's skills and duties? Have you done so in a way that ensures that the highest level of communication? You should. When your business assesses the value, benefit and simply whether a new project should go ahead at all, it won't just be the project manager's view that gets the budget approved, will it? So align the technical gurus and the project gurus as one to ensure that the lowest risk and highest ROI projects are commissioned. Perhaps the future is the perfect pairing of a PMO with a TMO -- a technical management office. It may be that the TMO is formed as a separate entity but closely works alongside the existing PMO -- or even that the PMO embraces and includes the TMO function. The specifics of how a PMO or TMO relationship would take shape depend on what's best for your own organization, but perhaps it is the future. What do you think? |
In Celebration of Project Managers
| One of the attendees at the Fifth PMI National Congress held recently in Brazil said something that really resonated with me: "I want people on my team who truly believe in the project." That statement is so simple and yet so elegant. It made me think of the project that my company is working on now: International Project Management Day 2010. A senior consultant at IIL, Frank P. Saladis, PMP, created the idea for this day of recognition and acknowledgment of project managers worldwide. Now in its seventh year, the event brings together project management thought-leaders in a virtual conference accessible to anyone and everyone around the world. Gregory Balestrero, president and CEO of PMI, and Harold Kerzner, PhD, will each deliver a keynote address. The event launches on 4 November, and attendees can earn up to 11 free professional development units (PDUs) for participating. There will also be a virtual recognition booth where you can name people you think are great project managers. This project is a joy, but often a challenge, for all of us to pull together and make it happen. We do it to help realize the goal and intention of the special day: to make sure that all of you are being celebrated. It's certainly a project that every one of us truly believes in and is proud to be a part of. Head over now -- it's not too late for you to join in the celebration. If you can't make it, the content will be up for three months and you can still earn those precious (and price-less) PDUs. |
Can Agile Work in a Consulting Structure?
| I recently attended my first PMI global congress and was struck by how many of the ideas presented confirmed my current thinking. I also learned new techniques and angles to consider for the issues I face daily in a non-traditional project management environment. In John Stenbeck's session, "Agile PM Mastery in 60 Minutes, Guaranteed!" he had a fantastic way of boiling down the essentials and explaining them in a way that traditionally trained project managers easily understand. Many agile proponents will tell you that the methodology will work within almost any environment that traditional waterfall methodologies will fit. In fact, there's one comment on my previous post suggesting that the issues that I've described -- like needing faster time to market and the ability to address fluid requirement -- would be addressed by implementing agile. I see a big gap, though: staffing. Agile works best when you have a dedicated team for the life of the project -- or at least the sprint. But many "consulting-structured" organizations rely on their ability to maximize cost benefits by pooling resources. This means assigning one person to two or more projects at a time. That strikes me as a big issue for an agile team structure. So, in a non-traditional environment with team members who aren't always dedicated to one project, what are your options in terms of attempting to implement agile? I look forward to hearing your thoughts. |
Resource Movement and Management
Categories:
Teams
Categories: Teams
| The IT industry is growing—and that means more work for project managers. This is good news, but it also means teams need more people to complete the work. While recruiting for new talent, project managers have to optimize existing team members as best they can. Some times people may be moved from one project to another, but such changes can make it hard to control the triple constraint of cost, quality and schedule. Here are my observations on how so many moving parts can impact project delivery: 1. Long-running projects require more time for people to adjust. New team members need about six to eight months to understand the project and its processes. 2. Learning curves vary. An experienced newcomer can still take awhile to become 100 percent productive. Someone just starting out may take more than a year. 3. Getting the highest-quality team members may not be feasible because of the urgency, availability and cost involved. Leverage the strong resources you have. 4. Team leaders may have less time to devote to the project. Taking on new project members could force the team leader to focus on daily tracking, resolving team issues and client communication, and less time to work on the project. 5. Implement an induction plan. It can take three to four weeks to get a replacement for a team member who resigns or leaves the team. Teams can most effectively deploy new additions by following a regular induction plan to get them up to speed on the project and culture. 6. Be flexible. Some people may perform poorly because of the project's complexity, domain, technical knowledge or their interest level. However, that same team member might do well in a different project. 7. The estimate for completing a task always differs from the actual effort. This is more severe in long-running projects. The client expects us to have complete knowledge of the system, which is not always true because of internal movement among team members. 8. Teams can work smarter on projects on a fixed bid and when work approval comes in small modules. You can have multiple modules running parallel in different phases, but there will always be some idle time in between. What do you say? |