Skip to main content

Tag: Leadership

Writing Better Project Charters

Written by Simon Moore on . Posted in Articles.

betterprojectchartersA project charter is a critical document in that it authorizes the start of a project. Unfortunately it is sometimes viewed as a formality in the rush to get a project started. The costs of rushing the project charter will be felt later in the project with greater role ambiguity, slower decision making and lack of focus. The project charter serves as a reference throughout the life of a project and even in the subsequent post-mortem. The project charter is a formal deliverable that should not change, unless there is a significant change in the project itself, which, of course, should be detailed in the risks and mitigations section of the project charter. It is important because the project charter must be approved by the project sponsor, granting the required resources for the project.

Given that project charters are such important documents, here are some tips for writing better project charters, which will result in better project performance:

Clear Project Goals

“Management by objective works – if you know the objectives. Ninety percent of the time you don’t.” Peter Drucker

Charters typically start with the project name, but far more important is the project goal. What exactly is the project setting out to achieve, and what does success look like? Be crisp about this; the goal should be less than a paragraph, ideally a sentence, and ideally refer to key performance indicators later in the document. For example, “Upgrade our IT systems” is not a clear goal.

  • Who are the systems being upgraded for?
  • To what version?
  • When will this be finished
  • For how many users?
  • Is it merely upgrading, or does scope extend to training and usage?
  • Will the system be customized, based on user feedback or deployed without modification?
  • Will the project include any ongoing support?

A clearer goal is “Enable the 135 employees within PPMCo’s accounting and financial departments to perform SEC compliant project based accounting for the 2011 fiscal year, and train the 135 employees so they are able to maintain and support the new process themselves.”

Firstly, the goal doesn’t have absolutely all the answers, but it sets things up well for detail later in the document. You’ll also notice that the example goal above does not include the IT system itself, that’s intentional, just deploying the IT system will not meet the goal, the goal is to improve accounting within the organization, not simply to roll out a new piece of software. It has been determined that the IT system is the way to reach the goal, but not the goal itself. This is a critical distinction, and the project charter should make this distinction.

The Dialogue is as Important as the Charter that Results

A significant part of the value of a project charter results from the dialogue that should surround its creation. Ideally, the project charter is the summary of a round of critical discussions. Since the project has not begun when the charter is written, it gives a great opportunity to discuss potential trade-offs before the project starts. This is typically a much better time to have the discussion because the pressure is much reduced when there is no angry client, sub-contractor or supplier phoning, emailing or knocking on your door. By having these discussions in advance they are much easier and a number of problems can be avoided before they even occur.

For example, is it more important to finish a week earlier or save $20,000? Is user satisfaction more important than consistency with other systems within the organization? Is the director of finance to be held accountable or consulted for a particular task? Bear in mind that this is the document the project sponsor puts their signature on, so it carries a lot of weight and can be used to lay out the framework or decision structure for as many decisions as possible in advance.

This may feel like overkill and an unnecessary burden, but remember that the project manager will have much less time once the project is in flight, and the project sponsor might be on vacation or in a different time zone as key uncertainties arise. Taking time to be thorough in production of this document will pre-empt as many potential issues as possible. It will save a great deal of time once the project is in progress, because rather than kicking off a series of meetings to solve a problem, onc can simply refer to the project charter for many answers about scope, roles, trade-offs and so on. The project charter will also empower decision making by the project manager, because the needs of the project sponsor are set out in the document.

Define Roles

“Be candid with everyone.” Jack Welch

Any project charter should define roles, but there is an opportunity to be clear on what those roles really mean, rather than just citing job titles. There are many frameworks for doing this. I recommend using a PACE framework to define roles. PACE stands for the roles within the framework (Process driver, Accountable, Consulted, Execution):

Process Driver: The responsible party does or assigns the work for a particular task and makes decisions after consulting with the accountable party. The process driver has a close relationship with the accountable party, who can veto their decisions. The process driver assigns work to those in execution roles and engages with those in consulting roles.

