Last night I had the privilege of facilitating a session with Yohan De Silva about Agile and Change Management for the South Australia Chapter of the Change Management Institute. Much like the projects we all work in, the session I had planned to run and the session I ended up facilitating were a little different.
I had planned for the group to work through a few case studies and we debrief at the end… we ended up with a much more organic session with me walking through one of the case studies (inspired by one of the projects I have worked on) and answering questions through the session. I have to confess that I hadn’t really prepared to present the session that way. So I thought I might clarify some of the points and learnings from case study and other experiences from delivery projects using Agile.
In the case study I used, I was working as the Senior Project Manager for one of two client facilities in a statewide programme of work. My first fatal error was believing that my change management experience would make this role a walk in the park. I learned more about myself, my ability (and sometimes lack of) to lead teams and stakeholders as a project manager than I ever have as a change manager.
The fundamental difference between a project manager and a change manager
The project manager is front and centre. It is a much more visible role than a change manager.
I believe this is how it should be because change should be about leading through influence. It’s a role that provides support to the ‘change champions’ and the project manager to navigate the change. They provide the mentoring and coaching, they assess the change impact, provide expertise on the most effective ways to communicate and engage with stakeholders and work with the change champions to plan the transition and make the transition. It’s done this way to ensure that that the business has the capability to sustain and reinforce new behaviours once the support structure of the project has finished. I’ll say it again, a change manager should not lead from the front, they influence and support the business to lead the change.
The project manager is there to keep the project and team on track. Leading from the front provides powerful optics that the project is in control and gives the stakeholders confidence that the project will deliver the stated outcomes and benefits.
Managing an agile work package in a waterfall planned programme
In his session Yohan mentioned that Axelos launched PRINCE2 Agile. I totally agree with his comments that it feels like an oxymoron. The first time I saw PRINCE2 Agile, I was convinced the friend who sent it to me was trolling me. It was the funniest thing I’d seen in a long time–until I realised that they were actually serious.
All jokes aside, it’s similar to what we’ve been doing in development in IT project settings for forever, it’s just formalising it into a methodology. Governance is often a challenge in Agile projects and PRINCE2 definitely provides a solid governance structure.
There was a question asked about managing governance in Agile projects. I don’t think that there are any hard or fast rules here. Yohan provided some great examples from his client projects and was also quick to reiterate that effective governance must align with the maturity of your organisation and support quick decision making that is such a critical factor in Agile projects.
I want to expand on this a little further and suggest that it also comes back to how your project executive/sponsor and senior users are inducted into the project. It’s something that we (me included!) are not always great at and at times overlook. It makes such a difference to the journey we go on with them. Providing a basis of how the project will be run—the tools, techniques and process—manages their expectations and makes it a more predicable experience for them. It makes it easier for our executives and senior users to advocate ‘we’re doing this differently’ and champion the approach within the operational context. Executive sponsorship is such a critical aspect of being able to deliver effective change in organisations. Stack the deck in your favour—invest the time in inducting the executive and senior stakeholders into our world of project delivery, make it theirs too!
In the context of my case study. We were delivering within a waterfall planned programme. We were delivering one module of a statewide medical record in collaboration with another hospital. The programme’s planning approach was an effective way to control multiple sites, multiple go-live dates and all the other glorious planning considerations that go with high impact, statewide implementations.
Both hospitals had been using an older version of the scheduling module in their outpatients’ departments for 10-15 years. Both hospitals had their own instance of the application (a version that was only used by that hospital). Like all home-grown solutions it was highly customised which had grown and evolved with the hospitals and was an integral part of how their outpatients’ departments ran. There were a lot of assumptions made about the new version as ‘it was just a code jump’ and a ‘like for like’ implementation.
One of the assumptions that was made was around operational reporting. Part of moving to the statewide solution (a single statewide instance of the application) meant that the customisation (and flexibility that comes with that) had to transition to statewide governance module. Both hospitals had assumed that we would be able to transition our operational reporting to the new instance with a little bit of clean up.
This assumption was quickly challenged…
- It wasn’t going to be as simple and migrating the code. There were some foundational differences in how the new version was configured and its underlying core code structure. In non-geek speak, it was going to take a lot more time and effort that we thought!
- Between the two hospitals there were hundreds of reports… all of which we were told were critical to each unit to manage their clinics and do business!
- We were against the clock. Something that we thought was going to be code migration turned into significant redesign and development work. Being part of a statewide program meant that we were allocated certain blocks of time in the development and testing environments. And the clock was ticking!
- The redesign work meant that we had to agree on a common set of operational reports, partially due to the time we had for development and more importantly the overarching design principles of a statewide standardised solution.
What’s a project manager to do?
This was yet another thing we had to deal with. At this point I had been on the project for just under a year and it had been running for a reasonable period before I joined the team. After that sinking feeling in my stomach subsided, the project managers all got together to work out how we were going to do this. There were four of us (two hospitals, the program assigned project manager and the vendor). We already had a lot of learnings from collaborating on the overall solution design and normalising other aspects between the two hospitals. It had been a long series of workshops, robust discussions and negotiations. We simply did not have the time to use that approach.
The other hospital had started using Agile is other aspects of the project delivery not related to this program of work. It was suggested that we use an Agile development approach to design and develop the operational reports.
Initially I was not thrilled with the idea. My limited experience with Agile to date told me that it was going to be a developer-led exercise and a great excuse to skimp on the documentation. Remember we were working within a PRINCE2 and MSP framework and its glorious expectations of documentation to satisfy stage gate requirements. I’d just seen the gateway assurance process one of my colleagues had to do for the first release of the programme and I wasn’t convinced that we would satisfy the gating requirements using Agile. (At this stage of my career I had never seen an Agile team produce any robust form of anything let alone as-built specifications.) To say I was cynical and sceptical was a bit of an understatement. With no other viable option, we pulled together the relevant briefing materials (not very Agile!) and got approval to change tact.
Structuring an agile team
Yohan and I had a few questions about structuring Agile teams – what’s the ideal technical, business, experience mix?
I think the key to agility in project teams is a mix of experienced project professionals and experienced business representatives embedded in the project team.
In this particular project I had an incredible team! I’m totally ok with my highly biased view because they ROCKED! It was a really tough project. The experienced project practitioners on the project will all agree with me that more often than not, it felt like the deck was stacked against us. In spite of that, we had a lot of fun and I am so proud of how we worked together and what we delivered. We became a well-oiled dynamic team–clinical, administration and geeks–collaborating to develop a solution that was well received.
We seconded business representatives from the team managing the current operational support for outpatients, senior administration officers from the areas of the business using the application and a clinical nurse who used the application to manage patient side of things. What was there level of project experience? Well it was about as much experience as they had in IT. We went on quite a journey J The project practitioners learned just as much if not more than the ‘business’ people on the team.
By the time we got to the reporting work package we had hit our groove and changing methodology approaches part way through the project was a bit of a curve ball. In hindsight I think the design, build, test iteration of the Agile sprints was a welcome break after we had worked through the teething problems of new terminology and ways of structing tasks, defining requirements, and interacting with the technical teams. After months of working in a waterfall design stage for the core configuration (with very little to show for it in terms of being able to touch and see an end product), seeing ‘quick’ deliverables of each sprint were a great source of motivation for the team.
Structuring the sprints
As I mentioned, there were literally hundreds of reports between the two hospitals. Having their own instance of the application meant that historically they could accommodate all the individual differences and preferences of the end users. This was just not possible moving forward.
When we first brought the two hospital project teams together to start defining the user stories, priorities and backlog there wasn’t a whole lot of agreement. Not that surprising given we were asking them to ‘give up their individuality’ or at least that was a strong perception playing out. Needless to say, we were off to a bit of a slow start.
I’ve already told you about my amazing team. We had the most incredible Business Analyst. I don’t think there was a problem this wonder woman didn’t have or find a solution for. In between these initial planning sessions, she pulled together all of our hospital’s reports and we worked with our business representatives to pull out all of the common data elements. When the two teams came back together, this discovery step gave everyone a clear view of what we had in common. The two teams could then start to discuss why the differences were there and what was actually needed for either work flow or clinical reasons.
From here there was an agreement to start of the reports for the more routine clinics which all used a similar report format while they continued to unpack what was needed in the report to support the more complex clinics. This meant that we were able to deliver a proof of concept user interface and report template within the first four(ish) weeks and get feedback from end users during the sprint preview.
Managing expectations around Minimum Viable Product
I have a love/hate relationship with MVP. The concept of minimum viable product (MVP) is developing a product with just enough features to gather validated learning about the product and its continued development. Crudely put, you build something that meets basic business requirements, deploy it to the real world to start using, learn from it and then build the next iteration with improved features and workflow.
It’s mostly an easy sell for the executive and senior management layer because it’s about quick results, moving forward, learning lessons early and in many respects minimising risk.
From a project delivery team’s perspective, MVP is motivating because you’re getting runs on the board quickly and able to incorporate your learnings quickly. There’s very little that’s more powerful for a project team than consistent delivery and momentum!
May I suggest that end users really, really, really don’t care about any of that… people who have experienced IT projects have experienced the many promises that the new shiny solution brings. They have also experienced those promises being broken time and time again with ‘that will be fixed in the next release’, which may or may not ever happen.
MVP is a hard sell to end users! Over coming this perception can be quite challenging. My only suggestion here is to maintain momentum and honest, regular communication. Shock, horror. It’s about your engagement strategy and demonstrating through action that this is different to how things have been done in the past. Be as consistent as you possibly can, both in your delivery and communication.
How do you manage change in a sprint structure?
A change manager in the audience asked me how we planned the change during the sprints. My first response was not well. I had a lot of lessons from this exercise. I got caught in the trap so many project managers do and bent to the time pressures at the expense of stakeholder engagement. I beat myself up a lot for this, because of the all senior practitioners on the team, I should have known better.
Let’s face it—it’s pretty hard to get excited about reports. I mean they’re useful and are pretty important to how we run aspects of business areas. But really, there’s still nothing terribly exciting about a report, particularly when what you have works perfectly and has been tweaked and improved over years of use. We were also having to manage the perception of ‘I’ve already given a lot of ground’ during normalising other aspects of the solution. Consider that a lot of the time change management has very little to do with managing the reality; it’s about managing the perceptions of the stakeholders. After all perception is reality for that individual.
Engagement in the health has unique challenges and is rarely simple. Pulling people out of their day-to-day is generally at the expense of time with a patient. Engagement is almost impossible without sufficient notice so that they can reschedule patients or back fill supporting roles.
Working in the mindset of ‘time = patient care’ you have to be absolutely clear on what input that you are asking the clinician to provide. (This is the same for any time of engagement with all of your stakeholders by the way). Hospital staff (admin, doctors, nurses, allied health, orderlies) are busy people focussed on what’s happening with their patients. Does it have to be face-to-face in a workshop or is there another way you can get their feedback in the timeframes that you need it in? Can you hijack an existing team meeting to minimise the impact on their time?
Another interesting facet and important consideration when planning your engagement is that even though you’ve been told to engage with someone senior in a speciality or department, a lot of things don’t require input from a senior clinician. Someone more junior with a slightly more flexible schedule may be able to provide the insights that you need to continue. Another little tip—always let the senior someone in that speciality or department make that call. And never assume that because they delegated something in earlier consultation that they will automatically do it again.
So how did we do it? By learning a lot on the way. As I said it’s pretty hard to get people excited about reports. And we had to work with primarily with the expertise seconded to our team because of the challenges with pulling people offline at short notice. Getting people who are indirectly involved with dry content excited and to want to engage isn’t easy. We learned to get creative in our communication and engagement approaches.
Possibly the coolest part of reporting work package was the new graphic interface that we developed. Users we able to select their department, clinic and report template that they wanted and the report would generate. It was really flexible, worked beautifully with the user profiles and task access so people could only see and do what their profile let them and a very ‘modern’ edition to the application. This was met with some mixed feelings because it was totally different to how they currently did things. In their current way of doing things they would just select the report name that was specific designed that that clinic.
We developed a few videos of our project team members using the new interface and circulated the new report templates. Tools like Camtasia allow you to capture the activity on your computer screen and include a voice over. It is such an awesome way to demonstrate to your users what they can expect. Using your business people on the project team gives the videos an added element of credibility (and it helped that they were excited about the new interface and thought it was really cool!). It’s also a medium that users can access in their own time or be played at one of their team meetings. There are cheaper and free tools out there. Check them out!
I said we learned a lot on the way. People were viewing our videos. Perfect! We were developing interesting and getting people excited (or as much as you can about reporting). People were sending in feedback which is when were discovered that some clinics had automatic printing rules in place. Essentially when they started their shift the day’s reports were sitting on the printer for them ready to go. There was a bit of kick back because it wasn’t included. This wasn’t a requirement that we had identified in earlier sprints. We incorporated it in a later sprint and won some Brownie points.
Possibly my biggest learning about change management in a sprint structure is to include it in each of your sprints. Allocate story points to the tasks, define your success measures in the user story. Engagement and communication is such a critical part of what we do it projects and sometimes it gets overlooked in the sprint planning process. We did, and I should know better!
In summary
- Stack the deck in your favour—invest the time in inducting the executive and senior stakeholders into our world of project delivery, make it theirs too!
- Have a dedicated change management resource. While this may sound slightly self-serving, a resource 100% dedicated and with capacity to manage the change, engagement and communication will ultimately make the team’s life easier and keeps the need to engage and communicate in focus during the flurry of getting things done.
- Incorporate your communication and engagement activities and tasks in your sprint. By doing this you are ensuring that there is time and effort allocated to sharing the journey with the people who will be ultimately using what you’re developing. It makes it a considered effort rather than an after-thought and it does come through in the quality of your communication. Your team will thank you for not adding another rush job task to the sprint and your stakeholders will notice the difference!
- Keep learning! One of my favourite parts of using Agile is the retrospective at the end of each sprint. I don’t have all the answers to managing change in any project. Like every other practitioner out there I make fantastic mistakes as often as I get it right. It’s a project because it’s unpredictable otherwise it would business-as-usual. It requires a different way of thinking and doing things to achieve the desired outcome. Be bold, be courageous, be different, take action, learn and refine it for the next sprint.
We had a brilliant turn out and a great mix of change managers and project managers from our sister associations Australian Institute of Project Management and Project Management Institute. Thank you for being the first group that I’ve presented to in Adelaide! I hope that you had as much fun as I did.
Over the last decade Lesleigh Ross has been leading project and change teams in complex delivery environments and transformation projects across public, private and not-for-profit sectors.
Leigh is highly skilled in industry best practice methodologies and frameworks which is demonstrated through her ability to deliver quality business outcomes across ‘green fields’ and recovery projects and programmes.
As a ‘digital native’ Leigh believes delivering innovation in business is only possible through collaborative project design where the business and technical teams work hand in hand. A geek in her own right Leigh is able to “degeek the geek” and facilitate effective engagement through all stages of project delivery.
Leigh is the current Queensland Lead for the Change Management Institute and a proud member of the Australian Institute of Project Management and the International Centre of Complex Project Management. She is active in her local chapters and national interest groups which are focused on improving the professionalism, diversity and inclusion within the project management community.
