1. Life Cycle and Portfolio Management
Why should NRENs bother at all?
TERENA General Assembly, Catania, 18 May 2006
Hello everybody
I did not expect to be at a GA so soon again. Thanks for the invitation.
Currently I‘m heading the domain name registration at SWITCH. This is a very fascinating job. One of the changes is, that I have more from lawyers in my inbox than spam.

2. Life Cycle and Portfolio Management
Terminology
Life Cycle and Portfolio Management
Product Life Cycle Management
Lifecycle management steers the process in which a concept evolves into a new service, including the ensuing production phase and the phase in which a service is closed down
Product Portfolio Management
Let‘s start with a definition of life cycle and portfolio management.
These two areas are well known and understood in industry
Although the terms might be new to some of you, what there is behind is not new. We just use other words.
Our product life cycle starts with a project. At some stage it migrates to a service, generally reluctantly.
And we DO have a list of the services we offer. We just do not call it portfolio.
If we understand how to map our own terminology to the one used in industry, we can tap into the vast know-how out there.
We will now look together at our own NREN and how it develops services from different angles. It helps to be far away from home at such a very nice place here.
I will very much simplify things. This is mainly meant to provoke some thought on your side. It is not a tutorial on how to make it better or as a set of rules all NRENs have to follow.
Portfolio management is steering the process that should result in a well-balanced and well-aligned set of services, offered to the connected institutions

3. The Life of Sir Viss at an NREN
The cool open source tool Sir Viss is announced
A NREN staff member untars the piece and gets Sir Viss running
He shows Sir Viss to some colleagues at University IT departments
He convinces his boss, that Sir Viss is cheap to operate and that Universities are interested in Sir Viss
So Sir Viss becomes the official status as an NREN Sir Viss
And Sir Viss lifes forever
Here is the first example of how a service is developed
(*** 2 mal selber lesen um lange genug zu warten!!! ***)
(*** letzter Schritt ist ‚And Sir Viss lifes forever‘ ***)
Does this sound familiar?
Let‘s have a look from another angle:

