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.
Have you been in situations where it seems that only shouting generates results? Or has your team been pressured to complete tasks that don’t appear to benefit your project? Maybe as the project manager, you have been in the middle of confusion and agitation that seem to undermine your project management abilities.
Could it be that many of the scenarios you encounter have their roots in conflicting stakeholder requests and misunderstandings? Well, it’s possible to avoid these types of predicaments. Consider utilizing the following three tools that allow you to have better control of your project and your project team:
1) Communications Plan. Outline a plan with names, contact information, and details on when and what messages need to be delivered to and from you. This tool allows you to know the frequency of message exchanges and the media required for specific contacts.
It also lets you know what level of detail the message should have, i.e., if it is going to a senior manager vs. a member of the supporting team.
2) Stakeholder Analysis. Prepare an analysis of your stakeholders to understand what their roles are and what area of your project is impacted by their involvement. This tool can help you with the department that has the biggest impact all the way down to the departments that have even a small effect.
Additionally, this tool can show how those who are directly or indirectly connected to your project may have an influence that can be detrimental.
3) Project Plan. Develop a plan with the focus on your project objectives and what the project will entail. Organize the plan for what needs to be done and when. The tool should show ownership and timings that you can share with stakeholders to also make them aware of the potential influence of their requests.
Sometimes, we get can get distracted when trying so hard to make sure our projects meet every need. There are many voices, conflicts, risks and events that affect the success of our project. Leaning on these tools may make your stakeholder management process smoother.
By Wanda Curlee
Situation awareness is taught to many professionals, including pilots, firefighters, air traffic controllers and nuclear reactor personnel. This useful skill has been slow to cross over into the business world, however, though it is making strides.
Situation awareness is the ability to know what’s going on in a complex, dynamic environment. This skill is valuable in project management because a practitioner:
· Needs to evaluate multiple goals simultaneously
· Needs to determine the importance of tasks and goals, and not be distracted by the less important ones
· Needs to know that when team members are under stress, negative consequences may occur, resulting in poor outcomes
Let’s look at how situation awareness can affect projects, programs and portfolios.
I was once on a project that was implementing a new technology. The project manager did not know how to evaluate all the tasks that were happening at one time. Poor decisions were made because the practitioner wasn’t aware of which tasks and goals were important and which were distracting.
As the project continued and lessons learned began to be gathered, the project manager started to gain situational awareness and could share this knowledge with others.
At the program level, intra-dependencies and benefits realization are always on the mind of the program manager. He or she must understand the environment within the organization (such as the politics and the needs of strategic stakeholders) and the industry, as well as other external factors.
Knowing who has the power to do (or approve) different things can help you implement a successful program. The program sponsor can help you get the lay of the land. Thoroughly understanding a country’s laws as they relate to the program and knowing the specific standards for your program and industry are part of developing a better situational awareness.
Again, lessons learned and asking questions of subject matter experts can help. As a program manager, you may have to review lessons learned from similar types of projects to give you an understanding of which tasks or goals are most critical, and which may be just a distraction.
Finally, a portfolio manager should help leadership and project/program managers improve their situation awareness. This means the portfolio manager needs to require a review of lessons learned on a quarterly basis and establish metrics (normally tracked monthly) to look for strategic trends.
Here are some questions portfolio managers can ask to improve the organization’s situational awareness:
· Is there a process or procedure hindering advancements of programs or projects?
· Is the tool set correct?
· Are certain projects or programs failing in some industries but blossoming in others?
· Will there be a gap in resources?
· Will there be a gap in resources with the correct skill set?
· Is it time to re-evaluate a technology or product where sales are dwindling?
Most people in project management have some awareness of their situation.
What sets great project leaders apart is they’ve honed their situational skill set.
In one of my previous posts, I suggested ways to maintain documentation. And as you know, documentation is very important -- it's the essence of knowledge transfer. The beauty of documentation is that it allows us to avoid the pains of reinventing a series of events that may only reside in a person's mind as a singular experience. It can also lead us to extract some aspect that may move our project from uncertainty and unknowns to more useful information.
So, once we have taken the precautions I mentioned in my previous post for generating clear and valid documentation, the question becomes: What project documentation should we always have and hold on to? I would suggest, at a minimum, the following:
The charter. It is the closest disclosure to everything the project should touch on. It includes a high-level look at the project: resource list, budget, timeline, assumptions, constraints, risks, other areas of impact and dependencies, a brief description and an immediate focus.
Budget background and expenditures. This information typically details the budget spending and directs you to possible future support, if any can be used again.
Sources. These include contacts and stakeholders; where information is stored; direct lines of contact; contacts who would be next in the succession; who and where to reach out to in case of additional needs; and where information stemmed from, and how it should be categorized and even prioritized.
A status report of risks and issues in their most recent form. These items show the progress that has or has not been made and is especially helpful in communicating to a new project manager (or yourself, if returning to a project) where to pick up. This status report can even help determine the project's resource needs.
Scope. This tells you what should have been the focus of the project. It also helps determine whether there needed to be an extension to this scope or if something different should be embarked upon, such as a total new project or maybe a revamping of the current scope.
Are there any types of documentation you find significant to have during a project and to hold on to after a project closes?
|To keep project activities moving, I've been testing a strategy of having action generate action through status reporting. Here's what I've noticed that works:|
As it stands, the current status of a project or task either gives a call to action, which creates further productive activity, or it leaves things as they are.
For example, a task status might say, "Completed the requirements document." While it's a valid update on the task, it only tells us something that is already in the past. Rewording your updates to generate a vision of current action is more helpful.
Consider if the status update said, "Reviewing the completed requirements document with the business owner." By including the present tense, the status presents the same information, but it adds an action-oriented, current, activity-based standing.
As a result of using present tense, I've noticed that the action of simply reporting on status has generated further action. It actually put me directly into the doing part of action, rather than talking about the action.
Let's say I receive a status update that says, "Kim is getting the screenshots of the system alert message," or, "John is reviewing the requirements document with the business owner." From this, I would know to follow up with Kim on whether she got the screenshot and set a reminder to connect with John and find out how the review went.
Review one of the status updates you've recently done yourself, or one that you received. Did it use the present or past tense? If the latter, what better results do you see possible by using the present tense?