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.

Conclusion

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.

Author: Stephen Holton, PMP, CISSP, SSGB, ITIL, CD

After completing over twelve years service in the Canadian Armed Forces, Stephen moved to private industry where he was employed as a Director of Information Technology, Director of Operations and CIO for a number of private sector companies before finally electing to become an independent consultant in 2000. Since then he’s served as a management consultant, project/program manager and business analyst/solution architect in a number of industries and organizations - including a big-5 consulting firm. These industries and organizations have included the airline, railway, telecommunications and banking industries, the Canadian and US Governments, as well as mandates in Brazil and Bermuda. Presently Steve lives in Ottawa, Canada.

Leave a Reply

Your email address will not be published. Required fields are marked *