Solution design & procurement approach v1

570 views
458 views

Published on

A presentation discussing some of the issues relating to the application of Agile approaches to Solution Design while maintaining Risk Mitigation

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
570
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Solution design & procurement approach v1

  1. 1. A Hybrid SDLC Solution Design & Procurement Approach
  2. 2. Contents Section # Section Purpose Starts slide: 1. “Standard” Solution Life Cycle (Waterfall) – The Context 2. Solution Development Life Cycle – Waterfall versus Agile? 3. How do we Accommodate (more-) Agile Approaches? 4. Solution Design Approach – When & Who? 5. Solution Design Approach – How & What? 6. Solution Design & Procurement Approach (Managed Sandpits – Why?) 7. Solution Design & Procurement Approach (Managed Sandpits Scenario – What?) 8. Solution Design & Procurement Approach (Managed Sandpits Scenario – How?) 9. Solution Design & Procurement Approach (Managed Sandpits Scenario – Who?) 10. Solution Design & Procurement Approach (Managed Sandpits Scenario – Where?) 2Solution Design & Procurement Approach01/04/2014
  3. 3. SECTION 1 “Standard” Solution Life Cycle (Waterfall) – The Context 3Solution Design & Procurement Approach01/04/2014
  4. 4. OperateShapeConcept Problem Definition & Impact Assessment Feasibility Assessment High Level Design Deliver Detailed Design Build Test Implement Production Feedback • UK Government and its suppliers has, in the past, built a whole industry around this Life Cycle, typified by Prince II Project Management Methodology. • It is a lifecycle that is very commonly implemented – its attraction is that this delineation of phasing permits “checkpoints” at which a meaningful review and re-alignment (re-scoping or even cancellation) can take place, thereby de-risking the process, something which is greatly-prized by many stakeholders in solution life cycle process The “Standard” Waterfall Solution Lifecycle 4Solution Design & Procurement Approach01/04/2014 However: • The “Checkpoint” approach creates a cottage industry of assurance – by people without the technical skills to actually validate the solution, and thereby have to rely on documentation (creating its own cottage industry) – ADDED COST • Errors or incorrectly specified requirements found during the test or implement stages are extremely costly to go back & correct – ADDED COST • The process is invariably long-winded from beginning-to-end, which usually means that requirements change during the life of the project,. Invoking expensive and time-consuming Change Control. Worse, lengthy projects always experience personnel changes, with resultant changes in thinking & approach – ADDED COST, RISK
  5. 5. SECTION 2 Solution Development Life Cycle – Motivation for (more-)Agile Approaches 5Solution Design & Procurement Approach01/04/2014
  6. 6. Agile versus Waterfall Agile Waterfall Individuals & Interactions Processes & Tools Working Software Comprehensive Documentation Customer Collaboration Contract Negotiation Responding to Change Following a Plan 6Solution Design & Procurement Approach01/04/2014 Quality Features CostTime Quality Features CostTime Principles • Focus on the Business Need • Deliver on Time • Collaborate • Never Compromise on Quality • Build iteratively from firm foundations • Deliver Iteratively • Communicate continuously and clearly • Demonstrate control Variable Fixed WaterfallAgile
  7. 7. Motivation for Agile Approach Agile approaches are very suited to implementation of packaged software or outsourced services. They are also used to a greater or lesser degree by mature organisations in the development of software application components, where it is felt that they can accept the Pareto Rule: In an age where COTS software has become highly-sophisticated through deployment and experience in millions of Use Cases, the hypothesis is that: • 80% of the requirement can be satisfied with 20% of the total effort, and that • common sense tells us we should quit there while we are ahead. The lingering doubt: • Will the 80% work for us? • Is the level of Risk acceptable?
  8. 8. SECTION 3 How do we Accommodate (more) Agile Approaches? 8Solution Design & Procurement Approach01/04/2014
  9. 9. OperateShapeConcept Problem Definition & Impact Assessment Feasibility Assessment High Level Design Deliver Detailed Design Build Test Implement Production Feedback • How do we accommodate “more-Agile” approaches to the Solution Development Life Cycle while retaining Project Governance? • However, there is a fundamental question which is not necessarily dependent upon the type of “agile” that is adopted: Does Agile “kick-in” at the start of requirements elaboration, or at the point where design is stable? • The next few slides elaborate some thoughts on this question The Solution Lifecycle 9Solution Design & Procurement Approach01/04/2014
  10. 10. Iterative Build before Detailed Design 0 OperateShapeConcept Problem Definition & Impact Assessment Feasibility Assessment High Level Design Deliver Detailed Design Build Test Implement Production Feedback 1 2 4 5 6 Quality Gates • In this case, iteration and parallel development by teams working on different “sprints” takes place after the HLD has been reviewed and agreed. Revisions to design are accommodated during the sprint. This is more clearly aligned with pure agile. Update Project Plan Tech Design, Specs Create Detailed Test Cases Develop & Test Demo & Retrospec tives Refine Reqs 10Solution Design & Procurement Approach01/04/2014 Full Business Case Authorised or T&M • If a Fixed Cost Business Case is agreed at this point, the customer is exposed to the risk of incomplete delivery or escalating change control. Depending upon the rigour of the original specification, the supplier may also be faced with an unacceptable level of risk • On the other hand most customers are reluctant to agree to a T&M approach
  11. 11. Agile – Iterative Build after Detailed Design 0 OperateShapeConcept Problem Definition & Impact Assessment Feasibility Assessment High Level Design Deliver Detailed Design Build Test Implement Production Feedback 1 2 3 4 5 6 Quality Gates Full Business Case Authorised Update Project Plan Tech Design, Specs Create Detailed Test Cases Develop & Test Demo & Retrospec tives Refine Reqs • In this case, iteration and parallel development by teams working on different “sprints” takes place after the LLD has been reviewed and agreed. Revisions to design will only take place where detailed development work reveals an error or a gap in the design • This is not pure agile but rather a hybrid of waterfall and agile. • Clearly this allows the project to proceed with more certainty but mitigates against one of the benefits of agile – namely the feedback loop into design (and the end product of the sprint) from detailed development 11Solution Design & Procurement Approach01/04/2014
  12. 12. There is a way….
  13. 13. SECTION 4 Solution Design Approach – When & Who 13Solution Design & Procurement Approach01/04/2014
  14. 14. When - Phases Collaborative Requirements Engineering Convergence (including Sandpits) Iterative Build 14Solution Design & Procurement Approach01/04/2014
  15. 15. Who – Multi-Disciplinary Team Project Level Roles Business Sponsor - owns and ensures ongoing viability of the Business Case, & ready to pull the plug if necessary. Responsible for obtain funding & other resources, oversees decision making & escalation, responds rapidly to escalated issues & delivers Business Benefits Business Visionary - owns wider implications of business change; define communicate and promote business vision; contribute to key decisions, designs and review sessions, monitor progress, approve changes to high-level requirements, ensure collaboration & availability of internal SME resources, act as final arbiter on business requirements Project Manager - communicating with senior stakeholders and responsible for project governance; high-level project planning & scheduling; monitoring progress; managing risk;; motivating the project teams; resourcing specialist roles; managing problems & issues and escalating as required Architect - to agree and control the Technical Architecture; to identify and own technical risks, escalating to the PM as appropriate; to advise on and coordinate technical activity; to ensure non-functional requirements are achievable and achieved; to ensure adherence to appropriate standards of technical best practice; to control the technical configuration of the solution; to manage technical aspects of the transition to live use of the solution; to resolve technical differences between team members 15Solution Design & Procurement Approach01/04/2014
  16. 16. Who – Multi-Disciplinary Team Solution Level roles Members of the team are empowered to make solution decisions within an agreed terms of reference Team leader - a leadership rather than management role. Can be different team leader for different stages of project. Elected by peers. Responsibilities - to work within the team to plan & coordinate all aspects of product delivery, at a detailed level; to ensure that the team operates as an entity and fulfils its obligations; to report to the PM Business Analyst - provides clear direction for the business users; ensures business needs are analysed and reflected in guidance for the project team; works alongside the business but does not make decisions on its behalf, ensures no scope creep and only low level details are added during the solution development; manages requirements priority list Business Specialist - role filled by someone with specific knowledge relevant to some or all of the project - examples, legal or finance or security expert Technical Specialist - technical equivalent of Business Advisor - examples, DB developer or Technical author Solution Developer - technical skills (analyst / programmer) to the fore, but good communicator and team player; must be dedicated to the project because of the time-boxing approach Business SME - very knowledgeable about business area and its processes; links solution development team and the business; the role provides business-related information from end-user's perspective 16Solution Design & Procurement Approach01/04/2014
  17. 17. SECTION 5 Solution Design Approach – How & What 17Solution Design & Procurement Approach01/04/2014
  18. 18. How - Workshop Approach The workshops are structured to align with the new Target Operating Model Business Capabilities that are in scope. • Capabilities are de-composed into their constituent processes – these represent the scope of individual workshops The workshops will address both To-be and As-is jointly in workshops. • We can identify anything that exists in the As-is that can be reused for the To-be • This is more efficient in terms of the use of BA & SME resource • It is also crucial to condense the e2e Requirements Gathering into as short an elapsed period of time as possible: • Business context and therefore requirements change quickly, so a lengthy process can become like painting the San Francisco Bridge • Continuity of personnel is also vital, so shortened timescales mitigate the impact of personnel sickness, holidays and turnover 18Solution Design & Procurement Approach01/04/2014
  19. 19. What - Design Approach The workshops adopt a standard approach to analysis: 1. Quickly confirm the As-is process flows (with no supporting Information Flows etc) 2. Identify the Outcomes mandated for a successful implementation of the To-Be process 3. Map As-Is on to the To-Be model and identify any gaps 4. Extract information from the documentation of the individual workshops, such as Roles, Business Rules, Candidate Services, User numbers etc and lodge them in repositories so that they can be “normalised.” 5. Perform a MoSCoW analysis to determine priority 19Solution Design & Procurement Approach01/04/2014
  20. 20. SECTION 6 Solution Design & Procurement Approach (Managed Sandpits) – Why? 20Solution Design & Procurement Approach01/04/2014
  21. 21. Why - Motivation for a Managed Sandpit? COTS Approach • Speed to Market • Lower cost • Reduce Risk – Will it work? Of course it will – COTS software has been deployed and exercised in millions of Use Cases – Will it work for us? The Key Question Transformation Agenda • Drive stakeholder thinking about “will it work for us?” • Thereby inform RFP Requirements – “Outcomes focussed” Capturing the outputs in the form of potential future questions and ultimately RFP Requirements Experiencing a working relationship with bidders.
  22. 22. What is a Managed Sandpit? Three Sandpit phases: 1. Convergence 2. Close-down 3. RFP Evaluation A sandpit is an intensive, interactive and extended workshop where Examiner participants are encouraged to delve deeply to explore the capabilities of bidder “vanilla” solutions. Vanilla solution (configured to enable Examiner stakeholders to explore the scenario) which can be easily created, “trashed” then easily resurrected. Addresses the question “Will it work for us?” and starts Examiner thinking about: • “Can we adapt our ways of working to adopt the vanilla solution and…” • “What will we have to do to adopt the vanilla solution 22Solution Design & Procurement Approach01/04/2014
  23. 23. How - Process for a Managed Sandpit? The process can be broken down into: • Define the scope of the issue (Scenario) • Agree a common language and terminology amongst people from a diverse range of backgrounds and disciplines. • Share understanding of the problem domain • Mix of “hands-on” elaboration of the Scenario and break-out sessions focused on the problem domain, encouraging creative and innovative thinking within the framework of the initial scenario, and each bidder’s “vanilla” solution • Initial support for walkthrough of scenario (“Happy Path”) journey through the vanilla solution • Ad hoc support for user queries: – “How do I…? – “How would you achieve this (outcome-focussed) requirement? • Document outputs & further questions (we will maintain confidentiality of bidder IPR)
  24. 24. Who - Participants? • It will typically involves 20-30 participants over time – The Transformation Director (whose role is to define the topic and facilitate discussions at sandpit events), – Lead BA – Solution Architect – Subject Matter Experts (Bid team) – Solution Experts (Bidder team) • An essential element of a sandpit is a highly multidisciplinary mix of participants taking part, some being programme stakeholders and some being users of programme outcomes, to drive lateral thinking and radical approaches to addressing particular programme challenges. 24Solution Design & Procurement Approach01/04/2014
  25. 25. SECTION 7 Solution Design & Procurement Approach (Managed Sandpits Scenario) 25Solution Design & Procurement Approach01/04/2014
  26. 26. Sandpit Scenario – Students entering the Exam • 6 students enter for the F5 exam in the December exam session; Emma, Carol-Anne and Andy are all from the UK and wish to sit at a Glasgow venue. • Joyce and Nick live in the Caribbean and wish to sit at a Caribbean venue. • Jasmine lives in Hong Kong and wishes to sit at a HK venue. • All have decided to sit a computer-based exam, except for Carol-Anne who wishes to take a paper-based exam. • Each student logs into myAccount and navigates to exam entry. Once they have selected their exam and the exam they wish to take and their eligibility is confirmed, they each select the venue which is most convenient for them and choose an exam session from the available dates and timeslots shown. • As each of the students select an exam session and successfully completes payment, the available capacity at their chosen venue is reduced accordingly. Upon successful acceptance of their exam entries, students receive confirmation and full details of what to do next (e.g. venue directions and any authentication details which they will need on the day of the exam). 26Solution Design & Procurement Approach01/04/2014
  27. 27. Sandpit Scenario – Students sitting the Exam • After having entered for the exam Andy moves to Hong Kong and needs to change his exam booking from a Glasgow venue to Hong Kong. Again, this automatically updates the available capacity at both Glasgow and Hong Kong. • On the exam day, Emma arrives at her chosen venue and time slot (9am). The exam centre authenticates her identity, checks her in and then shows her to her workstation. • When instructed by the invigilator Emma enters her security credentials into the assessment system and is presented with the correct exam version (as per her time zone) and begins her exam. • The exam that she sits is the same version as that sat by Andy at 2pm local time in Hong Kong. During the exam a fire alarm is activated and the exam centre is evacuated. Emma is allowed to return to her workstation 20mins later and her exam is restarted where she left it with all previous responses retained. • When the exam is concluded all Emma’s responses and marks (where automatic marking has been possible) are automatically stored and sent to the Examiner along with associated data for manual marking (where auto marking has not been possible). • The Examiner uses the information received to conduct statistical and process analysis on automarked responses and sends written responses for expert marking. The Examiner processes the final marks and sends results to its students. 27Solution Design & Procurement Approach01/04/2014
  28. 28. Sandpit Scenario – Exam Centre set-up • In advance of each exam session the exam centres enter their available capacity into the online capacity management capability. • For the December session the Glasgow venue has 4 seats available, Caribbean has 3 and Hong Kong has 1. • Throughout the exam entry period the Examiner monitors the consumption of the available capacity via capacity management dashboards. It is noticed that the single Hong Kong seat is booked and therefore an additional seat is sourced and made available. 28Solution Design & Procurement Approach01/04/2014
  29. 29. Sandpit Scenario – Exam Production • The December session will be the first time F5 is available in a CBE format. The Examiner monitors the F5 item bank (showing “low stock”) and commissions approved Item Authors to write specific items • Sharon, an author who lives in India, accesses the secure authoring system from her home windows PC, creating 2 different longer style questions using the template provided, includes the initial set of question attributes (topic etc.) and submits to the Examiner. • Sharon’s 2 questions are automatically routed to Catherine, who is the specialist reviewer for all questions from this syllabus area. Like Sharon she is external to the Examiner and accesses the reviewing system remotely from her home Apple Mac. The communication between Sharon and Catherine’s devices and the authoring system is highly secure: their access to the system is subject to robust authentication and their access is controlled and audited. • Catherine reviews Sharon’s questions, edits them as necessary and adds comments; she marks it as reviewed and the production system automatically adds it to the list of items to be reviewed at the next relevant exam panel where it is reviewed, amended & accepted. • A member of the Examiner exam production team changes the status of the questions to ready for pre-test and they are banked ready for inclusion within a pre-test exam. • A pre-test exam is generated and sat by a small number of students at an exam centre. During the pre-test all responses and associated data are collected and submitted to Examiner (potentially along with qualitative feedback). • Examiner analyses the pre-test data and calibrates the questions. • Throughout the author, review, acceptance and pre-test process, the system prevents any leakage of content to the Internet or access by unauthorised persons. 29Solution Design & Procurement Approach01/04/2014
  30. 30. Sandpit Scenario – Exam Production • Following pre-testing a member of The Examiner exam production team changes the status of the accepted questions and they are banked ready for inclusion within a live exam. • In advance of the December exam session the F5 QTA (Qualifications Technical Advisor) requests several auto generated F5 exam versions: one to be offered as the paper-based exam and the others to be offered as computer-based exams. The system generates the draft exams using the F5 balancing rules. The F5 QTA and Examiner review the first exam version and decide that one of the longer style questions should be changed. They search the question bank and select a different question and edit the exam version. Once both the QTA and examiner are happy with the exam version its status is changed to published. Throughout this process, access to the system by The Examiner exam production team, QTA and Examiner is secured, authenticated, authorised and audited. • This exam versions is published both in a format suitable for offering as a Computer Based Exam as well as in a format that can be sent to Examiner’s security printers for printing. • Examiner’s Exam Production team regularly review the operational status of content production and chase Authors which are behind with their commission, thereby ensuring that the overall exam production schedule is followed. 30Solution Design & Procurement Approach01/04/2014
  31. 31. Sandpit Scenario – Exam Centre/Invigilator • In advance of the December exam session the Glasgow venue downloads all necessary software and exam content. On the morning of the exam they perform a diagnostic test to ensure everything is working as required to successfully complete the exams. • During the exam the invigilator monitors each workstation within the room from their own workstation. A fire alarm is activated, at which point the invigilator stops the exam and evacuates the centre. After 20 minutes all candidates return to their desks and the invigilator restarts the exam. • After the exam, the invigilator or centre administrator uploads student responses and any exam day reports and ensures that student attendance information is correctly recorded. Exam day reports include both details of the fire alarm incident as well as details of an incident where they noticed a student attempting to cheat by copying responses from the student sat next to them. • The centre administrator then validates that Examiner has received all the necessary response and data files, before removing all exam content from the exam centre’s computers. 31Solution Design & Procurement Approach01/04/2014

×