Accountable: The accountable party signs off upon completion of the task. The accountable party will work closely with the process driver and is more powerful than the process driver in that they can veto their decisions.

Consulted: Participates in two way communication. This group participates in decisions related to the project, the process driver makes the decision, and they should not escalate problems to the accountable party. Note that being consulted does not necessarily mean you get to make the decision, but you do have the opportunity to have a dialogue with the process driver and influence the process.

Execution: Receives one way communication and may work on particular sub-tasks An informed party gets to receive communication about what is happening. The nature and frequency of the communication should be outlined. However, the informed parties do not have the right to force any kind of decision regarding the project. For project success, moving as many parties from the consulted to informed group as possible will help speed communications.

The PACE model can either apply to the entire project if tasks are consistent, but more often the PACE roles differ depending on the tasks in question. Of course, usage of the PACE model does entail some difficult discussions up front, but it is far better to have those discussions once before the project starts than to manage ongoing ambiguity in relationships and roles as the project progresses.

Identify a Mitigation Strategy for Each Risk

“Risk comes from not knowing what you’re doing.” Warren Buffett

Risk management should happen at every stage of the project, including the project charter. Whenever a risk is identified, a mitigation strategy should also be identified and this should happen as early as during the project charter. Merely identifying risks without any thought for mitigation, should it occur, has limited value. Once again, this is a valuable opportunity to empower the project manager to solve risks, rather than going back to the project sponsor, and it means risks can be resolved quicker. Of course, there is still the possibility that unexpected risks arise, but investing time in mitigating other risks will enable the project manager to better identify material, unexpected risks as they arise.

Share the Project Charter Broadly

Just as the project charter is a good opportunity to have a detailed dialogue with the project sponsor and others, it is also an opportunity to reinforce transparency within the organization and build awareness of the project that is about to launch. Rather than just pulling out the charter when a dispute arises, the project charter should be broadly shared at the inception of a project to inform people of the project’s existence. This will also save some time for the project manager, as the project charter should answer a number of questions that people might have about goals, roles and scope which they would otherwise ask of the project manager directly. Writing a great project charter entails significant time and effort on your part, so ensure that you get the full benefit by sharing the charter broadly.

Don’t forget to leave your comments below

Simon Moore is the author of Strategic Project Portfolio Management (Wiley, 2009) and the Strategic PPM blog. He holds an MBA, CFA and an undergraduate degree from Oxford University. He is a product planner for Microsoft determining international requirements for future Microsoft Business Division products including project management tools.

Is an Agile PMO Possible?

Written by Curt Finch on . Posted in Articles. 4 Comments on Is an Agile PMO Possible?

agilePMO1It often seems that a lean, agile development environment will always be at odds with the structure and constraints of the PMO. Rick Freedman described the situation well in a recent blog post:

“Many firms have committed so completely to PMBOK process flows and CMM best practices that many of the core concepts of agile development, such as “barely sufficient” documentation and change-friendliness, seem like heresy. In fact, I’ve had people in my Agile Project Management classes tell me that their perception of agile is that the key message is “everything you know about project management is wrong.”[i]

Yet it does not have to be this way. The agile PMO can bridge the gap between these two very important groups and help organizations to execute projects more successfully. While it does require a bit of change management, it is not as impossible as it seems and the benefits far outweigh the effort. First, let’s look at the skills and strengths that each team brings to the table.

The Benefits of Agile

Agile development has exploded in recent years for a number of reasons. For one thing, it encourages constant communication with customers throughout the development process, which helps to minimize scope creep. I recently spoke with an executive at a well known financial institution who believes that this is one of the key benefits of agile. It allows customer advocates to see what you are developing very early in the cycle, and you can then correct as needed before it’s too late. This also enables companies to adapt themselves to the needs of the market very quickly. In a 2008 article, The Agile PMO Role, Tamara Sulaiman asserted that “agile teams are cross-functional, self organizing and self managing.”[ii] With characteristics like these, it’s not difficult to see how agile development teams can be extremely effective.

