Copyright Feature Creep 2008 Feature-Creep Delivery Framework Version 1

Copyright Feature Creep 2008

Feature-Creep Delivery FrameworkFeature-Creep Delivery Framework

Version 1


The Waterfall looks like this:The Waterfall looks like this:

The waterfall model is a special case of such rarity in

the real software industry as to be

of no interest


Spirals or TrainsSpirals or TrainsIn practice product development will follow either a spiral or release train model. The characteristics are essentially the same but release trains usually have a fixed cadence.


FDFFDF ProvidesProvides Predictability and quality in Product Releases

• By creating a structured process for agreeing timing and scope of releases.

• By reducing churn in requirements• By establishing baseline against which change can be

managed

Clear visibility of release content and timing Alignment of all business functions around

product releases Release Strategy Support and End-of-Life Policy


Product Release FrameworkProduct Release Framework End-to-end product lifecycle planning process. Defines the lifecycle in terms of distinct project phases Each functional unit in the business is responsible for

defined tasks and deliverables in each phase Governance is provided by a Product Delivery Team (PDT)

chaired by Product Management Each functional group is represented by a Product Delivery

Team Member The PDT is accountable to the overall business leadership

(C level execs and key stakeholders)


OverviewOverviewDistinct phases in the project from concept through to delivery

Phase review points where the project team presents to the Company leaders

Phase 1Concept

Product Delivery Team Formed

Post LaunchReview

Release Requirements

Installation & Integration Test

Phase 2Definition & Planning

Phase 3Development

Phase 4Readiness

Phase 5Launch

Integration Complete

DesignComplete

Marketing

Development

Test

Maintenance& Support

Integrated Project Plan

Business Case

Sales Validation

Sales ValidationPackage

Go-To-MarketStrategy

Go-To-Market Plan

Secure Field Trial Customer

Product Architecture Document

Construction and Unit TestSystemArchitectureAnalysis

Draft Product Description

Product Management

Project Plan Baselined

Test Plan and Test Design

Field Trial Plan

Test Analysis

Final Product Description

Product Delivery Team Leader and Project Mgmt

Design Specification

Training andDocumentation

Go-To-Market Execution

Sales Planning and Account Targeting

Update Software

Update Documentation

CodeComplete

Add M&S Requirements to PRD

EA

Field Trial

Requirements Baselined

Product Documentation Development

Training Plan Training ExecutionTraining Development

Test Execution

Phase Review

Functional Specification

Install and Deployment Plan

TPS Release Evaluation and Feedback

Interface ControlDocument

TC

Product Delivery Team Dissolved

GA

CR

TechnologyEvaluation

Documentation Plan

Design Documentation Review

CE Acceptance Criteria

GlobalServices

TPS User Documentation Review

Install & Deploy

Transitionto CE

PRD (Product RequirementsDocument)

Channel Strategy Channel Development

Role

ProjectMandate

TPS Operational Impact Statement

Workflow Model

Functional groups represented by a Product Delivery Team Member

Project activities coordinated by a Product Manager


Phase 1. ConceptPhase 2. Definition and PlanningPhase 3. DevelopmentPhase 4. ReadinessPhase 5. Release

Phase 1. ConceptPhase 2. Definition and PlanningPhase 3. DevelopmentPhase 4. ReadinessPhase 5. Release

Project PhasesProject Phases

Phase 1Concept


Post LaunchReview




Phase 3Development

Phase 4Readiness

Phase 5Launch


DesignComplete

Marketing

Development

Test



Business Case

Sales Validation



Go-To-Market Plan





Product Management



Field Trial Plan

Test Analysis







Update Software


CodeComplete


EA

Field Trial




Test Execution

Phase Review





TC


GA

CR


Documentation Plan



GlobalServices


Install & Deploy

Transitionto CE



Role

ProjectMandate


Workflow Model

Each project phase has a corresponding end of phaseReview, where project status, issues and recommendationsare presented


Functional GroupsFunctional Groups

Phase 1Concept


Post LaunchReview




Phase 3Development

Phase 4Readiness

Phase 5Launch


DesignComplete

Marketing

Development

Test



Business Case

Sales Validation



Go-To-Market Plan





Product Management



Field Trial Plan

Test Analysis







Update Software


CodeComplete


EA

Field Trial




Test Execution

Phase Review





TC


GA

CR


Documentation Plan



GlobalServices


Install & Deploy

Transitionto CE



Role

ProjectMandate


