Monthly Archives: February 2011

“Agile” Project Management Certification

Monkey see, monkey do.Well, its finally happened… the Project Management Institute has given in and is creating an “Agile PM” certification.  What a mess.

I think far too many people out there fail to understand the difference between project methodologies and development approaches; hence the reason why we are seeing an “Agile PM Certification” and people talking about “Agile Project Management” – when there isn’t such a thing.

Its like saying that there is “Waterfall Project Management” or “Software Development Life Cycle Project Management”.  These are just ways to approach the development of your deliverables; they are not project management methodologies in their own right (although the methodology needs to be adjusted to the needs of the development approach).

Furthermore, by raising a single development approach to the level of project methodology, we have hamstrung the possibility that people can choose multiple development approaches – depending on what best suits the needs of the various elements of the project (or even sub-projects), teams and customer requirements within the overall project/program structure.

Often the same project management methodology (adapted to the deliverable development approach) can be applied throughout – but highly structured sub-projects may benefit from a waterfall approach, while others may benefit from a more dynamic process such as Agile, iterative development and rapid prototyping.  Still others require a structured design, test and deployment approach such as SDLC.

To raise the development approach to the same level as a project methodology not only mixes apples and oranges, it also ends up breaking the project – because the real objectives of project management aren’t being met.

Developers are concerned with developing their deliverables within the context of the requirements; Project Managers are concerned that the development team is completing that task within the constraints of time, cost and quality.  While the two groups overlap, there are also many distinct boundaries and priorities between them as well.

Unfortunately, the protectors of the project management body of knowledge have finally been harassed enough to hop onto the all-singing-all-dancing “Agile solution” to everyone’s problems; we saw this with SDLC, and rapid prototyping, and now its going to happen with Agile.

Lets face it – the project managers cant get rid of the developers (nor should they) and their coding standards, source safes, module libraries, etc.  Nor should the developers invest so much time in trying to get rid of the project manager and project management.

It’s a complimentary relationship – and instead of investing time on working together and reinforcing each others weaknesses in approach, they are once again trying to do it alone.

We are stronger together than apart.

Effective Meeting Invitations

Woman yelling into megaphoneSo there you are, scanning through the myriad of endless emails in your inbox, as you do each and every morning. And as fate would have it, there they are waiting amongst the email onslaught. Much like young children waiting behind fortified snow hills, snowballs prepared in advance for the unsuspecting character to wander by: the often dreaded meeting invitation. Since you obviously don’t have enough meetings to already attend, you are quick to click on the Accept button. But what exactly did you just accept? And why?

As is quickly becoming the norm, you don’t really know, do you?

We have all received those invitations. Yes, the time and date are there. You may even see a few other attendees listed. The subject line is usually filled in, but may be as generic as “Discuss the Project” (of which project you will certainly know, since you are only involved in five this week). Finally, since there is no room booked or call-in information available, you know that we will all be expected to work on fine-tuning our telepathy capabilities before the meeting.

Perhaps it is a result of the absolute frantic pace in which we all work today, that many of us send meeting invitations to one another without much thought to an explanation of why we need to come together in a closed room to exchange information and ideas – or to make a decision about something vitally important to the organization. Whatever the cause, it is quite apparent that the behaviour needs to change, if not for efficiency in the workplace, well then maybe for something as forgotten and rare as politeness.

I’d like to share with you a few simple ideas for those times that you will be manipulating Microsoft Outlook or Lotus Notes to get one of these invites out to a group of your nearest and dearest. You want to be as informative as possible, giving the requested attendees the very best reason why they should choose to attend your meeting over the other ones they receive. Yes, believe it or not, they often are double and triple-booked, and will cognitively choose where they need to be.

Here is what should be among the elements in every meeting invite that you prepare from now on.

  • The Non-cryptic Subject Line
  • The Meeting Objective
  • The Expected Meeting Outcome
  • The Attendee List (optional / required)
  • The Frequency and Location
  • Call-In Information
  • Supporting Documentation / Web Sites

Although this may appear heavy at first glance, you will quickly realize (during your application of this in your daily life) that the “copy and paste” function available on most computers is actually not that difficult to master. Let’s go through each of these elements in detail.

The Non-Cryptic Subject Line

As was touched on a bit earlier, you want to make sure that your audience understands how this email invitation fits into their workload. Distance yourself from the generic titles such as “Meeting about Project Issue.” Remember, your invite will be buried amidst hundreds of other emails, and your audience wants to be able to quickly decipher what they are about to read. Context is everything, isn’t it? Couple that with the proliferation of handheld devices and you definitely have trouble. Imagine, if you will, a busy executive leaving a meeting, grabbing her blackberry to check for what/where/when details on the next meeting. Hhhmm, let’s see, a meeting on “Meeting about Project Issue.” Yup, that’s not cryptic at all.

Instead, offer your participants some information, but keep it concise. I usually maintain the following nomenclature on Subject Lines: “Project Name – Meeting Name – Topic, if necessary,” which results in something like “Project Genesis – Biweekly Core Team Status Meeting.”

The Meeting Objective

