Hints and Tips for Project Managers – for both New and Experienced
Being the manager of a project of significant scale and importance could be one of the most demanding things you do in your career. It could also be one of the most rewarding. They can be very challenging and the role of the project manager (PM) is crucial. An effective one can make all the difference.
The following project management tips deliberately address many of the most common issues found on projects and are drawn from decades of real-world experience. If you are already an experienced PM, why not ask yourself “how often do we really do what follows (well)?”.
The first thing to make crystal clear is the ToR for yourself and the team. If you ask more than one person in any business what the job (responsibility) of a PM is you’ll get significant differences in their answers. So, one of the first things to do is to agree and make your responsibilities crystal clear, especially with people like the your sponsor. Also, it needs to be stated in clear and practical terms that relate to your project (not just “deliver it on time, to budget etc.”). Too often, new PMs only get to fully understand their responsibilities gradually. If this is allowed to happen, this on its own can cause serious issues.
The same principle applies even more to the team, As team members are appointed (or even if they have been already) one of the most valuable things you will ever do is to define each core team member’s responsibilities (not just their role). Again, this means in clear terms. You should pay particular attention to their responsibilities relating to producing or defining key inputs (e.g. requirements) or reviewing outputs (specifications, documents, deliverables etc), or anything else. You should try as far as possible to get what we call input oriented information, rather than just feedback after a development activity.
Whether it’s called definition, initiation, PID (project initiation document), business case or whatever, all the most important decisions happen in the initial stage. Many of these decisions will have a great influence on the project’s success. It is also the point where we have maximum opportunity to influence any aspect and to sow the seeds of success as opposed to something far less attractive.
One of the biggest challenges and most important tasks you will do is to get all stakeholder groups to engage openly and effectively during this stage (and to commit the level of effort / input which is required). Any project that is struggling to achieve this should consider very seriously whether it can proceed to the next stages if this issue cannot be resolved.
And this is a massive point. Rushing through or skimping the activities of communicating and agreeing unambiguously the objectives / outcomes/ key requirements / expectations with all stakeholders will not ultimately save time or effort – but without doubt it will significantly raise the probability of serious issues downstream. Neither should asking fundamental questions ever be looked upon as a weakness – (i.e. “if I have to ask a question I may appear I do not know/ understand the answer”). Make no assumptions whatsoever, especially concerning the goals of the project.
This is a key task in the definition stage – ‘managing stakeholders’. Once you know who they are, it will involve engaging with stakeholders over their objectives. You should expect to find different and even conflicting expectations and needs among stakeholders. The time to understand and formally recognise this is at the start, as part of the definition phase. This is one of the most important tasks you will do; ensuring where issues or conflicts have arisen, they are being addressed formally, if necessary with the support of the sponsor.
There’s a lot written about ‘deliverables’, and this is entirely correct. However, much less is written about defining explicitly the goal(s), objectives and expected outcomes. This is without doubt the most important task, especially on internal business projects, where too often it is assumed that they are a) clear, or b) agreed (when in fact both may be far from true). Once again, without testing this formally at the start, damaging assumptions, which have not been shared (tested) across all stakeholders groups can prevail – potentially catastrophic in itself.
It is also very important to communicate the objectives and outcomes very clearly to all core team members – especially those who are responsible for defining and designing the solution.
Firstly, this is not the solution or the deliverable (or end product). It’s how these things are going to be defined and delivered. The delivery strategy should contain: goal; objectives; outcomes; responsibilities; project targets; key strategic decisions; key project assumptions; constraints; and risk mitigation strategies.
The delivery strategy should be captured in a format that can used easily as a mechanism to communicate to anyone: a) what the project is about; and b) how it is going to be delivered. That usually means not a Word document/ template.
There are numerous clichés surrounding projects and risk – many of which are true. For example, every one on the globe carries risks and assumptions. For example, dependencies can be obvious drivers of real risk. Good PMs will always look for these early. Understanding the key dependencies and risks is crucial to being able to develop a delivery strategy that stands a good chance of being successful. Recording and sharing assumptions, risks and dependencies within the definition phase is a hugely valuable exercise, followed by effective mitigation of significant risks. The PM should be very much in the middle of this task and never simply delegate this task to someone else. Ensuring the effective management of risk is one of the most productive things any PM can do. Again, this must be done in the definition stage – we can’t define, plan and launch a project and only then start to give serious attention to risk. It must be addressed as an integral part of defining the project and most especially at every major decision point / commitment in the life-cycle. The PM must make sure that this is done, even when others do not wish to hear the results. Otherwise, there is a very strong likelihood of counting the cost in time (delays) and effort (increased cost) downstream.
There are also numerous proverbs relating to project management and many relate to the incidence and power of assumptions. Whenever we plan something new, we make assumptions. For example, every unanswered question leads to the potential for assumption. In the early stages, we will often make major assumptions regarding the solution, delivery strategy, or any other aspect. They happen all the time. The room for assumptions is immense, even and especially among the team members and stakeholders. It happens because we are creating something new or are changing something, and is sometimes exaggerated by the simplistic way too many have been defined or communicated in the past. This principle can be extended to any aspect, e.g. the objectives; outcomes; solution; benefits; deliverables; especially the responsibilities; resources, and any other aspect you care to imagine.
The trick of course is to recognise (capture) assumptions, analyse them and decide which ones you need to deal with or test. If you cannot deal with them at the time, they may well become risks to your project – and are primary inputs to the risk identification process.
N.B.: we have witnessed many instances where a single assumption was made by the team but not shared with stakeholders (who would have identified that the assumption was false) until much later in the life-cycle, destroying the project’s chances of success, as its consequence was only properly understood far too late. In many cases sharing key assumptions with stakeholders earlier would have completely avoided this situation. (This is not being smart through hindsight; an effective project manager would have challenged this early).
Much has been written over the years on subjects such as critical path and scheduling, which are skills and processes in planning. However, the world of projects has sometimes confused the world of tools with the job of management. A great deal of the responsibility of management requires and relies upon effective communication. Part of the responsibility of PMs is to ensure that all core team members understand and are very aware of the ‘plan’. It is fundamentally useful if in doing this, we also develop commitment or ownership towards the targets within that plan.
Every project should have a means of communicating, preferably graphically, the key targets, responsibilities and actions that are required to achieve the plan. Detailed Gantt charts rarely achieve this and were never really intended to. Summary Gantt charts are OK, or perhaps even better, a series of major and minor milestones that connect the whole wok of the project, which the PM can talk through regularly with the team.
The target should be to capture and communicate the big picture on one page (or a single white-board even), for the purpose of face-to-face communication.
It is often said that communication is the lifeblood of projects. However, communication is also one of the biggest challenges. One area to consider is the degree of face-to-face communication that is employed, versus other more passive forms of communication (e.g. email, video conferencing and other written forms). Relying mainly on passive forms of communication, where face-to-face is limited, is one of the biggest risks you can have – over reliance is highly likely to cause delay, re-work, issues, and stifle the ability of a group of people to get to the point where they operate as a “team”.
You should ensure that all parties are working effectively by formalising ‘ways of working’ on a project. Ways of working can cover a multitude of areas, driven by your circumstances. Ways of working should always cover areas like communication, defining principles and practices for effective communication and team working.
Through the whole life-cycle, unofficial scope creep is one of the most common challenges you will face. It comes in a number of forms: take a good idea and many people will try and add to it all the ideas they’ve had waiting in the wings, many of which will bear no relation to your strategic objectives. Also, requirements gathering phases need to be managed with great discipline, to ensure that again, only requirements that support the project’s strategic objectives are signed off in the baseline requirements.
Exactly the same principle applies to the design and definition of the ‘solution’. In this area, thePM will have to work very closely with others to achieve this.
This requires that there is regular effective communication across the whole team. Choose the most simple but effective means of doing this. Don’t call meetings just to understand status. Only call meetings that decide how to go forward, agreeing responsibilities for actions that support the aims of the project.
To do this, all meetings must be held with a clear understanding of: current plan and status; (significant) issues; status of key risk actions; and most important of all clarity around responsibilities for key activities and actions in the coming period.
On bigger projects especially, this could easily save your bacon. Decision making can often be one of your biggest challenges. If you’re not fully prepared you could be swamped very quickly during the delivery phase. One of the biggest factors in being able to maintain a schedule is the ability to resolve issues – much of which of course is dependent upon decisions.
An issue/ decision management process should address who has a stake in key decisions and who has the final say over the same. That way, when it becomes necessary to escalate or resolve an issue, you have the framework ready to do so. The aim must be to resolve issues effectively and as quickly as you can.
If you have committees involved in these decisions, get to know how they operate, the key players, and make it as clear as you can to them what you require (timescale wise) relating to all key decisions. It may also be prudent to manage this aspect via the risk management process.
As with conflicts, it is the PM’s responsibility to ensure that all significant issues are being managed in line with the needs of the plan.
There will be conflicts on almost every project. Often those conflicts will involve stakeholders – it’s the project manager’s responsibility to ensure that these are: out in the open; understood; clarified; and are being managed. In a sense, he or she must cut through the politics and get the best solution for the owner of the project. Clearly, this can be a very challenging time, and clearly he or she may not be able to deal with these issues on their own – but they must ensure the issues are formally recognised and are being managed.
This is where value and function of the project sponsor can come into play. You may need to work with the sponsor, and perhaps other senior people in the business, to highlight these issues and propose the mechanism for their resolution. In this event, the project manager must highlight to all involved what’s required to maintain the project schedule.
The above is by no means everything that you will face – they are though aspects that a) often challenge projects and b) less experienced PMs will often underestimate.
In addition, if you achieve all of the above, you will have discharged many of your key the responsibilities professionally and with rigour. It is also highly likely that you will get noticed for all the right reasons in your organisation.
Good luck with your role.
Feedback or questions:
Click here for full details of Project Management Training Courses from PMIS.