8

Exploring Conference Room Pilots

In the previous chapter, we discussed prototype activities and their benefits and came up with a solid design solution. You gained an in-depth understanding of various prototype stages and categories with practical examples. In addition to prototyping skills, you gained knowledge of the benefits of good prototypes and practical tips that can make you successful at creating prototypes.

In this chapter, you will learn how to showcase prototypes to a wider audience. We will see how Conference Room Pilots (CRPs) help us progress from individual requirements to proposed design solutions in the right direction without any surprises. We also will see how the testing team and the UAT team can benefit from the demos by helping them understand requirements as well as how they shape up into a functional working solution. This helps them come up with possible holistic scenarios and be able to validate the solution.

No project goes entirely smoothly. You will encounter surprises and that’s what makes it more challenging and exciting. The earlier you encounter surprises, the better it will be for the team. This will give your team an opportunity to quickly reassess and understand the business needs better and align the project back in the right direction. This is where CRPs come to our rescue.

We will cover the following topics in this chapter:

• Understanding what CRPs are
• Exploring the timing and participants of CRPs
• Facilitating CRPs
• Managing scope creep during CRPs
• Reviewing the benefits of CRPs
• Practical tips for success

By the end of the chapter, you will have gained knowledge and understanding of the importance of CRPs. You will understand how CRPs can help identify and fine-tune functionality and usability and address any gaps in the requirements via a series of CRPs at critical junctures of the project. Concurrently, you will learn about the benefits that the testing team can derive from this activity.

Understanding what CRPs are

CRPs are workshops where key stakeholders, along with project team members, collaborate at various stages of projects to understand the business needs while transforming them into proposed business solutions. CRPs help stakeholders collaborate and see how their needs progress through each phase of the project, as well as being able to provide feedback. This helps users see what they are getting and keep the process transparent. Also, these CRP sessions help the technical team and testing team understand the needs better, so they will be able to deliver what the business truly wants.

Based on the complexity of the business requirements, the project team can decide when to do CRP and how often to do the CRP sessions. As a rule of thumb, I prefer to go with three CRP stages for a project with medium to high complexity and maybe a fourth one if the project is highly visible and critical or highly critical.

The four stages when we conduct the CRPs are as follows:

• Scope CRP: In this stage, we elaborate on the business needs/requirements. This is done during the plan/analyze phase of the project.
• Design CRP: In this stage, we connect various functional steps and integration points to understand the needs from a design perspective. This is done during the solution design phase of the project.
• Build/development CRP: In this phase, we actually show the users the actual functionality of the system. This is done during the technical development phase of the project.
• Test CRP: This is optional and recommended only for highly visible and very complex functionality. In this phase, we do a complete demo of the functionality, including any changes requested. This is to get all the stakeholders on the same page. Any suggestions or requests for changes are tabled and scoped for future release.

Based on the availability of time and resources, your project team can decide on how many CRPs they would like to do.

The CRPs we discuss in this chapter are critical project activities where the project team plans to do the following:

• Implement functionality on a new system, such as moving from old legacy systems into a totally new system. As an example, during our PRM implementation, we migrated partner data and functions from legacy systems and manual Excel sheets. Users do not know how to articulate their business needs. All they want is a system that they can use effectively.
• The project team implements totally brand-new functionality with a redesigned user interface and user experience. This functionality is very uncommon and your team may be one of the early adopters, such as implementing a partner locator.
• Your business users' needs are critical and highly visible. This is when you cannot go wrong at any cost, and you have dedicated business resources available for your project.

After understanding the various stages of CRPs, now it is time for us to explore and take a look at what point in the project and how often to facilitate the session. We will discuss what participants need to be invited to these sessions to make them valuable and productive.

Exploring the timing and participants of CRPs

For each of the CRP phases, plan to do two sessions. The first session is done mid-way through the project phase so that users get a chance to see how things are progressing. The second one is done at the end of the phase to get an agreement and approvals. The first session will usually be longer and can consist of 1 to 3 full-day sessions. The second session will usually be shorter. You do not need to plan exactly the same duration for all phases as it depends on your business needs. For example, if the requirements are vague, then the scoping CRPs can run for longer. Similarly, if the design is complex, then the design CRP needs to run for longer. In my case, when we did a PRM release, which is a high-priority company initiative, our first sessions lasted a week, where we invited key stakeholders from various regions to collocate in a full-day conference session. The second session we did was a hybrid model as it was too much for users to travel for in-person sessions.

Participant invitations will vary based on CRP phases. Since this session is time consuming, invite only stakeholders and project team members who can add value and are directly responsible for specific functions/capabilities.