Your audience deserves an explanation as to why this meeting needs to happen. Equally, why you deserve their attendance and participation. Meetings come in a few flavours:

  • Informative: One-way sharing of information, where the speaker “enlightens” the audience on a subject of interest
  • Brainstorming: A meeting of the minds and spirits, to gather as many ideas as possible. This is also referred to as white-boarding, where we all grab dry-erase markers and take our turns at understanding one another’s icons (and hieroglyphics)
  • Analysis: Taking any idea and breaking it down into choices and elements, weighing the pros and cons of each. This usually results in the scheduling of subsequent “analysis” meetings. It’s infinitely recursive, we all realize, yet we enjoy the practice, let alone the time in a closed conference room to enjoy fresh-brewed java.
  • Status: Ah, the Project Manager’s favourite meeting. Ah, the delivery team’s least-favourite meeting. This is the ultimate “what are you working on and why are you late again?” back and forth meeting that we’ve all become accustomed to. We take turns surfing on our laptops when it’s not our turn to provide status on the deliverable of the moment.
  • Decision Making: Perhaps the most under-used, the Decision Making meeting is often the most politically challenging one available for us to schedule. Gulp, someone’s going to make an actual decision?! Egads! Will that mean there’s accountability after the meeting, and that the giant wheel will turn a few clicks?
  • The Mixed Bag: Sometimes, just sometimes, we need to realize that we are, indeed, capable of accomplishing a few things within the confines of one specific meeting.

Make sure that you tell the participants what type of meeting you need to have. Meetings have been derailed for far less a reason. It’s always nice to remind rambling folk that “we are gathered here to make a decision on this, and not to debate its merit.” We all know those individuals who love to hear themselves talk. I firmly believe that every organization should have some sort of quota to meet in regards to that archetype.

The Expected Meeting Outcome

Be specific here. This element underlines the value of this meeting to the business. You may even want to further state what may be the result of a failure to meet the outcome. Whatever the reason for the meeting, it needs to get done. Unless, of course, it doesn’t need to get done – at which point you should question why you are scheduling a meeting in the very first place. Uh-hum…

The Attendee List

I’m sure you’ve all heard it. The “Do I really have to attend your meeting?” line that comes at us from all angles. If I had a nickel for every time that someone said “I can’t wait to attend your meeting”, well, then, I wouldn’t have any nickels.

I usually use the mail client’s TO: and CC: features to cover this, but I explain my lapse in depth of logic within the email itself, using this element to cover it off. Those CCd are optional. Those TOd are not.

I often also insert a “Do Not Forward” statement on some instances of invitations. I’ve often been amazed at how unknown individuals start to show up at certain meetings I’ve chaired, with the meeting becoming a standing-room only event. I didn’t realize that I was such a sought-after speaker. Maybe I should start charging?

As a last note, we’ve all received wedding invitations (if you haven’t, lucky you!). We all know that we are supposed to RSVP. For some insane reason, I expect people at work to use that same logic. RSVP. Such a foreign concept, indeed!

Okay, so that wasn’t a last note. This one is though: For those of you that enjoy the “Decline” option of an invitation, in the spirit of over-communicating, you may want to explain to the meeting chair why you are declining. I love receiving a decline note with no explanation. It gives me the warm and fuzzies.

The Frequency and Location

Very simply put, it’s nice to set the expectation from the get go. Will this be a monthly meeting? Biweekly? Ad-Hoc? It simply puts people into context. It also avoids the “Oh, I didn’t realize that this was a recurring meeting!”  Consider integrating the “frequency” into your Subject Line, such as “Biweekly Status Meeting.”

Yes, it’s also incumbent on you to use the “recurring” feature of your email client. Lock the participants in! However, you may have a more difficult time with the conference rooms. Many organizations now allow scheduling of rooms as “resources” within email. It’s not always easy or feasible to reserve a specific room every Wednesday morning at 7am, given how much people love 7am meetings. Yes, elbow grease may be required at this point. You have options. Send separate email invitations for each recurrence, using different rooms. Barter with your peers to get the room you need. Meet at the bar across the street. Or better yet, barter at the bar across the street.

If you will be scheduling a remote team, and you are able to reserve a conference room in that location as well, it might be a good idea to reserve a room on their behalf. By having remote participants in a common room, they are more likely to be actively engaged in the conversation (rather than scanning through email at their desk while on the conference bridge, muttering their hmm-hmmm’s ever so often to keep you thinking they care).


Oh, people who sit a few feet over from you or on another floor in the same building don’t qualify as “remote participants.” They need to attend in person. They should not be permitted to call into the conference bridge from their desk, as that leads to the same disengagement and lower quality communications that sometimes results with remote teams. Plus, the extra few feet of walking to that conference room can move them over the top of that much-hyped guideline of 10,000 steps daily!

Call-In Information

You have invited people from different time zones to your meeting, as is becoming the case with this virtual wired world in which we reside. The meeting starts. You wait for everyone to join. Suddenly, urgent emails flow in, your cellular starts to vibrate with incoming calls and text messages. That 1-800 number that works in your location ONLY works in your location.

Don’t assume that it will work in Canada if you are in the US. Apparently, it may also not work in the US if you live in Canada. Do I really need to speak of the intricacies involved with the telecommunications networks in the rest of the world? While we’re at it, you may want to provide “local” call-in numbers, since carriers sometimes won’t allow a 1-800 number within a local calling area.

Supporting Documentation / Web Sites

Instead of sending  your supporting documents within the invitation or by email, make them available for download on your corporate intranet, portal, or shared virtual space in whatever cloud that exists for you. Make reference to this within your invite. Finally, if you want your meeting to be productive and without the noise of frantic paper-rustling, endeavour to make the reference material available a full 24 hours in advance of the meeting.

