The Emperor's New Clothes

My friend Amy was telling me about a project she was on. Being new to the industry, she had asked her project manager (PM) for more information on a term. The PM blustered through an explanation. My friend left the conversation, still not understanding.

The next day, Amy decided she would go back to the PM and ask some more questions. Amy told the PM she just didn’t get what the term meant. With that, her PM admitted she didn’t really know either. They decided to look into it together.

When Amy told me about this situation, I thought of the story of The Emperor’s New Clothes. Sometimes we are afraid to admit we don’t know something because we are supposed to be the expert. (In the story, everyone can see the Emperor has no clothes but the only one who will say this is a young child.) However, admitting to not knowing something is really a sign of strength. After all, who knows everything?

Probably even more importantly, the manager admitting her lack of knowledge built more trust with Amy. Only by admitting we don’t know can we grow, both personally and professionally.

Who Needs to Know?

Have you ever had someone say, "You don’t need to know that; leave that part to me," when working on a project?

After your first reaction ("Huh?"), if you are like me, you would be thinking, "Hmm, I asked because I needed to know."

What happened here? It seems as though clear roles and responsibilities have not been defined. One person thought it was their responsibility to do that part of the work and didn’t realize another person also needed to know.

What could have helped? A RACI chart would have been useful. RACI stands for responsible, accountable, consulted and informed. It would show who is:

• (R)esponsible for the work (to get the job done)
• (A)ccountable for the work (to report on it)
• Needs to be (C)onsulted on the work (their input gotten)
• Needs to be (I)nformed about the work (perhaps their part of the project depends on it)

Typically, a RACI chart is drawn with activities down the left-hand column, and roles or people’s names along the top row.

Here is an example of a RACI chart from raci.org:

It's a very handy tool indeed to prevent some conflicts from occurring.

Why Record Lessons Learned?

In projects, it is a good practice to document 'lessons learned'. These are things we have discovered to do - or not do - to make our projects stronger. For example, we may have learned to order supplies earlier, to have team meetings in the mornings, or to print reports to give to the sponsor.

According to the PMBOK (Project Management Body of Knowledge), lessons learned are: "The knowledge gained during a project which shows how project events were addressed or should be addressed in the future with the purpose of improving future performance."

Documenting lessons learned benefits our current project, and ours and other's future projects.

Lessons learned are often gathered by teams in end-of-phase or project closing meetings. Like any facilitated meeting, it is useful to have a meeting leader and someone who records the discussion for these meetings.

Another way to gather these lessons is through a shared document, for example, a Google document. Using such a document allows team members to input the lessons learned as they occur. I can say this is one lesson I have learned: to not leave documentation to the end of the week or the month, but to record things as closely to their occurrence as possible.

It’s not just the fact of having the lessons learned for later use that makes them so important; it’s not even just the getting together of the team to record them, or the ability of team members to provide input to project processes. It is the positive outlook generated in the team by knowing the project is continuously looking for improvements - looking 'on the bright side', you might say.

After all, projects are for learning.

Projects: Helping Others Become Successful

I just read an article by Ross Simmonds on creating blogs. Most of it was about technical aspects of blogging - distribution and the like. But the last point struck me. It was general good advice for anyone at any time, and especially for project teams. He said:

"I’ve noticed something in the last few years that I wish I knew when I was 19:
It’s easier to become successful when you’re committed to helping others be successful.
When you make a commitment to helping the people around you achieve their dreams, the people around you tend to help you back."

I believe humanity is getting better and better at helping others become successful. The marches worldwide show how people from all over the word are attempting to help others achieve their dreams.

Nurses, healers and teachers often show a commitment to helping others. Project managers do, too, after all, that's what we do: help our customers achieve their goals (dreams) - big or small. We help our customers figure out what they really want when we clarify their requirements - defining the dream. While we are ensuring the project stays on track, we are helping customers in goal realization. Incorporating changes along the way is important, too - the refinements in the dream need to be made as the picture becomes more clear.

So, congratulations to project managers and those working on projects for making dreams come true!

In "the Biz"

Recently, I fell into a new project – getting a TV series produced. It's amazing how much project management is involved in the entertainment industry.

When I was in St. John's last month, my friend Anne Marie told me that the romantic comedy series she had submitted to a producer could use a boost to get going. People who saw the write-up liked it, but things weren't happening. Hmm, I thought, we have the wherewithal to get this on the go. So, that's how our project together started.

First, we talked with a friend who was in "the biz" here in Halifax. He generously gave us an indepth view on the process for getting a series started and what type of key players would be needed.

Seemed to me this effort required a lot of project management - creating a workable plan, coordinating resources, and keeping stakeholders engaged, among other things. It became clearer and clearer to me that those project management principles will help us keep this project on track.