Workflow Model

Product Delivery Team

Training & Documentation

Development

Sales

Product Management

Test

GlobalServices

Marketing

Product Delivery Team Leader Maintenance &

Support

Product DeliveryTeamLeader*

Product Management (lead)MarketingDevelopmentTestDocumentationSupport & MaintenanceServices inc. Training

Product Management (lead)MarketingDevelopmentTestDocumentationSupport & MaintenanceServices inc. Training

Define the swim lanes

appropriate for your business


Tasks and DeliverablesTasks and DeliverablesPhase 1Concept


Post LaunchReview




Phase 3Development

Phase 4Readiness

Phase 5Launch


DesignComplete

Marketing

Development

Test



Business Case

Sales Validation



Go-To-Market Plan





Product Management



Field Trial Plan

Test Analysis







Update Software


CodeComplete


EA

Field Trial




Test Execution

Phase Review





TC


GA

CR


Documentation Plan



GlobalServices


Install & Deploy

Transitionto CE



Role

ProjectMandate


Workflow Model


ArchitecturalAnalysis



Deliverable – i.e. a document that is usually required within the Development Framework

Task – i.e. a activity that is performed by a functional group within the project

Optional Deliverable – i.e. a document that may be required

Generally, a Deliverable will have a Template Document and a set of Guidelines for completion of the document

A Task will usually have a set of Guidelines for the activity

Modify these tasks andDeliverables to fit your

business


OverviewOverviewPhase 1Concept

Product Delivery Team Formed Post Release

Review


Integration Test


Phase 3Development

Phase 4Readiness

Phase 5Release


DesignComplete

Development

Test

Maintenance



Product Architecture Document Implementation and Unit Test

ArchitectureAnalysis

Optional Phase Review

Draft Product DescriptionProduct

Management


Test Plan and Test Cycle Design

Field Trial Plan

Test Strategy and Planning




DevelopmentCommitted

Concept Committed

On the Radar

Documentation

Concept Complete(RPG Review)

Definition & PlanningComplete(RPG Review)

DevelopmentComplete(RPG Review)

ReadinessComplete(RPG Review)

Re-work Software


Feature Complete

Add S&M Requirements to PRD

Field Trial



Training Assessment Training ExecutionTraining Materiel Development

Test Execution

Phase Review

Feature Status



Supportability Review

ReleaseComplete(RPG Review)

TC


GACR


Documentation Plan


Maintenance Acceptance Criteria

Project Task

Deliverable

Optional Optional

TC = Test CompleteCR = Controlled ReleaseGA = General AvailabilityKey

Servicesinc. Training

Install & Deploy + Partner support

Maintainability Review


Role

Support Operational Impact Statement

Support

Unit Test Plan

Updated Roadmap

Release Notes

Support Training

Alpha TrialServices Training

Certification

Test Preparation

Sales &Marketing

Business Case

Sales Validation(with customers)

Go-To-MarketStrategy(inc Channel Strategy)

(Updated) Go-To-Market Plan


Sales Planning and Account TargetingMRD (Market Requirements Document) Sales Collateral

Sales Training

Add Services Requirements

Performance Reqs

Benchmarks

Prescriptive Architecturesand Activity Profiles

Developer Performance Guidelines

PerformanceDesign Changes

Perf designanalysis

Tuning & Benchmarking

Tuning/sizingguidelines

Custom Benchmarking

Iterative performance adjustments, tuning and testing


Platform Defn

UpdatedPlatform Defn

Looks complicated but…Most people live in a single laneand the tasks and deliverables

are likely familiar


Phase 1Concept

Product Delivery Team Formed Post Release

Review


Integration Test


Phase 3Development

Phase 4Readiness

Phase 5Release


DesignComplete

Development

Verification

Maintenance



Product Architecture Document Implementation and Unit Test

ArchitectureAnalysis

Optional Phase Review

Draft Product DescriptionProduct

Management


Test Plan and Test Cycle Design

Field Trial Plan

Test Strategy and Planning


Release Manager



Concept Committed

On the Radar

Documentation

Concept Complete(RPG Review)

Definition & PlanningComplete(RPG Review)

DevelopmentComplete(RPG Review)

ReadinessComplete(RPG Review)

Re-work Software


Feature Complete

Add S&M Requirements to PRD

Field Trial



Training Assessment Training ExecutionTraining Materiel Development

Test Execution

Phase Review

Feature Status



Supportability Review

ReleaseComplete(RPG Review)

