Clarity of Roles & Responsibilities is Essential

I have observed numerous times that a number of the key challenges encountered by many projects often boil down to one key root issue: Lack of Clarity around Roles & Responsibilities.

There are many facets of Roles & Responsibilities, each of which need to be clearly communicated, including:

• People - who is responsible for what, and what deliverables are they tasked with. This may be an individual, group or project.


• Technology - what is the responsibility of a particular technology component (or sub component) that is to be delivered as part of the solution. This needs to be addressed from a logical component (e.g. CRM) and a system perspective (e.g. Siebel).


• Process - From a project delivery perspective, who is doing what tasks and what are the dependencies and constraints. In terms of implementing business processes or activities, what technology component(s) will be realising this.

Of the above, I have found that People and Technology are the key areas that need to be focussed on. Process does however help to glue everything together and identify gaps, primarily because it is looking at the solution delivery from a different perspective.

People

I have found that addressing the People aspect from a high level "RASCI" and a more focussed "Statement of Work" perspective works well, and helps to drive increased clarity early on.

RASCI

RASCI models are very useful in terms of communicating in a simple manner where different People fit in and provides a high level overview of key stakeholders. For each deliverable it is worth defining the RASCI model:

• Responsible - Who makes it happen?
  
• Approve - Who needs to approve this?
  
• Support - Who provides the expertise?
  
• Consult - Who can add value?
  
• Inform - Who needs to know?

There should only be one person Responsible, and any more than one Approver can be troublesome and for me raises alarm bells. For the other roles it is perfectly fine to have more people.

Statement of Work

In addition to RASCI models it is a good idea to have a "Statement of Work" established with each Individual, Group or Project. The key purpose of this is to clearly articulate what your expectations of them, and when you are expecting various deliverables by. I often do this via an email message asking them to confirm that they agree. Sometimes these are for a particular deliverable, sometimes it is broader and more of an overall engagement consisting of multiple deliverables to support an outcome. Sometimes there is a bit of to-and-fro, but in the end all parties have increased clarity as to what is going on.

Technology

Understanding the role each system plays in the architecture for each release of a project is key to providing focus, identifying the right people to get on board, and is often a key input into a Statement of Work (in particular for engaging an external delivery partner).

There are many approaches that can be used to determine the roles & responsibilities of a system, but typically starting off with a logical component view and then doing a system view is a good way to reduce existing system constraints polluting the architecture. Running Use Cases through these views also helps to prove the architecture (on paper at least). It is also often just as important to be explicit about what the component or system will not do.

Process

Who is doing what tasks, dependencies and constraints can be well represented by a Gantt chart (or similar method). This helps to provide visibility of the tasks required to complete each deliverable and where it all comes together.

Going through business requirements line by line can be a tedious task (in particular when the document is 299 pages long like the one currently on my desk) and even more tedious is providing full traceability through to each system component to show where a requirement is being delivered. Whilst this provides great visibility for which requirements a particular component has a role in fulfilling, and being able to rapidly assess the impact of requirement changes, I have yet to see this managed well either during or post project implementation. I therefore tend to adopt a less rigorous approach to business requirements mapping and tend to use it as a cross check once the solutions are quite well evolved and essentially just tick off each requirement. Maybe I should revisit this approach...

Photo Attribution: Published with permission from unplain-jane http://www.flickr.com/photos/unplain-jane/