Part of our mission includes inspiring the ability in people.  As such, an important component in doing this is to transfer knowledge. 

Whenever we are implementing a project, we gain information about the resulting product (or solution). Transferring this knowledge to the client and whomever is supporting the product is paramount to ongoing success. Without this knowledge, additional expense in the form of money, time or lost opportunities are incurred.

Therefore, in line with our mission, we offer this portion of our website to transfer general knowledge about projects and project management. Happy reading and learning!

Merlin Project has many useful features. One of these is publishing. This is the ability to publish files automatically or on demand in a particular file format such as calendar, HTML, image (e.g, PDF, JPG, etc), mind map, MS Project, and more. 

Publishing files to HTML is a great way to share specific project views (read only) with colleagues or clients who might not have Merlin Project. This will work with PC, Mac, or other OS users as long as they have a browser. You could publish to an FTP server if you have one or save it to dropbox or a file share on your local network for colleagues.

HTML publishing is just one example that we've illustrated, but it will show you the basics of publishing which you can explore to find other publishing options. One way we use publishing is to have an automatic backup to an XML file in case we need to transfer the main data to another program, such as back to Merlin 2 as we did when we were testing Merlin Project. 

If you've used Merlin 2, be sure to check out the expanded publishing capabilities in Merlin Project including more file formats, methods, views and autosave options. 

This "how to" documentation is available on our Downloads page or by simply following this link to How to Publish HTML in Merlin Project.

This post is part of the Clarifying Project Team Roles series of posts. In these, we'll look at project role definition in detail.

In part 1, we looked at why team member roles should be clarified; here we explore when.

Part 2: When should project team roles be defined?

The most obvious answer is at the start of the project, however that's not always possible, nor is it the only option. Projects often start before the PM is involved. Odd as this may seem, it is often reality in managing resources and specifically when dealing with contracted PMs.

Since we can't always define roles at the start, a better answer to the "when" question is "to define roles whenever there is a change to the project team." Take a moment to digest that statement. "Define roles whenever there is a change to the project team."

Roles should be reviewed when a team member is added to the project. Same for when a team member leaves the project, whether during the project or as the team shrinks towards project closure.  

If a PM joins the team after the initiation phase, then roles should be reviewed with the team. (This is also a great way for the PM to understand the team dynamics and the work of the project.)

The start of the project is also a change to the project team. Even though that may be the best time to review roles, many of the team members are yet to be engaged with the project.

Use this rule as the best practice for when to define project team roles. Any change to the project team will impact the team members' roles thus making it necessary to review and clarify them.

As a PM, define roles as soon as possible when starting an engagement. It takes time to gather information about roles, people and project specifics before this can be completed. Proactively planning role clarification for known or anticipated team changes is also a best practice.

There is one more "when" relating to defining roles. That is when the team isn't following the currently defined roles. If this occurs, review the roles as defined with the team and consider modifying them if necessary. Keep this in mind as it may help offset additional problems later in the project.

About the Series

This series focuses on defining roles on a project or project team and the importance of doing so.  Search for Clarifying Project Team Roles to see the related posts for more information role definition. You may comment on this article on our blog - Projects in a Simple Way

This post is the first of the Clarifying Project Team Roles series of posts. In these, we'll look at project role definition in detail.

Part 1: Why clarify project team member roles?

Everyone involved with a project plays one of two roles. They either contribute to the success of the project or they don't. Some people play both roles at different times and very few, if any, play both roles at the same time.

That is a bit of an oversimplification and is likely not helpful to actually defining team member roles on your project. That being the case, we'll look at role definition in a more practical manner through the posts in this series of articles.

Why define project team member roles?

The project manager’s goal with respect to peoples' roles is to make sure they contribute to the success of the project. This can be achieved in many ways and one of the best ways is to make sure everyone involved knows what they are supposed to do and where to go if they have questions.

When roles are left undefined, it opens the door for people to, well, be people and cause all sorts of turmoil. Some will be superheroes going above and beyond to deliver the project and make it a success and others will be "doormats" in term of the project, working on other unrelated activities but still likely appearing busy.

Defining roles creates accountability. Accountability brings either results or identifies issues that can be addressed. All this leads to being able to manage a project and determine if it's on track or off.

About the Series

This series focuses on defining roles on a project or project team and the importance of doing so. Search for Clarifying Project Team Roles to see the related posts for more information role definition. You may comment on this article on our blog - Projects in a Simple Way

Communication is one of the most important aspects of project management, if not the most important. However, the discussion of communication's importance is for another day. Today's topic deals with communicating who is doing what and one of the tools Project Managers have at their disposal, the RACI Chart.

Lets start with a brief explanation - RACI stands for Responsible, Accountable, Consulted, Informed. These are the 4 different roles people take on a project. Creating a matrix of team members and stakeholders along with their role - R or A or C or I - helps clarify who is doing what on a project or in a specific area of a project such as a work package.

RACI charts define the responsibilities and accountabilities for project work.

A person is Responsible if they are assigned tasks to do. Then they have specific responsibility to complete those tasks to the required specifications.

Sample RACI chart
RACI Chart Example

Accountable means that when things don't go right, this person is the one who has to answer for work not being completed as expected, within cost or on-time. To truly be accountable, they should be the one worrying if they will be demoted or fired when something goes wrong. As a general rule of thumb, only 1 person should be identified as Accountable.

A person with a C designation is Consulted for a particular area. That means they are given the opportunity to provide input on how things should be accomplished or what should be done. This person isn't responsible to complete the work and won't have their job or position at risk if things don't go correctly.

The last part of RACI is the I. This is the person who is Informed of status, activities, risks, problems, successes, etc. They are to be kept in the loop of what is going on in a particular area, therefore falling in the area of Informed. Communication flows to them, not from them for the particular area.

The RACI chart can be done at various levels of detail on a project. Starting with work packages from a work breakdown structure (WBS) works well for many projects. At times, going into more detail or less detail may be appropriate for a given project or team. The project manager or a PMO can help guide what the right level is for a particular project.

Complex projects, projects with large teams, or teams with members who don't value project management provide excellent opportunities to use a RACI chart.

A spreadsheet can be used to create a simple RACI Chart. Here is a link to a sample RACI-Template.

Do you use RACI charts? We've posted this topic on our blog Projects in a Simple Way - share your comments with us there.

Communication channels are the number of person to person ways a team can communicate. The formula to calculate the number of communications channels is:

(n*(n-1))/2 where n is the number of people on the team.

Communications Channels
Communication Channels Formula

For example, a three person team has three channels (A - B, A - C, and B - C). Adding a fourth person increases the communications channels to six.

Sometimes its hard to grasp the concept of how much more difficult communications becomes as more people get involved. We all know it happens, but just how difficult can things become?

One of the masterful equations that experienced project managers know is the communications channels equation. It goes like this, for each person added to a project team, the number of ways communications can flow between team members grows in an exponential fashion.

To figure the quantity of links between team members, we use the formula (n*(n-1))/2 where n represents the number of people on the team.

The graph shows how simply adding a 10th person to a team increases the communications channels from 36 to 45. That's 9 additional communications channels by adding the 10th person.

In fact, by adding the 50th person to a team adds 49 additional communications channels for a whopping total of 1,225 ways the communications can flow between team members on a team.

The Formula

The number of communications channels on a project team is determined by the following equation:

(n*(n-1))/2 where n is the number of people on the team.