The Panic Guys build an amazing project status board using CSS/HTML and display a bunch of internal stats about each project. They reported that it provided an amazing degree of collaboration they never had before because all the information was always in view and held each team accountable. Some of the the most important numbers are at the top where the support queue depths are displayed at all times. The middle shows project due dates and currently assigned members. The bottom shows key metrics and bus schedules when it is time to go home. A very nice idea!

[From Panic Blog » The Panic Status Board]

Channels:

1. Phone
2. Web
3. Email
4. Instant Messaging

Service Providers:

1. IT
2. Project Managers
3. Finance
4. Procurement
5. User Acceptance Testing

Key aspects of providing a clearly defined service:

• The User of the services needs a clear way to use each of the channels to reach the service provider.
• Where the user consumes the service the service must be clearly defined and provide “hints” to the User so they can provide required information so the service provider upfront. The “hints” must be in end user terms.
• All requests for service need to be queued and prioritized. Think about how many services are provided via email and the disaster which occurs when your inbox is full of responses to questions. You can no longer keep the queue straight.
• The execution details of actually executing the service should be hidden from the User. For example the User isn’t interested in the detailed tasks or collaborations which are required to dig into a capacity request and provide a response.
• There should be only one place all the channels end so users can always have a consistent experience.
• The user should have the ability to switch channels during service acquisition. For example, they may start by submitting a request on the web, but they may discover that the priority needs to be escalated. The User should be able to get a Service Desk Analyst on the phone and discuss how to escalate.
• At the end of the service the user should be surveyed to understand their satisfaction with the service. The survey results should be used to provide continuous improvement to the service structure.

Components of a well defined service:

• Service Description – An end user focused description of what they will receive as a result of requesting the service to be performed.
• Service Requirements – An end user focused script which leads the User through a set of questions which help discover requirements needed for the Service Provider. The better this script is the less times the Service Provider will need to consult with the user to clear up what is required. Continuous improvement is key in this space to reduce cost.
• Pre-defined service Execution Plan – A set of repeatable tasks which the service provider will use to deliver the service. The tasks provide a vehicle to deliver the service the same way every time with lower risk. Lessons learned and review of the tasks at a frequent interval should help drive down cost and remove errors which may occur.
• Clear Approval Process – The approval process for Service Execution should be pre-defined and the approvers should be pre-defined.
• SLA – A clear Service Level Agreement will help the user understand when they should expect the service execution to be complete. This reduces unnecessary queries to the service provider. These queries are a critical distraction.

Service Pipeline:

Channel -> Service Request -> Change Request

Service Contact Flow:

User -> Service Desk -> Service Owner -> Approver -> Specialist -> Service Desk -> User

What would have really knocked my socks off would have been a mixed mode web 2.0 synchonization story and a powerful P2P play which would have enabled desktops to work together over adhock wired and wireless networks.  How often are we in a conference room and we are trying to exchange files which might be stored on a web site, but oops we don’t have a connection.  However, a bit of P2P magic over an adhoc P2P network would solve it.  Now that is a Mesh story.

Perhaps, the real play is coming, with a true free Groove collaboration and Mesh integrated vision.  For now, it sounds like just another synchonization service.