TC


GACR


Documentation Plan


Maintenance Acceptance Criteria

Project Task

FDF Deliverable

Optional Optional

TC = Test CompleteEA = Early AccessCR = Controlled ReleaseGA = General Availability

Key

Servicesinc. Training

Install & Deploy + Partner support

Maintainability Review


Role

Support Operational Impact Statement

Support

Unit Test Plan

Updated Roadmap

Release Notes

Support Training

Alpha TrialServices Training

Certification

Test Preparation

Sales &Marketing

Business Case

Sales Validation(with customers)

Go-To-MarketStrategy(inc Channel Strategy)

(Updated) Go-To-Market Plan


Sales Planning and Account TargetingMRD (Market Requirements Document) Sales Collateral

Sales Training

Add Services Requirements

Performance Reqs

Benchmarks

Prescriptive Architecturesand Activity Profiles

Developer Performance Guidelines

PerformanceDesign Changes

Perf designanalysis

Tuning & Benchmarking

Tuning/sizingguidelines

Custom Benchmarking



Platform Defn

UpdatedPlatform Defn

continuedcontinuedThe key items delivered by Product Management in order to commence the FDF process are: - Market Requirements - Business Case

These items will permit planning for a Concept Commit to commence.

Several of the Product Delivery Team members may be required to plan for Concept Commit. The Product Delivery Team Membership will be confirmed at Concept Commit milestone.

The “Go / No Go” Milestone is confirmed by RPG prior to investing in the next phase of the project.

Each Product Delivery Team member is expected to provide a recommendation based on the status of their activities and those of the wider team.

At Development Committed it is expected that all functional groups have a fully resourced plan for project delivery.

Three types of release: Early Access (EA)Controlled Release (CR) and General Availability (GA).


Release TypesRelease TypesName Definition 1st/2nd

Line Support

3rd Line Support

Early Access 1 (EA1)

A partially tested and/or functionally incomplete release, made available to one or more customers who want to deploy/explore features early.May NOT be put into productionInformally supported

? Dev

Early Access 2(EA2)

A partially tested and/or functionally incomplete release, made available to one or more customers who want to deploy/explore features early.May NOT be put into productionInformally supported

? Dev

Controlled Availability(CR)

A functionally complete and fully tested product release available to a limited number of customers (perhaps only one) for one of the following reasons:Custom release not suitable for other customersMajor or Minor release requiring field hardening with small number of customers before making more widely availableTactical release not intended for wide deploymentPM and Engineering must be involved in all decisions to sell/deploy a CA product release with a customer

Support Team

Dev & Maint

General Availability(GA)

A functionally complete and fully tested product release available to all customers. No specific PM or Eng approval for sales/deployment required.Functionally identical to any previous CA releaseSupported by IBG (see next chart)

Support Team

Maint


Release CriteriaRelease Criteria

Quality levels defined at DC Performance report and

sizing capability Maintenance sign-off

S&M sign-off in turn requires: All the GA criteria plus: Maintainability Review Supportability Review M&S Revenue stream S&M resource plan

(heads, training, hardware, tools)

Dev Readiness Launch Production

CR GA

Customer field Trial(s)

requires

Development Support S&M Support

Quality levels defined atDevelopment Commit

requires


Product Delivery TeamProduct Delivery Team

Enable cross-functional collaboration and coordination

Facilitate efficient communications and effective decision-making

Build ownership and accountability for project performance

Enable rapid execution of project activities Provide project focus within an effective

functional organization Direct day-to-day activities Create and manage to an integrated plan Resolve issues and make trade-off decisions

Assess Release readiness E.g. Sales assess readiness of product for

release and demonstrate sales team readiness.

Each FDF project is driven by the work and recommendations of a cross-functional Product Delivery team.

Documentation

Development

Product Management

Verification

ServicesInc Training

Product Delivery Team Leader

Support &Maintenance

Sales &Marketing

Release Manager


Release Manager presents to RPG

Product Management representatives and Product Delivery Team members are invited to RPG

RPG Focus and StructureRPG Focus and Structure


Training & Documentation

Development

Sales

Product Management

Test

GlobalServices

Marketing

Product Delivery Team Leader Maintenance &

Support

Product DeliveryTeamLeader*

Sales/MktingCTOCEO Services S&MDev Verification

• The Roadmap Planning Group is the governance body that provides management oversight and direction for FDF projects.

• The RPG is responsible for

• Setting direction and committing resources