The Benefits of the PMO

Likewise, the PMO brings significant advantages to the organization. Its primary focus is on metrics and progress tracking, which are crucial components of successful project execution. It can also help facilitate communication between developers, project managers and executives. Sulaiman puts it this way:

“Let’s say you are a manager or leader in an agile organization. Your development teams have implemented Scrum and are now working toward release. You’ve got the Scrum of Scrums working so that teams can communicate with each other about cross-team dependencies and impediments on a daily basis. But there’s a gap, isn’t there? As a manager, how do you effectively and efficiently measure progress, manage risk and keep your eye on the big picture across these agile teams? Wouldn’t it be great to have an easy way to communicate budget and schedule information at the program level to the organization?”[iii]

While the agile worker is concerned mainly with innovation and fast delivery, the PMO can help to keep the rest of the organization informed as to what is going on. Scope changes, delays or quality issues can arise at any time, and when they do, they must be communicated to all of the stakeholders so that they can revise timelines and adjust their expectations.

In addition, standard PMBOK methodologies (e.g. compliance management) are often more successful at managing corporate initiatives than other methods. The executive at a large grocery store chain once told me that in his company, it is necessary to meet deadlines and not allow any deviation from scope from a legal standpoint. While agile is all about discovery – discovery of what the customer really needs, as well as the discovery of what is possible – it does not always meet the needs of project-oriented organizations with specific requirements. If you have to meet a new HIPAA regulation right away, you don’t have much use for discovery. This is where the PMO can help the most.

The Value of Working Together

Combining the strengths of these two groups is a strategic move that will help organizations reach new heights of profitability they never thought possible. Project risk can be more effectively managed when the PMO is keeping an eye on things, and agile teams can achieve greater levels of transparency than before. In addition, the PMO can benefit from increased flexibility and dialogue with the customer, not to mention the fact that they will have more time to focus on their leadership role. A recent article entitled Agile Project Management makes the following point:

“Agile methodologies free the project manager from the drudgery of being a taskmaster, thereby enabling the project manager to focus on being a leader – someone who keeps the spotlight on the vision, who inspires the team, who promotes teamwork and collaboration, who champions the project and removes obstacles to progress.”[iv]

Steps Towards an Agile PMO

One of the best ways to get two different teams to work together is to highlight their similarities instead of their differences. Believe it or not, the agile team and the PMO do have things in common. For one, they are both interested in prioritizing projects to ensure that the organization is investing in the right ones. Even as the economy improves, this is something that organizations must continue to do; and both agile teams and project managers can work together to achieve it.

When it comes to a difference of opinion, compromise is necessary. Creating an agile PMO in your organization will take a bit of diplomacy and mediation. The executive I spoke to at the aforementioned financial institution warns, “Don’t be pure PMI or pure agile.” Rather, find ways to get each team to give a little ground. Agile developers might compromise by tracking their time to task in order to keep the PMO updated on their progress. At the same time, project managers can compromise by being flexible and willing to update plans and schedules as necessary. If the organization uses a project tracking solution, a work request module would be especially helpful by providing a mutual feedback loop.

Organizations can really benefit from the agile PMO if they are willing to put in a little effort to make it succeed. The right management processes such as open discussion and compromise will enable managers to capitalize on the strengths of each group, resulting in successful project execution and increased ROI.

Don’t forget to leave your comments below

Curt Finch is the CEO of Journyx (pr.journyx.com),a provider of Web-based software located in Austin, Texas, that tracks time and project accounting solutions to guide customers to per-person, per-project profitability. Journyx has thousands of customers worldwide and is the first and only company to establish Per Person/Per Project Profitability (P5), a proprietary process that enables customers to gather and analyse information to discover profit opportunities. In 1997, Curt created the world’s first Internet-based timesheet application – the foundation for the current Journyx product offering. Curt is an avid speaker and author, and recently published All Your Money Won’t Another Minute Buy: Valuing Time as a Business Resource. Curt authors a project management blog at www.project-management-blog.com, and you can follow him on Twitter at twitter.com/clf99.

