Friday, September 26, 2008

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/

Saturday, September 13, 2008

Yammer & Laconi.ca: Enterprise Status Updates / Microblogging

Within the last week I have started using Yammer, a version of Twitter designed for companies. Yammer is based around the question of “What are you working on?” and the concept of only allowing users from the company's domain (e.g. domain.co.nz) to signup. This provides for an interesting closed community where people are willing to ask questions and have discussions that would not be appropriate to a public community (e.g. "Simon and I are hitting the ABC requirements hard this month... any suggestions/recommendations?").



It has been interesting to watch the viral infiltration of Yammer throughout the company. As people register they are prompted to enter in who they work with @domain ; an email is then sent to these people requesting them to register. Similarly a user can add Org Chart information such as boss, staff, assistant and these people will be sent an invitation to register. Unfortunately the invites are currently marked as Spam by our email system so many people will not be finding their invite that is residing in their Spam folder, but word of mouth is helping to get people onboard.

A number of the people who have signed up to Yammer have not used Twitter or a similar service before, so the concept is new to them and they are feeling their way as to what is appropriate to "yam" (I don't know what the offical term is to send a message on Yammer, but this sounds appropriate) about. It will be interesting to see how people end up using Yammer (if at all), and then whether somebody tries to close it down as not being an official internal communication tool for the company.

The Adobe AIR based desktop client is currently a bit too limited in functionality, but according to the Yammer User Forum an updated tool is on its way. I really like Twhirl for Twitter and have been using this for a while so any other client really needs to match this imho. Ideally I would like to be able to use Twhirl with Yammer.

Some additional functionality of Yammer is available at the cost of US$1 per user / per month, which whilst this might be suitable for a small company, the cost for a larger company will possibly be hard to justify. This is Admin functionality and includes being able to brand Yammer with your company's logo, ability to restrict access to IP address ranges, implement password policies, ban users, delete any messages and delegate Admin functionality.

Another option is Laconi.ca with Twhirl


If this cost makes you cringe or you would like to host a Twitter-like solution yourself, laconi.ca might be suitable for you. With the beta version of twhirl v0.8.5 laconi.ca is also supported as a client.

I think this makes a very attractive alternative for corporates.

The next big question in my mind is, "When will Twitter release group and company-centric functionality?"