Voices on Project Management

By Conrado Morlan

Project management practitioners know the importance of communication during the project execution, hand-off and operations stages. For each of these, the communication plan should cover all the different forms of communication and the target stakeholders.

The frequency of communication during project execution often has a defined cadence and uses different artifacts to deliver the message to stakeholders, who usually are internal.

During the operations stage, the project is usually in production and practitioners are communicating directly with customers, either internal or external. While the specifics depend on the situation, communication with customers must be regular, concise and delivered in a timely manner through the proper channels.

How Not to Communicate
As you may know from my past posts, I have been running for several years and have often thought about connections to project management. One of my running goals for 2020 is to run the Popular Brooklyn Half, the largest half marathon in the United States.

As I did not meet the pre-registration requirements, the open registration was my only option. On registration day I was ready: My account was available, all my personal information was filled out, and I had my credit card on hand. At the designated time I visited the registration website to compete for a spot with thousands of runners from across the world.

I thought I would be directed to start the registration process, but instead, I was directed to an electronic queue page. After a few minutes, my expected waiting time was listed as 25 minutes. I got a little anxious thinking that the limited number of entries would sell out in less than that time. A few minutes later, the waiting time changed to 40 minutes, then to more than an hour; all of a sudden a message about “experiencing technical difficulties” was displayed.

In the meantime, upset runners from across the world took to social media to vent their frustration and dissatisfaction. But the organizers did not acknowledge the blast of posts until three hours after the designated registration time. That’s when they posted a message stating that they were trying to figure out the problem, and if they were not able to resolve it soon, a new registration date would be announced.

That message ignited the runners, who inundated social media with posts venting their resentment.

By this time, the organizer’s website was down, and the homepage showed the “experiencing technical difficulties” message. I stayed away from the postings on social media and kept refreshing the website persistently.

Finally, five hours after registration began, the website came alive and the new registration time was posted. I checked social media for postings from the organizer but found nothing. Right at the new posted time, I started my registration process while thousands of runners kept venting their frustration. This time it only took me 20 minutes to complete my registration for the Popular Brooklyn Half.

The Project Management Takeaway
As project management professionals, we can face similar situations in the course of a project and need to be prepared with mitigation plans. In the case described above, communication with customers was not regular and sufficient, perhaps because the project team was too focused on solving the problem. This affected the customer experience.

In general, production problems have a resolution time window, which may vary depending on the seriousness of the issue. This is usually unknown for customers, but that does not hinder the communication process. We as project management practitioners need to consider that we are living in times dominated by instant gratification; customers expect that issues will be resolved immediately. At the same time, they expect frequent progress status reports.

As a project management practitioner, have you experienced a similar situation? If so, what did you do to keep your stakeholders/customers informed? What channels of communications did you use? How effective were they? Share your experiences with the community.

By Lynda Bourne

Everyone is talking about innovation! But to innovate requires two things. The first is an innovative idea, and the second is a process to turn that idea into something valuable. In this post, I will look at what’s needed to create innovative ideas; my next post will look at one of the ways to transform the idea into something useful, even valuable, through design thinking.

The challenge of developing an innovative idea is part personal and part cultural.

The Personal Part of Innovation

Every innovation starts with an idea. So if you want ideas that may turn into useful innovations, you need to allow people time to develop the idea. This may occur in a number of ways:

• The idea may arise as a result of an unexpected outcome from something you are doing. Many of the major innovations, from penicillin to Post-it notes, started with something going wrong. What sparked the innovation was people taking the time to consider the situation and look for opportunities.
• The idea may come from a structured process deliberately set up to generate innovative ideas, such as a brainstorming session or hackathon. What sparks innovation is in part group dynamics and in part the challenge posed to the group. Careful planning and skillful facilitation are needed to get the best out of the group.
• The idea may come from quiet reflection over time. A powerful way to solve problems or exploit a possible opportunity is to have the question or challenge written on something you interact with from time to time, such as a white board or a note pad on your desk. Take the time to look at the question and then allow your subconscious to work on it. The problem with this approach is the ideas usually pop up into your conscious mind at highly inconvenient moments. Thought processing benefits from quiet time, ideally doing something that requires little or no conscious thought, such as walking. One of the problems in the modern, 24x7 world is most people are too busy being busy to have time to think reflectively. 

The Cultural Part of Innovation