[i] http://blogs.techrepublic.com.com/tech-manager/?p=2798
[ii] http://www.gantthead.com/articles/articlesPrint.cfm?ID=243988
[iii] http://www.gantthead.com/articles/articlesPrint.cfm?ID=243988
[iv] https://www.projecttimes.com/wp-content/uploads/attachments/AgileProjectManagement.pdf

Sometimes a Great Project; Eight Secrets of Top Project Managers

Written by Ann Latham on . Posted in Articles. 2 Comments on Sometimes a Great Project; Eight Secrets of Top Project Managers

The difference between decent project management and excellent project management can be measured in delays, cost overruns, lost customers, employee misery, and business jeopardy. A great example is the Dreamliner, Boeing’s latest aircraft that has received steady press for delays, cancelled orders, and the accompanying overruns and internal pain.

So what are the secrets of the top project managers? What do they do differently that makes their projects finish on time, on budget, and with good results?

  1. The best project managers are always looking ahead and anticipating and preventing potential problems. By asking project team members good questions, they help the whole team anticipate and prevent problems. Many of these questions are generic. What are we taking for granted? What do we know least about? What is different or changed?
  2. The best project managers know the difference between relatively easy, familiar, predictable tasks and those critical components loaded with unknowns and risks. They know that the unknowns and risks must be investigated as soon as possible and they resist the temptation to get the familiar tasks underway – and out of the way. Doing the easy things first can lead to enormous waste as long as lurking unknowns are capable of causing a major shift or even the cancellation of the project. In addition, doing the easy things first creates false confidence.
  3. The best project managers know that detailed, accurate project schedules give the illusion of control but are usually mostly fiction. They expect detailed tracking and planning for familiar elements and drive hard toward milestones that demonstrate the removal of unknowns and risks for unfamiliar elements. Those unfamiliar elements can’t be planned and tracked in detail until the details are familiar.
  4. They ensure team members have complete and clear assignments regarding who needs to do what by when. These assignments are not just activity-based but also outcome-based. How will we know we have cleared that hurdle? How will we know we are there?
  5. They track progress at a risk-based frequency. If the schedule can slide a month, they may follow up only monthly. If it can’t slide a day, they follow up at least daily.
  6. They know their team. They know when to push, when to be patient, and when to intervene. Some people will ask for help at the first obstacle and others will spin their wheels for a week or more without asking. Some will slack off without external pressure and others always come through as promised. An excellent project manager knows how to keep each team member moving forward and feeling committed to the success of the project.
  7. They can distinguish between necessary structure and bureaucracy. Regular monitoring is important, but updating task progress charts from 25% to 30% is meaningless. The top project managers ask more telling questions. How do we know we will finish on time?
  8. Last but not least, the top project managers shift easily between the nitty-gritty details of execution and the high-level options and opportunities that impact project scope and quality. One minute they are helping a team member tackle a technical problem and the next they are discussing project requirement modifications with the customer. This ability to deal with technical requirements and dig for solutions, while also learning from the development process and recognizing new opportunities that will benefit the customer, can result in better outcomes for all parties.

The difference between decent project managers and excellent project managers is usually years of sweat and struggle. Management respect and support for project managers is often inadequate. But the best project managers, those constantly committed to honing their project management skills, can make a huge difference in company performance, customer satisfaction, and employee commitment and happiness.

Don’t forget to leave your comments below

Ann Latham, president of Uncommon Clarity in Massachusetts, helps clients get better results faster. She is a consultant and board approved Master Facilitator. She is also a frequent speaker and author of Clear Thoughts – Pragmatic Gems of Better Business Thinking. For more information or to signup for her free newsletter, visit www.uncommonclarity.com or call 413-527-3737. Her blog can be found at www.clearthoughts.com.

Project Sponsor as Core Team Member

Written by Catherine Daw on . Posted in Articles. 4 Comments on Project Sponsor as Core Team Member

