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.

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.

A Great Team

“My model for business is The Beatles. They were four guys who kept each other's kind of negative tendencies in check. They balanced each other and the total was greater than the sum of the parts. That's how I see business: great things in business are never done by one person, they're done by a team of people.”

- Steve Jobs

"Never doubt that a small group of thoughtful, committed people can change the world. Indeed, it is the only thing that ever has."

- Margaret Mead

This week I'm writing about a tremendous team that I am proud to have worked with. It was the Steering Committee for the PDSummit (Professional Development Summit) in Halifax, Nova Scotia.

The PDSummit was the grand finale of eight months of planning and preparation by a team of about ten people. Our team met every week (except Christmas) on the phone for half an hour to plan, come rain or shine.

Each meeting had an agenda put together by the Chair. The Chair also distributed minutes right after each meeting. Some members of this team had been together for a few years, and other members were brand new.

Why did this team work? I think a large part was the great leadership, including the roles being allocated and processes defined and followed. Another large part was the attitudes of the team members, which contributed to the collaborative culture.

I did some research on great teams (thanks Internet!) and here are some links about strong teams. I believe this team met all the criteria stated in the following articles:

• Characteristics of Effective Teams
• Top 10 Qualities to Build a Successful Work Team

Happiness is... being a Project Manager

There is a lot of research on happiness these days. One of the latest books to come out on the subject is by Shawn Achor - Before Happiness. Mr. Achor gives five strategies for being happy. I found these strategies to be similar to those required for being a successful project manager:

1. Use success accelerants - signals that tell your brain success is possible. I would liken this to collecting metrics in a project; with measurement, we have guidance on what to do to achieve success.
2. Set meaningful goals. What is a project if not a goal to be reached?
3. Eliminate as much as possible the negative emotions of fear, pessimism and doubt. This sounds like providing the vision and leadership that any project needs to be successful. When pessimism starts to abound, find ways to cut it short and turn it around.
4. Share your good feelings of happiness with others. Hopefully that would happen in any team environment. I have certainly been in environments where one person's happiness inspired and buoyed a whole group (and cases where the opposite was true, as well).
5. Focus on the positives rather than the negatives. I don’t think I have seen any successful team where there was a focus on the negative!

So, a happy person can be likened to a successful project team. How does your team line up?

Is it Really a Project?

I asked a colleague the other day how everything was going with his project. He told me that what he was working on was supposed to be a project, but really it was operations.

The word was that the company had described the work as a project to win the contract. However, the work wasn't seen as a project.

Was it a project or not?

First, I would say that if the team member did not think he was working on a project, he was not. No matter if there was a project name that he put on his time sheet each week.

How could it have seemed to be a project?

My guess is that the Project Manager and executive saw it as a project. There was an account code assigned and surely there were reports to the customer on the deliverables. And, hopefully, there was an end result in mind.

However, if the project team members did not see any sign of this being a project, it surely wasn't to them. (If a tree falls in the woods and no one hears it...)

If there were regular team meetings with outcomes the team was working toward - that would be seen as a project. Even if there weren't team meetings, but regular communication from the Project Manager, possibly outlining the overall status of the project, there could be some semblance of a project.

What was the missing key?

I would say communication from and to the Project Manager.

So, I guess my colleague was right - this was operations cleverly disguised as a project.

Positive Questions

Have you ever used affirmations? Have they given you results? I have read lots on the power of affirmations but must admit I have never really used them.

However, when I saw “The Book of Afformations” by Noah St. John, I was intrigued. Mr. St. John came upon a realization that our subconscious mind acts upon questions. If we pose questions to ourselves, things happen.

I was happy to test out this theory. For the past few weeks, I have reframed my thinking to be in the form of positive questions. I think, along the guidelines provided by Mr. St. John, “Why do I provide such great service to my customers?” Interestingly enough, using this questioning technique has coincided with many opportunities to prove my customer service skills.

