Voices on Project Management

by Christian Bisson, PMP

Documentation—at least on IT projects—is one of those great project challenges. Documenting everything (and then keeping it updated) can be tedious, and requires a lot of time and discipline. But documenting nothing can leave people lost as a project evolves.

Like many things in life, balance is everything. Documentation doesn’t need to be a pain. It just needs to be relevant, easy to find and reliable.

Relevant

Documents can easily (and quickly) become obsolete, therefore it’s important to limit documentation to the information that can help the team save time and avoid errors. Stick to the most important elements, such as project scope, important links, FAQs, key decisions, approvals, etc.

Easy to Find

If information is scattered between emails, a server, a computer and a filing cabinet, chances are team members will skip looking for it and simply ask around (most likely starting with the project manager) to find what they’re looking for.

There are several software options out there today that are great for storing and organizing documentation, like Google Drive or Confluence (part of the Atlassian suite). Each allows you to consolidate documentation in one spot and provides access to simultaneous editing and commentating features.

Reliable

If you follow the first two tips, you should only have to maintain a limited amount of information in one easy-to-find location. This is essential because documentation that is not updated can have negative consequences on your project. It can mislead team members and accidentally force them into working off of outdated information.

Where do you store your important project documents? How do you ensure they are relevant and reliable? Share below!

by Wanda Curlee

I often write about neuroscience and its affects on project management. So I spend a lot of time scouring academic research, trade journals and even LinkedIn for new information on the topic. That’s how I came across this recent Business Insider article about what makes a good speaker.

Neuroscience is the very first thing mentioned in the piece, which makes the cognitive case for storytelling. It argues that understanding how our brains work can make us better speakers.

According to the article, you have about 15 seconds to grab your audience—and the average attention span is about 5 minutes. So how do you keep people engaged?

By using stories, says Princeton University researcher Uri Hasson. Mr. Hasson and his colleagues used fMRI machines to measure blood flow to regions of the brain of a speaker and the audience while a story was being told.

This research “found that the brains of a speaker and his or her listeners ‘exhibited joint, temporally coupled, response patterns.’ Simply put, the listeners' brains mirrored the speaker's brain—only when the speaker was telling the listeners a story.” The implication? Our brains are wired for story.

While I was in the Navy, stories were often used as a learning tool. And as a university professor, I’ve seen this approach work with students, as well. But what does this mean for people working in project management?

Relate and Resonate

Project professionals need to be storytellers. We may not all be on a large stage speaking to a big audience, but we’re always presenting, whether it be to stakeholders, sponsors, senior executives, etc. And think about the mundane information we often have to report.

An effective presenter is able to tell a story that will resonate with his or her audience and make mundane information more interesting.

Recently, I was a speaker for the Human Capital Institute (HCI). I used stories to make neuroscience resonate with the audience. I was delighted with the feedback I received. Each person that approached me remembered one of my stories that stuck with them and even resurfaced previous memories.

So when it’s your turn to talk to the C-suite, interject stories. You will be remembered by your ability to relay the information well—and that may serve you well when the next difficult assignment comes up.

What’s one of the best presentations you’ve ever heard? Did the speaker use stories to illustrate his or her presentation?

by Lynda Bourne

In my last post, I discussed one of the more effective approaches for understanding team interaction: the McKinsey 7-S framework. The basic premise of framework is that there are seven internal aspects of an organization that need to be aligned for a company to succeed:  

• Strategy: The agreed-upon approach to accomplishing the project’s objectives
• Structure: The way the project team is organized, including who reports to whom
• Systems: The tools, techniques, and processes used by the team to execute the strategy
• Shared Values: The core values of the team that are evidenced in its culture and general work ethic.
• Style: The behavior patterns of the team, how people interact, and their approaches to leadership and authority
• Staff: The makeup of the team — “having the right people on the bus,” as Jim Collins writes in his book Good to Great
• Skills: The existing skills and competencies of team members

Project managers can have the most impact on style and shared values. These elements are typically set at the beginning of a project and new team members tend to adapt based on what they see from their colleagues.