• Reviewing product line priorities

• Ensuring that projects are well planned and remain on track

Milestone Review


Milestone Reviews – what is presentedMilestone Reviews – what is presented

Phase 1: Concept

Phase 2: Definition and

Planning

Phase 3: Development

Phase 4: Readiness

Phase 5: Release

Product Concept

Fit with strategy and roadmap

Marketing Requirements

Target market and size

Value proposition to customer

Product Requirements

Business case Project

schedule Resources

required Project costs

Gap between product requirements and actual product

Updated business case

Updated project schedule and costs

Test results Field trial

feedback Launch plan Updated

business case Updated

project schedule and costs

Initial bookings and revenue

Review of development effort

Retirement plan


And this process will give you a roadmap…


DisclaimerDisclaimerDue to the forward-looking nature of this Roadmap,

Feature-Creep includes information about products that are in the planning stage of development or that

represent custom features or product enhancements. Functionality cited in this document that is not publicly

available is discussed within the context of the strategic evolution of the proposed products. This document is for

informational purposes only. The information in this document is provisional and is subject to change without notice. Nothing in this document should be considered as

a commitment by Feature-Creep in relation to future functionality, release dates, product roadmaps or any

other matter. Feature-Creep MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.


Feature Status DefinitionsFeature Status Definitions“Radar” “Concept Committed”

“Development Committed”

• The feature has been identified as a potential future feature

• Deliverables created:– TBD (feature description)

• The feature has been prioritized by the management team and it has been decided that we will spend additional resources to determine if it is technically feasible and fits within the product strategy– More information required to

determine the actual release• Probability of the feature going to

market – Medium-Low

• Probability of the feature going to market in the targeted release– Low

• The feature has completed a business case and most product and market requirements have been defined

• Deliverables created:– Business Case Or– Drafts of PRD and MRD

• The management team has approved resources to complete the product and market requirements, functional specifications, development and implementation plan, and perform any technical feasibility studies– The management team has updated

the “target release” • More information required to

determine the actual release• Probability of the feature going to

market– Medium-High

• Probability of the feature going to market in the targeted release– Medium

• The feature has been approved to be developed

• Deliverables created:– Business Plan– PRD and MRD– Development and Implementation

Plans– Functional Specification

• A management team has approved resources to complete the development of the feature– The management team has placed

the feature in a “locked” release• We are spending resource to

ensure the feature is included in the “locked” release

• Probability of the feature going to market– High

• Probability of the feature going to market in the “locked” release– High

" Due to the forward-looking nature of this Roadmap, Feature-Creep includes information about products that are in the planning stage of development or that represent custom features or product enhancements. Functionality cited in this document that is not publicly available is discussed within the context of the strategic

evolution of the proposed products. This document is for informational purposes only. The information in this document is provisional and is subject to change without notice. Nothing in this document should be considered as a commitment by Feature-Creep in relation to future functionality, release dates, product roadmaps or any

other matter. Feature-Creep MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. "


Timeline July 2008 Q4 2008 Q2 2009

Release Gerbil Hamster ShrewTheme • Replication & Distribution

• Smart clients• Physical Records Management• eMail Management

• Office 12 support• Advanced Physical Records

Management• Manage-in-place APIs

Core Features

Feature 1• Feature 2• Feature 3• Feature 4• Feature 5

Feature 1 Feature 2 Feature 3 Feature 4

• Feature 1• Feature 2• Feature 3

OptionalFeatures

• Feature 1• Feature 2• Feature 3• Feature 4• Feature 5

Feature 1 Feature 2 Feature 3 Feature 4 Feature 5

• Feature 1• Feature 2• Feature 3

PlatformsOS/DB

• Windows 2000, XP• Office 2003• .Net 1.1



Radar Concept Committed Development CommittedFeature Status

Feature-Creep Roadmap 2008Feature-Creep Roadmap 2008


Irregular or Cyclical PlanningIrregular or Cyclical Planning

Cyclical (example) Annual Planning Cycle: Owned by Roadmap Planning Group (Key stakeholders)

Set out 12 months of Business and linked Product Strategy. “Concepts Committed” based on Business Cases. Product Management and Marketing driving the process.

Quarterly Planning Cycle: Owned by Product Management Define the content of 3 monthly releases for the next quarter. “Developments

Committed” based on engineering analysis, estimates and plans. Approved by PSC

Monthly Planning Cycle: Owned by Engineering Detailed delivery planning for the next release Agile: daily Stand-up with cross-functional participation

