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.
When I started as a project manager, the focus of my attention was on the mechanics of project management. This involved becoming very involved in work plans, risk/issue trackers, status reports, progress metrics and all those artifacts that form the means by which one manages a project.
What I realized after a number of years (as well as after a few hard learning experiences) was that while the mechanics of project management are important, they are merely enablers for the core activities that truly create a successful project.
I needed to think more about the successful direct and indirect business outcomes that could be created from a project. The attainment of successful business outcomes was what my stakeholders were really looking for, not necessarily the most impressive work plan or status report. This shift in focus become one of the turning points in my project management career.
So how does a project manager, in particular one early in his or her career, make the transition from executing the linear mechanics of project management to producing desired business outcomes? Well, they need to acquire the skills and behaviors that enable business success from projects— hopefully without harmful learning experiences along the way.
Here are four tips for making this transition.
1. Don’t Be Afraid of Business Processes
When I was a relatively new project manager, I spent a lot of time at my desk. This desk time was occupied with working on project management artifacts that if created perfectly would, in my mind, automatically lead to a successful project.
A senior project manager noticed this and encouraged me to spend a fixed amount of time creating project management artifacts, with the remainder of my workweek interacting with stakeholders in the business areas. In fact, this senior project manager arranged for me to work for a few days with some of the employees that were actually executing the business processes that were to be impacted by my project. Those few days of immersion were a great learning experience that it completely changed my outlook on how to run the project.
Today, I still employ the same technique for both myself as well as fellow project managers and team members. Whether it’s working in a retail outlet helping to stock shelves, processing billing exceptions in a call center or spending time in an airliner simulator, the immersion experience is essential to understanding what makes for successful business outcomes from projects.
2. Define Business Success Criteria
Very early in my career, I took what my stakeholders initially shared with me as business success criteria without any subsequent qualification. No surprise that some of the success criteria entailed—“just make it easy to use,” “finish testing by the end of the year” or “do whatever the senior vice president says”—didn’t really indicate a clear path to business success.
As I grew as a project manager, I began to spend more time in the beginning of projects articulating in detail with stakeholders clear criteria for business success. This involved not only understanding current processes by immersion, but also challenging stakeholders on the methods we would use to objectively measure business success. If something cannot be objectively measured, it would be difficult to determine the success of the project.
I also allocated time in the project to build and execute the processes to measure success. By doing so, I had the capacity to create evidence of how the project benefited the business.
3. Understand Your Industry
In my first few years as a project manager at an insurance company, I took every course on project management I could find (this pre-dated the creation of PMP certification). While I became adept at the mechanics of project management, I had no real foundation of business knowledge for the projects I was leading.
On a recommendation of a senior project manager, I took a course on the principles of the insurance business. This course covered the terminology, core business processes and emerging industry trends. I left the course wondering how all of this was going to apply to running projects.
Within two weeks of taking this course, my supervisor passed along a compliment from my stakeholders how much more effective and efficient I was in running their project. This newfound productivity came from the ability to more easily understand the challenges that the project was intended to address. Little did I know that the industry training was a form of business process immersion.
4. Get Comfortable With ‘Design Thinking’
The concept of “design thinking” originated with companies finding out that while project managers thought they were achieving the desired delivery success criteria of being on time and budget, they were not really producing the desired level of business success from projects. These companies began to explore ways of changing the approach in determining business success for a project.
Design thinking gives project managers several approaches to fully qualify the path to business success by techniques such as charting a customer journey, business process brainstorming, business case creation and creative reframing.
All of this opened my mind to going beyond the traditional boundaries of a project to ensure I was going to both define and execute to true business success.
I sometimes long for the days when I ran smaller, simpler and shorter projects whose goal was typically to finish on time and budget. I could afford to relax a bit and strive to achieve a high professional standard in the mechanics of running a project.
But as our projects become larger, more complex and longer in duration, we as project managers have to delegate some of these activities to other people, so we can get on with the business at hand of producing successful business results from projects.
These four things helped me make the transition to achieving business results on projects. What are some of the things that allow you to do the same?
By Marian Haus, PMP
There are dozens of studies about project failure. (To name just three: Standish Group’s Chaos reports, PMI’s 2013 Pulse of the Profession®: The High Cost of Low Performance and Gartner’s 2012 survey on why projects fail). There are at least as many reasons why projects fail.
Although in some cases forces external to a project can imperil its success, I am convinced that properly managing internal factors, particularly scope, is a key enabler for project success. This is because internal factors can be controlled, while external factors can merely be influenced.
Let’s take some classic reasons projects fail and tackle their root causes from a project scope management perspective.
Vague or unclear requirements and no change control—aka the never-ending scope. These are typical problems related to poor project scope management. The remedy is straightforward. Complete and clear requirements should make it to the scope; anything else poses a risk. In addition, at least a basic change management process is required to keep scope creep under control.
Lack of clear roles and responsibilities (R&R). You tailor your project team around the scope work that needs to be carried out. Because of this, you have to be clear about what your project needs to deliver. This includes product specifications, product design, implementation, integration with other related product parts, validation, delivery, etc.
If the lack of R&R clarity lies within your client organization or with an organization external to your project, then break down your project scope into specific deliverables and lay out the assumption and prerequisites for delivering them. For example, a product specification will have to be reviewed and signed off by the client, the client is expected to provide you with the validation benchmarks, etc.
A lack of R&R often results in lack of ownership and accountability of deliverables.
Underestimated timelines. This can happen especially if estimations are done based on insufficient information or when the scope is not well understood. Estimates are consequently rough, based on previous experience, approximations and assumptions. If conditions are changing during the project lifecycle, this can lead to time or budget overruns.
Unclear and/or unrealistic expectations. This is often related to the project scope. Your project team might be unclear about what it is supposed to deliver or what level of quality and maturity your deliverable will have to pass to meet the acceptance criteria. In other cases, the team might be unclear on how the delivery of your project scope will impact the receiving organization.
Project complexity. This relates mainly to the failure to break down a large scope into more manageable pieces and deliverables. If the list of deliverables is not clear, the sequence in which these are to be produced will not be determined. If the deliverables’ relation to each other isn’t clear, then team members will just be busy delivering something, sometime, for some level of effort. This leads to missing the project goal or ending up with time or budget overruns.
A well-understood and executed scope brings you a huge step closer to finishing your project successfully.
What is your experience with managing project scopes? What key factors, other than scope, do you see as enablers for project success?