The Project Management Handbook

Many organisations adopt a “PM Methodology”, often without giving enough thought to what that means or how it is documented and published.

My working definition is: “How we do things around here”. It is the what and how of applied project management, including the tools and templates, within a specific ecosystem.

A methodology needs to relate to an organisation’s environment, including the systems, processes and culture. What this means is that adopting an industry standard framework (Prince2, PMI, APM, ITIL, ISO21500, Scrum, etc) is all well and good, but it can never be sufficient. Someone needs to think through and explain to the PMs how to apply the framework in the specific organisational context.

How to do this? From the reader’s perspective (i.e. the PM), it needs to be:

  • Relevant and practical
  • Complete
  • Up-to-date
  • Easy to access and to use
  • All in one place, including processes, templates and links
  • Relevant to first-time users as well as to experienced practitioners

For the custodian of PM best practice, it needs to be easy and rapid to maintain.

In the bad old days, a PM Handbook was a physical document in a binder. Typically, these took many months to author, and then suffered a very slow and expensive update cycle, with perhaps a new iteration after a year. In practice they seldom survive beyond Version 2. Of course, a paper document can’t easily contain templates – so they were often accompanied by a CD or a website, which rather starts to defeat the purpose. Worst of all, handbooks in binders tend to be read once (at most) and then left on the shelf.

Intranet sites can be a good solution, the downside being that they are sometimes cumbersome to administer. But it is at least possible to document the process, attach templates, and provide links to related corporate tools.

A downloadable handbook is a workable solution. The main part of the handbook might be a Powerpoint or Visio document, and templates can be embedded. However it relies on users downloading the latest version periodically. It has the advantage that it can be used off-line, so the PM doesn’t need to have always-on internet access.

I have seen unsuccessful attempts at publishing PM methodology using a process management tool. Unfortunately most are not designed to be read by mere mortals; you have to be a trained process expert to decode the flow-chart symbols typical of these systems. So you end up with something loved by the process experts, but hated by the project managers.

However, there are business process tools that provide tidy and human-readable output. The best I’ve ever used is Tibco Nimbus, and I wouldn’t hesitate to recommend this as a way to publish a PM handbook. Unfortunately it is intended as a top-down corporate tool and is a bit overkill, hence unlikely to be cost-justified just for project management purposes. But if it is available in your corporate environment, then definitely go ahead and make use of it.

I have recently come across Skore, which is a lightweight tool that is ideal for documenting a simple project management process, but without the sophistication of Nimbus. Here is a generic PM Handbook authored in Skore, including some simple templates (click the diagram to open the handbook in a new window).

 

pm handbook

This version can be used as it stands, but of course it has not been tailored to any organisation. It is now ready for additional context-specific detail and links, and additional levels of drill-down where needed. It would also be possible to adapt it to Prince2, APM, PMI or other methods and terminology.

The attributes of this PM Handbook are:

  • Uses the “Seven Essentials” structure
  • Templates can be found in context, within the process flow
  • Easy to access and navigate
  • Easy to maintain
  • Can be tailored to suit any organisation
By | 2015-08-21T13:38:46+00:00 November 1st, 2013|Project Management, Seven Essentials|1 Comment

Project Start-up Meetings

You know what they say about first impressions? Good. I won’t bother repeating it, then.

For a Project Manager, the Project Start-up Meeting is that chance to make a positive first impression with the team. So it is perhaps surprising how often PMs just seem to “wing it”, without really having thought about the objectives, purpose and process of the meeting. Even worse, some PMs simply don’t seem to bother… which rather sets the tone for the rest of the project.

In response, I offer you this five-minute guide.

The Start-up Meeting is an opportunity to:

  • Ensure everyone understands the purpose of the project. The “big picture”, if you like.
  • Gain commitment and ownership from the team, by involving them in thinking through the process and outcomes.
  • Work through and overcome perceived objections and obstacles.
  • Establish ground rules and working relationships.
  • Display and promote the project manager’s leadership abilities.
  • Build a team, and have a bit of fun.