In Conclusion

I know what you’re thinking – I’m crazy. There is no way this can be efficient. Way to heavy to use in a practical context! Go ahead, keep not doing what you are not doing, and reap the results of that. If you change your mind and you are interested in introducing some efficiency and politeness in the way we all work together as human beings, give this a try. Let me know what different things that you’ve tried work for you. I’d love to exchange, learn and adapt my own way of working.

And to save you some time, I’ll leave you with the following. A simple “copy and paste” into the body of your invitation will have you up and running in mere seconds, leaving you time to attend more of your favourite meetings!

Feel free to contact me at . Or better yet, schedule a meeting today!

Sample Body of an Effective Email Invitation


Try a quick copy/paste into your next invitation, and see how easy this really is.

The Meeting Objective:

This is a Status Meeting. Each team member will provide informative insight with respect to their current activities, with special focus and notes on any issues or risks. Please come prepared with sufficient details to share (such as dates). There will also be a decision point towards the end of the meeting with regards to selecting Option A or B.

Expected Meeting Outcome

Formal Decision on Option A or Option B, followed by execution of that option after the meeting. If a Decision is not reached, we will not meet our target date promised to the Executive Committee.

The Attendee List (optional / required)

All member of the core team are expected to attend. Please delegate to someone, if you cannot attend.
Those invitees cc’d on this invitation are optional.

Please do not forward this invitation to anyone other than a named delegate.

Frequency and Location

This meeting is held every Monday at 3pm. On Holiday Mondays, this meeting will be rescheduled to the following Tuesday.

Call-In Information

North American Toll Free: 1-800-555-1212
England Toll Free: 011-44-124-13233
Local City: 514-555-1212
Participant Passcode: 987 6543

Supporting Documentation / Web Sites

