By Jen Skrabak, PMP, PfMP
In the first part of this series, I introduced PMI’s new governance practice guide and reviewed basic differences between organizational (corporate) governance, portfolio management governance and portfolio governance.
With that foundation, I’ll now discuss the four basic governance functions, which together can ensure alignment to strategy. Since portfolios include programs and projects by definition, those are not called out separately.
In addition, there are four basic governance domains:
For some portfolio managers, there may be confusion over governance activities versus portfolio management activities. Portfolio managers may play a governance role on certain programs and projects and provide oversight and decision-making. However, day-to-day portfolio management is distinct from governance, as shown in the diagram below:
Look for part three of this series—which will be focused on key success factors—in the coming weeks! And comment below to share your reactions.
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.
Agile, or Real Agile?
By Christian Bisson, PMP
Agile approaches allow for iterative and flexible avenues to develop software. (It can be used in other fields, of course; I work in the software world.) When used properly, it can be an efficient way to adapt to changes in requirements and scope, and provide stakeholders with an up-to-date and ongoing list of deliverables to review.
Unfortunately, it’s a misunderstood approach that leaves many of us wondering if they’re really working in agile ways. Here are a few misconceptions I’ve encountered throughout the years.
Things just change names
My favorite misconception of agile is that terms suddenly need new names.
Meetings become “scrums” or “daily scrums”—even though the team is just having a regular meeting. A “week” becomes a “sprint”—even though there is no deliverable/release at the end.
Going faster is agile
Project managers sometimes “crash” a schedule to speed up project deliveries, knowing that it uses more budget in order to meet a deadline. Sometimes “crashing” is confused with “agile,” which is thought to deliver projects sooner and cheaper by having everyone start their work sooner than they would have in a traditional waterfall approach.
Having people start sooner and risk rework is still crashing even if the practice is called “agile.”
Stakeholders don’t have to be involved
Stakeholder involvement is a critical part of the agile approach. It requires them to be available and in constant discussion with the team. This prevents surprises and allows constant feedback.
The misconception I see sometimes is that a team can work “full agile,” with stakeholders only involved when they receive assets and go through their typical review cycles.
We’ll just “try” agile
Agile is not about trying out a new software. It’s a culture, and it involves everyone from stakeholders to the team. Some believe that a few people can “try agile” on a project and see how it goes, even though none of them worked in an agile environment before.
Scope and cost can be fixed
Although agile could work with a fixed cost, it is quite the trap. Agile assumes that what will be delivered is the work that the team was able to deliver in a set amount of sprints, and each sprint will cost a certain amount based on the team’s size (among other things).
This means that if a feature took twice the amount of time estimated because it was decided to create something a bit more complex, then another feature might be removed or budget will be added to compensate. However, if you keep the budget the same but still expect to deliver everything planned on day one, then this more complex feature is simply scope creep.
These are just a few examples of agile misconceptions. My bottom line: When I’m told stakeholders want to use “the agile approach,” I make sure to ask for a definition of agile.
Have you encountered other agile misconceptions? Share them below!
In recent years, agile approaches have rapidly gained ground in many parts of the world—but not everywhere. Some areas of Asia, including where I live (Taiwan), have generally speaking not yet embraced agile ideas and practices, despite their value and potential in the region. For this reason, I’ve been working to promote the adoption of agile approaches.
What is agile? It means being flexible and able to quickly adapt to unpredictability. Agile approaches are useful where the environment is constantly changing, where requirements are not fixed or where stakeholders face constant uncertainty.
Agile is typically used in software development, but it’s becoming more suitable in any organization facing rapid changes. Developed over 20 years, agile practices focus on customer value and emphasizing collaboration.
My work has involved training Agile Certified Professionals (PMI-ACP)®, organizing agile communities, promoting agile practices and reporting on the successful use of agile. I have a digital magazine, “PM-Mag ,” with over 100,000 readers across the Chinese-speaking world. Two of the editors have earned the PMI-ACP® credential.
Through my company, I ‘ve also commissioned reports and articles about the use of agile to generate its acceptance and support. I’ve also taken advantage of other media (such as radio and YouTube videos) to raise awareness of agile in the project management world. And then there are other more novel approaches—like an ACP song played at events and before speeches. I introduced a “Hybrid PM” badge that I award to project managers I see taking up agile ideas.
In the last year alone, I trained 149 PMI-ACPs, accounting for nearly 50 percent of the PMI-ACPs currently working in Taiwan.
It was my honor to win the 2015 Agile Award for Person Who Has Done the Most to Promote Agile. The competition was strong, and I’m very humbled by this recognition.
Currently in their sixth year, The Agile Awards are organized by business management consultancy Yoh to recognize businesses, organizations and individuals who actively promote knowledge of agile, as well as its proper application and development. In the past, the awards have been dominated by Europeans and Americans.
I hope that my recognition will spur more international recognition of agile methods in project management, encouraging the further development of agile in Asia and allowing European professionals to understand agile application and development throughout Asia.
To improve the acceptance of agile even more, I encourage those who have already gained their PMP to learn from agile, especially the concepts of incremental delivery, adding business value and embracing change. These new ways of running businesses can improve the competitiveness of small to medium-sized businesses. The added value is too great to ignore.
By Kevin Korterud
I’m frequently asked how program managers can synchronize projects using waterfall approaches with those using agile or other approaches. As programs are launched to address larger and more complex business problems, harmonizing a program’s projects becomes an essential component of success.
In my last post, I shared two tips for achieving harmony: remember that there’s no such thing as agile or waterfall programs, and make the correct delivery approach choice before a project begins.
Here are two more tips.
3. Establish a Program PMO and an Agile COE
One of the critical success factors for any large program is the program management office (PMO). The program-level PMO enables the program manager to spend time on higher-value activities while the PMO creates the operational governance, reporting and overall management foundations required to run a program.
As agile and other delivery approaches mature, there is a great need for a COE (Center of Excellence) model that fosters efficient and effective delivery approaches for projects on programs. Just as PMI has created a consistent approach to project management, agile and other delivery approaches are at a point in their maturity cycle where consistency is needed for them as well.
An agile COE can facilitate this consistency while serving as a clearinghouse for improved agile practices. This COE can also address different variants in waterfall, supplier and governmental delivery approaches, thus resulting in an overall harmonized approach for program and project delivery.
4. Speak the Same Metrics Reporting Language
George Bernard Shaw once said, “England and America are two countries separated by a common language.” Being a program manager with projects utilizing multiple delivery approaches can feel like living in one country separated by multiple languages!
On a program, it is essential that no matter their delivery approach, projects need to be able to both accurately describe their progress and do it in a way consistent with other projects. When dealing with projects with multiple delivery approaches, a suitable translation needs to be in place for progress metrics. This is particularly necessary for stakeholders such as finance, human resources or other business functions where an easily understood definition of progress is critical.
For example, agile projects do a great job in counting projected versus actual requirements and their weighted points. Using the total and completed requirements, a percentage completion can be calculated that is consistent with a waterfall delivery approach. Other agile-specific metrics such as effort per story point can be used to supplement the core progress metrics.
In addition, even between waterfall delivery approaches there needs to be defined a consistent approach for earned value structures, tracking actual cost and other progress essentials. (Note that aside from progress metrics, the concepts of risks, issues, dependencies, milestones, cost forecasts and governance escalations all remain the same no matter the project delivery approach.)
Program managers are orchestrators of both project delivery and the attainment of business results. They need to be always thinking about eventual business outcomes, no matter which delivery approaches are in play. Remember: no one chooses an airline or car model because the company used agile or waterfall on their projects—it’s all about the experience.
What methods have you seen employed in programs to handle multiple delivery approaches?