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

2. 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!

3. 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

4. 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.

5. 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

6. 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

7. 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.

8. 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

9. 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.

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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.

21. 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

22. 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

23. 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)