Wish us luck! If you have worked in the TV industry, and have some advice (or contacts!) to share, please drop me a line.

Contract Improvements

This week I had some contract issues to look at regarding an agreement with a supplier. Several areas concerning deliverables needed to be examined.

I called the supplier to get more insight on what had happened. They said they would investigate and get back to me.

Then I sought out my trusted advisors, who gave good recommendations. But something was still gnawing at me, so I called Bob, my older brother who has run a very successful business for many years.

Bob said, "Thank the supplier for their work - everyone needs more thanks." He went on to say there will always be challenges in business, and that’s when we improve. This advice resonated with me. Yes, take the high road and learn from the situation.

Doing so was definitely the best option for my business, in several ways. It would keep the business relationship (which is what a contract signifies), and would also keep me and my associates in a positive frame of mind. This last part, I believe, being the most important part of the lesson.

Who is a Successful Project Manager?

My manager at Motorola, Jim, was one of the most successful project managers I have known. His projects completed as planned, but he was successful because his team got the work done happily. He hired people to do a job and he let them do it. Now that I am teaching about project management, I take some of the knowledge that PMI (Project Management Institute) gives on project management and apply it to Jim’s approach.

As a successful project manager, Jim was:

1. Inclusive: He made everyone on the team feel like they were the project manager. Once responsibilities were accepted, Jim let you do your job. But he didn’t ignore you – we knew any time we needed to communicate with him the door was open.
This is related to the PMBOK (the Guide to the Project Management Body of Knowledge) in that roles and responsibilities were assigned, and everyone knew who was doing what on a task. We knew our RACI (chart for who is Responsible, Accountable, Consulted and Informed.)

2. A delegator: Jim told us to figure things out ourselves. He didn’t take on our jobs, and he had faith that we could do what we were lined up to do. When I asked Jim a question about a software model, he said, “Read the book, that’s what I did.” It might have sounded gruff, but I got the point. And I was also encouraged that he thought I could do what he did.
The PMBOK says, “Successful project managers have strong leadership skills.” Jim was a good leader and set an example.

3. A communicator: He provided structure to the team. Everyone knew what they were supposed to do. We met weekly. We were never “lost” about what to do or what was expected of us.
We had: the RACI, mentioned above; a schedule with milestones; a communications plan; and project ground rules – these weren’t necessarily named using PMI terminology, but followed the standard.

4. A leader: He gave direction in a clear manner.
We always knew where we were in the project schedule and what we had to do. The team was led by Jim and the work was managed, monitored and controlled to stay on track.

Jim died a number of years ago from ALS (Lou Gehrig’s disease). Right up to the end he maintained his attitude and approach, and continued to lead and be insightful.

If you are interested in learning more about project management, our needs assessment at PMneeds.com will help you determine which type of development would benefit you most. There are opportunities for learning about the fundamentals of project management, advanced project management applications, and PMP certification preparation.

Bravery and Vulnerability

At a business meeting I was in recently, a senior manager asked the facilitator if he should follow his instincts to make a decision, even if people didn’t agree with him.

I thought, "Isn't that brave?" He wasn't afraid to ask a question about his leadership style in front of colleagues.

A quality to be admired.

The Project Tribe

I listened to a fascinating interview of Sebastian Junger on CBC Radio the other week. Mr. Junger is an award-winning journalist and author. His most recent book - Tribe - talks about the war veterans who return home and experience PTSD. His findings are that it is the lack of closeness they feel when they get back, as compared to the friendship they felt while serving, that causes stress.

Junger claims the individualistic nature of modern society lacks the community we have evolved to need.

Applying this to working in projects, isn’t it the good feelings we have by working together that bring out some of the best experiences of project work?

I know, for me, achieving a goal as a team is much more powerful than achieving it on my own. I believe that is part of what Mr. Junger is getting at in his book.

All the best to you and your project "tribe"!

Click here for more information on Sebastian Junger and the CBC interview.

Project Management: How to Implement Trust

The basis for a good team is trust.

Team members who trust each other have positive expectations of each other. This is a great underpinning for resolving conflicts and discussing problems.

Simon Sinek talks about trust and leadership in his TED talk Why Good Leaders Make You Feel Safe.

So, how do we create a culture of trust? The basis is not that difficult: make the decision yourself to trust. Model and share this with your team. When making decisions yourself and with your team, reflect on whether those decisions agree with your value of trust.

So, as Simon says:

What I learned was that it's the environment, and if you get the environment right, every single one of us has the capacity to do these remarkable things, and more importantly, others have that capacity, too. 

You see, if the conditions are wrong, we are forced to expend our own time and energy to protect ourselves from each other, and that inherently weakens the organization. When we feel safe inside the organization, we will naturally combine our talents and our strengths and work tirelessly to face the dangers outside and seize the opportunities.