Workshop 21st March 2017 Sheila Fraser EST080 Lessons Learned Workshop 21st March 2017 Sheila Fraser

Workshop Purpose Identify key lessons from the EST080 Estates Helpdesk Project Suggest solutions for discussion Breakout groups Share draft ‘straw man’ proposals Pull them apart and make them better Share improved proposals for agreement Identify any actions to be taken and owners Focus on the positive to enable us to undertake the next project more effectively Explain action board & parking lot. This means changing the way we work in a small or large way – that’s probably everyone here, not everyone else changing!

Agenda Workshop Purpose Key Lessons Learned Short Break Breakout Sessions Key Lessons Review Issue Management Process & Release Management Environment Documentation Project Breakout Reviews Action Summary & Close 09:10 09:55 10:25 10:50

Key Lessons Learned The whole team should understand the standard project development process: The associated roles, responsibilities and tools used need to be clear for each stage in the project Proposal You’ve gone through all of these stages, and are in closure. This is called a ‘waterfall’ project methodology as each stage is dependent on the previous one completing. We assume that the business have a business case in relation to the proposal, this is often wrong. Use this picture to help explain what the lessons relate to in the top right hand corner. Sorry this presentation is wordy – it’s also for a breakout group and a takeaway. Some of the lessons have been for individuals – those I’ve discussed with the individuals rather than share them here. Wider lessons I have included. A number of additional lessons learned were identified in this process, the ones highlighted here are key, or recurrent, or cross-cutting ones which have practical steps that we can take to address in advance of the next similar project.

Lessons and Suggestions – Project Proposal Significantly under-estimated complexity e.g. mobile not mentioned! Business spend more time thinking about what is needed and genuinely detailing as much as possible in the proposal IS ask a lot more difficult questions about what is really needed at proposal stage Proposals list affected roles to prompt understanding of potential complexity The business case is crucial in gaining support Every project takes a lot of time from people who already have day jobs - every proposal should have a business case that makes it clear what is being done, why, the expected costs and benefits, and this is used to help gain buy-in to the project The business case should be revisited at every change in scope to check if it’s still valid Include cost of back-filling key positions for duration of project to avoid day job impact

Lessons and Suggestions – Project Proposal Had multiple assumptions: The ‘out of the box’ module would require minimal configuration The business requirements will be required to match the ‘out of the box’ solution Many undocumented, e.g. use of mobile technology and 3rd party supplier, no data migration, low risk Document ALL assumptions in proposal IS seriously query if those assumptions can work in the reality of a project with stakeholders with requirements Project team validate or update these at project brief – any assumption is a risk to be actively managed Associated costs were not listed or estimated, e.g. mobile technology Least list things that may need to be purchased, e.g. mobiles, to get a sense of scale of cost – relates to business case

Lessons and Suggestions – Project Brief Proposal Lessons and Suggestions – Project Brief Lesson Suggestion Still significantly under-estimated project complexity Separate similar projects into stages: Known scope with detailed 3-point estimate Research and development Checkpoint for re-evaluation and re-estimation Expected, but unknown scope with high-level 3-point estimate until checkpoint Scope changed significantly from proposal Review roles to determine all those likely to be impacted Develop clear view of stakeholders and high-level communications plan considering roles from the outset Review, and revise the business case if necessary Identify key risks to the project Undertake this with the business, in particular to include any business projects that may impact Expand on each task in 3-point estimate to understand risk of best case turning into worst case Include additional tasks with best case estimate 0 to mitigate risks where appropriate.

Lessons and Suggestions – Project Brief Proposal Lessons and Suggestions – Project Brief Lesson Suggestion Senior engagement is essential Projects are owned by the business to implement a business change, facilitated by the project team If the sponsor is not fully engaged then consider stopping the project until this is in place Project Manager understanding is essential Project Manager speak to business about what they do and why to understand the context of the change Business explain all of the roles that may be affected by the project, and how (high level) All roles involved as stakeholders, including end-users Identify escalation route Identify how and when to escalate issues during project, considering business timescales Consider simple project board: Project Sponsor, Senior User, Project Manager Estimate associated costs As minimum list things that may need to be purchased, e.g. mobile technology

Lessons and Suggestions – Analysis (Requirements) Proposal Lessons and Suggestions – Analysis (Requirements) Lesson Suggestion Original expectation of business requirements being changed to match technology was not realistic Involve key business people in discussions at proposal stage to determine realistic view of what is needed, and key risks, assumptions and unknowns Data migration needs to be considered early on Even for ‘out of the box’ implementations determine what types of data are likely to be needed at analysis phase, and estimate time for migrating or populating data Assume old data needs to be cleansed, and this will be a low-level, detailed and time-consuming task Load testing needs to be considered early on This was in the project from the start, a good step It’s a really good intention to change the business to match the requirements: this take into account best practice which is inherently coded into software that has been developed over time with multiple different customers. It’s hard to do in practice as it means a much bigger change in management and staff thinking.

Lessons and Suggestions – Analysis (Requirements), Design & Build Proposal Lessons and Suggestions – Analysis (Requirements), Design & Build Lesson Suggestion Identification of the business lead was really positive Clarify the role and responsibility of the business lead, and estimate the time likely to be needed – on top of day job Business were not clear on requirements & business requirements changed frequently Facilitate requirements workshops, with potential models of operations, thinking through to ‘what does this look like on day 1’ to gain agreement and final sign-off Involve all affected roles Use change control Relate changes to business case Use methodology: stage containment, i.e. do not move onto next stage (systems analysis) until previous stage (business analysis) agreed and signed-off – otherwise there is a high, real, risk of re-work and increased cost Share ‘V’ model of waterfall delivery early on