If an organization wants its people to be innovative, it needs to create a culture that allows innovative thinking. There are many ways this can be encouraged, so getting the mix right is key. Some of the options include:

• Provide quiet spaces and quiet time to allow reflective thinking. If everyone is working hard, over extended hours, there’s no time for creative thinking. And when they stop working, they are too tired to think.
• Encourage innovative conversations. There are many opportunities that can be used, including various review meetings, quality circles and other, less formal interactions. The key is to encourage discussion around how things could be improved. Everyone looks at what went wrong, but innovative organizations also play to their strengths: “We did that well, but could we do it better?”
• Try occasionally doing something more dynamic, focused on a known opportunity or problem. Done properly, events such as hackathons not only generate ideas in the moment, they also empower ongoing conversations and reflective thinking.
• Allow people to be wrong. Every idea is a good idea; some may be useful.
• Have systems to collect the ideas and allow the people who originated them to be involved in moving the useful ideas forward if they choose.

Recognition and rewards can help, but they are far less useful than most managers think. The driver for innovative thought tends to be introspective, and when a person has a good idea, self-fulfilling. The real challenge is having an open culture that allows new ideas to come to the fore and be considered on their merits. Systems can help—the old “ideas box” needs to be brought into the 21^st century if you want an innovative culture. 

Last, having identified an innovative idea, the organization needs to do something with them! More on this next time.

Please share your experiences: How have you sparked innovation within your organization?

By Christian Bisson

Inspired by The 8 Stances of a Scrum Master (a great read if you haven’t done so already), I want to focus this article on a few of the “misunderstood” stances of the scrum master.

Recently, I asked colleagues to share what they think a scrum master does, and the answers revolved around organizing scrum events (secretary) or note taking (scribe). It’s even expected that they make sure the office has coffee (coffee clerk).

Although there is nothing wrong in helping the team with any of the above—especially when it’s a brand-new team figuring out everything from setting up their work station to getting to know each other—there is a line between helping and not fulfilling your potential as a scrum master. This is important for you as an individual, but also for the team in the long term (even if they don’t know it).

So how can we fix this?

Stop Doing It

As a scrum master, you have to factor in everything when making a decision about whether or not to do something for your team. So, if the team is used to you doing a task and all of a sudden you stop, this might have a negative impact.

On the other hand, it might be what they need to break bad habits. If you do stop doing it, the team will have no choice but to do it themselves. However, in this case, you should warn the team or give them a heads up that you will stop by the next sprint, for example.

Never Start Doing It

If you are new to the team, or the whole team is new, you might have the opportunity to simply never start doing a given task in the first place. Although it seems counterintuitive to “not help” the team, you’ll avoid creating any habit that will affect them in the long term—and will be challenging to break.

In this case, you should explain to the team that it’s everyone’s responsibility to handle these tasks and to build good habits from day one.

I personally did this with note taking a few years ago. It was challenging at first, but now I go to meetings without any apparent ways of taking notes, making it obvious that I won’t be doing it. (I do have my phone in case something important comes up that I need to note for myself, of course). Now in meetings, I’ve gone from the note taker to being able to focus on facilitating the meeting and help the team get the best out of the conversation.

In Conclusion

It’s quite challenging to avoid all the “misunderstood” stances of the scrum master, but we have to do our best to be true to the real value scrum masters can bring to teams.

What misunderstood stances have you fought against? How have you tried to combat them?

By Wanda Curlee

Some believe that project management needs a complete overhaul. Whether you agree or not, there’s no doubt that technology is driving radical change. As I have mentioned in different blogs and presentations, I believe that artificial intelligence (AI) and the Internet of Things (IoT) will have a large impact on the next generation of project managers. Thanks to this new tech, project managers will be adding more value, versus completing mundane tasks.

Technology will do the mundane for the project, program or portfolio manager. So, what will be left for the practitioner to do? For starters, the project manager will be able to focus on the many things put to the side because they’re doing their best to keep stakeholders informed and complete routine tasks, as well as trying to maintain their sanity.

Targeting the Mundane
So, what constitutes a mundane task? This includes creating schedules, communications, status reports and presentations, along with tracking down resources, reviewing issues, assessing problems and reviewing risks, among other jobs. These things need to be done and many times, the project manager needs help doing them. But leadership may not understand the need for this assistance, or the resources may not be available.