A sample simplified schedule of the CRP is displayed in Figure 8.1. Below timeline, we have the project phases with a duration of about 6 weeks. Above the timeline, we have the CRPs planned approximately 10 days after the start of each phase and the second one just before ending the phase:

Figure 8.1 – CRP schedule (sample)

Let’s discuss each CRP stage in detail in the next sections.

Scope CRP

During the scope CRP, we start with a whiteboard and progressively develop it into a simplified process flow where the team gets the opportunity to identify gaps and missing requirements. This is the phase where we develop the as-is and to-be process flows collaboratively with input from business users and SMEs. By the end of the scope CRP, our team comes up with a simplified process flow for one specific functionality in our project scope, as shown in Figure 8.2:

Figure 8.2 – Quote approvals – simplified process flow

We used this process flow as the starting point for our next CRP.

During the scope CRP, invite key stakeholders, SMEs, and only the core project team leads. Developer, QA, and training team members are not required at this stage.

Design CRP

During our design CRP, we refine the flow and create a more detailed process flow and screen mockups. For the user interface design aspect, we can mock up the screen with fields and design the pages and navigation. In our simplified example for one of the functionalities, we came with up a flow from start to finish for a quote approval process with each role doing specific tasks, as shown in Figure 8.3:

Figure 8.3 – Quote approval process

This process helps the stakeholders and the project team, especially our technical team, understand the process visually and be able to come up with all appropriate non-functional requirements.

During the design CRP, invite key stakeholders, SMEs, solution architects, technical architects, tech leads, and core project team members.

Build CRP

During the build CRP, our technical team started developing the functionality of the system. The demo done during the first build CRP will be more focused on the user interface and the happy path (or happy flow). After socializing and incorporating the input from participants, the technical team goes ahead and completes the fully functioning solution with all possible exceptions and error handling conditions. This fully baked product is demoed during the second build CRP. This is where the stakeholders and business users can view and get a feel for the proposed functionality of the system. The business users at this point usually tend to ask for more enhancements and it is up to the business analyst and project manager, along with the project sponsor, to manage and see what can be implemented now and what can be implemented later in a future release. A sample simplified solution for quote approval is shown in Figure 8.4. The figure displays the fully functional quote layout screen with action buttons such as Create PDF, Submit for Approval, and Email Quote:

Figure 8.4 – Sample quote screen with fully functioning actions/buttons

During the build CRP, invite key stakeholders, SMEs, solution architects, technical architects, tech leads, dev team members, QA leads, and core project team members.

Test CRP

The last CRP is just before starting testing. We prep and load test data so that the user can use this data to test various scenarios. This one is optional as you can include this in the design CRP. Since this can be done via remote methods, I prefer to have this so that the business users doing UAT will have an opportunity to understand and see the functionality from end to end. This will result in fewer queries and waiting during the actual UAT phase. A sample screenshot with the output of the quote in PDF format is displayed in Figure 8.5:

Figure 8.5 – Sample quote PDF page

During the test CRP, invite all team members as required. This can be just one session (about 2 to 4 hours) done hybrid (on-site and/or remote).

Spacing the sessions logically and planning them well in advance helps the team members get value out of the sessions. Their active participation and involvement keep everyone on the same page and leave no room for misunderstanding related to requirements, the designed solution, and, finally, the build.

Note

Try to keep session participants to approximately 20 team members. More than this will be excessive and may not be productive. Also, you do not need the same team members on all CRPs. Pick the ones that have the required knowledge and can add business value.

Facilitating CRPs

CRPs must be planned well in advance to provide an opportunity for the participants to make arrangements to attend these sessions. This means some participants may have to make travel arrangements and free up their calendars to be able to dedicate their attention and time to CRP sessions. To make this a rewarding experience for your participants, you need to ensure that the session is planned and executed efficiently and effectively.

Let us look at some of the important tasks that we can do to make CRP facilitation successful:

• Plan and create a CRP road map.
• Identify key participants of these CRP sessions: key stakeholders, SMEs, architects, and key project team members. Communicate with the participants after finalizing adding/removing team members before making a final list. Always keep a primary and secondary team member.
• Prepare a detailed agenda approximately 2 to 4 weeks in advance and communicate this with the participants. This will help the users to know what meetings to attend and come prepared for the sessions.
• To optimize usage of time effectively, schedule main sessions for 90 minutes with 15-minute breaks. Breakout sessions with smaller groups of participants can be 60-minute sessions.

Note

Breakout sessions are useful for teams to discuss in smaller groups and come to a consensus where there is a divergent understanding or misunderstanding of requirements or functionality.

