Please enable JavaScript.
Coggle requires JavaScript to display documents.
Why do we have too much support? (Developments are not delivering against…
Why do we have too much support?
Focus has been on implementing new systems – eVision use has grown
We've tackled development before sorting out processes - introduced issues into the system that were previously hidden from us
It has been an emergent approach - we haven't designed for scalability (for developments or support) so we are now tripping over ourselves
Skill-sets and the technology itself haven't kept up, things are taking longer than they should
Developments are not delivering against or capturing all requirements, meaning enhancement requests are increasing
Scope of projects are ill-defined, so work is being requested post-project
Processes not always well understood before development, so systems not always delivering to expectations- causing increase in calls post-project
Developers acting as BA’s – focus is technical features over process, so missing important aspects of the process or change that need tackling during projects
Admins acting as BA’s – focus is day job rather than change and project work, so problems occuring post-project
No formal Project Management – everyone is doing the best with the time they have, but confusion creeps into the post-project support process
Focus on projects is deadlines/time over requirements/features – impact of this to the business is not well understood at senior level, but is being raised with Ops as a problem post-project
No formal change management and ongoing process ownership to mitigate impact where requirements deliberately not tackled, so calls raised with Ops to sort out problems which aren't theirs
Not consulting with the right people when putting briefs together – needs people at the coal face feeding in more
Developments are not ‘high quality’ enough i.e. we are introducing too many bugs into Live
Testing issue - work is emerging post-project that should have been dealt with during the project, increasing calls and contributing to the 'hidden cost' of increase in eVision work
Wrong focus in projects (i.e. deadlines (‘time’) comes before ‘quality’), so features, usability and general quality of developments are seen as 'nice to haves', but get raised as issues post-project
Culture issue – in the past it has been seen as acceptable to ‘throw it over the fence’ to Ops when they should really be focussing on BAU
Increased use of contractors has caused quality problems, with developments suffering in quality and limited knowledge once they have left contributing to extended resolution times
Organisation and prioritisation (help-call and incident management) is poor
Calls are being ignored where they’re deemed too difficult – too much escalation after extensive periods of nothing happening, increasing duration to resolution and duplicate requests entering HEAT system
Too much cherry picking , meaning complex calls go untouched and extend the overall response and resolution rate
Motivation is low in some areas, so cultural issues are being ignored in the team (and so are help-calls)
Not enough leadership - solving these problems is seen as too difficult, the message is wrong and not leading by example - systemic issue
We're not following our own processes, adding confusion and increasing length of time it takes to get stuff done
Technical skills are not what they need to be / the mix is wrong
Struggling to support both basic and complex functionality – so keep tripping over ourselves after each Go Live
Ongoing professional development not seen as an important aspect of the role. Lack of growth mindset is hindering progress
Where technical training has been provided, it has proven to be ineffective because motivation to use it is low
Recruited lower skilled / lower paid support analysts to support and enhance systems designed and developed by higher skilled developers - there is a natural knowledge gap
Structured problem solving is poor
Relying on single points of failure, contributing to growing volumes of calls (so not using the breadth of resource available effectively)
Developers spending time solving help-calls, sacrificing time in projects and therefore impacting quality of those developments (vicious cycle)
Not enough root-cause analysis and resolution of underlying issues, so problems recurring frequently instead of being wiped out at first pass
Limited Process Ownership and Change Management
Calls sent to Ops when should be handled by process owners
etc... we know this one in depth..
High business reliance on Training, but this receives poor feedback, suggesting we are not utilising this post effectively
Lack of standardisation
BAU projects should be sequential and easy to follow - but we are reinventing the wheel every year because we're not spending time documenting or specifying procedures, which adds to time spent on upgrades and issues occurring post-upgrade
The goal post keeps changing for technical documentation, meaning there is now disparity in what we produce and how we provide it - still doesn't contribute to better problem solving
Developers have their own methods and styles, meaning Ops need to familiarise themselves with different approaches