This questioning technique can be related to projects. For teambuilding, perhaps the project team could think this way: “Why do we get our work done so efficiently? Why do we provide such great value to our customers and company?” These questions are starting points. Your team will undoubtedly come up with excellent questions themselves. Then, it will be interesting to see what happens.

It doesn't cost anything to use the technique and I would encourage you do to so. Let me know your results!

Project Management Truisms Ring True

I went to a fascinating presentation on lessons learned from projects yesterday. The two presenters analyzed ten projects they had worked with and came up with twelve lessons learned. I listened intently.

Of great interest to me was that these were not project management professionals and did not even use the term 'project management' in their talk. What lessons did they come up with? Among them were:

1. Senior leadership needs to be committed to the process and open to the outcome.
2. Make sure the purpose and intention of your project are clear. If you are confused, everyone else will be too.
3. Go slow to go fast. Planning and implementing an effective and meaningful project takes time. Are you ready for this?

Do these findings sound familiar to you? The findings underlined for me that the theories of project management ring true. The personnel involved in these projects discovered these truths from their own experience.

So, I conclude that whether you think in project terms or not, having a sponsor you can rely on, having a clear vision and purpose for what you are doing, and planning are fundamental principles of success for any work.

Managing Your Multiple Projects - Get the Exec on Board

Project Managers know that executive support is crucial for successful projects. But did you know that senior management support and organizational culture are especially important for those project managers who manage multiple projects?

A study done on team culture in managing successful multiple projects found that organizational culture was more important, by far, than the culture created by the project managers and teams. This may seem a bit counter-intuitive. Wouldn't you think that it was the environment created within the project teams that made the most difference towards the success of the project?

Commitment, communication and rewards for performance were the signifiers of a strong organizational culture. In organizations with a strong culture, project team members felt committed to their projects, contributed strongly to project development, communicated with each other to transfer information and knowledge, and were recognized and appreciated for performance beyond expectation.

Senior managers are usually the ones who lead the development of organizational culture. To create this multiple-project-supporting culture, the study found that senior management established a group-oriented organizational culture. That is, they supported project teams and valued working in groups as opposed to individually. They “walked the talk” in leadership by setting in motion policies for team rewards, as opposed to individual ones, and supported group decision-making techniques.

Senior managers developed a collective sense of mission and good relationships with those who followed them.

Organizations that support teams in policy and action = strong success for multiple projects run by one project manager. If you are an executive, are there policies for rewarding group performance that you can introduce? If you are a project manager, how can you incorporate the strengths of the organization, for example, in relationship building or how teamwork is supported, to improve the success of your projects?

Thank you for the research done by:
Managing a Group of Multiple Projects: Examining the Influence of Team Culture and Leader Competencies, Peerasit Patanakul and Zvi H. Aronson, Stevens Institute of Technology - Wesley J. Howe School of Technology Management, January 23, 2013

Starting Something New?

In this day and age many businesses are working on incorporating online tools into their product portfolio. If you are, you might want to consider planning before you begin your exciting new project.

Here are four guidelines:

1. Begin with the end in mind. Stephen Covey’s maxim holds true for any project. Before you can start any venture or project, you must know what you want!
2. Gather a support team. It is hard to work by yourself. In fact, we cannot achieve many goals without the involvement of other people. Build in support for yourself and your project. Think about whose help you will need in achieving your aims, and get in touch with them. It might take a few conversations to get the ball rolling, but you will eventually find it much easier to achieve your project goals with the right team in place.
3. Identify everything you need to do to achieve your goal. You will want the help of your team to do this. Maybe you will have a brainstorming meeting where everyone feels welcome to shout out their ideas about the tasks required. Once you have identified what needs to be done, you can put the tasks in order and figure out how long each will take and who will do them.
4. Document! Don’t forget to put your plan in writing. This will make tracking and keeping control much easier. As well, any decisions about your project, such as what tools you will use or who does what, should be documented.