Please see current word doc on project folder on shared drive, subfolder titled `”Meetings” with today’s date

The Result




The Case of the Missing Customer

83c2446a0896df0a1f4af01c940ae1d9_XLIt was a dark and stormy night my friends. The type of E-mail storm that pushes the mail account to over capacity in a few minutes.

I was sitting in my cube wondering if my earned value would allow me to either purchase my dream car (a Lada with white wall tires) or less of a beating at the next project steering committee.

That’s when she walked in.

Over the years I had seen many Project Managers but none that could speak CPI as she could. A single look at her communication plan and any PM would fall off his critical path.

My name; not important as you will see it soon enough (at the bottom of this article).

My job; help Project Mangers when they are confused and need support.

Call it job security for life.

“Can you help” she says; nobody can refuse a beautiful risk plan.

I ask her if she can afford my consulting services. She was told her project was in jeopardy because she had lost sight of her customer and did not understand why.

I asked her to walk me through her project plan in a open kimono approach, “show it all” I told her. She willingly revealed it all, as she confirmed doing:

  • Structured project reviews with status, accomplishments, issues, risks and financials.
  • Working with the delivery steady state teams to ensure both high quality and on time project activities while providing interim milestone related deliverables as production.
  • Engaging the contract manager in order to build customer sign off documents that would have the proper objectives and measurements for the post project life cycle.
  • As a true PMP she had in her weekly activities, team motivation activities to ensure the individuals would remain highly focused.
  • Her project plan had obviously included reviews with her up line management team and made sure they were part of the most appropriate communication plan.
  • To ensure internal processes and dashboards had the quality required she had been working closely with her Project Control Officer. As a PCO/PM team they had established a true partnership that would allow him to represent her any time she would have had schedule conflicts.

She paused…..and asked me, who is the missing customer?

It was a classic case, one I had seen occur with many PMs, junior and senior ones.

So I asked her one question: who is the end user?

She asked me “What is an end user”?

Project Managers often forget about the end user.

The rigidities  imposed by either: project plans, delivery team requirements and/or organizational processes that often make us loose site of the end user who is, in fact, the true customer.  Project execution has structured layers that separate us from understanding the end user’s needs and their ways of operating.

The IT business office often dissociates itself from the customer, and business organizations often disassociate themselves from IT.

Recent observations show me that IT justifies itself within methodologies that no longer validate customer operations. In reverse, business organisations often operate assuming IT will provide and supply what they need to operate.

The benefits are structured project deliveries. The impacts are customers that do not understand IT project execution and a Project team that does not know how to adapt project plans to customer needs. These new realities become more than obvious when projects become troubled.

What should (or can) be done by the project team is relatively simple; ask questions.

Ask questions that will hopefully trigger further reviews of the solution and execution BUT with an end user focus. Organisational boundaries can easily be taken down with proper communication and willingness.

With a splash of humour above my objective was to present what represents one of the many areas of focus we all, as project managers, need to focus on while the project execution landscape evolves.

The golden years of project management may be behind us; PMOs will now need to bring a refined project management value statement.

There was a time where project management in an IT shop was done by the employee who had shown the most organisational and people skills within a team of IT savvy individuals(also referred to the team lead that had over the years demonstrated success in implementing complex projects). This person usually had followers/supporters in his or her ability to resolve implementation issues, but also had his or her detractors that believed the compromise was a loss of technical skill.

The success of these individuals brought organisations to understand and value them, and value a project methodology that was structured and applied firstly at a team level and then to be implemented at an organizational layer.

This evolution supported Project Management specializations to form and develop unique skills which distanced themselves from the technical spectrum and focused on an ability to communicate and track project evolution.

The usage of, as an example, PMP or PMI in current CVs or in job search activities is a demonstration of this evolution and of this need at the industry level. What could represent the next evolution and how should a Project Manager evolve to maintain a true value add to an organization? Is project execution threatened by the fact it can be described as a set of work products and compartments to be applied under condition X, Y or Z ? Can Project management be offshored to serve a onshore customer ?

Unfortunately I do not have the answer, but I have the suspicion the answer is Yes.

I can not imagine the evolution of all other areas of IT with some success to an off-shore model to not be applicable to Project Management (or at least some project management).

Let me take you back to my opening story where we are loosing sight of “end users” and of their needs. I would think moving project execution to an offshore model would lead us in the same direction. Is it truly a bad evolution?

Probably not; I can imagine some project execution from an offshore outfit to answer very well the needs of projects implementing “black boxes”. More and more I am seeing situations where an “appliances” or black boxes, which are stand alone solutions, get selected by customers as answering their needs.

Hosting via internet solution falls into this category of IT solution and as all others of the type probably requires little project management.

So where is the need for Project Managers? In my opinion: in their ability to “over deliver”.

Over delivery can be achieved by interpreting the principles of a project methodology and applying the elements that are required but more importantly in a manner that distinguishes it self from all others.

Each project should in a sense be creating a new methodology ready to be changed and adjusted for the next project.

In my humble opinion, the moment we as project managers think we have found the way to deliver projects in the most efficient manner is the day we have stopped being Project Managers.

Our worst enemy is stagnation, or a stale project model.

Management is the ability to handle exception or uniqueness – and to ensure it becomes seamless.

Our value proposition is a project management methodology that is unique that relies on the needs of the customer at that moment and of the situation at hand.

Each customer is unique, and each project is unique by definition of being a project. Why do we force a methodology to be applied and to fit? Probably because the methodology has been interpreted as being bigger than the requirements.

So how should a PMO institute a moving target?

The first step is acknowledging and understanding the principles that go along with an ever changing method of project delivery. The templates and base structure must be one that is open and adjustable to each project. The project reviews assume an understanding of each individual initiative and of each individual customer.

An important milestone would be for a PMO to evolve beyond the Red, Yellow & Green dashboard as well as passed the Earned Value, SPI, CPI and other metrics and use them all as important guides – not key measures in themselves.

Each project needs to establish its success criteria probably at the deliverable level. The organization needs to track to that objective. Once a PMO can establish an understanding of the unique objectives a project must have the PMO can then understand the aggregate needs a customer organization would have and hence bring a UNIQUE valued Project Management proposal.

The PMOs that can see the value in delivering to the individual need will then gain the ability to provide highly skilled Project Managers that can be justified in terms of skills and effort levels.

Selling project management in its purest model on projects that require little management as do Black Boxes is becoming a daunting task; but selling Project management skills that are adapted to the needs of the project and the customer gains an easier path to closure.

Project Management is no longer a required service to IT delivery; unless it demonstrates itself as unique, it has reversed itself back to being over head.

Reaching over the levels of abstraction between project managers, through the PMO and other organizations and process, to the end-users themselves will go a long way to bridging the perception gap between project managers and their “missing customers”;  providing an opportunity for PMs to excel again at over-delivering beyond the expectations of a static methodology and process.

Further more project managers should rise to the challenge of pushing the methodology they are governed by to the next evolution. Continuously strive to adjust, tweak, improve,  to make better, enhance the way in which they execute to address and meet the real end user-user needs this industry should be leading with.

Lastly, and probably most importantly, as practitioners within an organisation or as practitioners working independently we should all look to push ourselves to be better then we were on the previous project.

This will make us unique and a true value for the end user: The ones we all work for.

These simple steps should resolve the mystery of missing customers on projects.

Quick Meeting Minutes (Record of Decisions/Discussion)

Man thinking of how to take notes during a meetingI’ll admit it; I was notoriously bad for not writing up minutes or records of decision after meetings (I’ll leave the distraction between the two for a future article). I’ve gotten much better in recent years – due in part to using the actual original meeting invitation (assuming you issued one electronically) as part of the solution/quick fix.

Most electronic calendars/email packages (including Outlook, Lotus Notes, etc) have an option where you can send an email to all invitees of a meeting.


The technique is relatively simple; reply to everyone on the original meeting list – and use the list of addresses to help form your “attendee” checklist in the body of your message.



As attendees join the meeting – you can simply “check” them off – by adding a Y or N (or blank) beside their name to register their attendance.

Add a simple text template to keep track of the agenda, record of decisions, summary of next steps and then (perhaps the hardest part) – actually USE your computer during the meeting to keep notes as you proceed (this can be tricky for those who may be two-finger typists, but you can get an assistant or PCO to do this as well).


Important Tips

  • Remember to use the template as a tool to organize your thoughts prior to and during the meeting.
  • Don’t waste a lot of time on making perfect notes on the initial pass; just use point form and get into the habit of using indents to handle sub-topics/side-discussions related to a particular topic (much like the “outlining” method for creating a document).
  • Remember that you will have a chance after the meeting to refine your notes a little further before pressing send.

The advantage of this approach, if you are disciplined and have the necessary keyboarding skills, is that you can get meeting minutes/records of decision out quickly (within a few minutes to a few hours) of a meeting being held.

Basic Template

I’ve gotten to the point that I can pretty much do the template on the fly – as I pretty much have it memorized.  Until you reach that point however, you can cut and paste from here to help you:


MEETING XYZ  (usally taken from the subject line of the original message)
RECORD OF DECISIONS <put in the date/time of the meeting>


(this is where the block of email addresses comes in handy; now just indent them one tab and put a Y or N in as they attend your meeting)


(bulleted list of agenda items – if you have one)


(you may want to re-attach reference documents issued before or during the meeting; remember to indicate if they have been updated since the initial release – possibly from discussions during the meeting)


(I usually start off by cutting and pasting my agenda here; then that becomes level 0 of my bulleted list/outline of discussions – which I’m noting throughout the meeting.  Its also okay to stop the meeting and ask for everyone’s thoughts/input on the best way to summarize the outcome of a discussion)


(this isn’t always necessary – but it’s a nice touch if you really want to emphasize who is doing what; especially if you don’t have an issues & actions log to release)


(manage expectations; even if the next meeting isn’t set or known – at least state who will organize the next one if/when it is required)

Finally, I like to add the following at the end:

Kindly advise if I’ve made any errors or omissions; reply to all if the matter is particularly important/urgent.


Don’t forget to review the distribution list just before you send out your notes; often there are people who were not invited to the meeting (and therefore wont be on your distribution list) that may need to be added – just as a courtesy, or for information purposes.

While this technique doesn’t make writing meeting minutes/records of decision any better, it tends to “suck” a little less – and you look like a hero to your team when you can get them out in a matter of minutes or hours vs. the days (or never) like many others.

Top Project Management Tools & Templates

PM looking at a huge stack of papers on his deskWhat are the core Project Management tools/templates and processes? I realize we already have a wonderful “body of knowledge”, with its 42 processes in 5 process groups and 9 knowledge areas, but I’m really talking about the “core” essentials.  What do you need, as a minimum, to “manage” a moderately challenging project?

Of course the phrase “moderately challenging” opens up a can of worms on its own, so lets just say that I’m thinking of a situation where:

  • you have a project that is more than just a trivial/off the back sheet of a piece of scrap paper challenge
  • requires a degree of care in planning and execution
  • with a small team of fellow professionals (lets say 10-20)
  • over a period of a few months
  • without necessarily needing a lot of technology and processes to back you up

It’s not an easy question… I’ve been struggling with it for years, as I’ve attempted to digest various texts down to their essentials, but I think I have my top 10 list (not all of which readily maps to that body of knowledge I was referring to earlier either – although all the pieces do fit in there); more on this later.

Even as I write the article, I continue to struggle with my list – and keep modifying it on the fly.

In any case, if I had to force myself into producing a hierarchical list of tools/techniques and processes, I would propose the following:

  1. Project Initiation Document/Charter
  2. Project Scope Statement and Traceability/Signoff Register
  3. Issues and Action Log
  4. Meeting Record Template
  5. Risk/Opportunity Register and Continuous Iterative Risk Management (CIRM) Process
  6. Change Register/Change Management Process
  7. Project Team Worksheet/Communication Plan
  8. Schedule/Scheduling Management Process
  9. Information Management Plan & Repository
  10. Project Budget/Financial Management Process

Let’s examine each of these in more detail…

1.  Project Initiation Document/Charter

Formally launching a project, with a signed buy-in/acceptance from a sponsor and clear authority for the PM to take action is essential to a successful engagement.

Additionally this document should include:

  • A description of the problem to be resolved or business objective to be gained (try to avoid providing the “solution” – unless that has already been defined by another pre-project process)
  • What would constitute success, or how it would be measured (acceptance criteria anyone?).
  • Who is the “sponsor” of the project (usually a business-owner) and key stakeholders responsible for acceptance, usage and (if applicable) post-delivery support of the project deliverables (an often overlooked group).
  • Indication of the budget/funding; this is especially important if the project is still in its early development/design stages – where an initial budget is required just for analysis and planning as an overall solution may not yet be selected or mature.
  • Initial assignments of team members and/or other resources – especially subject matter experts, technical specialists, end-user contacts, etc.  This isn’t necessarily the complete team – just the key players that can help the core project team understand the problem.

Ideally there would also be some kind of indication of the span of control and authority of the project manager; ie- can he or she make purchases?  Can they engage in the hiring of contractors, etc?

Some of these may be spelled out in subsequent documents and plans, but knowing it at the early stages can help eliminate some confusion and expedite delivery.

Often there are limits on such authority, so the process or at least a key point of contact should be specified (especially if this is an external project manager).

2.  Project Scope Statement and Traceability/Sign-off Register

The Project Initiation Document/Charter usually serves as only a preliminary statement of the scope of the project; it provides just a high level overview of the problem to be resolved and possibly some initial deliverables.

Further analysis and definition is generally required – including the possibility of the identification (and ideally acceptance by the sponsor) of supplemental/implied deliverables that they may not have considered when initially defining the project.

The project scope statement should contain:

  • An overview of the problem to be solved
  • A simplified description of the intended or ideal solution (if known)
  • A list of “SMART” (specific, measurable, achievable, realistic/relevant, testable) requirements for the solution (both technical and business)
  • A list of “SMART” deliverables/products from the project
  • Any relevant specifications, regulations, standardization and/or compliance guidelines
  • A list of tests (if known) that will be applied as acceptance criteria on the deliverables from the project (which may, in part, be derived from the specifications and standards indicated above)

The traceability/sign-off register is one of those supplemental components most commonly found in a separate tool or template – but in this case, is added to the scope document to provide a means of tying requirements, deliverables, specifications and tests together.

As the deliverables are produced, and validated against the appropriate requirements, standards and (ultimately) tests – sign-off is secured from the appropriate customer representative.

Obviously this becomes a living document as a result – which is the intended effect – so that changes cannot take place without considering their impact on all of the elements in the traceability matrix.

It also ensures that nothing gets missed or overlooked from the original scope, as it is no longer document that is only seen and reviewed in early or ending stages of the project.

3.  Issues and Action Log

Short of having the charter/scope document, the next most important tool/template you can have is your Issues/Actions (IA) log.

An issue is any problem for which you do not yet have a resolution for in your plan.

In the early stages of project initiation and planning, when your plan still isn’t formalized, the IA log will become your key reference of who is doing what and how you intend to address all those little outstanding items of business.

After your plan has been created, the little problems that creep up and require resolution can be tracked in your IA log until they are either resolved, or you incorporate the solution to that issue as part of your modified plan (often through a change request).

4.  Meeting Record Template

From the initiation of the project right to its closure, like it or not, the primary means of getting people directed towards their tasks, resolving problems and getting guidance is through meetings.

With such an important activity, it would only make sense that recording the outcome of meetings would naturally be crucial to a project manager and his team – but it is amazing as to how many meetings are held, and no formal record of what was decided or who is doing what, is actually created.

There are some simple means to do this – one of which can be found in our recent article on Quick Meeting Minutes.

There should always be a record of every key decision in the life of a project, and there really is no excuse for keep track at meetings with something as simple as just what the major decisions and action items by assignee.

5.  Risk/Opportunity Register and Continuous Iterative Risk Management (CIRM) Process

Risks are similar to issues in that they are events that may have a damaging impact on your project if not dealt with (or a positive effect, in the case of an opportunity) – but there is no certainty that the event will actually occur.

As a result, you need to decide what to do – either by:

  • accepting the situation and choosing to do nothing until it occurs (to take no immediate action is an acceptable choice in some cases);
  • taking some pre-emptive action to mitigate and minimize the likelihood of the risk (or expand and exploit an opportunity) – but it takes time, effort and resources and the return on that investment had better outweigh those costs;
  • transferring the risk to another team, project, stakeholder, outsourcer, or whatever – but always at some cost to someone – once again raising the issue of return on investment; or
  • similar to acceptance – establishing a contingency plan to be executed on the first indications that the risk or opportunity is about to occur (usually done after whatever mitigation/exploitation has been done); this too costs resources – but having a well thought out, understood and approved plan that is ready to go can often offset a larger disaster that you may otherwise need to react to without any preparation.

The problem is many project managers and their teams only pay lip service to risk management, creating a quick list of things that “may go wrong” (and often a vacuous list at that) and then fail to develop any kind of formal response or action plan.

In those cases the risk review is only conducted a few times (or even just once – at the beginning of the project) and often neglected until problems arise.

A proactive stance is critical to effective risk management, and hence the reason why the template is also accompanied with a simple process that outlines the who does what, frequency of reviews, raising new risks to the attention of the project management team, etc.

6.  Change Register/Change Management Process

As military leaders are often fond of stating:  “No plan survives contact with the enemy”, the same is often true of project plans as they enter the delivery phase.  The only thing that remains consistent in life is change iteself, and as a result you should to manage it just as you would manage issues and risks.

Key to successful change management is having a register of all the change events that take place within a project (including all those little low-cost/no-cost changes that we often let slip by as they are within our available contingency/budget reserve).

While not all changes may need a formal change request – enough little ones, when grouped together, do – and hence the reason why it is essential to track all change events – both major and minor.

Some form of directive on change management should also exist – even if it’s to outline who approves what, and the process for requesting such changes.  Even having just a few simple directives in your project charter or plan, coupled with your change register, will go a long way to keeping change effectively controlled.

You cannot prevent or disallow change; it can be imposed upon you just by virtue of events or authorities outside of your control (including Mother Nature).

You can, however, manage how you deal with those changes – and ensure that decisions made on how to meet change don’t live on to haunt you too badly later.

While I’m generally not a big fan of covering my softer body parts with a layer of paper, change management is one of the few exceptions; trust me — and keep good records.

7.  Project Team Worksheet/Communication Plan

It doesn’t have to be a major creation, but even something as simple as just a who’s who list – names, what they do and how to reach them, will save a lot of time wasted by those trying to track down the right person when needed.

Ideally, and if you have time, you can expand this simple contact sheet to include other great contact/team and communications information such as:

  • a standing project conference bridge – for group calls, meetings, etc (including a reservation process if you only have one bridge, and its shared between team members)
  • group email accounts/distribution lists – that get the word out to everyone in a team or across the entire project
  • social media channels (such as a private Twitter list) that can distribute messages to people’s phones or other devices for when they are away from their computer – or in the event you are working in a closed network (but don’t send sensitive information in such a case)
  • fanout/callout lists – who calls whom in the event of a critical emergency
  • a reporting structure if you are in a hierarchical organization (its always nice to know who your boss is, or who can make decisions on their behalf if they are absent)
  • customer contacts, key subject matter experts, advisors, vendors, etc
  • standing meetings, their objective, and who should attend
  • terms of reference for key roles, and secondary duties
  • deliverable assignment or work package assignment matrices – who is doing what today/this week/this month; especially important with large teams or complex initiatives (it doesn’t necessarily need to be in a lot of detail; just enough to minimize the amount of “asking around” when someone needs to find out something about another team’s work)

8.  Schedule/Scheduling Management Process

You may have thought this would have been closer to the top of the list – and you may be correct in many cases – but I’ve also seen a lot of projects that were managed “on the fly” with the tools listed above (not idea, but its reality) – so while a schedule is incredibly important, you can live without it for a while if you absolutely have to.

I’ve also taken the liberty of cheating a little – and I’ve “assumed” that you cannot readily have a schedule without first developing a clear work breakdown structure (WBS).  For the non-PM types, this is a decomposition analysis of the deliverables in order to derive a set of work packages and, ultimately, activities or tasks which, in turn, form the basis of your schedule.

In truth, the WBS is pretty high up on my list – and if I’m delayed in getting one because my schedule development has been delayed, then I at least start the decomposition of the deliverables into some kind of preliminary WBS in the scope document.

That said, both the WBS and the schedule are living documents – and they should be reviewed regularly with the team.

It’s critical to not just look at the schedule and nod and congratulate yourself on your work; you need to go through it in detail with the actual practitioners performing the work and analyze not just what they’ve accomplished, but to also look ahead and estimate how much additional effort is necessary to complete tasks and whether or not their original estimates were indeed accurate.

This means you need to teach these practitioners to read your schedule, and to ensure they are ready to provide the input you need for effective management and control.

You not only get a better estimate of where your project stands, but your team really begins to appreciate how all the dependencies fit together, where they can afford to slip if it should be necessary, how to better communicate with you and their peers with respect to those dependencies and, ultimately, to buy into the management of the project as a whole and coalesce as a team.

Of course, education and understanding is key – and you may want to establish a standing process/coordination document that not only explains how you are going to review and manage the schedule, but also key terms, and what information needs to be brought to the schedule reviews so everyone’s expectations are being managed.

Don’t forget that such reviews are also a great time to periodically perform risk analysis and review trigger events that may initiate the execution of a contingency plan.

9.  Information Management Plan & Repository

Looking at the list above, it should be clear that you could easily be swimming in information – and you really want to avoid having people wandering about asking “where do I find this?”

Some kind of shared information repository is usually essential, coupled with a plan or guidance on how information is to be maintained and distributed (often as an extension to the communication plan outlined earlier).

Some of the considerations are:

  • accessibility and availability of data (especially if all your team members are not on the same network, or the information you deal with may be sensitive and therefore always kept in secure or internal systems)
  • classification and/or designation of information – as well as “need to know” among your team and other 3rd parties (also don’t underestimate the potential value of the aggregate of information from your various sources may represent, especially when interconnected or correlated, which could be of greater value than what the individual pieces represent in isolation)
  • integrity issues – as to who can modify information, and whether such efforts are tracked (perhaps even with some kind of version controls); can changes be reversed if necessary?
  • duplication, including the threat from having multiple, but slightly varied, copies of the same document – without a clear, definitive (and accurate/up to date) source

You may find that simply having a shared network drive isn’t sufficient – and you may need to rely on some kind of collaborative groupware application – either within your network, or through a 3rd party service provider.

While its often easier to outsource to a 3rd party vendor – remember to keep in mind the potential security risks associated with storing information outside of your immediate control, and think of how embarrassing it could be for your team, your client and their partners should information get into the wrong hands.

Likewise, some vendors may maintain their services in another country (such as Canadian data stored in USA-based servers); as a result, you may actually be in violation of your (or the other’s) national standards or regulations (such as storing personal information subject to the Canadian Privacy Act in US servers that are subject to Homeland Security regulations that allow them to access those records).  Look up “Quagmire” when you have a chance (and I don’t mean the cartoon character).

Sounds like a great topic for one of your preliminary risk analysis sessions during the early planning stages of your project.

10.  Project Budget/Financial Management Plan

This could just as easily have been at the top of the list – but we’ve all seen projects that needed to be done, regardless of cost – or costs were managed “on the fly” by senior management or sponsors overseeing the initiative as it was being rolled out.

Less than ideal, a lot of projects are performed this way – and it doesn’t minimize the fact that the project team needs to ensure they are being economical and efficient within the delivery of their project.

Tracking of expenses (including efforts) are key, which means you need some kind of guidance that outlines:

  • once known/set, what are the budgets for the various components of the project/initiative, including differentiating between various accounts/billing codes (if you use them) and the breakdown between capital vs. operating costs and other relevant details that define your total budget/pool of resources
  • who has authority to spend/authorize expenses and procurement; what are the “clip” levels of each approver, before they need to seek higher approval?
  • where is the data collected and the frequency of reporting?
  • how are efforts tracked and reported (we all know that “time is money” – and that is especially true for the efforts of your team members)

There are many other factors to be included, but these vary dramatically with each organization and the type of project/industry, which means that if some kind of financial management plan or guidance doesn’t already exist with your organization – some serious research and sign-off by senior stakeholders and the sponsor is required.

Don’t underestimate the impact that poor financial management can have on a project; not just legally for the PM and Sponsor, but also in terms of delivery – since that delivery is dependent upon resources that are ultimately controlled by available finances.


Now I have cheated a little.  As I hinted earlier that some of these don’t quite fit into the classic definitions of some of these documents; many touch on other documents, processes and knowledge areas than their traditionally defined boundaries – but the objective is to make things lightweight, compact, reusable and serve multiple needs (or have a “cross functional utility” as a marketing guy would say).

The truth is, these form just a skeleton – on which further refinements could be added to flesh out a fuller and more robust methodology.

Most notable in the “missing” pieces that I’d add on right away are:

  1. A Formalized Project Plan/Framework.  Oddly enough, few projects rarely get beyond a schedule and a few guidance documents – and generally do not have a really clear or formal project management plan.  If you can produce one for a project within your organization/industry however, you will quickly discover that vast sections of it can be re-applied to many of your other projects – and as a result, you can quickly develop a set of standing operating procedures (SOPs) for your organization.  The “unique” elements applicable to your specific project can be attached as a separate summary to your standing project plan.  This is a highly worthwhile investment in time and effort for any organization engaged in regular projects.
  2. A Formalized Project Management Cycle and Development Life-cycle.  The cycle of recurring project management activities used to guide/govern the project teams is not necessarily the same set of activities used to PRODUCE those deliverables by actual developers, specialists or construction workers.  The development life-cycle/process is enveloped by the project management one.  Developers/delivery teams are concerned with producing deliverables/product in accordance with the specifications; project management teams are concerned that the developers perform their tasks within the time, cost and quality constraints agreed to with the sponsor (all while mitigating risks, exploiting opportunities and dealing with issues).  They are similar, and there are overlaps – and documenting the two cycles as well as their interfaces will go a long way to improving overall success and efficiency.  There are lots of development approaches (waterfall, cyclical, Agile, etc) – but most project management tools and techniques are similar.  Unfortunately there is a growing myth that you can have a development approach without the benefit of a project methodology – and as a result, only partial governance is exercised – and projects, while technically successful in terms of delivering to specification, are business failures because they arrive to market too late and over budget.
  3. Formalized Testing, Acceptance and Quality Management Processes.  Call this one number 11 from my top 10 above.  Testing and acceptance should be planned for from the onset before development begins since everyone will want to be in agreement on how the sponsor/customer will be validating how they have indeed received what they have requested.  Similarly, establishing various quality assurance checks throughout the development process and establishing appropriate controls will ensure that they deliverables are correct before they get to the customer.  In some cases, having a pre-defined development process (as mentioned above) will also allow for the definition of such processes to be built in automatically within that development lifecycle.  In other cases however, it may be necessary to create such quality assurance/control processes are part of your overall project plan – especially when it comes to final testing and acceptance.
  4. Time Tracking/Reporting Tools & Process.  While I indicated that time tracking/reporting is partly involved in both the scheduling and financial management processes above, it doesn’t hurt to bring it together into its own clear summary process – easily referred to by all concerned.  Having a good time-tracking/reporting process, ideally tied into your schedule, will help keep your project delivery and costs in track.  More often than not, however, the reporting of actual efforts is not readily mapped against the schedule – and some careful analysis (as well as lots of coffee ingestion) will needed to ensure that the project really is on track (a topic leave for another article).
  5. Personnel Assessment Process.  Ultimately project management is about leadership, communications and team building – and one of the key tools to help maintain and develop a team is some form of feedback process on how an individual is performing, what they can do to improve, as well as feedback to the employing organization in general on how the individual is developing – with recommendations on future assignments, assessments on the long term potential for the individual and other development needs.   See our article on the Individual Post Project Assessment (IPPA).

Needless to say, the missing/desired supplemental portions to the top 10 listed above could easily warrant a further article in their own right.

All of this, of course, has lead to my 10 year struggle developing small-PM (a project in its own right) as a light weight, and yet reasonably robust, project management methodology that would lend itself to a broad array of projects, industries and environments — but more on this another time.

Individual Post Project Assessment (IPPA)

Someone having a review session with their supervisorAs part of the ongoing development in my own project methodology (small-PM), one issue kept coming up – which was how to document and disseminate information on the individual performance of team members associated with our projects.

Good or bad, I borrowed a few lessons from the old Performance Evaluation Reviews (PER) from my time in the military, and adapted the concept for use in project environments.  The result was this Individual Post Project Assessment (IPPA) form you see here (at the end of the article).

ippaWhile a few organizations had some form of annual assessment, people assigned to individual projects were often “outside” of the normal review process – and there needed to be a way to put input into their annual assessment, and the IPPA proved to be an effective means to get a broad, comprehensive snapshot of the individual’s performance.

For those organizations without formal annual assessments, we just used multiple IPPAs for each engagement throughout the year – and as a result, we were able to fill their HR file with meaningful information.

Since its development, I’ve actually had a lot of success using this form – and although it may undergo some more revisions with the upcoming release of small-PM 3.0 this spring, I thought I would re-release the form here… and invite you to use it and provide whatever feedback you can.

In addition to the form, I’ve also attached some real examples (with names and details removed of course) so you can get a better feel of how the scores and text need to support each other.

I’ll be posting the other tools, templates and forms from small-PM on the site in the weeks that follow – as we lead up to the official release of small-PM version 3.0 this spring.

Please send your feedback directly to me, or via comments to this article.  Good luck!

Word Template: DK2473_IPPA_version_11

ippa_SAMPLE_1 (PDF)

ippa SAMPLE 2 (PDF)

ippa_SAMPLE_3 (PDF)