Tips for Project Managers
Hints and Tips for Project Managers – for Beginners & Experienced
Being the manager of a project of significant scale and importance could be one of the most rewarding things you do in your career. It could also be one of the most demanding. Projects can be very challenging and the role of the project manager (PM) is crucial. A skilled PM can make all the difference.
All the following project management tips come from real-world projects. Not textbooks.
The following tips cover many of the most common issues found on projects and are drawn from decades of experience.
If you are already an experienced Project Manager, why not ask yourself “how often do we do what follows really well?”.
The first tip is to make responsibilities crystal clear across the entire team including the PM. If you ask more than one person what the job (responsibility) of a PM is you’ll get significant differences in their answers.
Therefore, never assume anything in this area. So, one of the first things to do is to agree and make your responsibilities clear, especially with people like your sponsor. Also, it must be stated in simple 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 very slowly. When this happens, on its own it can cause serious issues.
Exactly the same principle applies to the team. As team members are appointed (or even if they are 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.
Pay particular attention to their responsibilities relating to producing or defining key inputs (e.g. requirements) or reviewing outputs (specifications, documents, deliverables, etc.). Try as far as possible to get what we call input-oriented requirements/expectations, rather than just feedback after a development activity is done.
The second tip is regardless of what it is called, is that the first stage of every project is always the most important.
Most of your important decisions will happen in this initial stage. Many of these decisions will have a huge influence on your eventual success. It is also the point where we have the maximum chance to influence any aspect and to sow the seeds of success as opposed to something else.
One of the biggest challenges (and most important tasks) you will do is to get all stakeholders to engage actively during this stage (and to commit to the level of effort/input which is required). If you are struggling to achieve this you should consider very seriously whether you can proceed to the next stages at all.
And this point is massive. Rushing through or skimping the activities of agreeing unambiguously the objectives/outcomes/ key requirements/expectations with all stakeholders will not ultimately save time or effort. If this happens, it will significantly raise the probability of very serious issues downstream.
Asking fundamental questions should never be seen 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 your sponsor/customer.
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 and expectations.
You should anticipate finding different and even conflicting expectations and needs across stakeholders. The time to understand and resolve this as far as you can is at the start.
This is one of the most important tasks you will do. Ensuring where issues or possible conflicts happen, they are being tackled openly and in a transparent manner. If necessary, with the support of the sponsor.
There’s a lot written about project ‘deliverables’, and this is entirely correct.
This is, without doubt, the most important task you do, especially on internal business projects, where too often it is assumed that they are a) clear, or b) agreed (when in fact the opposite may be true).
Once again, without testing this with the right people at the start, can allow damaging assumptions or even worse to exist. Potentially catastrophic in itself.
It is also very important to communicate the objectives and target benefits 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; targets; key strategic decisions; key assumptions; constraints; and risk mitigation strategies.
The delivery strategy should be captured in a format that can be used easily as a way to communicate to anyone: a) what the project is all about; and b) how it will 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 major project around the globe carries risks and assumptions. For example, dependencies can be real drivers of 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 success.
Recording and sharing assumptions, risks and dependencies within the definition phase is a hugely valuable exercise. The next task is to develop 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 important things any PM can do.
Again, this must be done in the definition stage. We can’t define, plan and launch and only then start to give serious attention to risk. It must be addressed as a central part of definition and planning and most especially at every major decision point/commitment.
The PM must make sure that this is done, even when others do not wish to hear what it produces. Otherwise, there is a very high chance of counting the cost in time (delays) and effort (increased cost) downstream.
There are also numerous proverbs relating to PM and many relate to the incidence and power of assumptions.
Whenever we plan something new, we have to make assumptions. For example, every unanswered question leads to the potential for assumptions.
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 changing something, and is often exaggerated by the way we communicate important elements of the project. This principle can be extended to any aspect, e.g. the objectives; outcomes; solutions; benefits; deliverables; especially the responsibilities; resources. Any aspect you care to imagine.
The trick, of course, is to recognise (capture) assumptions. Then 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. They then become primary inputs to the risk identification process.
N.B.: we have witnessed many instances where assumptions were made by the team but not shared with stakeholders (who would have identified that the assumption was false) until late in the project. This alone can destroy the chances of success, as the impact will only be understood when it is too late. In many cases sharing key assumptions with stakeholders earlier would completely avoid this situation. (This is not being smart through hindsight; an experienced PM would always do 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.
You should communicate preferably graphically, the key targets, responsibilities and actions 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 work of the project. This can be used by the PM to talk through regularly with the team.
The goal should be to present the big picture on one page (or a single whiteboard), for the purpose of two-way communication and decision-making.
Communication is the lifeblood of projects. However, communication is also one of the biggest challenges.
One area to consider is the degree of two-way communication that is employed, versus other more passive forms of communication (e.g. email, and all other written material). Relying mainly on passive forms of communication, where two-way is limited, is one of the biggest risks you will have. Over-reliance on one-way communication is highly likely to cause delays, re-work, and issues. It will also stifle the ability of a group of people to reach the point where they operate as a “team”.
You should ensure that all parties are working effectively by agreeing on ‘ways of working’ for the whole team. Ways of working can cover a multitude of areas, driven by your circumstances. Ways of working should always cover areas like communication, capturing principles and practices for effective communication and team working.
Another very important tip throughout the whole life cycle relates to unofficial scope creep. It can be 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 activities need to be managed with great discipline. You must ensure that only requirements that support your 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, the PM 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 the status. Only call meetings that decide how to go forward, agreeing on responsibilities for actions that support the aims of the project.
To do this, all meetings must be held with a clear understanding of: the 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 already prepared you may 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 quickly. Much of which of course is dependent upon decision-making.
An issue/ decision management process should cover who has a stake in key decisions and who has the final say over the same. That way, when it becomes necessary to escalate an issue, you have the framework ready to do this. The aim must be to resolve issues effectively and as quickly as you can.
If you have committees making 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.
Expect conflicts, especially between different stakeholders.
It’s the PM’s responsibility to ensure that these are: out in the open; understood; clarified; and managed.
In a sense, the PM must cut through the politics and get the best solution. 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. The PM must though ensure that issues are openly acknowledged and managed.
This is where the value of the 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 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 responsibilities professionally and with rigour.
It is also highly likely that you will be 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.