Life Cycle and Portfolio
Management

A BoF Session on Product management at the TNC2004 9.6.2004

(notes on the session by KH, HK, PL (Funet/CSC, Finland))

1 Topic

The BoF was called to tackle three different aspects of product management:

1) New product development

  • how the development processes are being managed, and;
  • how the quality of new services is being guaranteed

2) Product life cycle planning

  • the time that the service will be offered; or
  • the criteria under which the service will be offered; or
  • checkpoints for the offering of the service

3) Product portfolio management

  • what is the proper set of services for the chosen clientele

These questions have become important in the NRENs for various reasons:

  • services have been quite often offered without contracts or any service description
  • there is a growing need to define services
  • there is a growing need to be flexible to customer needs
  • resources don't grow and therefore reallocation is a must
  • killing services is a pain.

2 Participants

CARnet (Croatia)

  • Zlatko Jelaèić (zlatko.jelacic@carnet.hr)

Funet/CSC (Finland)

  • Kaisa Haapala (kaisa.haapala@csc.fi)
  • Harri Kuusisto (harri.kuusisto@csc.fi)
  • Pekka Linna (pekka.linna@csc.fi)

GRNET (Greece)

  • Ζαχαρόπουλος Δημήτριος, Zacharopoulos Dimitrios (jimmy@ccf.auth.gr)
  • Δημήτριος Αδάμος, Dimitrios Adamos (dadam@ccf.auth.gr)

HEAnet (Ireland)

  • Ann Harding (ann.harding@heanet.ie)

RedIris (Spain)

  • Diego López (diego.lopez@rediris.es)

Rhnet (Iceland)

  • Jón Ingi Einarsson (jie@rhnet.is)

Surfnet (the Netherlands)

  • Maurice v/d Akker (maurice.vandenakker@surfnet.nl)
  • Sandra Passchier (sandra.passchier@surfnet.nl)
  • Elise Roders (elise.roders@surfnet.nl)
  • Jacques Schuurman (jacques.schuurman@surfnet.nl)
  • Ton Verschuren (ton.verschuren@surfnet.nl)

Switch (Switzerland)

  • Urs Eppenberger (eppenberger@switch.ch)

UNINETT (Norway)

  • Lars Skogan (lars@uninett.no)

3 General pressure: funding problems

Almost all participants were reporting either cuts in the centralised funding or difficulties in covering the costs with the fees collected from the customers/users.

4 Life cycle planning - service retirement problems

In the NRENs there are no systems, nor culture for tackling questions of this sort. The necessary efforts in the beginning of the life of a service are typically recognised but not the ones in the end of the life cycle.

In a few NRENs there is an effort to systematise life cycle planning, in some a decision is made upon the delivery of individual services every year.

Need to shut down a service:

  • service no longer supported (and there is a need to maintain good quality in the services because of image reasons)
  • service is not scaling well and the maintenance/support demands a lot of resources

Questions relating to shutting down a service:

  • what is the limit for people objecting (when do you not need to care any more)
  • it takes time to be gentle and this takes resources
  • how to find out the actual need for a specific service (what is the figure that tells the need)

5 Portfolio management - how to meet the needs of the community

Finding out the user/community/customer needs

  • individual customers wish for new services especially when there is no direct (‘favours’)
  • market pull can be sought out with the help of user panels
  • sniffing the air and making educated guesses about the user needs
  • the people that pay your expenses, they tell you what to do (but this is mostly only the ministry that gives extra tasks - not the HE community)

The portfolio cannot be defined (only) based on technological possibilities:

  • Switch-model: mission - clients - technologies - political and economical environment -> strategy (every three years) -> service portfolio
  • SURFnet observation: well-defined new-product -launch system does not guarantee a consistent portfolio that meets the needs of the community: need to find the balance between technology push and market pull
  • there are strategic papers where the tasks/missions of the NRENs are being defined
  • some NRENs negotiate with the local ministry about the services given

Roles of different actors within the NREN in relation to the portfolio

  • who decides what and when
  • not everybody defines an activity to be a service with the same criteria (‘it is only development work / co-operation’)
Some services are not that well recognised as services
  • there is a move from backbone to middleware and applications
  • there is a move from one-way service delivery towards consultation and co-ordination
  • more difficult to get a picture of the whole, more difficult to tackle the needs with the customers (‘would you feel that you need to be co-ordinated?’)

6 New product development - how to launch well-defined services

Switch: AAA-infrastructure service was well defined and different from others. Steering comes from the top down. Also took a very long time that is unusual. The problem now is to get the HEIs to utilize the service and to make it economically sustainable.

SURFnet: A new fairly well-defined framework for new product development: technology assessment / go or no-go / proof of concept / go or no-go / piloting / go or no-go / customer support etc. -> product launch

  • the problems seem to be on the side of portfolio management: what are the criteria for creating a service at all?

UNINETT: Users may think something is a service, when it's not, and in that sense product launch can get out of hand.

CARnet: The problem is pushing the users into using all the services.

7 Contracts and billing

Some of the NRENs do not have service contracts with the HEIs

  • users on top and on the bottom: this takes care of the steering and supervision (HEI representatives are in the board of the NREN)

A change in technology may change the nature of the service so that the old contracts are totally out-dated (e.g. the move to optical networking may cause this)

Users may depend on the service although not much has been promised

  • in this situation there are growing risks for both parties when responsibilities and their limits have not been properly articulated
  • in this situation it might be rational to express the limits of the service: to make a contract in order to avoid conflicts, not just in order to win them

Billing

  • NRENs don’t seem to bill accurately from each customer all the small services that they have been using
SLAs
  • not all the NRENs have SLAs/SLSs
  • instead of SLAs a redundant infrastructure
  • critical services built on the IP-connection, for example phone systems; higher demands on reliability and overall quality

8 Future co-operation

E-mail list

  • Pekka will ask Terena to start a mailing list for this purpose
  • the participants will be added to that list

Future meetings

  • at least in the next Nordunet meeting in Spitsbergen, maybe also before that
  • more discussion on the mailing list