Author: Colleen Berish

Agile Framework – a Different Method of Elicitation

Written by Colleen Berish on September 5, 2017. Posted in Articles.

Elicitation can be tricky. Generally, stakeholders know something needs to change or must be created but….

may have a difficult time articulating what that looks like, which makes it difficult to design a solution that adds value to a business process or software system.

After working as a business analyst in IT software development for seven years, I made a career move to learning and development (L&D) for a newly developed division in my existing company with close to 200 people. I became a training department of one. One of my first directives was to figure out how to accelerate the training process because the division expected to hire more than 75 people in the next two years in the midst of 45% attrition due to retirements and a challenging business environment.

The biggest transferrable skill from business analyst to learning guru was the elicitation and collaboration process. In L&D, it’s called a needs assessment – in my case, this meant determining what a division of five distinct departments needed to make training faster and stronger. Sounds easy, right? The challenges resembled every IT project I had worked on in the past. Department leaders didn’t have time to devote to the process, the managers wanted a magic bullet or easy fix and finally, the managers thought the existing process was working. My analyst instincts were on high alert.
My first step in the elicitation process was getting the right people into the process and clearly defining who would benefit most from a change in the process. The people who had the most at stake were the front-line employees in the individual departments. This group would gain the most by getting trainees up to speed faster than before, enabling the trainee to become immediately effective, in turn, increasing the productivity of the entire team.

The next challenge in facilitating the elicitation process was getting a group of diverse employees to quickly brainstorm the problem and identify their needs while recognizing that each department had a distinct set of business processes and represented a different step in the workflow.

The elicitation for the problem was scheduled to occur over three, one hour sessions. For the elicitation process, I utilized a concept from David Crowther and Jim O’Loughlin and the Agile Performance Group called the Agile Framework for Facilitating Strategic Conversations. The process is designed to gather information from stakeholders in a way that removes the tendencies of bias, emotional decision-making and fear of risk. A power facilitator (me!) works with a team of people in a three step, diagnostic process. The process promotes openness and collaboration, where all participants brainstorm ideas and everyone has equal input into the process. We used a series of three brainstorming questions to discover the root cause of the stated problem (how can we accelerate the training process), describe the ideal solution and come up with valid, valuable and implementable solutions. The first step determines “Where are we?”. Stakeholders independently consider where they are in relation to the problem – in other words, what is the current state?

After my first elicitation session, it quickly became clear that the roadblocks were bigger than making the training process faster. The stakeholders quickly identified the real issues – the departments had no structure to the training process, trainers were not equipped to train successfully and there were no tools or documentation for the training process. The added challenge was that each department’s process and tools needed to be consistent among all departments, even though each performed a distinct function. Our problem had suddenly changed from making the process faster to making the training process structured…a problem that looked very different than making it faster.

After all stakeholders agreed on the “where are we”, the group moved onto to the second question in the process. “Where do we want to be?” This is where a good business analyst or power facilitator is the most crucial – encouraging the brainstorming process so that all stakeholders have a voice and are willing to buy into the final, desired product. The group came up with four key areas of development:

Materials, documentation and videos to support a hybrid self-guided and trainer led program
Trainers who have the tools, qualifications and desire to be a part of the training process
Milestones and checklists so trainees, trainers and managers can visually see where the trainee is during the training progression
A structured on-boarding process for all new employees.

After the team confirmed the elicitation results (the desired end state), we went to work creating a task list and process map for next steps. The department stakeholders broke into functional teams to design what we’re now calling the Training Framework. Phase 1 of the framework has been successfully implemented and components include a training checklist with clear milestones, a Train the Trainer certification and an onboarding outline with courses designed to introduce teammates to the company and the industry. Phase 2 is underway and includes the documentation and tools required to support the training process.

Although the stakeholders were not well versed in business analysis, by providing a frame of reference and a clear understanding of where we wanted to be, we were able to incrementally develop and implement a useable product over the course of three months. Had we not taken a step back to look at the real problem, the solution would not have met the real need of the division. Engaging the stakeholders in the business analysis process guaranteed the desired outcome that meets the needs to the employees and the department as a whole.

5 Tips for Successful Lessons Learned

Written by Colleen Berish on July 20, 2016. Posted in Articles.

Call it what you want – look back, reflection, retrospective or post-mortem – but an effective lessons learned session is sometimes harder to come by than most people realize.

During most projects, best case is that people are able to identify problems or roadblocks and fix them quickly; worst case is most people are heads down in the actual work and don’t stop to think about what might be going wrong or what might work better. Or somewhere in between. For longer projects or multi-phased projects, lessons learned sessions can make the difference between future success or status quo.

Holding a Lessons Learned session has many challenges. There is always the danger that it will deteriorate into a complaint session or that people only remember what happened in the last week or two of the project. Successful lessons learned sessions are held with some degree of frequency throughout the project, include all working members of the team, even if individuals have moved on to other projects and be an organized part of the overall project plan.

1. Capture in the moment

Use google docs, company wiki, outlook task or note, email to yourself, running list in a spreadsheet or even writing in a special notebook for those of you still like pen and paper. It’s important to capture the details of what happened, why it was good or bad, the impact of the event and how to avoid it or promote it for the future. Otherwise, you might end up forgetting, exaggerating or blaming.

2. Encourage openness

The only way the feedback is valuable is if people are encouraged to be honest and open about how something went. If someone really feels like they can’t speak up, you probably have a bigger problem.

3. Plan ahead

Outline the lessons learned process at the beginning of the project so the entire team understands how the information will be used. Define the timeframe (every three months we will have a lessons learned), the structure (identify an event and the impact) and how team members should capture the information (see #1).

4. Summarize

For the actual meeting, provide a summary of common comments, solutions or tasks that should be entered as future best practices. Don’t call out any one individual’s comments. Center the discussion around the summary points.

5. Implement

Have the team figure out solutions and how to best implement, then assign tasks. Get buy-in and commitment from group to do what will make the project better. Lessons learned only work if you actually use what you learned (duh!).

It’s also important to communicate best practices to a larger group or team. Depending on the size of the organization, many lessons learned can be packaged for other teams. Try to keep tools and summaries in a central place for future reference.

My own personal experience with lessons learned came from working on several high-profile corporate initiatives in a busy IT department. As a participant, I witnessed several sessions degrade into angry finger-pointing sessions. As a first time Quality Assurance (QA) lead on a highly visible project, I set the expectation at the beginning of the project in order to get quality feedback. The first time one of the QA’s came to me with a complaint about something, my response was, “please write this down on a document or as a task so that we can make sure it doesn’t happen again.” After addressing whatever issue was causing the complaint, I moved on.

For each iteration (usually monthly), our team got together and discussed issues and what we might change in the future. Then we assigned actions items to those things we knew we could fix, brainstormed mitigations for risks we couldn’t fix and documented everything for future iterations of the project.

In order to solicit feedback that is constructive in nature, I also kept my own list of issues. Sometimes, the items on my list were the result of an emotionally charged confrontation or failure in one part of the project – either a team member or a business partner who wasn’t fulfilling their role responsibilities, personality conflict or an area where I failed to recognize an issue, which then escalated. When I reviewed the list before holding the meeting, several topics usually fell off the list because my temper had cooled down a bit and I recognized that it would not be a productive topic for the look back. However, many of the items on my list also made it onto everyone else’s list which provided the starting point for conversations during the session.

Lessons learned provide a huge opportunity to improve individual projects and institutionalize best practices uncovered during the process. Harnessing the best ideas and suggestions from the team is the easiest way to get good results for the future.