• Assign a junior team member to take care of meeting logistics, such as conference room booking and arranging the resources required during the meeting, including flip charts, markers, sticky notes, a projector, and microphones.
• Identify a scribe for these meetings to take meeting notes and any open questions. This person should be knowledgeable and be able to take notes effectively. Team members when actively discussing or debating will not stop or pause for the note-taker to take notes. The scribe should be able to take notes and elaborate on them in detail and document them for the team. Assigning a junior team member will be very ineffective.

In this section, we learned how prior planning of a few simple but important tasks can help us effectively facilitate our CRPs. Now let us take a look at how these CRP sessions can introduce a few pain points and how we can manage them.

Managing scope creep during CRPs

Planning and conducting many CRPs has its own pros and cons:

• The pros are that we keep everyone informed and on the same page. By collaborating as a group during the CRP session, participants get an opportunity to progressively see the product (functionality) develop. This helps with having open and honest conversations and helps the team steer in the right direction.
• The cons are that there is a lot of room for scope creep. Business stakeholders may realize they failed to identify or inform other business needs. This is a good thing as far as the scope of the CRM phase is concerned, as the main goal here is to identify gaps and improvements.

Let us see the impacts of these pros and cons during each stage of CRPs and how we can manage them to our advantage.

During the scope CRP phase, we certainly should expect many requests, and the majority of them are usually valid. What is in scope and what is not in scope needs to be carefully managed by you as a business analyst and the project manager.

During the design phase, the scope needs to be controlled more aggressively. Anything new cropping up should be evaluated and parked for later release or provided with an alternative simplified solution, and this can be a manual process too. The most important outcome of this design CRP should be identifying usability aspects and non-functional and integration-related requirements.

The build phase should be focused on changes, if any, related to the user interface and user experience. If the design CRP is done productively, we should not see any functional gaps. The tech team may find some non-functional related gaps or technical constraints, and this CRP can help identify them and the technical team can utilize CRM sessions to inform the business stakeholders.

Note

For every constraint that is not feasible, the team needs to come up with a workaround. Without a workaround, the business may not have a way to operate, and you cannot simply say there is a constraint and there is no workaround.

The testing CRP should be more of a demo to all the project team members, and this will help the operations team, training team, and production support teams to understand the functions and features. This will help prepare the team for go-live and post-go-live support.

Any changes—big or small—need to go through the change control team. This team, comprising project sponsors and key project team members, should determine whether this can be absorbed in the release or pushed to the next release. There may be cases where, based on how critical the requirement is, the project date is extended. Make sure the project team documents all additional requests (can be gaps, usability, or enhancement requests) and captures who raised it and when, a brief description, the importance, who it was reviewed by, who accepted it, or if it was kept on hold.

Note

Do not be too rigid in change control. Any low-hanging fruits that are easy to implement should be added to the scope after socializing and agreed on by the team during these CRPs. This is a great motivating factor for CRP participants; you will see better engagement and it will be a win-win scenario for the project team and business team.

Note

The change control team should be participants in these CRP sessions and any new requirements that come up should be added during the breakout session. I would say each day, in the CRP schedule, the change control meeting should take place an hour before the session closes. This session should not take more than 15 to 30 minutes and a decision on go/no-go for additional requirements should be communicated by the close of the session. This saves an enormous amount of time for the whole team.

Reviewing the benefits of CRPs

A well-oiled CRP planned and managed efficiently and effectively will provide many benefits. Let us list some of them here:

• Provides transparency and a common understanding of business needs, the designed solution, the product built, and the final product.
• It is a platform for effective collaboration and idea generation. Effective CRPs facilitated efficiently will let the team interact naturally, allows them to contribute, and creates the most productive outcome.
• Multiple dedicated in-person sessions away from regular work will help create bonds with different team members and enable team members to learn from others. For example, the opportunity/quote management team can learn how the contract team operates and will have an opportunity to understand their business processes and procedures. Similarly, the contract team can learn from the quote team. This helps them empathize with others’ work by understanding the intricacies (procedures and policies) and helps bring out the best in people.
• It is an opportunity for stakeholders, SMEs, and project team members to socialize and share experiences. Bonding and creating friendships make future interactions between team members much easier.
• Getting approvals and resolving disagreements will be much faster as all the key team members are in the same sessions. This saves a lot of time for the team members and the project.
• CRPs allow users to see the mockup solution/prototype firsthand. This helps build confidence within not only the participants but also the rest of the team as the session attendees can take the prototype back to their team and communicate to them how their needs are shaping along with the project.
• CRP attendees can help with encouraging and answering queries from their team members. This helps with increased user adoption. Your team can identify a few trailblazers from these sessions and recommend them as SPOCs/champions from their group. These experts can help you bridge the connection between the project and the end user.
• The technical team will benefit immensely as they understand exactly what is needed by the business. Iterative feedback and listening to discussions during CRPs help them deliver a great final product with proposed features and functions.
• The QA (testing) team will benefit by understanding the progression of the needs to the final solution. The testing team will be able to design and test the right test scripts and scenarios and be able to know what to test from a business user perspective. This helps in reducing user acceptance testing defects/queries.
• The training team will be able to prepare and curate the training materials and deliver them productively.
• It is a good place for idea generation. Team members are encouraged to be innovative and free to express their ideas, and this provides your team with an excellent opportunity to capture and document them. Many of them may be off the chart but are excellent ideas that can be implemented in future releases or other projects in your organization.
• It is a good source for project team members to understand the evolution of business needs into a workable solution. This can immensely help the team with the documentation and creation of various project artifacts, such as flow charts, process flows, FDDs, DDDs, and training material.