projectsponsor1Recently I was teaching one of our human dimension skills seminars and the question about who was on the core project team was put to the participants. Someone said the project sponsor was always part of their project team. When quizzed further they indicated that, in fact, the sponsor was also responsible for activities and deliverables in the project plan. This surprised me since we always position the sponsor on the project organization chart above the project manager and team in the overall hierarchy.

It made me wonder how are projects using their sponsor and what level of active involvement do they play?

Who Should the Sponsor Be?

The logical sponsor is the person who both wants the project accomplished and has responsibility for all of the organizational units affected. In essence the person who can make it happen.

This person needs to possess an organizational authority equal to or greater than the scope of influence of the project. The sponsor is usually an executive or member of management and champions the project, pays for it and makes sure the changes are accepted in the business units affected.

One of the most serious problems for projects is not having the right person as sponsor or having a steering committee as your sponsor. This could mean they do not have the organizational authority commensurate with the scope of the project. They could be either too high and have no time or they are too low and become ineffective in clearing the roadblocks that are inevitable in any project. Multiple or co-sponsors can create conflicting interests and put the project in stalemate or jeopardize its success.

What Role Should the Sponsor Play?

The sponsor has a number of key aspects to their role. Along with the management body that approves projects the sponsor will set the project priority, provide funding and approve resource levels. In addition the sponsor will

  • Finalize (and approve any changes to) the project objectives, scope and success criteria
  • Ensure the team has time and resources to achieve success
  • Communicate with business management
  • Commit resources from the various business areas
  • Participate in major project reviews and approve key deliverables
  • Make key project decisions

  • Ensure timely resolution of issues affecting project success

What are the Potential Problems?

If the sponsor is an active team member this will create conflict with their functional role as sponsor. It makes it very difficult for them to be an acceptor of project deliverables when they are responsible for the delivery of some of the components within the project. How will they be able to approve and ensure quality of the project product(s)?

It may undermine the project manager’s role and accountability. The sponsor needs to be able to clear the path for the project manager when there are issues that need to be dealt with at a senior management level. As a team member there will be confusion in making sure the sponsor meets their time and task commitments versus when a project manager needs their support to ensure specific resources are committed from the various functional areas. What happens if the sponsor is one of your resource problems? Then whom do you go to for support? The sponsor then becomes merely a figurehead with limited authority.

The sponsor as a team member also buries them in the micro or detailed level of the project, when their real role is to support and provide direction at the macro level. They need to eliminate possible obstructions and assist in key project decisions from an objective, neutral position. This would be fairly difficult if they are immersed in the day-to-day minutiae.

With a sponsor so actively involved it may even raise the question as to whether or not you indeed have the right sponsor. They may lack the credibility of your other project team members as well as senior management. They could even be viewed as meddling in the regular activities of the project.

Summary

What comes to mind is the analogy of the manager of the hotel also participating as a member of the restaurant staff. How would the chef be capable of successfully delivering meals to guests when the hotel manager is one of the cooks and still trying to manage the hotel?

An effective project sponsor can make the project and the project manager’s life immeasurably easier. Making sure they understand their role, responsibilities and what level of support you require at all stages during the project life cycle is a key ingredient of project success. The sponsor needs to be at the top of the project organization chart where they can affect the most influence and authority.

Don’t forget to leave your comments below

Catherine Daw, MBA, PMP is President and co-founder of SPM Group Ltd. She provides the vision and leadership needed to evolve the firm including the current corporate direction of enabling effective enterprises through strategic initiative management. Catherine has over twenty-five years of experience, working in a variety of public and private sector companies, holding progressively higher positions both in Information Technology and Business areas. Catherine’s personal commitment has always been to deliver results within a foundation of integrity, open communication and with a strong understanding of value creation and strategic advantage for businesses.

Make Your Project Meetings Matter

Written by Tom Ferguson on . Posted in Articles. 2 Comments on Make Your Project Meetings Matter

