Over the years I have found that my most popular blog posts are those that speak to entry-level project managers. They value information which is clear and concise and which helps them understand what tools and techniques to use. Project management is a vast practice area and for somebody who has only recently started managing projects, it can seem overwhelming. It is my observation that there are more entry-level project managers coming into the field. And there is a good reason for that. With more and more changes taking place at a faster rate, we have a need for more people to manage those changes. This can be anything from integrating new technology to streamlining business processes or producing cheaper and better consumer goods. With that being said, let’s look at the three most fundamental project management tools and techniques that will help entry-level project managers get their project off the ground.
Here is an article on project description.
Projects need to be defined and scoped before they are planned and executed. That is true for all projects irrespective of the type of methodology they use. Defining the project helps us understand what it is meant to deliver, what the benefits are, what the costs might be and by when it is needed. This may sound like a plan to you, but it’s more like a high-level description of the project without the details having been fleshed out. The main question we ask during project definition is whether the project is worthwhile doing or not. There may be lots of ideas for new projects but not all of them have a good business rationale. Therefore they shouldn't be executed at this moment in time with this particular scope. In the company where you work, I’m sure there are many things you could improve on and many ways in which you could enhance your products or services. But not all of these enhancements will be viable business ideas, perhaps because there is a small market for some of those products or too low a margin.
When we define the project, we’re essentially looking at the project’s business case and ascertaining if it provides a strong enough foundation for the project to go ahead. Defining the project can take as little as a couple of days for a very small project and several months for a larger one. You can capture the conclusion of this phase in a Project Definition Document, Project Charter, Terms of Reference or Business Case. Different companies use different terms for this document, but they may essentially contain the same information. What I recommend you to put in the document is: Aims and objectives of the project, high-level deliverables, expected benefits, high-level constraints, assumptions and risks, expected costs, future revenues, expected end date, name of project sponsor, project manager, and core team members.
Once the project has been approved, meaning that the Project Definition Document has been signed off, you can move to the next part of the project, which is to plan it. The way you plan a project and lay out its phases, stages, and milestones will look a bit different depending on the methodology your company prefers. If you’re in a more traditional waterfall environment you’d be planning the project in a sequential way, beginning with requirements gathering and detailed statements of scope. You’d then plan for the build or execution phase to take place followed by some testing and final delivery or implantation. And of course, you’d plan for a project review to take place at the end. In more agile environments you’d carry out the above activities (requirements gathering, build, test, deliver, and review) in much shorter intervals or iterations. In addition, you’d deliver something tangible after each phase or iteration instead of all products or features being delivered at the end, which is what we do with a waterfall methodology.
No matter how you plan your project, it’s a good practice to plan it collaboratively with the team. Those days are over where the project manager was sitting in isolation behind their desk doing all the planning. That approach simply doesn't create buy-in from the team members. They want to be involved in planning the work that they are expected to carry out.
There are several collaborative planning techniques out there that you can make use of. I favour an old-fashioned post-it note-approach where you get people together and brainstorm what the phases, work streams and milestones of the project might look like. You’ll need lots of post-its and a white board or a wall to stick the notes onto. You also need a good facilitator (perhaps your good self) who can guide the team through the process. At the end, you should have a rough idea of which milestones and outputs will be delivered by when. You should also assign ownership to each milestone or deliverable as otherwise, the project manager may end up owning most of the items. Ask the owners to carry out the detailed planning of their individual items and revert at the next meeting with a confirmation of exactly what will be delivered by when. If your team is remote you can make use of virtual post-it-note planning tools.
The outcome of your collaborative meetings and planning activities can be captured in a milestone plan. This would be a simple Excel sheet listing the project’s top ten milestones, the owner of each milestone and the expected delivery date. Very simple! As a project moves forward you can also use the spreadsheet to record whether each milestone is on track for delivery and comment on their status. In that way, this simple one-pager overview of milestones becomes a high-level plan and a tracking tool in one. This is an ideal overview sheet to use as a communication tool to your stakeholders so that they can ascertain the status of the project. Your stakeholders don’t need a detailed plan. An overview of the top ten milestones will be sufficient. The detailed plan is reserved for the core team.
Be warned that no matter the size, complexity or methodology of your project, I can assure you that it will be full of risks. That’s because all projects are about creating change, meaning that the project will result in something that hasn’t been done before in that exact setting. In other words, every project is unique and therefore contains a certain element of risk. Project management methodology is essentially there to control risk and to help us execute a project with some level of predictability in spite of its uncertain elements. Defining a project, identifying and analysing user needs and requirements, planning how these requirements will result in outputs and deliveries, clarifying roles and responsibilities and prototyping the solution are all examples of activities we undertake in project management with the aim of driving down risk.
Managing risks is a dynamic process as the project’s environment changes on a daily basis. Identifying and mitigating risks is, therefore, something which shouldn’t just be done when the project starts up. It’s an essential project management activity that should be carried out on a regular basis to make sure that new risks are identified and managed and that the existing ones are reviewed. In essence, I suggest that you sit down with your team every couple of weeks to go through the risk list. The collaborative element is important, as the project manager cannot identify all the risks on her own. The team has the knowledge, not only of the things that could go wrong but also in terms of generating ideas for how to overcome potential roadblocks.
The outcome of the collaborative risk management meetings is risk list. This is a simple Excel tool, which lists and describes all the risks, the date they were logged, what the potential impact of the risk is and how it can be mitigated. The risk list should also contain information about the probability and likelihood of each risk (high, medium, low) as well as an owner. In many projects, there is a tendency that the project manager ends up owning most of the mitigation strategies. But in many cases, a team member or a stakeholder is the best person to manage a specific risk because they are closer to the detail.
Project management tools and techniques can be difficult to navigate for an entry-level project manager. Three of the most important tools for a project manager to make use of on any project are: a Project Definition Document, a Milestone Plan and a Risk List. Whereas the project manager owns all of these tools, it’s not sufficient to simply fill them in on their own. Irrespective of whether we are running an Agile, Waterfall or a hybrid project, it will be the collective effort of the people involved who will get the project delivered. For that reason, the tools we use must be as collaborative as possible so that we can make the most of our precious team.