4. Technology Push versus Demand Pull
Your logo here
NREN
User
It is about the difference between technology push versus demand pull.
You might have heared these terms already during the conference.
At the bottom we have the User.
And at the top there is an NREN offering services to the user.
(***Click
Yes, your logo should go here. I just take the one of SWITCH.
(Click***

5. Technology Push versus Demand Pull
more features
higher availability
new services
things we want to push
things we feel necessary
things we got funded to do
User
The technology push side works as follows:
We offer the services we want the user to use
We offer the services we feel are necessary
And we offer the services we got funded to offer
Generally there are enough resources to do this.
Now the user gets used to this. He learns to use the services and starts to ask
for more features
(***click: For higher availability
(***click: Even for new services
(***click: And quite often for this side of the game there are not enough resources
In the SWITCH case this is logical. Our foundation is there to foster new communication technology for research and education. Our foundation document does NOT mention that we have to listen to the users.
OK, we learned that it is helpful to listen, because this makes our technology push mission easier to fulfill.
Do you have time for another viewpoint?
not enough resources
generally enough resources

6. Another view at new services
EU/national funding bodies
fund
new
projects
offer
innovative
services
User
Here we go:
It is the MISSION of the NREN to offer new and innovative services to the national research and education community.
And it is the strategic goal of national or even EU funding bodies to become the most advanced global economy, so they fund research and development projects.
At some stage the users have enough it. Most of them do not need glorious HD TV video conferencing, IPv6 or Teragrid-computing.
So the NRENs have a problem fulfilling their own mission

7. Another view at new services
EU/national funding bodies
Funding
request
fund
new
projects
need
offer
innovative
services
demanding
User
The solution was to look out for the demanding user
And luckily we found some.
(*** click
We helped them to formulate their need
And with this we found additional arguments for funding requests

8. Another view at new services
EU/national funding bodies
Pros:
Works for 2-3 years
Cons:
High cost
Small customer base
Stochastic portfolio
fund
new
projects
Funding
request
offer
innovative
services
need
demanding
User
Now this works well for about 2-3 years. This is the time given by the funding bodies to establish the new service. Then funding generally stops.
What the NREN ends up with is a cost intensive leading edge service for a very small customer base.
Since we have based the service on the request of specific demanding users, we end up with a stochastic portfolio. That term has been created quite fittingly by Tarmo Asnaar from EEnet.
Let me expand a little bit on this:
I think it is not too bad on the lower layers. We have IP with global connectivity for all our users. This is what they need and this is what most of them even agree to pay for. This basic service has a few added options for our demanding users. I think the portfolio on the lower layers is quite comprehensive. And we have good processes to evolve it where necessary.
But on the upper layers there is a complete mess. A service here and a service there with very rarely any notion of building a complete set for the user. I do now, that this set needs to be offered by the local IT departement. But do we work close enough toghether here? Is it possible at all?
And there is another comment to make: Now that we have a high cost small userbase service, we need to fix this. The usual way would be to expand the user base and lower the cost by normalizing the service. But this needs more effort exactly at the time when the funding stopped.

9. The classical model (Theodore Levitt – 1965) Producer Consumer
Product Customer Value
Pricing Costs
Place Convenience
Promotion Communication
Service Sales
Time
Introduction
Growth
Maturity
Decline
I do not want to end my talk with these depressive remarks.
So we continue our series and look at our service development from yet another angle.
This is the classical marketing model by Theodore Levitt. It shows the life of a service in four stages.
I stole these slides from Zbigniew of PSNC.
To the right there is a table called the marketing mix, the four Ps and the four Cs.
The Producer has a focus on the product itself, the consumer mainly wants to satisfy a requirement if he buys it.
The producer thinks carefully about the pricing, and the consumer basically checks the cost
The producer needs to think at where to offer the product, what distribution channels to use, and the consumer just wants to get the product at a convenient place.
The producer thinks about promotion to let the users know about the product, the consumer is more focused on the communication with the seller, if at all.
(Theodore Levitt – 1965)

10. Introduction stage
Building service awareness and develop market for the product:
Product: branding and quality level established,
Pricing: low penetration pricing or high skim pricing
Distribution: selective until the product is accepted
Promotion: aimed at innovators and early adopters – building awareness and learning
Services Sales
Time
Introduction
Growth
Maturity
Decline
Now lets have a look at the stages and focus on the four Ps:
In the introduction stage we build a new service and look out for customers.
The service is designed, we know how to call it and we now how to offer it and at what quality level.
For the pricing: in industry they go either for a very cheap introduction price and practically hand it our for free or at a very high price if they have an established brand. In our case it is generally for free since it is funded at that stage.
We focus the service at pilot users or early adopters and promote the service to build awareness

11. Growth Stage
Building the brand preference and increasing the market share:
Product: maintaining the quality, additional features and services may be added
Pricing: maintaining the initial strategy
Distribution: new channels are added, demand is increasing
Promotion: aimed at broader audience
Services Sales
Time
Introduction
Growth
Maturity
Decline
Now the users start to take up the service
Often you do not even need to add new functionality. You do this only if you have left out some of the functions to speed up development time.
With the pricing you stay with the initial strategy
And you add more distribution channels since you want to broaden the user community

12. Maturity Stage Defending the market share while maximizing profit:
Services Sales
Defending the market share while maximizing profit:
Product: feature may be enhanced to differentiate the product from that of competitors
Pricing: lower because of the competition
Distribution: more intensive, some incenitves offered
Promotion: emphasizes the product differentiation
Time
Introduction
Growth
Maturity
Decline
With a well established service in industry you have a cash cow here.
At that time others know how to offer this service too, so the competition starts.
You add features to differentiate from your competitor and you lower the price.

13. Decline Stage Sale is declining so there are several options:
Services Sales
Sale is declining so there are several options:
Maintain the product, possibly rejuvenating it by adding new features and finding new uses
Reduce costs and continue the offer
Discontinue the product
Time
Introduction
Growth
Maturity
Decline
At the end users move to other services and you have to make a choice here if you want to discontinue the service or to put the effort at a very minimum and continue without new features.
OK, we have gone through all this, because I wanted to give you some material to think about when you introduce new services. You will have to find the solutions which best fit your customers and your political and funding situation.
In the TERENA task force on life cycle and portfolio management we just started the exchange of these thoughts.
We detect new things as we talk together. It is impossible to put this into deliverables at that stage. Or you might call this talk a deliverable, if you like it.
That is why we had to think very hard, what presentable value can we offer to our bosses and to TERENA to justify the task force.
Logically we looked at the life cycle of a service again.

14. Life cycle of a service Life- Cycle Technology Scouting --------------
Scoping of
Customer
Requirements
Impact
Analysis
Service-
development
Service-
production
Service-
shut-down
Technology-
development
Customer
requirements
Yeah, this is another graph I have stolen, this time from Walter van Dijk from Surfnet.
The stages presented here compress the four stages from the previous model into the last three to your right.
The first two stages are new and for us important too. They are unseen to the customer because there are no users, not even pilot users in these stages.
Maybe you print this out and nail it to a wall in your office. 1 2 3 4 5
Research
study
Service-
development
plan
Start of
service
Service
discontinuance
plan
Turn-off
service

15. Areas of potential synergies
Joint Development?
Synchronisation?
Life-
Cycle
What is promising?
Technology
Scouting
Scoping of
Customer
Requirements
Impact
Analysis
Service-
development
Service-
production
Service-
shut-down
Requirements?
If we take the product life cycle model, we have several areas where we can work together and have synergies between the NRENs.
Watching the technology development in all important areas IS EXPENSIVE. Either you have a number of experts who can devote some of their time to this, or you buy documents from consulting companies. Since we are not competitors here, it is easy to share this information. This conference is one of the places to do this.
We offer our services to more or less the same type of users. If one NREN does a user survey, this can easily be used by the others, since the requirements will not differ very much. In the worst case it helps to ask better questions to your local users.
Once we know what they need it might be possible to jointly develop services. Eduroam is one very good example here. Maybe we will find others in the future.
Another option for synergies is the joint operation of services. One NREN could buy it from another, like Surfnet buys the sourceforge service from SWITCH. Or some NRENs pool their buying power together, like they did for the server certificate service.
At the end a synchronised shutdown might give better arguments towards your users.
Joint Operation?

16. Deliverables Joint Development? Synchronisation? What is promising?
Life-
Cycle
What is promising?
Technology
Scouting
Scoping of
Customer
Requirements
Impact
Analysis
Service-
development
Service-
production
Service-
shut-down
BoF on new Ideas:
low profile, first contact, no blame
20 attendees
Here we have three concrete deliverables we are working on:
The first one is a BoF on new ideas. Generally when we have a BoF, the topic is clear and the whole BoF is dedicated to that single topic. We want a much lower profile, where people can share ideas using one or two slides. They might not know if this is going to work at all. It is better not to show it to the customers or the funding bodies yet, but it makes sense to discuss it with colleagues from other NRENs.
We found that if we want to pool our resources, we need to have a better understanding what services are provided by the NRENs. We do have an excellent compendium which provides us with some answers. We will be working together with the compendium team to make the service questions more useful.
With the full lists of services each NREN can check if they miss services and they can think about if they want to develop themselves of ask the other NREN if they can buy it from them.
What we found too is that more and more NRENs think about creating service level agreements of their own services towards their customers. What are the important parameters for your customers? Is it bandwidth, is it the technical competence on the phone, is it the time needed to implement a new customer requirement? Currently we are collecting the SLAs which are around already and share them so we can learn from each other.
This is a very interesting journey here.
The task force is a useful resource for any service manager out there in the NRENs. Please let your people at home know that we are interested to get in touch with them.
If you have questions, then that is great. Please join the mailing list. As you have seen we have a lot of questions too.
Joint Operation?
Service Descriptions
Service Level Agreements

17. 2005 © SWITCH 17