Practical tips for success

A few practical tips that can be of benefit during your CRP sessions are as follows:

• Use templates: Standardize and use the same format for all your CRPs, for example, Agenda, PowerPoint Deck, or an issues/enhancement tracker. This helps participants get comfortable with processes and procedures.
• Communication with stakeholders and project team members: Send status reports periodically with action items and due dates to all participants and possibly include their managers and other project team members who are not at the meeting. Make all artifacts available (a read-only version) on a central document management system that team members can access, such as a SharePoint/Teams site or a document management tool of your choice.
• Engage leads: Always make it a point to engage leads so that resources assigned to the project are completely motivated for the entire duration of the session. Also, provide feedback, especially where positive, to respective leads. These types of small things make a huge difference to the project.
• Checkpoints: Add checkpoints throughout the session, both during and at the end, to get a pulse on how things are progressing. I usually prefer to break the leads and key stakeholders into smaller groups to get a pulse during breaks, and these can be informal check-ins. The whole group can be included in a 15-minute session before ending the session for the day.
• Lessons learned: At the end of each session, make it a ritual to note the lessons learned. You’ll get valuable insight and feedback that can be incorporated into the next session. Ask each member simple questions, such as the following:
  • What went well?
  • What did not go well? How can it be improved?
  • Any concerns?
  • Suggestions for improvement
• Next steps: Just before you end the session, make sure you communicate the next steps with concrete dates, and if possible, include an agenda for the next session.
• Facilities: Ensure you have organized the facilities, such as the availability of a meeting room for the entire duration, including all meeting room equipment, such as a projector, whiteboard, flip charts, and telephone system.
• One note-taker/communicator: Designate an SME-level person who can understand and take notes. This designated person should be able to distill and refine the notes and prepare minutes for communication to all team members.
• Centrally located documentation for effective collaboration: Make sure team members have access to all project-related documents, including any flow charts, process flows, project artifacts, and all meeting minutes. These artifacts should be accessible easily from multiple devices.
• Give ample time for a Q&A before ending the CRP session: Stakeholders always love to ask for the next steps and committed dates, so plan and prepare well in advance.
• Plan to send MoM: Send meeting minutes on the same day after ending the session to all participants and their leads while the topic is still fresh in their heads.

CRPs are effective methods for team members to experience and see the progression of business needs into a fully functioning business solution. A well-planned and well-spaced CRP during various stages of the project helps identify and resolve issues effectively. These sessions also create opportunities to improve user adoption.

Summary

CRPs help bring the stakeholders, SMEs, architects, and QA, training, and project team members together. Holding these sessions at different stages of the project helps team members collaborate effectively to get a common understanding of business needs and the proposed solution. Well-managed CRPs help teams steer in the right direction, add business value, and avoid any pitfalls along the way, while progressively shaping the final product.

In this chapter, we discussed possible phases where you can plan your prototyping activities. You learned how to effectively facilitate CRP sessions with the right participants and the right timing while keeping an eye on how to manage scope creep. We also saw the benefits of CRP sessions and finally, you learned a few practical tips that possibly benefit and prepare you to be successful at facilitating and managing CRP sessions productively.

In the next chapter, we will cover technical and quality testing approaches and the role of a business analyst in making testing efforts effective and fruitful. We will review how to identify the skills we need our tester to have, help them understand the intricacies of the system and business concepts, and aid them with identifying scenarios and the right set of usable test data.

Questions

1. List a few benefits of CRPs.
2. What is change control and why is it important?
3. Given resource constraints, give one example of how you can optimize a CRP session.

Further reading

• Conference room pilot: https://blogs.sap.com/2010/11/14/conference-room-pilot-crp-why-do-you-need-crp-s-for-your-implementation/
• Proof of concept: https://blogs.sap.com/2010/10/27/poc-proof-of-concept/