The PMBOK(Project Management Book of Knowledge) specifies that a typical project manager spends 90% of his/her communicating. While this seems really high considering the grocery list of other items the PM is responsible for however, the PMBOK is right. A project manager should always ensure that there is information available to every stakeholder on the project. Stakeholders here refer to everyone who is interested in will be impacted by the project outcome which including vendors, contractors, executives and team members.
There are several ways a project manager can ensure information is available in real time to all stakeholders. Besides sending emails and instant messages to members, I find that curating information in a central location ensures that anyone interested in getting information can find them when needed. A method, I have used successfully for several years is to maintain a well structured/labelled repository of all key project artifacts.
“The single biggest problem in communication is the illusion that it has taken place.”– George Bernard Shaw
I have included a list of PM artifacts that I maintain for all of my projects.
- Kick-Off Deck- The kickoff deck is used in the project initiation phase to set expectation for the project.
- Project Charter: If your project has a project charter, it would be nice to make it readily available for reference purposes
- Signed Statement of Work/Contract
- Project Management Plan- For me, this is an MS Excel or PDF export of the detailed task plan from MS Project comprising of the dates, duration, resources, dependencies and comments where necessary. I also make sure to update new versions as change
- Work Breakdown Structure (WBS)
- Change Management Plan: My change management plan usually consists of 2 major items. The first is the process for introducing changes such as additional scope of work into the current contract. The second is the strategy for introducing a newly implemented technology to the organization. It includes meetings, workshops, training schedules, agenda etc
- Communications Plan: The Communication plan documents the strategy for disseminating information to all stakeholders on the project. Includes frequency, mode of engagement (email, meetings, calls) and type of information.
- Risk Register- Risks are any events that might happen and can impact the project outcome. They can be either positive or negative. The risk register lists out these risks, impact; likelihood to occur; plan to either mitigated, avoid, accept or transfer. The risk register is a living document therefore it is updated as new risk are identified and old risk are tackled.
- Issue Log– Issue log contains a list of issues experienced on the project along with assigned owners, due dates, actions taken and status. Like the action item list, the issue log is a living document where issues are logged as they come and crossed out as they are completed.
- Action Item List: Action items are more or less like a to do list- specific items that need to be taken care of . I like to maintain a growing list of these action items along with the assigned owners, due dates, actions taken and status. I cross out any action items as soon as they are completed.
- Project Schedule: For some people, the project schedule is same as the project plan depending what planning software they are using. This could be in form a of gantt chart or table with the high level task listed and a mark to indicate the project is on the schedule.
- Status Report Deck: I like to curate my past status reports deck in a centralize location so that it can be referenced from time to time.
- Responsibility Assignment Matrix (RACI): The responsibility matrix outlines key project responsibilities on the project and who should be responsible, accountable, a contributor or informed. It ensures that all key projects tasks have owners and avoids finger pointing exercises which can quickly derail a project.
- Database of Lessons Learned: Lessons learned data is an organization asset that can be used as a baseline for risk assessment. Knowledge of lessons learned from past projects prepare a team on expected risk and how to tackle them.
- Stakeholder Register: Stakeholders are any person or group of persons interested in or will be affected by the project out come. My stakeholder register usually consists of the Name, Title, Responsibility, contact information, Mode of Communication, Interest, Influence, Impact and any other relevant info on the stakeholder. Maintaining a stakeholder register provides visibility for everyone on why, where, how, who is interested in the project success
- Meeting Notes- I also like to store past meeting notes in the repository for reference. It comes very handy when there is a dispute as to what was discussed and agreed upon during meeting. It also allows invitees who were unable to attend the meetings to have something to look back to.
- Steering committee meeting deck- The Steering Committee deck is slightly different from the weekly status reporting deck. Steering committee meetings do not usually happen as often as the status meetings therefore some additional information about the history of the project might be required. From my experience, a steering committee meeting holds once monthly and sometimes quarterly depending on the duration of the project. This meeting caters to the project executives (key decision makers) who are not involved in the day to day but are interested in the project success. They are usually the CTO, CFO, CEOs etc.
- Project Specific Artifacts/ Deliverables such as documents describing requirements and architectures, test plans, test outputs, source code files, manuals, and support scripts
These documents can be shared in a central repository such as Confluence, Github, Sharepoint, Box or even an organization’s intranet web page.
You also want to ensure that there are different levels of access for each team member on these site. Documents like Statement of Work (SOW)/Contract should not be editable by anyone and should be stored as read only. You also want to restrict access to certain documents from some stakeholders. Only projects, I always make sure to restrict access to my financial documents especially to vendors. For this reason, you can assign read only/viewer access; updater access, Owner and Co-owner accesses depending on the repository you are using.
Finally, make sure to distinguish between artifacts that are for public viewing and those for your personal consumption. For example, the stakeholder register is for public viewing while the Stakeholder analysis is for personal consumption.