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 Marian Haus, PMP
There is obviously a high interest in the project management community and literature about what drives project success. For example, searching online for “why projects succeed” will return you five times more web pages than “why projects fail.” Similarly, there are four times more pages about “project success factors” than “project failure factors.”
This is no coincidence! The overwhelming interest in project success insights is driven by the struggle of many organizations and project managers to understand what drives success.
But before answering the question of why projects succeed, let’s first try to define project success.
The most common definition of success is delivering the project on time, on budget and in scope. PMI’s PMBOK Guide® says a project is successful if the following parameters are met: product and project quality, timeliness, budget compliance and customer satisfaction.
Others define project success by measuring the project ROI (or business case) over a certain period of time. If the ROI is positive, the project is declared successful, regardless of its deviations along the way.
I have my own definition: A project is successful if it meets its given goals, within acceptable variance boundaries (e.g., in terms of scope, time or budget). This is a relative definition and relies on the fact that the world is not perfect. Hence even a successful project will rarely be a 100 percent success.
A civil construction project might be declared successful if it meets its scope and quality. Acceptable time or budget deviations might not be seen as failure. Similarly, an IT project might be declared successful if it meets its scope on time, with acceptable deviations from quality or budget.
A project’s success is relative: it depends on how the success criteria and metrics are defined from the very beginnings of the project, along with who will measure them.
OK, there are clearly many definitions of project success. Similarly, there are also many views and studies on why projects succeed.
Let’s take a look at a few studies and try to find a common denominator.
According to PMI’s 2015 Pulse of the Profession®: Capturing the Value of Project Management, over the last three years the number of projects meeting their goals—hence being successful—has remained steady at about two-thirds of projects. This success is the result of organizations supporting project excellence by focusing on fundamental aspects of culture, talent and process.
But size matters, too. A Gartner study from 2012 shows that small IT projects (below US$350,000) are more likely to succeed than big projects (budgets over US$1 million).
Other studies reveal that project success is tightly linked to clear project objectives and requirements that are fully understood and supported by actively engaged stakeholders.
My view on the common denominator that leads to project success is simple: the main drivers of project success are rarely of a technical nature. Instead, the drivers are the basics of the project management culture and discipline within the project organization.
In other words, fix the project management basics, and your chances of reaching project success will increase.
By Jen L. Skrabak, PMP, PfMP
Just like portfolio managers, business analysts are gaining wide acceptance as a profession. Business analysts can now earn their own PMI certification (PMI-BA) and read their own practice guide (Business Analysis for Practitioners). (Here’s a piece of cultural trivia: Did you know the latest bachelor on the reality TV show “The Bachelor” is a business analyst?)
Portfolio managers should get to know business analysts in their organization, because they can help ensure alignment and management of the portfolio to achieve the organization’s strategic goals and objectives.
What exactly do business analysts do? They, well, conduct business analysis. That’s defined as:
•identifying business needs
•eliciting, documenting and managing requirements
•recommending relevant solutions
With this in mind, there are four major ways that portfolio managers can leverage a business analyst:
1) Develop Pipeline Opportunities
Business analysts can play a critical role in analyzing business problems and opportunities that will eventually be used to initiate projects and programs in the portfolio. Product or technology roadmaps can outline potential projects or programs that will be initiated at future points. They’re also valuable during a project because they can support proposed changes to a project scope (which will affect the overall portfolio) and ensure that the business justification for the project or program remains valid.
Many business analysts are embedded within business areas and are critical to early identification and understanding of future opportunities or changes to the portfolio.
2) Define Needed Business Capabilities
We often think of business analysts as documenting business requirements. Those requirements are built upon an understanding of which capabilities are needed for a particular business domain.
Typically, capabilities are based on the goals and needs of a particular business area. Those needs may be depicted through business domain capability maps, end-to-end process flows or functional diagrams. An assessment of whether the capabilities currently exist or not becomes the basis for identifying priorities and gaps (in processes or talent). It can also be used to benchmark against other companies.
3) Develop Business Cases
With their high-level understanding of the goals, objectives and needs of the enterprise, business analysts can assist in defining the justification for the proposed solution. The basis of a business case is the needs assessment. This process seeks to understand the underlying business problem, assess the current state and perform a gap analysis against the future state.
In addition, the proposed solution (see #4 below) is needed for high-level cost estimates that become the basis for the numerator of the ROI. The potential return (denominator of the ROI) is also based on an analysis of the impact of the solution on the current process.
4) Perform Solutions Analysis
One type of solution analysis is to assess a variety of options to go from the current state to future state. (For example, process changes vs. system implementations.) Business analysts can work with business stakeholders to define immediate solutions (quick wins that may be process changes) or longer-term solutions (new products or systems).
Business analysis outputs provide the context to requirements analysis and solution identification for a given initiative or for long-term planning. Business analysis is often the starting point for initiating one or more projects or programs within a portfolio. The analysis is an ongoing activity within a portfolio as the business environment changes and more information becomes available, creating new competition and strategies.
How do you work with business analysts? Share your experiences and best practices in a comment below. Also, if you’re looking to learn more about how business analysts can support practitioners, check out this pmi.org webpage.
By Mario Trentim
According to Le Chatelier’s Principle, any change in the status quo prompts an opposing reaction in the responding system. Although Henry Louis Le Chatelier was a chemist, his principle applies to project management, right?
No project occurs in isolation: Each inevitably disturbs the environment because it stems from the organization’s structure, politics and strategic objectives. So, it’s no wonder that some projects can’t succeed despite a project manager’s best efforts.
To make things happen, you need a support coalition of powerful and/or influential stakeholders. But how can you get the necessary buy-in for a project?
Let me assure you: You will fail if you try to guess what is in your stakeholders’ heads. We all have a natural tendency to do that because, by nature, we feel uncomfortable with uncertainty and ambiguity. That explains why we are always trying to "fill the gaps."
What does this have to do with project management? Everything. Project managers must overcome two biases that pose obstacles to successful stakeholder management.
The first is that we see the project from our perspective, which leads us to narrowly identify stakeholders. Forgetting to include the project’s "hidden stakeholders" can be catastrophic.
The second, which I believe is bigger, is that we conduct stakeholder assessment and analysis with preconceived thoughts and distorted vision.
The secret to stakeholder management is obvious: You cannot catch fish using your favorite food as a bait. You have to use the fish’s favorite food!
When assessing stakeholders and strategizing how to engage them in your project, be sure to do your homework. When possible, ask your stakeholders directly about their expectations regarding the project.
This diagram offers an overview of potential stakeholder interview questions:
(Monteleone Consulting, 2010“Generic Questions for Interviewing Stakeholders”)
Of course, to a certain extent you need to be skeptical of the answers your questions elicit. My MBA students always ask me: How do you know if a stakeholder is telling the truth?
My answer is simple: you don't. You cannot tell for sure if a stakeholder is trying to manipulate the project (and you). But here’s a tip. Keep observing your stakeholders' behaviors and attitudes. Always put yourself in the stakeholders' shoes and discuss hypothetical scenarios with your core stakeholder management team.
Here is a worst-case scenario: I once had a sponsor who was against the project. I admit it took me some time to realize that he would do everything he could to make the project fail.
How did I discover the truth?
I’ll explain in my next post—don’t miss it. Until then, share your thoughts. What would you do in this situation?