Project managers don’t have a crystal ball, but they do have experience…….
As with any body of work, project managers need to learn from every experience, good or bad. When issues occur on projects people are often puzzled at how they happened in the first place. There are a few occupational hazards that come with the territory of being a project manager. If you don’t get the basics right, you will have issues might have issues.
In many ways it’s like an electrician not taking the correct safety precaution and getting electric shock and wondering why. In many organizations today there is an over reliance on procedures and templates, and this is someway is contributing to experienced project managers reducing reliance on their own knowledge and experiences. In this article we discuss some common problems and how to anticipate and even prevent them from disrupting your project.
Roles and responsibilities
At the risk of sounding like a statement from the Project Management 101, this is a recurring issue that we are seeing constantly. At project initiation as responsibilities matrix is (or should be) drawn up. This should be as high level or as detailed as it needs to be. Every line item on the project plan needs to have an owner and may need a supporting cast in order to complete the task. The RASCI (Responsible, Accountable, Supportive, Consulted and Informed) matrix is a key document here. It is however generally underutilized. It is normally completed at the beginning of a project and not touched again. On a long-term project anything can change, and therefore the roles may need to change to adapt and ensure the same level of ownership.
At the first sign that people are unsure a bout their role on the project, e.g. someone may state “I wasn’t aware that this was my responsibility.” – Stand everyone down, get into a room and review the RASCI against the subject matter. Something new may have been introduced to the project so you need to update the RASCI based on the newly acquired knowledge and ensure everyone is aligned and clear on the content. If anyone else makes that same statement at any stage during the project, repeat the process.
If you let these types of issues fester. They will lead to one or more items being left undone or neglected to the point it causes a delay or a bigger issue down the line.
Change of personnel
We plan and execute projects with the knowledge we have at a point in time. If we have new information, we may need to re-plan, do things differently and re-think the project. Projects are not immune to personnel changes, people move jobs all the time, people become ill, people take holidays, people have unexpected log term absences from work. So, we need to build this in at the start.
Some roles may be more important on a project than others, i.e. if they leave during the project the impact will be bigger and more sustained. In large organizations priorities change all the time and it is not unknown that people can be re-assigned to other projects or other work.
So, again we use the basic foundations of all projects – the RAID log. (Risks, Assumptions, Issues, Decisions), and the RASCI as mentioned above. As a brief example, we place a risk in the log under “Resources” that if the Business analyst is removed from the project, there will be a negative impact, time or budget. We accept and agree this as a medium risk. We also need to asses the risk regularly. We could also log this as an assumption at the beginning that all personnel will remain on the team. If the Business Analyst is moved or seconded to other work, then you need to re-assess the risk, and move it to the issues log.
Before this happens, you need to make the impact clear to the decision makers. The RAID log is the perfect vehicle for this, and if it has been captured accurately, then the decision makers will accept they understand the impact of moving the person to another role outside the project. We may then need to record the decision in the Decision section of the RAID log. This will avoid any blame or unnecessary attention on the project team later. The decision log will be clear on who made the decision and why, therefore no surprises. This practice is particularly helpful in organizations that are prone to outbreaks of project amnesia from time to time.
There will always be unexpected personnel changes that you can’t see coming. To minimize the negative impact of these issues, you must ensure that all project documentation and material is accessible, clearly indexed and shared with the entire project team. There may also be a need to review the RASCI temporarily until a suitable replacement can be found.
Making sure there are no key documents stored on local hard drives, personal spreadsheets is key here. Insist upon and check regularly that shared network drives and folders are used, task management apps and plans are updated regularly and not stored locally.
Probably the biggest pet hate of most project managers, deadlines can be missed when they are missed, you need to get the bottom of it fast. You also need to have a strong culture of communication to give an early warning. During initial planning, you must look at all possibilities in how you can best achieve your targets. As the project manager you have an obligation to maintain focus on the end goals and be relentless in the removal of actual or potential obstacles that could get in the way.
During planning you paved the steps to necessary to reach each milestone. If any of those steps are delayed, the chances are that the milestone to which this step is contributing will be delayed.
The advice here is simple, if you miss a small deadline, you have a couple of options – re-plan and push the main milestone out or re-group and try to recover.
You can read more about this in the following blog:
The simple advice here is you need to make it difficult for people to change the scope of work and create scope creep. If you make it too easy for people to at work to your project while not reviewing the impact of this extra scope, they will keep on piling it on until it becomes unsustainable.
If someone requests something extra that is outside of the original scope you need to make them work for it. Extra scope will impact cost, schedule and complexity. So, utilize the project change process. Ask the requester to book some time with your best business analyst to gather their requirements. Make a detailed assessment and then get back to the requester with the impact in simple metrics of cost and time etc. If a decision is made to proceed, then the project change control process must be followed to approve the change before adopting it in to your scope of work. You can then re-plan. For more reading on controlling scope creep, see this previous article:
Communication is key to the success of any project. This is how you find out about any potential issues in advance of them becoming a big problem. Communicate often and in small bursts. Maintain team meetings weekly, talk 1:1 with team members at every opportunity. Look out for any signs of friction between the team and deal with them promptly. Ensure that all team members know that they can call you at any stage for a chat to discuss anything that may have an impact on the project.
Communicate clearly and ask for feedback. Utilize the multiple forums and tools at your disposal and make it easy for people to give feedback and make suggestions. When running project meetings and status updates, read between the lines to understand what is really going on outside of the official conversations.
This article provides more information on this topic:
What we’re saying here is that most project problems when examined could have been prevented or have had their impact reduced by following many of the basic foundations of project management. You cannot prevent every problem, but you can learn from previous experiences and certainly reduce repetitions of previous problems.