You should fully expect that your statement of the problem will change as you learn more about the situation but it's important to start from something if only to clarify why other people would be interested in participating.
I would say that it is not even necessary at the beginning to agree on what the specific problems are but rather only to agree that there are problems and it is worth investigating. It's also valuable to understand where everyone is coming from.
What to Do:
Answer the following questions:
- What is the overall change / improvement / problem you want solved?
- What is the purpose / business reason for change?
- What specifically needs to be improved?
- Productivity?
- Cost?
- Quality?
- Morale?
- What is the context?
- Has anything been done before?
- How does this relate to organisational structure and culture?
- How does this align with organisation strategy?
- What is your sphere of authority and sphere of influence?
Two general approaches to get the answers:
- Do it by yourself and walk around to get feedback, involvement, commitment
- Do it in a group session
Which approach you take really depends on availability of people, local preferences, your preference, timeframe, etc.
Example: Sev 1s; Scaling
(Note that even though I'm answering the questions, I don't need to structure the answer that way. Also, you may not be able to answer all the questions, which is fine. You should expect the answers to change anyway as you learn more. This still helps you setup a starting / talking point.)
Owned by: Bob (Site Ops team lead)
Authorised by: Alice (Head of IT Ops)
Overall Theme: Improve reliability and scalability of our Site Operations team
Background:
- Recent Sev 1 failures not managed well; incident levels have noticeably increased in the last few months
- Staffing growth is linear to revenue growth; un-scaleable cost structure
- The organisation plans to grow by 20% year-on-year
- Improvement attempts started 30 days ago have had no impact and have decreased morale
Example: Conflict between teams; too much overtime; too many projects
- many teams (DBA, Networks, Sysadmins, Service Desk, Release team) often inadvertently working against each other.
- All communication done via helpdesk software and emails, even when individuals sat next to each other resulting in very little collaboration and team work.
- Very large overtime bill with many individuals regularly working a 70 hour week.
- Over 60 projects in flight – prioritisation by “he who shouts the loudest”
- Project Managers going head to head over shared resources and applying unfair pressure to delivery teams
- Teams time-slicing between projects, departmentally struggling to manage many stakeholders and strike a healthy balance between projects, incidents, and BAU.
- Regularly missed deadlines, wasted capacity – particularly around hand-offs, waiting time, and lot’s of partially done work.
Example: Difficult to focus
(Note that this can be very simple as a starting point)
We get a lot of emergent work which makes it difficult to focus on projects
No comments:
Post a Comment