Depending on the size of the project, the Start-up Meeting can vary in size from a 1-2 hour meeting for the project team, through to a 1-2 day off-site workshop involving core team, extended team, internal and external suppliers, facilitators, etc.

Even for small projects, the meeting should always be held face-to-face (not a telco) to establish intra-team relationships and trust.

Naturally, I recommend applying The Seven Essentials as the basis for an agenda.

  1. Business Benefits. Invite the Project Owner to introduce the vision driving the project, and ideally link it to corporate strategy and objectives. A good Project Owner should be able to do this with passion and enthusiasm, motivating the team to deliver to the best of their abilities, and setting the mood for rest of the meeting.

  2. Scope and Quality. During project initiation, the Project Manager will have established the project’s deliverables, defined to a greater or lesser degree of detail depending on the circumstances. Now is the time to introduce this to the team, examining the definition of Scope, and ensuring a common understanding. Where there is uncertainty or ambiguity, this needs to be explored and understood. Quality requirements also need to be defined. Is a “beta release” approach allowed — with known omissions or faults? Or perhaps there are safety or security requirements that are absolute.

  3. Stakeholders and Communications. Again, the PM will have established an initial view during initiation. The Start-up Meeting provides an opportunity to review and possibly update the Stakeholder list and Communications plan. In particular, ensure that the team is understands and is comfortable with the communications that they can expect to receive, and also that they are committed to the communications that they are expected to provide (e.g. reporting deadlines).

  4. Plan. At least some of the team should have been involved in planning activities already. Now introduce it to the full team, and have them work through their own part to ensure full understanding and commitment. New information may come to light — don’t forget to ask about holiday commitments — so don’t be afraid to update the plan accordingly. Ensure that all activities have a clear owner. Check that appropriate contingency has been built in (based on past experience), and that dependencies are mapped and understood.

  5. Team. Is the team complete? Are there any gaps? Does the team feel empowered, capable and confident of delivering? If not, what needs to be done about it: perhaps additional skills or resource, specialist input, training? The Start-up Meeting also provides the opportunity to start building a high-performing team, particularly important if these individuals have not worked together before. Within the constraints of company culture and available budget, now is a good time to work in some team-building activities. Try to have some fun!

  6. Suppliers. If possible, include the major suppliers (internal and external) in the Start-up Meeting. They are part of the extended team, and are critical to the project success. Make sure they understand what is expected of them, and why the team relies on them. Understand their constraints, and give them ample opportunity to explain what they need from the team, why, and when.

  7. Risks. Reviewing risks should be a regular team activity, and the Start-up Meeting is the first iteration. Work through the risk register, add new risks as perceived by the team – and retire any that are no longer relevant. Review mitigation actions and assign owners. Review contingency plans.

A well-planned Start-up Meeting gets the project off to a good start, not just in terms of the mechanics of the project (the plan, the tasks, the responsibilities), but also setting the mood and atmosphere – hopefully one of cooperation, enthusiasm, openness and commitment. You should aim to spend enough time speaking to establish authority and leadership, and to spend even more time listening and questioning.

By | 2015-08-19T10:54:45+00:00 June 7th, 2013|Project Management, Seven Essentials|0 Comments

The Sixth Essential: Suppliers

When I have reviewed projects in the past, “supplier problem” is the most common reason I hear for projects running into difficulty. To some extent, this might be a convenient excuse: it is easy to blame something or someone outwith the project rather than admit failure within the project team. But the PM doesn’t get off the hook that easily, as there are techniques that will improve the chances of project success.

It is really difficult to generalise, as each project situation is different with respect to suppliers. Suppliers range from internal suppliers (such as a test team, office facilities, or HR) through to major sub-contractors supplying multi-millions of equipment and services.

Often, the internal suppliers are the hardest to manage. The problem is lack of accountability to the project manager. If the local IT department can’t provide enough working PCs for your team, what are you going to do about it? If the test team lets you down by rescheduling resources to a higher-priority project, who do you complain to? Best practice here is to establish Service Level Agreements (SLAs) with your internal suppliers. Agree the ground rules up front for critical internal suppliers, so that you know what to expect – and you then have clear grounds for complaint if the SLA is not met. Also, if I ever review your project, I will be more sympathetic to the “poor suppliers” excuse!

