Hit the Ground Running with a Badge, a Laptop and a RACI Matrix
As a consultant one of the things I most enjoy about the job is the variety of both roles and clients. Nothing is ever exactly the same as the previous project and I have been able to work in a number of different industries. However, starting a new project at a new client does have its challenges. Not only must you figure out where the closest printer is and how to work the coffee maker, but you need to understand what the work entails and how best to do it. There are a couple of tools and techniques I have found helpful to make the first few weeks productive and set up for success. These tools are helpful whether you are brand new at a company or are starting a new project at the company you have worked at for 20 years.
It may seem obvious, but one of the most important steps when beginning a project is to understand the goal. Many times, the first impression of the project based on an email or short conversation with your manager is different than the end result. To gain a better understanding of what the end result will be, I suggest you examine project initiation documents such as the project charter, project scope document, or statement of work (SOW). As a business analyst I will elicit the requirements of the solution from the stakeholders. These initiation documents contain a number of high-level requirements that are a great starting point for developing detailed business requirements. Those high-level requirements can be put into your business requirements document so there will be traceability back to the business objectives and these project initiation documents will give you a great frame and establish boundaries for your work.
On a recent project I had the role of Implementation Analyst, where I was responsible for gathering requirements from the external customer directly and gathering additional requirements and reviewing the external customer requirements with internal stakeholders. The organization was less formal and the roles of the various stakeholders were not strictly defined. As a new person in the organization and project team, I wanted to understand who all the stakeholders were and how I would be interacting with them. I created a RACI matrix to document my understanding of all the key stakeholders within the project. RACI stands for Responsible, Accountable/Approver, Consulted, and Informed. The RACI matrix creates a reference of stakeholders, roles, and the major deliverables or tasks to provide information about who is responsible for specific duties. Each stakeholder on the project, both internal and external, should be listed and defined in an individual row. For each stakeholder or stakeholder group, it is also important to list their role on the project. The columns list the major deliverables or tasks on the project. In the cells of the matrix are placed R, A, C, or I. There does not have to be a letter in every cell. For instance, as the business analyst, I would list myself as Responsible for the business requirements document deliverable. In a traditional RACI Matrix there is only one person Accountable/Approver for a given deliverable, and that may be the product owner or main customer representative. However, there are a number of people Consulted when creating the requirements document. This would include customers and subject matter experts. Finally, those who are Informed would include stakeholders such as the QA or training lead. The RACI Matrix is a great and simple tool to reference throughout the project. It defines your responsibilities and who should be included in the creation of any deliverable.
Reviewing the initiating project documentation and creating a RACI matrix are two ways to gain valuable knowledge early in the project. They are both fairly easy things to create, but provide lasting benefit. No matter the culture of the organization or the scope of the project, these items are applicable and helpful.