Changing these elements mid-project is difficult. If you start right, the tendency will be to perpetuate the good behaviors as the team grows.

However, if you need to spur a shift, I suggest taking these steps:

• Start with shared values. Are they consistent with your structure, strategy, and systems? If not, what needs to change and how can those changes be implemented?
• Examine the hard elements next. How well does each one support the others? Identify where changes need to be made. The project’s objectives don’t change but everything else can be adapted (including the strategic approach) to maximize the chance of a successful delivery.
• Finally, look at the soft elements. Do they support the desired shared values? Do they support the desired hard elements? Do they support one another? If not, what needs to change?

As you adjust and align the elements, you'll need to use an iterative approach. Make adjustments, then analyze how those changes have impacted other elements and their alignment. This may sound like hard work, but the end result of better performance will be worth it.

What are your tips for shifting your team’s style and shared?

by Lynda Bourne

I’ve always thought the McKinsey 7-S framework is one of the most effective approaches for understanding team interaction. Originally focused on large organizations, the concepts are equally valid for smaller groups, such as project teams. Let’s take a look.

Developed in the early 1990s by McKinsey & Co. consultants Thomas J. Peters and Robert H. Waterman, the basic premise of the McKinsey 7-S framework is that there are seven internal aspects of an organization that need to be aligned for a company to succeed.

These elements are considered either “hard” or “soft”. The hard elements are easier to define, and management can directly influence them. They are:

• Strategy: The agreed-upon approach to accomplishing the project’s objectives
• Structure: The way the project team is organized, including who reports to whom
• Systems: The tools, techniques, and processes used by the team to execute the strategy

The project’s strategy shapes the other hard elements, as the systems and structures used by the team need to support the implementation of the strategy — not work against it. The optimum structures and systems used in an agile project will be quite different, for example, than those used in a more traditional project.

The soft elements are more difficult to define, measure and document because they are influenced by personalities and company culture. They are:

• Style: The behavior patterns of the team, how people interact, and their approaches to leadership and authority
• Staff: The makeup of the team — “having the right people on the bus,” as Jim Collins writes in his book Good to Great
• Skills: The existing skills and competencies of team members

The soft elements are probably more important than the hard elements. When you have a team made up of the “right people” (staff) with the “right skills” working in the “right way” (style) to achieve a shared vision, deficiencies in strategy, structure and systems can be mitigated.

At the center of both the hard and soft elements are Shared Values — the core values of the team that are evidenced in its culture and general work ethic.

As shared values change, so will all the other elements. But when all seven elements are aligned they have enormous power to generate project success.

Have you used the McKinsey 7-S model or something similar on your projects? How can this type of approach help drive team performance improvements?

By Peter Tarhanidis

It is not unusual for project leaders to fill a variety of leadership roles over the course of the many unique initiatives we take on.

As I transition from one client, program, employer or team to another, my personal challenge is to quickly work out the best leadership role to play in my new environment. Therefore, I find it helpful to have some knowledge of leadership theory and research.

Leaders must understand the role they fill in relation to staff and management. That typically falls into three categories, as defined by Henry Mintzberg, Cleghorn Professor of Management Studies at the Desautels Faculty of Management of McGill University, Montreal, Quebec, Canada:

Interpersonal: A leader who is either organizing the firm or a department, or acting as an intermediary. He or she is the figurehead, leader or liaison.

Informational: A leader that gathers, communicates and shares information with internal and external stakeholders. He or she is the mentor, disseminator, and spokesman.

Decisional: A leader that governs and has to make decisions, manage conflict and negotiate accords. He or she is the entrepreneur, disturbance handler, resource allocator and negotiator.

During one of my recent transitions, I thought I was a decisional leader, but I was expected to play an informational role. When I acted on information rather than sharing it and gaining consensus toward a common goal, my team was very confused. That’s why it’s so important to know the role you’re expected to fill.

When you start a new effort, how do you determine what role you’re expected to play? How has that contributed to your success?