External suppliers are more normally governed by a contract, which will include penalty terms for non-conformance. Contracts are usually established by a procurement function – in itself an internal supplier to the project – and in my experience the service that they provide can vary enormously from a simple “standard terms” purchasing function through to taking a real interest in the project and tailoring the terms accordingly. The project manager needs to be fully engaged in procurement activities, to ensure that supplier contracts support the needs of the project.

Some procurement departments believe that their sole function is to buy at lowest price. Beware! If your supplier’s price has been pushed so low as to make the business marginal, then don’t expect to see much engagement from their best people.

The most important factor that a PM needs to think about is the assignment of risk. So in a “time and materials” contract the risk is mostly with the buyer, i.e. the project manager. If timescales slip, it can actually be to the supplier’s financial advantage, as the time and hence the price will increase. The PM needs to manager time & materials suppliers very closely.

At the other extreme, a fixed price contract specifies the deliverables (including quality and time aspects), and the risk of delivery rests with the supplier. If they do not deliver what they promised, on time and to the required quality, then there will be financial penalties to the supplier (usually referred to as “liquidated damages”). In this case, the PM needs to closely involved in defining the contract terms, but once the contract is signed then it is important to take a step back and let the supplier get on with it. Ask questions relating to progress, but leave them to make their own decisions. Changes to requirements may be welcomed by the supplier, as there will be a price tag associated with each change, and you can be sure that they will be looking for a higher profit margin than on the base contract!

Most of all with a fixed price contract, don’t try to interfere. If you, as PM, try to direct the way the supplier acts — no matter how well-intentioned — then in the event of targets being missed the supplier can use the interference as a legal argument to escape penalties.

An interesting and emerging trend is for “open book” contracts. In this approach, once a supplier has been chosen then the risk is shared. It is accepted that the supplier needs to make a profit margin at an agreed rate, and all of their costs are then fully revealed. The PM works with the supplier to agree cost/time/quality decisions with the best project outcome being the primary concern of both parties. If you can get to this situation, it is an ideal way to balance risk.

By | 2015-08-19T10:54:45+00:00 May 13th, 2013|Project Management, Seven Essentials|1 Comment

The Fifth Essential: Team

In the first four essentials we have established our business objectives, engaged our stakeholders, agreed a scope, and planned a delivery. Now the focus of the project manager should turn to enabling the team to deliver.

It is really important to understand that it is the team that delivers, not the project manager. From this it follows that the project manager works for the team and not vice-versa. True leadership is about vision and purpose – and enabling the team to succeed.

So who is the “team”? Whereas when defining stakeholders it is good to take a very wide view (everyone impacted), I prefer to be more focussed when it comes to the team. The team is the set of resources that are directly under the control of the project manager.

Often, the team members are not actually line reports of the PM. This gives rise to potential conflict between project manager and line manager, but the ideal situation is where the team member is effectively functionally assigned to the project manager for the duration of the project.

It is not unusual for staff to work on multiple projects in parallel. I suggest that a team member is someone who spends most of his working time (i.e. greater than 50%) on the project. Anything less, and that person is an internal supplier, not a team member.

The makeup of the team is often dynamic – for example it may have more designers early on, and more testers later on – but at any point in time the PM should be able to state unambiguously the current team membership.

Now we know who the team are, somehow we would like them to become “high-performing”. What does that feel like? When I’m part of a high-performing team, I experience:

  • a sense of purpose – of shared vision
  • absolute determination to deliver, no matter what it takes
  • willingness to step beyond the call-of-duty

I also feel excitement, enjoyment, and sometimes euphoric exhaustion!

How does the project manager gain this state of sustainable high-performance? There is no single answer, but here are few ideas that I have personally seen succeed:

1. Leadership and Vision

The project manager should be the second-best advocate of the project – the first being the project owner. The PM needs to be absolutely bought-in to the business objective, and to be able to articulate it with enthusiasm at every possible opportunity.

2. Clearing Impediments

