agile digital services · a quick tour peter stansbury, lead author. the trigger agile pm digital....
TRANSCRIPT
Geof Ellingham, Chair, Agile Business Consortium
Agile Digital Services
Agile Digital Services
➢Digital Services within the emerging Framework
➢Agile Digital Services – new qualification overview
➢A slide on openness
➢ Lots of interaction
➢Discussion…
Introducing:
The Framework for Business Agility
Agile Culture
and Leadership
Agile Enablement
and Governance
Agile Strategy
and Portfolio
Agile Projects
Agile Service
EvolutionAgile product
Evolution
Agile
Programmes
Continuing to evolve the stuff we’re known for…
AgilePM(2018?)
AgilePgM(?)
AgileBA(?)
Agile Culture
and Leadership
Agile Enablement
and Governance
Agile Strategy
and Portfolio
Agile Projects
Agile Service
EvolutionAgile product
Evolution
Agile
Programmes
Introducing:
The Framework for Business Agility
Agile Digital Services(foundation & practitioner Jan 2018)
Agile Portfolio Management(minibook November 2017)
Extending the stuff we’re known forinto new areas….
Introducing:
The Framework for Business Agility
Agile Culture
and Leadership
Agile Enablement
and Governance
Agile Strategy
and Portfolio
Agile Projects
Agile Service
EvolutionAgile product
Evolution
Agile
Programmes
And creating content beyondthe stuff we’re known for to support growing business agility.
Characteristics of Agile cultureAgile Leadership Principles???
Something in 2017!
Agile Digital Services(AgileDS)
A quick tour
Peter Stansbury, Lead Author
The trigger
Agile PM DIGITAL
The trigger
Agile PM DIGITAL
Exam nightmare
Roles
Products
Lifecycle
User Research
The goal
3
Ideation workshop with training organisations
Observation of a course in alpha
In-depth interviews with training participants and commissioners
User testing of new concepts and materials
User Research
Certification gives credibilityand sense of achievement but the exam makes the training seem like a box ticking exercise.
“95% of my motivation for the training was thecertificate. But I would measure the learnings, not by “can you recite the book”, but by setting up a development plan of how you will apply it over the next 3 months.” —A. MoJ
“Certification is a big factor. It gives a guaranteethat the training itself covers certain standards.”—R. Newcastle County Council
“If there’s an exam to get, I’ll getit.I need to know that I’ve achieved something.” —Cl. MoJ
8
The Wider ContextBETA
Governance PrinciplesBETA
➢ Don’t slow down delivery
➢ Decisions when they’re needed, at the right level
➢ Do it with the right people
➢ Go see for yourself
➢ Only do it if it adds value
➢ Trust and verify
New Lifecycle – single serviceBETA
New Lifecycle – single serviceBETA
SERVICEMANAGEMENT
SERVICE
RETIREM
ENT
DISCOVERYALPHA
PRIVATEBETA
PUBLICBETA LIVE
ServiceDelivery ServiceManagement
SJ SF SR SL
ServiceJustificationMilestone
ServiceFoundationMilestone
ServiceReleaseMilestone
ServiceLive
Milestone
New Lifecycle – project approach
9 October, 2017 © 2017 Agile Business Consortium Limited 17
BETA
New Lifecycle – project approachBETA
Multi-Service ProjectBETA
Roles and ResponsibilitiesBETA
Multiple TeamsBETA
Project Work Products
Business owned work products
Solution/Technical owned work products
Management owned work products
BETA
Solution Work ProductsBETA
Users at the CentreBETA
Design Principles
➢ Start with needs
➢ Do less
➢ Design with data
➢ Do the hard work to make it simple
➢ Iterate. Then iterate again.
➢ This is for everyone
➢ Understand context
➢ Build digital services, not websites
➢ Be consistent, not uniform
➢ Make things open: it makes things better
BETA
Getting the increments right
MVPs
Learning
MMP
Usable
Lovable
Additional Increments
Improving
BETA
Timeline from Alpha to Live
Alpha Private Beta Public Beta Live
Spring Jun - Oct Nov-Dec 2018
Are we building the right thing?
Are we building the thing right ?
A New Openness
➢ Free content copyright licence
➢ Enables the free distribution of an otherwise copyrighted work
➢ Gives people the right to share, use, and build upon work
➢ GDS Service Manual and Scrum Guide both published like this
➢ Could damage Consortium revenues?
➢ Or spread our ideas more widely?
➢ Might develop “membership beta” publishing process…
Discussion
Embedded Learning
➢ Make it relevant
➢ Make it enjoyable
➢ Make it stick
30
Ongoing Development
➢ Short and long term
➢ Personal and organisational
➢ Change behaviours
➢ Realise results
31
Practice Card Games (Practice Adoption/Improvement)
➢ Outcomes1. Prioritised set of process improvement actions (pretend!)2. Feedback on the playing cards / gaming experience (real!)
➢ Play1. Picture a project or team that you know of that “used agile practices”2. Play “7 Practice Brag” to find the top priority practice to drill into3. Play “Practice Assessment Tic-Tac-Toe" to prioritise improvement areas4. Brainstorm (Post-It Notes) a prioritised list of improvement activities/actions
➢ Feedback1. What could you use a set of Agile Digital Serviced cards for?
2. Card Usability Experience - Good and Bad/Improvement suggestionsWhat we
liked … (real)
It would be better if … (real)
We could use cards
for … (real)
Improve-ments
(pretend)
!
Contact details
➢ Geof Ellingham
➢ Chair, Agile Business Consortium
➢ Workstream lead, Agile Digital Services
➢ 07990 574667
This presentation contains public sector information licensed under the Open Government Licence v3.0.
These slides are licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/
➢ Peter Stansbury
➢ Lead Author, Agile Digital Services
➢ 07703 658641
HISTORY
9 October, 2017 © 2017 Agile Business Consortium Limited 34
at the dawn of Agile…
1995
1997-2006
2007 – DSDM Atern
2010 – AgilePM®
Based onDSDM Atern
Certification in collaboration with
Todayover 60,000 people certified
Where next?
Agile Software Development
➢ Hit the mainstream around the turn of this decade
➢ Adopted by GDS in 2010
➢ Now more commonly used than any other approach
➢ ’Pure’ Waterfall is in steep decline
➢ Lots of focus on scaling
➢ Lots of hype about projectsbeing an outdated concept
➢ But it only deals with part ofthe problem
Many businesses struggle to
understand how to harness the
Agility of their technology teams
for real competitive advantage
Many technology teams struggle
processes, practices and
behavioural norms that run
counter to Agile philosophy
Many business leaders struggle to understand
how they can implement the innovative wisdom
of modern business leadership
and sometimes lose
the will to even try
And still too many people, regardless of role,
struggle to see how they can make a genuine
contribution to the success of their organisation
2016
We took action…
Rebrand and Vision
New Focus
New Brand
Still non-profit
Beyond Software
Beyond Projects
Our Mission:
To provide global leadership in
promoting, supporting and enabling business agility
GDS Design Principles
09/10/2017 © 1995-2017 Agile Business Consortium 50
Design Principles
➢ Start with needs
➢ Do less
➢ Design with data
➢ Do the hard work to make it simple
➢ Iterate. Then iterate again.
➢ This is for everyone
➢ Understand context
➢ Build digital services, not websites
➢ Be consistent, not uniform
➢ Make things open: it makes things better
Start with Needs
➢ Good service design starts with identifying user needs. Without a clear understanding of user needs it is highly unlikely that the right solution will be delivered.
➢ When considering user needs, it is particularly important to:• Have empathy with the users when establishing an understanding of their needs and wants
• Give user needs priority wherever possible
• Remember that what they ask for is not always what they need.
Do Less
➢ Government should only do what only government can do.
➢ If we’ve found a way of doing something that works, we should make it reusable and shareable instead of reinventing the wheel every time.
➢ This means building platforms and registers others can build upon, providing resources (like APIs) that others can use, and linking to the work of others. We should concentrate on the irreducible core.
Design with Data
➢ In most cases, it is possible, and desirable, to learn from real world behaviour by looking at how existing services are used
➢ Letting data drive decision-making, is preferable to using hunches or guesswork
➢ Using data is important throughout the project lifecycle and should also continue after the service has gone live
➢ Analytics should be built-in, always on and easy to read. They’re an essential tool.
Do the Hard Work to Make it Simple
➢ Making something look simple is easy
➢ Making something simple to use is much harder • especially when the underlying systems are complex
• but that’s what an Agile Digital Services project should be doing.
➢ Don’t take “It’s always been that way” for an answer
➢ It’s usually more work and harder work to make things simple, but it’s the right thing to do
Iterate then Iterate Again
➢ The best way to build good services is to start small and iterate wildly.
➢ Release Minimum Viable Products early, test them with actual users
➢ Move from Alpha to Beta to Live adding features, deleting things that don’t work and making refinements based on feedback.
➢ Iteration reduces risk. It makes big failures unlikely and turns small failures into lessons.
➢ If a prototype isn’t working, don’t be afraid to scrap it and start again.
This is for Everyone
➢ Accessible design is good design.
➢ Everything that is built should be as inclusive, legible and readable as possible. • If this means sacrificing elegance — so be it.
➢ A solution should be built for needs, not audiences.
➢ It is important to design for the whole target user base, not just the ones who are used to using the web.
➢ The people who most need the services are often the people who find them hardest to use. • Therefore, it is essential to think about those people from the start.
Understand Context
➢ Effective design is built around people, not screens and the team needs to think hard about the context in which they’re using the services. • Are they in a library?
• Are they on a phone?
• Are they only really familiar with Facebook?
• Have they never used the web before?
Build Digital Services not Websites
➢ A service is something that helps people to do something. • The job is to uncover user needs, and build the service that meets those needs.
• Of course, much of that will be pages on the web, but that does not mean the project is there to build websites.
• The digital world has to connect to the real world, so the team has to think about all aspects of a service, and make sure they add up to something that meets user needs.
Be Consistent, not Uniform
➢ Consistency of language and design patterns helps people get familiar with the services as well as driving efficiency through re-use• When re-use and enhancement of existing components is not possible or sensible, it is important to
ensure the new developments are consistent with those already built into the service and, where defined, agreed organisation-wide standards.
➢ However, it is important to understand that every circumstance is different. • Sharing, debating and re-using is a good conceptual start point but should not inhibit improving or
changing components if better ways of doing things are discovered or the needs of users change.
Make Things Open, It Makes Things Better
➢ We should share what we’re doing whenever we can. With colleagues, with users, with the world • share code
• share designs
• share ideas
• share intentions
• share failures
• the more eyes there are on a service the better it gets — obvious issues are identified, better alternatives are pointed out and, as a result, the bar is raised
➢ From an ethical perspective, any organisation exploiting open source code and the generosity of the web design community should pay that back if possible
Roles and Responsibilities
Roles and Responsibilities
Roles and Responsibilities
➢ One person can have more than 1 role
➢ A role can be shared between people
➢ All responsibilities must be covered
➢ Project roles• Manage
• Direct
• Co-ordinate
➢ Solution Development Team roles (SDT) • Shape and build the solution
➢ Supporting roles• Specialists, as appropriate
• Provide ad-hoc assistance and guidance
Project Level Roles
➢ Project-level Roles• Build projects around motivated
individuals
• Trust teams, confident that everyone will work to best of their ability
• Give teams the environment and support they need
• Adopt facilitative empowering leadership style enabling SDT to ‒ Learn as they go and reflect
‒ Adapt and enhance process
• Ensure SDT has freedom to do the job
Business Sponsor
➢ Most senior project level role – the Project Champion
➢ Committed to project and proposed solution
➢ Committed to the approach for delivering the project
➢ High enough in organisation to resolve business issuescand make financial decisions
➢ Responsible for business case and project budget
Business Interests
Business Visionary
➢ Single person actively involved to provide a clear vision and strategic direction
➢ Interprets and communicates business needs of Sponsor and ensures these needs are represented in business case
➢ Ensures solution will enable business benefits
➢ have overall responsibility for developing, operating and continually improving your service
➢ represent the service during service assessments
➢ make sure the necessary project and approval processes are followed
➢ identify and mitigate risks to your project
➢ encourage the maximum possible take-up of your digital service
➢ have responsibility for your service’s accessibility and assisted digital support needs
Business Interests
Technical Architect
➢ Technical authority for project, providing the technical vision
➢ Ensures project is technically coherent and meets agreed standards
➢ Provides “glue” that holds technical aspects of project together • Advising on technical decisions and
innovation
Solution/Technical Interests
Project Manager
➢ Management Style:• To provide high-level Agile-style to Solution
Development Team(s)
• To adopt facilitative style for managing empowered SDT
• Leaving detailed planning to SDT
➢ Focuses on managing the working for evolving the solution
➢ Coordinates high-level aspects of project
➢ Responsible for business and technical aspects
Management Interests
Business Ambassador
➢ Key business representative within Solution Development Team
➢ makes sure the evolving solution is fit for purpose and fits in with your organisation’s priorities
➢ make sure your service will meet user needs
➢ prioritise user stories
➢ comment on technical, content and design solutions
➢ accept user stories when complete
➢ Responsible for day-to-day communication between project and business
Business Interests
User Ambassador
➢ Key advocate of the end-user within Solution Development Team
➢ Collaborating with the Business Ambassador to guide the detail of the evolution of the service
➢ Contributing to all requirements, design and review sessions
➢ Providing the end-user perspective for all day-to-day
➢ Providing the detail of user scenarios to help define and test the solution
➢ Communicating with User Researchers and service users Providing day-to-day assurance that the solution is evolving correctly from an end-user perspective
➢ Organising and controlling user acceptance testing of the solution
➢ Ensuring end-users of the service are properly trained and supported
Business Interests
Delivery Manager
➢ Managing risks and issues at the Timebox level
➢ Monitoring progress on a day-to-day basis
➢ Facilitating communication of team progress
➢ Facilitating the Daily Stand-ups
➢ Facilitating reviews and retrospectives
➢ Leading the collaborative, dynamic planning and prioritisation processes
➢ Matrix-managing a multidisciplinary team
➢ Ensure all products are built to an appropriate level of quality for the stage (alpha/beta/live)
Business Interests
Business Analyst
➢ Fully integrated with SDT• Not an intermediary between Product Owner and
team
• Supports communication between the business and the SDT
➢ Facilitates relationship between business and technical roles
➢ Ensures accurate, appropriate day-to-day decisions about the Evolving Solution
➢ Ensures business needs are properly analysed and correctly reflected in evolution of solution
Business Interests
Solution/Technical Interests
Solution Developer and Tester
➢ Solution Developer• Interprets business requirements and
translates them into a deployable solution
➢ Solution Tester• Empowered and fully integrated with
SDT
• Performs testing in accordance with agreed strategy
Solution/Technical Interests
Business Advisors
➢ Providing specialist input into relevant:• Requirements, design and review activities
• Day-to-day project decisions
• Business scenarios to help define and test the solution
➢ Providing specialist advice on, or help with:• Developing business user and support
documentation for the ultimate solution
• Deployment of the solution releases into the business, as appropriate
Business Interests
User Researcher
➢ The User Researcher helps the team understand the service users so it can design the right kind of service in the right way. When working on the service, they will:• Plan a programme of research for the service
• Develop a clear understanding of and empathy with the users
• Design, conduct and analyse user research using a range of techniques
• Provide guidance on design based on their understanding of users’ needs and behaviour
Business Interests
Assisted Digital Lead
➢ The Assisted Digital Lead is responsible for ensuring the appropriate levels of Digital Assistance are designed, developed and delivered. In particular ensuring that:• Research is undertaken to understand the users’ needs
• The right support methods are used
• The right support partners are used
• Users are made aware of the support available
• Appropriate performance analysis is carried out
Accessibility Lead
➢ The Accessibility Lead is responsible for ensuring that services are built so that anyone can use them, regardless of whether they have a disability. This can be carried out by ensuring that:• Research is undertaken to understand the users’ needs
• Appropriate testing is carried out
• Accessibility is considered for digital and non-digital channels
• Appropriate performance analysis is carried out
Performance Analyst
➢ Performance analysts help your team understand and improve the service’s performance by:• Collecting and presenting key performance data and analysis for the service
• Working with the service manager to make sure their service meets the agreed performance requirements
• Helping the service team understand user needs by providing quantitative and qualitative evidence from web analytics, financial data and user feedback
Business Change Lead
➢ Agile Digital Services projects usually involve much more than technology and the Business Change lead will ensure:• Stakeholder mapping and management is carried out effectively
• Change management activities are planned in with other project activities
• Benefits are identified, defined and realisation is assessed
• Appropriate training and support is delivered
• Transition plans are in place to ensure “Business as Usual” is maintained whilst changes are delivered
Technical Advisor
➢ Provides specific / specialist technical input to the project
➢ Often advising from the perspective of those responsible for• Operational management
• Operational support
• Ongoing maintenance of the solution
Solution/Technical Interests
Solution Designer
➢ A range of skills that will vary by project - e.g. interaction, graphic, user experience (UX) and content. Designers work within the team to:
➢ Design user-centred services, interfaces and interactions
➢ Turn concepts into user-centred services
➢ Create an engaging user experience
➢ Advocate for users challenging requests that don’t support their needs
Business Interests
Coach and Facilitator
➢ Workshop Facilitator• Responsible for planning, organising and
managing workshop process
• Independent of workshop outcome
➢ Agile Coach• Helps teams with limited experience
to get most benefit from Agile DS within context and constraints of their organisation
• Needs to be an expert with real practical experience
• Preferably certified
Process Interests
Other Roles
➢ PMO
➢ Programme Manager
DevOps Engineer
➢ Bridging the traditional gap between Development and Operations – enabling incremental delivery by:• Running your production systems
• Helping the development team build software that’s easy to use
• Working with developers to optimise existing applications and design new ones
• encouraging everyone in the team to think about how new applications will be run and maintained
MVPs and MMPs
Minimum Viable Product (MVP)
➢ Many definitions - but the key is to identify a subset of service features that maximise the learning for a minimal amount of effort.
➢ MVPs are not intended to be fully usable products but are learning vehicles used to ensure future increments are built on firm foundations.
➢ This should link to the objective of every Timebox from Alpha onwards developing potentially deployable software.
➢ In some projects it will be possible to release an increment at the end of every timebox but this often won’t be the case.
➢ MVPs will be released during the Alpha phase and at early stages in the Beta phase and possibly later in the project depending on the nature and complexity of the service(s) being developed.
Minimum Marketable Product (MMP)
➢ A subset of features that is deployed to real users and intended for use in a manner that should enable delivery of real business benefit.
➢ Many MVPs might have been deployed before an MMP• and only once sufficient learning and further iterative development has taken place will the MMP be
released.
➢ Likely to include software and systems along with supporting processes (often not digital) and require user training and higher levels of communication than an MVP.
➢ This is the first usable Work Product resulting in a usable service• but must not be seen as close to the final Work Product or service.
➢ It is recommended to have at least one MMP for each of Private Beta, Public Beta and Live phases. • For more complex products and services it is possible to have more than one MMP per phase.
Additional Increments
➢ Desirable to consider the MMP as a starting point and to continually enhance the service using the concept of Additional Increments.
➢ Once the MMP has been released user feedback and other supporting data must be gathered and analysed. • The team should then work out the smallest incremental change that can effectively apply the lessons
learned and add further value to the service users.
➢ As implied by the name the MMP is likely to require a “launch” • whereas additional increments often only require further communication and, perhaps, limited
additional training.
➢ In cases where manual processes and workarounds have been in place from the MMP • these are often replaced sequentially by additional increments.
Lifecycle
The Digital Service Lifecycle
Moving Between Phases
Project Governance and Service Delivery Lifecycle
PRE-PROJECT
SERVICERETIREM
ENT
DISCOVERY
Service
ALPHAPRIVATEBETA
PUBLICBETA
PROJECT
LIVE
SERVICEMANAGEMENT
PJ
SJ SF SR SL
PCPF
Pre-Project
➢ Pre-Project • Ensure only the right projects are started
• Ensure projects are set up correctly based on clearly defined objective
➢ Keep Pre-Project short and sharp
➢ Main purpose is to position project and justifyAlpha
➢ Formality varies, depending on organisation
➢ Takes place at portfolio or programme level
Discovery
➢ You should find out:• who your users are
• your users’ needs and how you’re meeting them, or any needs you’re not meeting
• which services currently meet your users’ needs
• how you’d start developing a new service if your discovery finds there’s a user need for one
• the people you need on your team for the alpha phase
• what the user journey for someone using your proposed service might look like
• how you might build a technical solution given the constraints of your organisation’s legacy systems
• the policy that relates to your service and how it might prevent you from delivering a good service to your users
• Whether the project remains feasible in light of the findings
PRE-PROJECT
SERVICERETIREM
ENT
DISCOVERY
Service
ALPHAPRIVATEBETA
PUBLICBETA
PROJECT
LIVE
SERVICEMANAGEMENT
PJ
SJ SF SR SL
PCPF
Alpha
➢ During the Alpha phase you• build prototypes of your service
• test your prototypes with users
• demonstrate that the service you want to build is technically possible
➢ You should use your experience building prototypes in the alpha to:• find the problems with the design of your service and decide how you’ll solve them
• make some estimates about how much your service will cost
• identify the biggest risks for the beta stage, as early as possible
➢ By the end of alpha you should know:• whether to move your service into the beta phase
• what you need to build in beta if you are moving into beta
PRE-PROJECT
SERVICERETIREM
ENT
DISCOVERY
Service
ALPHAPRIVATEBETA
PUBLICBETA
PROJECT
LIVE
SERVICEMANAGEMENT
PJ
SJ SF SR SL
PCPF
Alpha Prototype
➢ Your alpha prototype needs to allow a complete end-to-end transaction.
➢ You should think of it as a proof of concept and use it to check:• you’ve got the right solution that meets the user need
• your approach is viable and cost-effective
• the technologies exist to implement your plan
• the things that won’t be easy to change and whether you can still go ahead despite these
• you understand the needs of your users enough to be able to meet them
• If not, find out more and make a new prototype
Beta
➢ During the beta phase you build a working version of the service based on your alpha prototypes• improve your service by testing it with users based on the user stories you created in the alpha phase
• solve any technical or process-related challenges so that your service meets the Digital Service Standard
• get the service accredited
• make a plan for the launch of your service
• release updates and improvements into the development environment
• measure the effect of any changes to the Key Performance Indicators (KPIs) you established in discovery and alpha, for example if you changed KPIs because of new data
• test the assisted digital support model you designed for your service
PRE-PROJECT
SERVICERETIREM
ENT
DISCOVERY
Service
ALPHAPRIVATEBETA
PUBLICBETA
PROJECT
LIVE
SERVICEMANAGEMENT
PJ
SJ SF SR SL
PCPF
Private & Public Betas
➢ Private Beta isn’t open to everyone so you can:• have more control over the type of user that gets to use the beta
• restrict the volume of transactions that go through the beta
• start small and get quick feedback before rolling your service out to a wider audience
➢ Public Beta is open to anyone• Will run in parallel to existing live service (if there is one)
PRE-PROJECT
SERVICERETIREM
ENT
DISCOVERY
Service
ALPHAPRIVATEBETA
PUBLICBETA
PROJECT
LIVE
SERVICEMANAGEMENT
PJ
SJ SF SR SL
PCPF
Before Go Live
➢ Before you can make your service live, you must make sure:• the service meets the user needs you found in your discovery, alpha and beta phases
• the service meets information security rules
• you’ve set up your analytics to accurately measure the success of your service
• you’ve got a plan for the transition or integration of any existing services that meet a similar user need to yours
• the service fully meets the Digital Service Standard and can continue to do so
• you can support the service and you’ll be able to keep iterating it and improving it until it’s retired
Live
Live
➢ Don’t forget the live phase is the time to keep improving your service based on:• user feedback
• analytics
• your ongoing user research
PRE-PROJECT
SERVICERETIREM
ENT
DISCOVERY
Service
ALPHAPRIVATEBETA
PUBLICBETA
PROJECT
LIVE
SERVICEMANAGEMENT
PJ
SJ SF SR SL
PCPF
Service Management
➢ Don’t forget the live phase is the time to continuously improve your service based on:• user feedback
• analytics
• your ongoing user research
• Benefits assessment
PRE-PROJECT
SERVICERETIREM
ENT
DISCOVERY
Service
ALPHAPRIVATEBETA
PUBLICBETA
PROJECT
LIVE
SERVICEMANAGEMENT
PJ
SJ SF SR SL
PCPF
Service Retirement
➢ Sometimes a service needs to be retired
➢ User needs have changed
➢ Policies and legal requirements have changed
➢ Some other service fulfils the user needs
PRE-PROJECT
SERVICERETIREM
ENT
DISCOVERY
Service
ALPHAPRIVATEBETA
PUBLICBETA
PROJECT
LIVE
SERVICEMANAGEMENT
PJ
SJ SF SR SL
PCPF
Retiring a Service
➢ Consider user needs just as you did during the project
➢ Communicate with users
➢ Protect and manage user data
➢ Make a transition plan if there is a replacement service
Service Justification Milestone
➢ Indicates that the objectives of the Discovery Phase have been met
➢ Achieved when stakeholders are confident that the needs of the service users are understood and that the investment in creating the service is justified
Service Foundation Milestone
➢ Indicates that the objectives of the Alpha phase have been met
➢ Achieved when prototypes of the service demonstrate that the needs of the service users can be met, that implementing the service is viable from a technical perspective and that it makes sense from a business perspective
Service Release Milestone
➢ Indicates that the objectives of the Private Beta Phase have been met and the service is ready to release to the full user community.
➢ Achieved when the service is considered mature enough to be used by anybody who is interested in using it. Results of rigorous testing and live use by the Alpha phase users will provide evidence of the maturity.
Service Live Milestone
➢ Indicates that the objectives of the Public Beta Phase have been met and that the service is ready for use by all users by default.
➢ Achieved when development of the Service is largely complete as a result of ongoing development through the Beta Phase
Project Justification Milestone
➢ Indicates that the objectives of the Pre-project Phase have been met
➢ Achieved when stakeholders agree that implementing one or more services as part of a single project is aligned with business strategy and now is the time for the service(s) to be investigated in more detail
Project Foundation Milestone
➢ Indicates that:• A project to deliver one or more new / enhanced services has been shaped and planned
and is ready to proceed to delivery
➢ Achieved when:• A reasonably accurate time and cost budget for the project will be available
• A clear understanding of the wider context for how the whole project will be delivered. Including:
• How constraints will be addressed
• How legacy systems integration or replacement will be carried out
• How cross-service dependencies will be managed
Project Closure Milestone
➢ Indicates that the objectives of the Project have been met
➢ Achieved when all the services delivered by the project have transitioned into Service Management
Configuring the Lifecycle
Scaling Considerations
➢ Do enough Discovery (but not necessarily all) before starting Alphas
➢ Alphas and Betas can run in parallel.• Might be a natural link or dependency between the services
• Might just relate to project capacity or timing needs.
➢ Project Foundation Milestone very important
➢ Multiple teams can be used• Pay attention to team size and team stability and the capacity of users to accept the level of planned
change
➢ Formality of governance and Work Products might need to increase
➢ Phased procurement, aligned with stage gates or Phases