Irregular Product Strategy reviewed and updated when desired Each product release cycle kicks off as the previous cycle nears Readiness Each release of arbitrary length based on business view of best compromise

between release date and feature content


Each quarter, Product Delivery Team takes next quarter’s Concept

Committed items go through Definition & Planning Phase and breaks down

into 3 Agile Sprints

Product Lifecycle exampleProduct Lifecycle example

1 MonthDefinition & Planning


Roadmap Planning Group

Month 1Sprint 1

Month 2Sprint 2

Month 3Sprint 3

3 MonthsDevelopment

1 MonthReadiness



Release

Roadmap Planning Group reviews and approves release

Roadmap Planning Group approves next quarter’s release plan: it becomes

“Development Committed”

Annual Planning Cycle

Roadmap Planning Group Roadmap Planning Group Roadmap Planning Group

Q nConcept

Committed

Q n+1Concept

Committed

Q n+2Concept

Committed

Q n+3Concept

Committed

Q n+4Concept

Committed

Q n+5Concept

Committed

QnConcept

Committed


12 or 18 month roadmap


Change Control

Product Delivery Team manages sprints and final

release



Release Train ExampleRelease Train ExampleAnnual Planning Cycle

Roadmap Planning Group Roadmap Planning Group Roadmap Planning GroupRoadmap Planning Group

Q nDevelopmentCommitted

Q n+1Concept

Committed

Q n+2Concept

Committed

Q n+3Concept

Committed

3 MonthsDevelopment

1 MonthReadiness

1 MonthDefn & Plan

3 MonthsDevelopment

1 MonthReadiness

1 MonthDefn & Plan

3 MonthsDevelopment

1 MonthReadiness

1 MonthDefn & Plan

Dev transitions smoothly from one release to the next

One Month contingency to meet quarterly roadmap

commitment

Activity for Qn starts beginning Q n-1

Ongoing development of major components

Delivery of major new component(s)





Ground RulesGround Rules Don’t try to jump on a moving train; you may cause a

crash and kill everyone – wait for the next one The train at the station will almost always be full – if

something goes on, something else has to come off, or at least change from a Must to a Should or Could

Customers don’t (often) expect total flexibility but they like predictability: quoting a date and then hitting it earns more loyalty longer term than aggressive but missed commitments

Product Management have to provide the change control mechanisms and communicate the changes to stakeholders in a timely manner


Points to rememberPoints to remember

FDF is not a Quality Management System – it doesn’t define how detailed planning and execution of product development is carried out.

Individual functional areas are expected to have their own more detailed plans, intermediate milestones and deliverables and to be actively managing them and reporting progress to the PDT.

It’s NOT complicated – most people need only be aware of the tasks and deliverables for one or two lanes.


Feature-Creep Custom DevelopmentFeature-Creep Custom Development


CDF ObjectivesCDF Objectives

Provide value added service to customers by delivering features outside normal FDF roadmap

Provide consistent approach to dealing with customer enhancement requests

Price features correctly in respect of cost to develop and opportunity cost of resources applied

Ensure that Support and Maintenance issues and costs are properly addressed.


Four Delivery OptionsFour Delivery Options

Roadmap Normal roadmap process, dates and content established by FDF process and approved by RPG

Accelerated Product A release to deliver one or more generic features, possibly already on the roadmap, in accelerated timescales

Extended Product A release to deliver one or more customer specific features, not applicable to the general customer base and not road-mapped.

Custom Professional Services developed modifications or extensions to standard product


Economic BasisEconomic Basis

Product Development resources (R&D, Maintenance and QA) drive software licence revenues and should deliver a contribution margin of >85%

In other words – Product Development resources should not be diverted on to work which delivers lower margins than this.

Loaded labour rates around £250 per day• Standard Product Development daily rate: £1700• Accelerated Product Development rates (EMEA) £850 p.d.• Extended Product Development rates (EMEA) £1700 p.d. Note that Accelerated rates are comparable to standard Professional

Services rates and Services resources may be used for Accelerated (or Extended) Product Development work when skills are available

Any discounting must be agreed between the Sales Manager and the resource owner.


Custom Delivery FrameworkCustom Delivery Framework

Quotations valid for 4 weeks,then need re-confirmed sinceresource may have been re-assigned

Note that Extended Product may never actually be purchased by a customer but having the concept allows positive customer engagements around unique needs

Delivered by Development Costs