Meeting_in_ProgressI read somewhere recently that some 25 million meetings take place in corporate America every day and that roughly half that time is wasted. Many of these meetings are project related and I am confident that the dismal statistic relating to time wasted is just as applicable in the project context.

Time is usually a scarce resource on projects and it is also one of the fundamental criteria on which the success or otherwise of a project is judged. Projects have lots of meetings so the potential for consuming that most scarce of resources is obvious. However, project meetings are important and the decisions made are the grease on the wheels of progress.

Responsibility for minimising the time wasted on meetings rests with the project manager as it is they who initiate and facilitate the process, in most cases. The two key considerations in a lean meetings process is for the project manager to first of all consider if the meeting is necessary? If it is, the project manager should run meetings that are effective and achieve their objectives.

Should We Meet?

Firstly, consider the objectives of the meeting very carefully. The objectives are the reason why the meeting is pulled together. Meeting’s objectives should be like all project objectives, that is, Specific, Measurable, Achievable, Realistic and Time Bound (SMART). SMART objectives create common ground, expectation, focus and potential for productivity. And like all project objectives, it must be possible to express them in a way that makes it possible to measure the outcomes to verify that success has been achieved.

Once the SMART objectives have been defined, the project manager must ask themselves if the meeting is really necessary. Many meetings should not happen. They start from the premise of “I am going to hold a meeting so I’ve got to decide on the objectives”. Think of the very many standing meetings that happen just because they are in the diaries well in advance. Many of them are aimless, useless and wasteful of our most precious commodity. But they keep on happening.

The project manager should ask the following questions before proceeding with the meeting:

  • Could an alternative communication mechanism do the job? For example, email, teleconference, video conference, groupware, bulletin board, one-to-ones or the Internet?
  • Do I or someone else possess the knowledge to make the decision alone?
  • Can the decision be made by a sub-set of the project team?
  • Is the synergy of team needed in this instance i.e. is substantial creativity and innovation required?
  • Will there be new knowledge created or is it just a rehash of something old?
  • Is the decision of the type that needs to be made collectively by the team?
  • Is the topic complex, requiring explanation, understanding and acceptance by all the project team for implementation?
  • Is brainstorming necessary?
  • Will there be conflict?

If after considering these questions, it is still thought necessary to hold a meeting, the project manager must next decide who needs to attend? Frugality is the order of the day; the more people in the meeting, the less that will be achieved. In the case of meetings, the old tale of too many cooks spoiling the broth is especially true.

As a project manager, you are obliged to run your meetings in a way that gives everyone present, including unnecessary attendees, a chance to be heard. They will all expect their moment of fame. Unnecessary attendees can be a particular challenge as they probably know that they are not required and that their precious time is being wasted. They may even decide to be obstructive or mischievous!

The project manager should therefore ask themselves the following questions before finalising the list of attendees:

  • Do they possess knowledge or expertise necessary to achieve one of the meeting’s objectives?
  • Have they skin in the game i.e. will they be impacted by any decisions?
  • Are they needed because they have the authority to make something happen?
  • Will they become responsible for implementing some aspect of a decision?
  • Do they need to be reassured about some situation?
  • Do they hold strong views that will act as a catalyst for fruitful discussion?
  • Will they learn, grow or be developed by attending?
  • Can they favourably influence other project stakeholders?

The fundamental rule is that if they are not needed, they are not needed! Don’t ask someone just because they have always been asked. Don’t ask someone just because they are funny or are nice to be around. Don’t ask someone because they suck up to you and agree with your every utterance. Don’t ask someone just because you like them. Remember, just don’t ask them!

Running Effective Meetings

At this point, I am reminded about an incident I witnessed on a train some time ago. An elderly lady got on the train with a bag overflowing with the results of a day’s shopping. As there were no seats available, she stood in the aisle, hanging on grimly to a bar. After a few minutes, a kindly gentleman of similar vintage, stood up and asked if she would like to sit down. Chivalry isn’t dead after all, I thought to myself. The lady refused the kind offer. However, the man was determined, took hold of her arm and insisted that she take his seat.

