Helpful Hints For Project Meetings


People generally go to meetings because they are asked to attend. With a simple click of the mouse, they accept. Rarely do they respond to your request with the why did you invite me question. Some accept and just don’t show up. These are contributing factors that sway a meeting from productive to unproductive.  I sometimes see people go an entire day and only attend meetings. When do they get actual work done? We all know that answer.

Here are a few helpful hints for the next meeting you organize.
[1] Write out the purpose of the meeting with actionable events in mind. e.g. “Provide an updated status, identifying risks and opportunities, and identify new action items.”

[2] Identify your attendee list but only keep those you can map to the actionable events listed in step 1.  There is a difference between an attendee list and a communications distribution list.

[3] Create an agenda.  Do not ever arrange a meeting without a written agenda.  Your meeting will suffer scope creep in the worst possible way.

[4] Identify who will run the meeting and who will take notes.  It should not be the same person.

[5] Circulate the completed agenda and collateral documentation prior to the meeting.  Have some on hand in the event people don’t bring their own copies to the meeting.

[6] Provide different means of attending the meeting.  e.g. In person, via telephone, via web meeting.

[7] Start every meeting on time.  If you don’t start on time, how do you expect to finish on time?

[8] Ensure discussion points align to the agenda.  If they don’t, recommend taking the topic to another forum.

[9] End the meeting by having the note taker read back the discussion points and the understood action items.

[10] Send out the meeting minutes within one to two days.

Here are a few helpful hints for the next meeting you are invited to or attend.
Upon receiving an invitation, ask yourself if it is really necessary to attend this meeting.  It could be you just need to be kept informed.  Ask to be included on the meeting minutes distribution list rather then attending.

[2] If you are going to attend, arrive on time!  It is rude to walk into a meeting after it has started.  Have a little respect for the other attendees.  They found it important enough to arrive on time, why can’t you?

[3] Know which agenda items pertain to you prior to coming to the meeting.  Be prepared.

[4] Verify the published meeting minutes for accuracy.

I hope this helps you get the most out of your project meetings.  As an added bonus, I am including a link to my free Meeting Minutes Template.  You can also find it by navigating to my Free PM Templates page.

I welcome your feedback and suggestions.



Understanding Agile Scrum and common terms

No Comments

I’ve been in a few meetings this last week where people were mentioning Scrum terms but didn’t know what they were. It’s not their fault. The person introducing the terms into the project vocabulary should have provided an explanation before referencing them.

For those of you new to Agile Scrum, here are a few basics:

What is Agile Scrum? There are many specific agile development methods. Most promote development iterations, teamwork, collaboration, and process adaptability throughout the lifecycle of the project.  Agile methods choose to do things in small increments with minimal planning, rather than long-term detailed planning.  There is a heavy emphasis on face-to-face communication over written communication.

Agile Scrum is not ideal for every project.  If the project has high criticality, is using junior developers, has clearly established requirements that do not change often, employs a large number of developers, you should think twice about using it as your method of choice.

I’ve seen it work very well with small (5-9 member) teams, where all the stakeholder knew they wanted “something” within a short period of time.  They did not know specifically what it was nor how to get from start to finish.  We used a lot of wireframes and prototypes to get us in the ballpark, until we could lock down clear functional and design requirements.

I think it’s important for people to understand key terms in Agile Scrum as they relate to other project management methodologies.


Product Owner
The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.  This owner could be a project manager, director…  Whatever their title, they must have the authority to make decisions on behalf of the project.

The person responsible for the Scrum process, making sure it is used correctly and maximizes its benefits.  This is NOT a project manager.  This person is a facilitator.  They are merely there as a communications bridge and to offer motivation or remove impediments.

A cross-functional group of people responsible for managing itself to develop the product.  This is a small team (5-9) consisting of at least one person from each area (BA, QA, Risk, CM, Software Engineering…)  This team traditionally sits in the same room or area.

Scrum Team
Product Owner, ScrumMaster and Team.  Everyone directly involved in the project, with the exception of users, stakeholders, and managers.


Sprint burn down chart
Daily progress for a Sprint over the sprint’s duration.  This chart can replace a Gantt chart in illustration of progress.

Product backlog
A prioritized list of high level deliverables assigned to teams.  This list is similar to milestone deliveries you’d find in a Work Breakdown Structure.  These deliverables will still need to be decomposed (in the sprint backlog).

Sprint backlog
A list of tasks to be completed during the sprint and assigned to individuals.  These are the actual decomposed items from the product backlog.  This list must be agreed to by the entire team prior to the sprint actually beginning.  If there is a change in the scope of the sprint backlog during a sprint, the sprint must be immediately stopped and scope redefined.


A time period (typically between 2 weeks and 1 month) in which development occurs on a set of backlog items that the Team has committed to.  Sprint time periods are established to provide enough time to deliver something, get feedback, and begin another iteration.

An output requested by the customer.  It is a completed document, process, web page, database…  Regardless of what it is, the customer believes that it has value.

Other terms to be listed in a later post:
Sashimi, timebox, daily scrum, chickens, pigs, retrospective, user stories

Kobayashi Maru for Projects

No Comments

Without trying to appear to be too much of a geek, I sometimes code-name a project as Kobayashi Maru. For those out there who are not Star Trek geeks, Kobayashi Maru is a test in which command division cadets at Starfleet Academy are presented with a no-win scenario as a test of character. I use the term for a project in which management gets involved and I’m presented with a no-win scenario.  I doubt they are trying to test character. Rather, it’s an example of their lack of understanding project management.

I’m sure there are PMs out there who have had management redirect resources from your project to others, only to refuse to narrow scope or push out a delivery date. That is a Kobayashi Maru.  Just because I have a PMP®, don’t expect me to pull a rabbit out of a hat.  On a previous program, I’ve looked management in the eye and reminded them that something will have to give.  Narrow scope, extend the deadline, lower quality expectation, or increase the budget.  Do something or this will be a no-win scenario.

Image from :

Using Agile does not mean a lack of defined process

No Comments

Agile Scrum processSometimes I’m not surprised to hear one of our current contractor say they are now using Agile.  This is their explanation for ad-hoc builds, lack of documentation, and lack of predictable process.  It can be frustrating to hear of development groups using it as a scapegoat.  Waterfall has been the decided process for our main program I’m working and it makes sense.  The requirements have been clearly identified, for several years.  The budget and schedule have been fixed, for several years. I’m not saying we can’t use Agile in different areas of the program.  But, most important the current contract is not structured to support it.

The contractor does not seem to understand the difference between cowboy coding and Agile.  Agile teams, do follow defined and often very disciplined and rigorous processes.  What is lacking, by this contractor, is any example of a defined process.

Agile certainly can work well if utilized by people who know what it is.  I’ve signed the Agile Manifesto. I know what Agile is.  Don’t use a lowecase “agile” and think you’re getting away with it.