Support & Maintenance

Normal Roadmap

Product Development

No charge Standard

Accelerated Product

Product Development

Costs shared 50/50 with Customer.

Standard

Extended Product

Product Development

Costs born by customer

25% of Development costs

Custom Services Services Rates 25% of Development costs

IPR retained by Company throughout


Delivery OptionsDelivery Options

Owned by Maintenance Latest Version Service Pack:

Preferred option but resource constrained In-Support Version Patch Release:

Strongly discouraged – very undesirable to add features to a patch release.

Out-of-Support Version Controlled Release:Discouraged but option for customer on legacy version who will not upgrade. Priced to reflect increased costs of support.

Owned by Product Development• Roadmap Release

Longest lead time and limited flexibility after Concept and Development Commit Dates


Feature-Creep ReleasesFeature-Creep Releases


Release TypesRelease Types

Major Release Minor Release Service Pack Service Release Update Release


Major ReleaseMajor Release Content

A full product release which delivers major new functions and/or architectural changes, which can include schema changes, new components, new deployment models and new packaging/licensing models.

NamingFirst digit group increment e.g. 4.0, 5.0, 6.0

SupportSupported for 3 years after next major or minor release

FrequencyNo more than one per year and more typically 2-3 years apart

Upgrades supportedFrom any version in support at time of release


Minor ReleaseMinor Release

ContentA full product release which delivers significant new functions and/or architectural changes, which can include schema changes, new components, new deployment models and new packaging/licensing models.

NamingSecond digit group increment e.g. 4.1, 5.3

SupportSupported for 3 years after next major or minor release

FrequencyNo more than two per year and typically 1-2 years apart



Service PackService Pack Content

A partial product release which delivers a roll-up of all patch release functionality since the last Major or Minor release, plus additional critical fixes. Will not normally include new feature content but small enhancements are permitted. No changes to schema, architecture, packaging or licensing.

NamingNew build number e.g. ? (not that the patch numbers are monotonically increasing but not necessarily consecutive)

SupportSupported for ? months after next service or patch release

FrequencyNo more than four per year and typically 6-9 months apart



Service ReleaseService Release Content

A full product release which delivers a roll-up of all patch release functionality since the last Major or Minor release, plus additional critical fixes. Will not normally include new feature content but small enhancements are permitted. No changes to schema, architecture, packaging or licensing.



FrequencyNo more than four per year and typically 6-9 months apart



Update ReleaseUpdate Release Content

A partial release which delivers one or more fixes for specific critical issues. Will not normally include new feature content but small enhancements are permitted. No changes to schema, architecture, packaging or licensing.



FrequencyNo more than one per week and typically 1 month apart


Product Support PolicyProduct Support PolicySupport terms for both technical assistance and maintenance releases are as follows: Major (no dot) Releases are supported for one year after the date of the

next Major Release or Minor Release. Minor (one dot) Releases are supported for six months after the date of

the next Minor Release or for twelve months after the next Major Release Service (two dot) and Update (three dot) Releases are supported for three

months after the date of the next Update Release or for six months after the next Minor Release or for twelve months after the next Major Release.

DefinitionsUpdate Release – unplanned release to fix one or more bugs. Will typically “roll-up” all previous patch releases since last Major/Minor release.Service release – planned release to “roll-up” contents of multiple Update releases, and often to introduce small features.


Support PrecedenceSupport Precedence

The Major Release grace period will take precedence over the Minor Release grace period, and the Minor Release grace period will take precedence over the Service and Update Release grace period. Technical assistance will be available for the life of a Major Release, but Updates for a given Service Release will only be provided for the life of the Service Release.

In addition, Feature-Creep is only obligated to support the two (2) most recent Minor Releases of the Licensed Product at any one time.

This de-support policy is OS specific, in that the de-support period is related to the next release on the OS platform in question e.g. where the dates for an AIX release differ from those for Solaris, the support period on AIX is solely determined by dates of the AIX releases.


We will not support a product release beyond de-support date unless by specific contractual agreement.

When a product release is de-supported, the customer can buy a contract for Support even after de-support date.But the contract will normally state that -a- Support will not guarantee response timeb- Support will not fix bugsc- Support will try to get the customers a work-around but will not guarantee it.

The actual level of support will vary by contract and preceding agreements may take precedence.

Extended SupportExtended Support


Questions?

Documents

Copyright Feature Creep 2008 Feature-Creep Delivery Framework Version 1