By Conrado Morlan
The project you led is complete! You are celebrating with your stakeholders and other project managers. The company is right on track to achieve its strategic goals based on the benefits delivered by your project.
After handing over the project to the business functions, you are now ready for your next move. You are nervous and excited about discovering your new assignment, so you don’t worry about your recently completed project. Somebody else will be following up on the project’s contributions to the organization. You’re done, right? Well, let’s find out.
During the first six months of your new assignment, you overhear that the benefits of the project you recently completed are not at the expected level. In parallel with your current assignment, you start looking for clues about what’s gone wrong.
Your findings reveal that related processes supporting the product or service delivered by your project are not aligned and are producing damage and losses, resulting in the erosion of benefits. Examples may include:
So what should you do? Focus on your current project assignment and ignore the benefits erosion? Or work on a solution with the project’s stakeholders?
Whatever your answer, one thing you will need to do for sure is update the project’s lessons learned. The project may be over, but benefits didn’t reach the expected levels. So as the former project manager, you’re obligated to document what went wrong to support efforts at establishing a solution.
Have you ever learned of benefits erosion after completing one of your projects? If so, how did you react?
By Kevin Korterud
It’s typical for new project managers to be assigned to a small project to build their skills. Why? Small projects have a limited value at risk, a modest budget, a shorter schedule and a smaller team. But project managers early in their career who have successfully led small projects often ask me how they can move on to leading big projects.
Small projects, to some degree, can be more difficult to lead than larger ones. You are given much less in the way of reserve budget, schedule and resources. However, big projects are not just smaller projects with larger budgets and longer schedules. They have inherent complexities relative to stakeholders, scheduling, resources and deliverables not found on small projects.
My recommendation to project managers wanting to move to larger projects is to “think big” while running smaller projects. Thinking big involves adopting, where possible, practices required for large projects.
Here are two ways project managers can think big on projects. My next post will offer two more tips.
1. Leverage Support Resources
Many times, project managers running small projects attempt to perform all of the project operations activities themselves. This can include creating new work plans, calculating progress metrics, scheduling status meetings, and performing a host of supporting activities for the project.
While it may be a source of great pride to a project manager to perform these activities, they represent an opportunity cost. In other words, the project manager could instead be working on higher-value activities like stakeholder management or risk management.
Employing support resources even on small projects can save valuable time and costs. It also means the project manager doesn’t have to spend time becoming an expert in the tools and internal project operations processes. By having other people assist with the mechanics of building project plans and producing metrics, the project manager will have additional capacity for running the project.
2. Implement Quality Assurance Processes
Project managers on small projects tend to become immersed in a level of detail not possible on large projects. The small project also allows for deep interaction with team members that may not be effective on large projects.
In addition, a project manager on a small project may be tempted to start serving in roles akin to a business analyst or technology designer. This can distract the project manager from actually running the project.
To keep focused on project management activities, quality assurance processes should be implemented. Phase gate reviews, deliverable peer reviews, change control processes, quality performance metrics and the definition of project acceptance criteria are all good examples of quality processes. With the implementation of these processes, project managers can focus on deliverables and outcomes without getting too deeply immersed in the details of the project.
Check back for my next post on more ways project managers can develop a big-project mindset while executing small projects.
By Taralyn Frasqueri-Molina
A lot of things change when moving from traditional project management frameworks to agile ones. But what doesn't change (or shouldn't!) is how much and how often teams communicate.
Agile frameworks don't actually require daily stand-ups or regular retrospectives. But you should consider adding some new trade tools and a few other staples to your project management toolkit if you’ll be working in an agile context. You may find that they quickly become essential to keeping communication flowing through your team—and your project on track.
Here's a short list of tools I've used on all of my projects.
Sync-ups/Planning Meetings: This helps me start a project off right by making sure the product owner and execution team are on the same page. We set expectations, talk requirements and the direction for deliverables in areas such as UX, design, marketing.
Daily Stand-Ups: Quick check-ins with the entire team help gauge project health and bring roadblocks to the forefront sooner rather than later. This is also where we address scope creep, taking note of good ideas that need more exploration before being included in the backlog.
Retrospectives: After each sprint and after each project, a retro helps the team ensure processes are working— and decide if we want to carry over those processes to the next iteration.
Wiki: These often get a bad rap but can act as an excellent centralized location for real-time documentation editing and sharing. In my experience, it can serve as a digital asset management (DAM) system for sharing web copy and design assets. While not a perfect DAM solution, it will do in a pinch.
Instant Messaging: Whether collocated or remote, teams sometimes need quick answers to questions—and a meeting can be overkill as a way to get answers. The challenge with instant messaging, though, is to make sure teams are on the same page about how and when to use an IM tool.
Email: This tool still reigns supreme when it comes to quickly keeping a lot of people in the loop about what's going on. Even if it's an email directing people to a wiki, it's still one of the best tools for mass communication. But maybe not for decision-making!
What tools am I missing? And do you find any of the tools mentioned particularly good or bad for certain kinds of communications? Share your thoughts below.
Project Leaders as Ethical Role Models
Human Aspects of PM,
New to Project Management,
Nontraditional Project Management,
PM Think About It,
Reflections on the PM Life,
Categories: Best Practices, Career Help, Communication, Communication, Complexity, Ethics, Facilitation, Generational PM, Human Aspects of PM, Leadership, Leadership, New to Project Management, Nontraditional Project Management, PM Think About It, PMI, PMOs, Portfolio Management, Program Management, Project Delivery, Project Failure, Project Planning, Project Requirements, Reflections on the PM Life, Roundtable, Social Responsibility, Stakeholder, Strategy, Talent Management, Teams, Tools
By Peter Tarhanidis
This month’s theme at projectmanagement.com is ethics. Project leaders are in a great position to be role models of ethical behavior. They can apply a system of values to drive the whole team’s ethical behavior.
First: What is ethics, exactly? It’s a branch of knowledge exploring the tension between the values one holds and how one acts in terms of right or wrong. This tension creates a complex system of moral principles that a particular group follows, which defines its culture. The complexity stems from how much value each person places on his or her principles, which can lead to conflict with other individuals.
Professional ethics can come from three sources:
In project management, project leaders have a great opportunity to be seen as setting ethical leadership in an organization. Those project leaders who can align an organization’s values and integrate PMI’s ethics into each project will increase the team’s ethical behavior.
PMI defines ethics as the moral principles that govern a person’s or group’s behavior. The values include honesty, responsibility, respect and fairness.
For example, a project leader who uses the PMI® Code of Ethics to increase a team’s ethical behavior might:
Please share any other ideas for elevating the ethical standards of project leaders and teams, and/or your own experiences!
By Kevin Korterud
As both a project and program manager, I’m always keen to have projects and programs take the right first steps toward success. In the past, this would involve selecting the unified delivery approach used for all of the projects on a program. The idea was to impart consistency to the way projects were managed as well as produce common metrics to indicate progress.
It’s not that easy anymore. Today’s programs have projects with agile, waterfall, supplier, corporate and sometimes regulatory-mandated delivery approaches. In addition, these approaches as well as the different arrangements made with suppliers (e.g., time and materials vs. fixed price with deliverables) have dramatically increased the level of complexity and diversity of delivery approaches within a program.
So as a program manager, how do I keep all of these projects in sync no matter the delivery method? As a project manager, how can I execute my project in concert with the overall program in order to maximize the value that will be delivered, while avoiding schedule and cost overruns resulting from projects not operating in harmony?
These are emerging challenges for which there are no single easy answers, of course. But I have found a handful of tips useful in getting a program’s projects to operate in a synchronized manner. I’ll share the first few in this post and the final ones in my next post, appearing later this week.
1. Remember: There’s No Such Thing as Agile or Waterfall Programs
Given the mix of project delivery approaches, the program needs to properly segment work to manage the budget, resources and schedule regardless of the project delivery approach. In addition, the schedule alignment points, budget forecast process and deliverable linkages need to be identified between the various projects.
Typically, I find that while there is effort to plan for these items at the project level, the upfront effort for this harmonization at the program level is underestimated or sometimes left out altogether—program managers think the project teams will figure this out themselves. This sets the program up for schedule and budget overruns as well as overall dilution of the program business case.
Some ways for a program manager to harmonize projects on a program include:
2. Make the Correct Delivery Approach Choice Before a Project Begins
The type of delivery approach for a project is determined by the type of work being performed and the end consumer of the project’s deliverable.
For example, a project on a program that is slated to create a consumer portal would be a desirable candidate for an agile delivery method. Another project that involves heavy system integration that a consumer never sees would be a candidate for a waterfall approach. A project to pass data into a government system would likely have its delivery approach set by the governmental body.
So before a project starts, program and project managers should agree on the optimal delivery approach that is the best fit for the project.
Look for more advice in my next post on synchronizing a program’s projects, regardless of delivery method.