The good news is, AI and IoT will take on these mundane tasks. Technologies will be able to review a schedule and track down those who haven’t inputted their time. The schedule options, along with recommendations, will be provided to the project manager.

And that’s not all: Tech can also assist with drafting presentations and status reports. The project manager can then add the final touches. Potential risks can be assessed and the probability and cost to the project can be determined.

Impact on the Project Manager
What does this leave the project manager to do? Plenty, of course. They need to determine what resources are needed and negotiate with functional managers, human resources and the project management office if one exists. Human resources are one of the biggest headaches for a project manager.

They’ll also have to deal with problem resources already on the project. This may mean less qualified individuals who aren’t able to do the work (through no fault of their own), those who are unhappy on the project and are projecting the feeling throughout the project, and those who are lazy, among other things. The project manager may need to counsel these individuals or may even have to fire them, which, of course, creates risk for the project.

In addition, the project manager may have to deal with subcontractors and vendors. More attention can be paid to higher-level risks and preventing or minimizing their occurrence.

Integration management is also an area of focus. There are project managers who put this aside because they feel if the schedule is all right, the project integration is handled. This is not true. There may be individuals who are not sharing their information promptly, or those who are producing a major milestone but have a family emergency. Without them, no one else can finish a milestone that’s critical to the remainder of the project.

Predicting the future is hard. Time will tell how technology will be used in project, program and portfolio management. Technology should not be considered a silver bullet, but a means to provide help with everyday tasks, allowing leaders to devote time to value-added work.

What do you think: How will future technology change the way we manage projects?

Years ago, when I first heard of agile making waves, I was curious enough to pay for a class out of my own pocket to learn more. 

By the end of the two-day session, I knew I wanted to be associated with agile. It wasn’t just its merits that convinced me—it was the basic philosophy of trusting another being, of being open to communication and most of all, respecting another’s opinion. It seemed humane.

In the mad rush of work, all of the above are often sidelined. There’s no time for niceties, no time to respect another opinion; there’s only the ambition to prove another wrong. 

It’s miserable. 

Agile teaches us to be open, trustworthy and make mistakes. Failure isn’t the end of the road; risk-taking and experimentation are supported and bonhomie is encouraged. 

My Experiments With Agile

As I started working as an agile coach, I brought in the humane side of work. I helped my teams to stop finger-pointing and instead, really talk during standups. I tried to liven up the mood by asking team members about the last book they read or movie they watched, and I learned the name of the scrum master’s kid. This helped the team get to know each other as humans. 

I planned games and drew on whiteboards so team members could match the hobby with the individual who practiced it. It was hilarious. Interest grew, not in agile but in knowing each other and building better relationships with team members. 

We celebrated birthdays, we talked about failure, trust and anything that would bring out even the introverts and encourage them to join discussions. Everyone’s opinion mattered. The right complexity point during estimations didn’t matter, as long as everyone was talking and participating. 

And our work wasn’t virtual anymore. I would move a story card to completion, draw to celebrate the completion of a goal and use the white board to keep the team motivated with quotes, scribbles and doodles. It got everyone involved. 

Managers soon joined the sessions, sometimes just listening when they were uncomfortable. It allowed team members to be vocal and to think for themselves. Everyone was involved—not because that’s how it should be done, but because it takes time to build that vibe and tribe. 

Why Agile Works

Agile isn’t for measuring KPIs or bringing in ROI. But those results happen, because the team comes together and enjoys working with each other. 

Agile has been written about over and over again, from why it works to why it’s a failing fad. People rarely see the fact that agile has made many organizations humane again. The best way to understand agile is to think about working in a secure, comfortable environment with people you trust. 

In 2013, Rosabeth Moss Kanter published an article in the Harvard Business Review about how the happiest people seek out the most complex problems. It just makes sense to keep individuals and the team happy at work. 

It can be intimidating to turn around a team struggling with bad quality, low productivity and minimum engagement. But the best fix has always been to get team members to feel engaged, and that their views are heard and their opinion respected. It’s always about people. Once you get that right, the rest is easier. 

I have always had a positive experience with agile. When everybody comes together and believes in it, I have seen change happen. However, the most rewarding experience for me has always been that associates in an organization become humane again. They care about their colleagues, they speak face to face and they handle difficult discussions better. 

What about you? If your organization has embraced agile, what results have you seen?