Voices on Project Management

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.

       By:  Rex M. Holmlin

This month’s theme at projectmanagement.com is “communication & collaboration.” I want to focus here on a crucial part of communication: confirming that we’ve understood the message someone has given us.

The PMBOK® Guide discusses what is called the “Basic Communications Model.” One aspect of this model, also known as the Shannon-Weaver Model, is the responsibility of the receiver to both decode a message and then confirm he or she has understood it.

Here’s a story to illustrate why that model matters.

A few years ago, I was in a project meeting about some stone we were going to purchase from a quarry in Egypt for flooring in an atrium. Stone is typically sourced by a stone broker. Stone brokers know the various quarries and work with everyone involved to select the correct stone from the quarry, get it turned into the proper size of tile and then get it to the project site.

As we wrapped up, I stood up and began to think about my next meeting. At this point, the stone broker came over to me. “You know,” he said, “stone is a natural material.” That’s not something anyone had ever mentioned to me before, but I acknowledged his statement. He seemed pleased, and I went to my next meeting.

A few weeks later, we received a call from Italy where the blocks of stone were being cut and turned into the flooring tiles. We learned that the tiles were crumbling into pieces when they went through the saws.

Fortunately, we had ordered the stone well before it needed to be installed, so there was time to source another block of stone, get it turned into tile and ship it to the project site. But later, as I reflected on this, I thought about the stone broker’s words. When he told me stone is a natural material, he was encoding a message that I’d failed to decode.

The message was that every piece of stone is different. This is one of the qualities that helps make stone beautiful and a key reason we want it in our homes and offices. Unlike steel or glass, stone might have veins of quartz or other imperfections that can cause the stone to crumble when cut.

Keep You Head in the Game

As I thought about it, I realized there were two things I did that contributed to an imperfect communications process. First, as I stood up, I “changed channels.” I was beginning to think about my next meeting. The lesson here is that if you’re in a meeting, be in that meeting. As a coach would say, “keep your head in the game.”

The second thing I did was fail to ask the stone broker to “Say more, please.” He likely would have told me a lot more about stone and the process of turning it into tile. The stone broker was not trying to conceal his meaning; he was being economical and selecting words that were meaningful to him.

This is something we all do. As the receiver of the message, I was the one responsible for confirming I had understood his message.

It may not always be the other party that causes a communication to fail. But it only takes a few seconds to ask someone to say more about the message they are trying to communicate. It also only takes a few seconds for us to confirm we’ve understood it. Sometimes taking the extra step to take these two actions can make a big difference in our projects.

By Linda Bourne

How important is happiness to team performance? We’ve all heard that a happy workplace is a productive one. And in fact, studies have demonstrated that a motivated, happy workplace is more productive and has better health outcomes than an unhappy one.

What is less clear is the relationship between happiness, motivation and productivity. Is a happy workplace an essential prerequisite to motivation, or is it a consequence of a motivated team enjoying their work and successes?

The relationship between happiness and motivation is not straightforward. Firefighters dealing with a dangerous wildfire are likely to be highly motivated, risking their lives to save the lives and properties of others. But they aren’t likely to be happy about the situation they are in. If their efforts are successful, there will probably be a very happy celebration. But the prospect of this celebration is unlikely to have any effect on their firefighting efforts.
 

The search for the role of happiness

So what is the role of happiness in team performance?

The elements associated with motivation are well-defined (for a discussion of the basic theories relating to motivation, read this article  (PDF)). But none of these theories includes happiness!

Unhappiness is a powerful de-motivator that has to be removed to allow the motivators to work, but does this flow through to the positive motivator side of the equation? Happiness may be a motivator, or it may be a collateral benefit of other positive motivators.

There are three possible scenarios:

1. The fact that a team is motivated tends to create a happy workplace.
2. Happiness and motivation are independent attributes but may be influenced by the same stimuli.
3. Happiness is a significant facilitator that helps create a motivated team.

My last post on this topic, looking at the Australian Cricket team (PDF), tends to support the proposition that unhappiness is a de-motivator. It argues for option 3, since the new coach brought fun back into the team. Certainly the new approach caused a major change in performance standards; the success identified in 2013 has largely continued through 2016.

What’s not so clear is if the fun factor contributed to the improved motivation and performance or if the successes of the team created happiness. There may even be a combination of both effects in a beneficial feedback loop.

To complicate matters, happiness itself is a difficult concept. Happiness can range from the wild euphoria of a team that’s just scored a winning goal to the contentment and inner peace sought by Buddhists.

Then there’s biology. The brain seems to be designed to keep our level of happiness relatively constant. So while a positive stimulus will generate a short burst of happiness for everyone, the increase in happiness starts from the person’s innate baseline and reverts back to that setting after a short period.

So what to do?

My recommendations for using happiness to help motivate your team are in two parts:

• First be aware of unhappiness. It’s a powerful de-motivator, and its causes need to be addressed. Everyone will experience unhappiness differently, so careful observation is needed to notice what’s occurring and then alleviate the issues.
• Seeking to create happiness is less important. If you focus on the other elements needed to create a motivated team—such as setting clear objectives, recognizing good performance, offering the ability to develop and providing a cooperative team environment—then happiness might emerge spontaneously.

How important do you think creating a happy workplace is in the overall quest to motivate your team? 

By Conrado Morlan

We’re all novices when we start out as project managers. That’s okay. The key is to learn from your missteps.

As a young project manager in Mexico, I used to struggle with resource planning. Like many other neophyte project managers, I wanted to make sure that all the tasks in my work breakdown structure would have the required resources assigned to them by name.

The challenge was that the resources were not my direct reports. I had no control over their schedules. 

My first approach at resolving this problem was to meet with the appropriate resource managers to review all the breakdown structure tasks and available resources, assign resources’ names, and reserve the resources for my project.

Sounds pretty straightforward, right? I would get the needed resources for my project, while helping managers keep their resources busy. Then I discovered I hadn’t considered all the other projects competing for the same resources. Not to mention all the project intra-dependencies.

I kept trying hard to build a perfect project plan (full of names attached to specific tasks) without success until I was assigned to a high-visibility project that was part of a strategic initiative. The initiative was led by an experienced project manager from the organization’s headquarters in the United States.

I didn’t want my struggles with resource planning to cause me to fail in such a high-visibility setting. So during my first meeting with the American project manager, I let him know about my struggle and asked for advice.

He was glad I brought my challenge to his attention, recalling that earlier in his career he faced the same challenge. His solution: the “Chinese army approach” to resource planning.

Because resource planning can pose such a huge roadblock to many project managers, the Chinese army approach assumes an abundance of resources.

Our conversation went like this:

American project manager: How many soldiers does the Chinese army have?

             Me: Millions.

American project manager: Right. The Chinese army has unlimited resources available to the commander in chief. Applying this approach, assume you have unlimited resources with the right skills that can be assigned to the different roles in your project. The resource planning stage is too early to be worrying about names.

Since then, I’ve followed the Chinese army approach, identifying the necessary resources for the early stages of the project—and their availability—during the project approval process.

On several occasions, I found that the roles could not be filled with internal resources because of a lack of required skills or because the resources with the right skills were in high demand. So I had to source from a contractor.

While working with resource managers and external sources, I found the need to acquire and master communication and negotiation skills. That helped me to get the best resources, while also sometimes allowing other projects to have the resource I was pursuing. All that truly mattered was that my projects were able to produce the expected results tied to organizational business goals.

What’s the most important thing about project management you now know that you didn’t know when you began your career?

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!