Then a very interesting thing happened. The lady’s response took me by complete surprise. She pulled away from the man quite forcefully and said in a strong clear voice, “I said no thanks, do I look like I need a seat”? And then the knock-out punch, “sure you need it much more than me”. The man sat down nodding his head and looking like he had been hit in the face by a wet fish.

The relevance of the story for project management meetings is clear. Misunderstandings, false assumptions, lack of commitment, force, hurt, and showing off were all part of what was on display and so it is also for many project meetings.

When people ask me about project management, I compare it to an orchestra. Just like the conductor conducts the performance of the orchestra, a project manager conducts the performance of the team. And nowhere is this approach more needed than in project meetings.

The conductor cannot facilitate optimum performance unless all of the pieces, woodwind, brass, percussion and strings etc. are in place and working to the same music sheets. Likewise, the project manager cannot achieve optimum performance in the meeting unless all of the key people are in attendance.

Depending on the piece of music and what music sheet they are on, different sections of the orchestra take the lead and contribute most. And depending on the agenda for the meeting, and the item on the agenda, different team members take the lead and contribute more than others. But generally everyone gets to play a part and sometimes the smallest part can be the most important.

So how does the project manager conduct the orchestra? I have put together my top tips below.

  • Prepare and circulate a structured agenda well in advance. This is akin to the conductor telling the orchestra what music will be played.
  • Keep the meeting as small as possible by inviting only those that are necessary to achieve the agenda. If the wind section is not required for this particular piece of music, don’t have them hanging around cluttering up the room!
  • Set the stage. Reiterate the desired outcomes of the meeting at the start. Clarify any ambiguity and get everyone on the same sheet of music. Lay out the ground rules and tell them how long each item and the whole meeting will take – and stick to the timescales.
  • Ensure a smooth flow through the meeting. Conduct in a light but firm way and stick to the score! Your job is to interpret how the meeting will be played (style, tempo, dynamics, feel, articulation) and to convey this to the team members.
  • Control the meeting by managing both the content and the process. Conduct in a way that ensures that all the team stick to the music and timing and that transitions from one contribution to another and from one agenda item to another, happen in an orderly way.
    • Watch the timing and move things along as per the agenda
    • If an impasse is reached, it may be necessary to move on and assign the issue to another meeting or a sub-meeting off-line
    • Clarify confusing statements
    • Keep to the point
    • Identify common ground and areas of agreement rather than getting too hung up on differences
    • Summarise and organise ideas/decisions
    • Test for consensus as decisions appear to be emerging
    • Maintain order – one voice only
    • Give everyone a chance to participate
    • Indicate appreciation of contributions.
    • Ensure that decisions are clear and ownership is accepted
  • Do not abuse your role of conductor. On their own, the conductor can sway the baton wildly but nothing will be achieved. The players must be heard. And finally, and most important in a project,
    • Ensure a record is kept of decisions made and action items assigned. Record the music, or at least the highlights, and circulate for review.
    • End the meeting as something of a social event. Thank all for their time, participation and contribution. If a meeting is stormy, smooth ruffled feathers and do some maintenance on damaged relationships.

So remember, next time you think you need that meeting, think again before going into auto mode and sending out the invitations. And if you must hold that meeting, make sure it is a harmonious event!

Don’t forget to leave your comments below

Tom Ferguson has over fifteen year’s project management experience across both the public and private sectors. He holds a Masters in Project Management from the University of Limerick, a B.Sc. in Information Technology from Dublin City University and a Diploma in Executive Coaching from the Irish Management Institute (IMI). In addition, he has been certified as a Project Management Professional (PMP) by the Project Management Institute (PMI) and as a Certified Training Professional (CTP) by the Irish Computer Society. Tom runs his own company dedicated to collaborating with organisations to make their projects work. For more information, please visit http://www.pmedge.ie

© Tom Ferguson 2009