Service creation project information flow

Visualising service creation project information and making a framework on the topic that has been very lightly touched by academia in the past has turned out to be time consuming pursuit.

Here is the result of my current thinking on the topic.

Service creation project consists of at least of 7 steps. Those steps are:

1. Situation analysis
2. Exploration
3. Concept
4. Decision to invest
5. Implementation initiation
6. Development
7. Commercialization

What makes this whole process worthwile to inspect is that there usually exists a change of personnel in the project around 4th step, the decision to invest. At that point the idea needs more hands to implement. People develop their professional knowledge to either scope customer needs from the haystack of the world or they become masters in some detail of value offering and harvesting.

While the implementation of new services into the organizations current value stream is rather researched, standardised and of constant interest, the earlier phase seeks form in many organizations trying to expand. Academic research observing organizational practice patterns lags further behind and not much has been said about best practices on that topic.

What is of my special interest is the gap emerging from earlier concept making put to an hold and then continued at later date when resources or priorities have changed for the organization. How usable are the concepts and documents created earlier? Is the trail hot anymore? How do the implementers make sure that the concept is still worth pursuing?

There is a bunch of information created during the exploration and concept phases. Customer needs have been identified in detail. Solution space has been tied with prototypes. But no amount of documentation is likely to convey all that information absorbed by the individuals at that stage. The role of the project owner becomes of great importance. They are the people/role who carry vision across the time gap and hold the information that was not written down. Alternatives of groups or persons remaining same in exploration and implementation exists and of course in information-flow-optimal situation they would be the same.

Smaller organizations are almost immune to this problem. Only larger organizations with high division of labour strugle to keep hold of the information that would still be in somebody’s memory.

Border objects, like concept decks, prototypes or working product, become tools to communicate across time and people. They store information in themselves. Several of these border objects exist inside the service creation project and they are used to communicate between people during the project team work. What separates concept/prototype and final product/service from others is that their audience is larger and they communicate outside of the team. Concept/prototype and further analysis of them are used to pass the “money-gate” in step 4. Product/service is used to break trough in the market in step 7.

What makes this interesting from the human-centered design point of view, is that if the customer need is there, you can base your project at any time using 10 randomly selected customers from your very focused target group that you are creating the service for. It is a good practice to iterate with the customers if some information is not passed trough the project team. You should be able to find same indicators as the previous ones. The only reason why some organizations don’t do it, is that they hold such a belief in the stationary nature of knowledge that they try to minimize resource usage by optimising information flow inside the organization between teams. Sometimes it is worth, sometimes the world has changed and new iteration with evolved customer needs is better.