I’m deliberately using SCRUM terminology here – clearing impediments is the first responsibility of the ScrumMaster. And it is also applies to project management of any kind of project. The PM needs to be sensitive to anything that stands in the team’s way, and clear the obstacle. Is there an awkward process that needs to be side-stepped? Is there a budget deadlock that needs to be resolved? Does the team have a problem with desk space? No matter what the impediment, it needs to be tackled. And if it really can’t be fixed, then the PM needs to help the team accept the constraint and agree a coping strategy.

One of the biggest impediments in a demanding project is cynicism. Cynicism diverts energy, and destroy the team’s performance. Project managers can counter this with enthusiasm and sense-of-purpose. But sometimes decisive action is needed to remove a “bad apple”.

3. Self-Determination

Teams, sub-teams, and individuals should be encouraged to think through the challenges and devise their own solutions. Trust the team to come up with the best solutions for themselves. Not only will it (probably) be the best answer, but they will most certainly be fully committed to it.

Occasionally the project manager may know better – but not very often. And even when this is the case, you are likely to have more success with a sub-optimal approach that the team supports than a “perfect” solution that isn’t supported.

This is, of course, a coaching style of leadership.

4. Push and Challenge

It is amazing how hard people are prepared to work, if they are motivated! Don’t be afraid to set demanding targets. You are not being kind to a team by giving them an easy ride; most of us prefer to work hard than to be bored. Some people actually thrive on working long hours – but we’re not all the same in this area – so be sensitive (and also take account of health and legal constraints).

5. Celebrate Success!

Always remember that when the PM delivers an outstanding result, it is actually the team that deserves the credit, not (just) the PM. Be appreciative of good performance, recognise and reward it to the extent that you can, and always try to find some beer money for an occasional team event.

By | 2015-08-26T15:34:12+00:00 April 16th, 2013|Project Management, Seven Essentials|0 Comments

The Fourth Essential: Plan

I was once a team leader in a large project. At that time I wasn’t yet a project manager, but the project did indeed have someone with that title. I expected him to ask to see my plan, because that’s what project managers do, isn’t it?

His answer surprised me. “I’m not interested in your plan. But I’d like to help you produce one.”

I asked him what tools he would like me to use – again, isn’t that what project managers are supposed to do for a living? “I don’t care. Just invite me to your team meeting and we’ll do some planning.”

What happened next was a team workshop, in which we spent a lot of time coming up with a messy diagram on a whiteboard. It had activities, deliverables and arrows, and some dates. The PM challenged us to define the objectives, and constantly asked about dependencies. He didn’t do any “planning” that I could see – he just asked us tough questions.

At the end of the meeting we had a rather ugly diagram, but it was one that we were all happy with. I asked whether he would be turning it into an MS Project plan. “No, but you can if you want. As far as I’m concerned you’ve done the planning. You now have a high-quality plan that your team has bought into. As I said before I really don’t care how you document it.”

I learnt a lot from that PM – in fact, he became a role model for me. His point, of course, is that the planning process itself is what matters, and it matters far more than the plan. It matters because:

  • The team does the planning. Not the project manager.
  • The team thinks through the issues, and comes up with their own solutions.
  • The team now owns the plan, and are committed to delivering against it.

I wouldn’t personally go quite to the extreme of not caring about the subsequent plan. It is an important baseline – something to track against – and it is an essential communications tool.

When I look at a project plan, the things that interest me are:

  • Does it demonstrate how the project delivers against the project scope – is there a clear linkage?
  • Are the dependencies properly shown?
  • Is it likely to be understood by the intended audience (including team members and senior stakeholders)?
  • Is it up-to-date?

I also like to ask how the plan was produced, and how it is maintained. To what degree are the team involved?

The form of the plan doesn’t matter. It can be MS Project, Powerpoint, Excel, or a squiggly diagram on a whiteboard. Just as long as the team regards it as being their plan.


Post script

Long after writing this article I came across an excellent quote which says it all far more succinctly:

“In preparing for battle, I have always found that plans are useless, but planning is indispensable.” – Dwight D. Eisenhower

By | 2015-08-19T10:54:45+00:00 April 2nd, 2013|Project Management, Seven Essentials|0 Comments