Lessons and Suggestions – Integrate, Accept, Deliver Proposal Lessons and Suggestions – Integrate, Accept, Deliver Lesson Suggestion Big bang go-live is a high risk strategy Phase rollout wherever possible – e.g. pilot in a small area, or start by function Consider business rehearsals, mock-up on non-working day to trial Development, Test and Live should be the same Environments should be consistent, and ideally refreshed from live before the project starts Check Dev and Test are the same before UAT starts Good code source control makes a world of difference Progress was much more effective once EBIS Online was in source control Have a separate project to move Archibus Client and Web Central into source control before the next business project Legacy systems are largely undocumented Take time during analysis to document all of the systems and interfaces involved before starting any new build Share the high-level picture with everyone, including Mass

Lessons and Suggestions – Integrate, Accept, Deliver Proposal Lessons and Suggestions – Integrate, Accept, Deliver Lesson Suggestion Legacy data may need cleansing Assume that the live data is many years old, and may need cleansed before it can be used for anything new! Mass time largely spent on investigating issues Have consistent, documented environments Use version control for code and files Use change control to document business change, and associate this with the version control in environments Mass document changes and version control, and fully document how and where to implement steps All need to understand what changes are applied in which environment An estimated 70% of recent Mass calls could have been avoided Focus on enabling help desk staff to resolve calls, Mass is a last resort Agree who can raise calls with Mass, and backup cover

Lessons and Suggestions – Closure Proposal Lessons and Suggestions – Closure Lesson Suggestion Every project will close! Explain the transition to normal support procedures and tools much earlier Consider the ‘good enough’ approach for final fixes – the business case for small changes should be positive Project reviews are helpful Project closures review and suggest improvements for future projects Review lessons learned from large projects before starting, many lessons are applicable to small projects

Lessons and Suggestions – General Proposal Lessons and Suggestions – General Lesson Suggestion What does success look like? Clear view of what success is at start, at checkpoints, and project team buy-in Team ownership & engagement is critical Strong (trained) project sponsor, championing the work Clarity of roles and responsibilities (and likely time commitment) Environment is unique Reduce customisation where possible & influence Archibus software development process Speak to other Archibus users to compare & learn Use appropriate tools Jira was great for issue management – process to transition to support mode (unidesk) should be clarified No formal 3-point estimates between project brief (Oct-14) and delivery (Nov-16) Re-estimate project (3-point) at each major change of scope, and at end of each stage Re-evaluate risks, roles, actions and processes to identify ways to improve working at such points Use difference between best case and worst case to identify risks to be managed, and potential new actions

Practical Next Steps - Highlights Project to document the technical environments Refresh data from LIVE Include logins for Mass / visitors and procedures for how they work Share with Mass Process to triage new issues (project / support) Aim to reduce calls to Mass by 50-70% Aim to reduce Mass time investigating issues by 50-80% Aim to meet SLA turnaround times for support level Process to implement fixes from Mass Business description of change Full description for implementing changes, including full locations for files

Agenda Workshop Purpose Key Lessons Learned Short Break Breakout Sessions Key Lessons Review Issue Management Process & Release Management Environment Documentation Project Breakout Reviews Action Summary & Close 09:10 09:55 10:25 10:50

Breakout Groups Breakout 1: Review and Improvements (Front) Grant Ferguson Derrick Matheson Paul Munro Zoe Stephens Breakout 2: Issue Management & Release Management (Back) Colin Pritchard Pauline Smith Chris Lawford Maureen Masson Mike McMonagle Anne Finnan Andrew Taylor Breakout 3: Project to “Sort out the environments” (Next door) Thalia NikolaIdou Jane Brodie Ron McLeod Mark Lang Martin Matt Andy Stewart

Breakout 1 Notes – Review and Improvements Objectives Review the lessons learned Identify any major gaps Suggest additional solutions – practical things we can actually do Identify action owners for solutions

Breakout 2 – Issue & Release Management Ongoing issue management process Review the process for raising issues from OLA Identify any major gaps/issues and propose solutions Agree updated process Release management process – next project Database refresh before starting project What’s the best way to implement change control? Across Dev > Test > Live & considering rollback Code, database, mapping, configuration, file locations Patching and live support issues Assume long timescale

Breakout 3 – “Sort out the environments” What tasks are needed to get Dev, Test and Live into a good position for everyone to be able to work together effectively? Standard software documentation: architecture, schema, interfaces, APIs? UoE-specific additions? Hacks? Reversing hacks? Configuration of the software? Historical tables? Archives? Get EBIS, Archibus (desktop client), WebCentral into svn and bamboo deployable? Or git server? Version control? Change backdoor ability to make database changes through client (to avoid future discrepancies)? Master passwords and appropriate access? Who is responsible for undertaking each task? Breakout 2 covering release management process EBIS Online is on svn and is Bamboo deployable. Need to put Archibus in there as well, and WebCentral.

Agenda Workshop Purpose Key Lessons Learned Short Break Breakout Sessions Key Lessons Review Issue Management Process & Release Management Environment Documentation Project Breakout Reviews Action Summary & Close 09:10 09:55 10:25 10:50

Agenda Workshop Purpose Key Lessons Learned Short Break Breakout Sessions Key Lessons Review Issue Management Process & Release Management Environment Documentation Project Breakout Reviews Action Summary & Close 09:10 09:55 10:25 10:50

Takeaway: what is project success? Knowing where you want to get to Knowing how to get there Knowing that you have arrived Vision/Strategy Objectives & Benefits (Business Case) Acquiring new capabilities Embedding them within culture, practices and behaviours of organisation Creating enablers + business changes (Project Delivery) Minimising the impact of dis-benefits Measurement of benefits realised (Performance Management) Time (Milestones) Cost (Estimate) Scope (Quality)