Prior to commencing the COTS implementation project, ABC Pharma utilized an RFP process to select a COTS package that will support the needs of their scientists in the R&D and clinical business areas. The scientists need to have thorough documentation and precise content generated through the course of their work. The package will enable upload, storage, management of digital assets – and include record retention rules, management of security and authority levels, and integration of data with other applications. It will also capture the required regulatory audit trails with transparency, compliance and reportable audit trails. These scientists are dealing with human trials. ABC Pharma must do this right.
Best Product was the chosen COTS package as the best fit for ABC Pharma’s requirements. Their practical implementation approach and cost-effective plan to address the high priority configuration needs uncovered through the gap assessment had won the attention of the business leadership team. The scientists and auditors were looking forward to a more streamlined process that would reduce some of the existing costs and risks associated with managing their digital assets. Leaders were cautiously thrilled with the prospect of better reporting and transparency to help improve regulatory compliance. The technology team was happy to be replacing an unstructured process that had more band-aids than they cared to let anyone know about.
Glenn was pleased at the spirited energy level from both the business and technology folks during the first project kick-off meeting with the vendor. High level build and release plans and architecture diagrams for the implementation of the new COTS package were reviewed. Everyone celebrated with hopeful confidence.
The standard RFP process had provided a solid foundation of the business requirements. Glenn had worked with the business team to create Personas of the primary stakeholders who would be using the new tool, the scientists and the auditors. The personas really helped to visualize the unique needs and challenges of each customer. Combined with the Journey Map and content strategy, these visuals gave clear insights and exposed an understanding of some requirements that were unique to ABC Pharma.
Before the kick-off meeting, Glenn had created a presentation that provided an overview of the solution scope for the MVP release. He had started his Stakeholder Map, adding the stakeholders and technology team members that were listed on the project plan. Even though the PM had a stakeholder list, Glenn likes to keep his own list. Understanding the characteristics of each person helps him to plan the best ways to work with the team. After the kick-off meeting, he updated the Stakeholder Map with some changes and additions. He also added some information to clarify roles and accountabilities, and communication preferences. He wants to keep the stakeholder map current because he knows how important it is to effectively build relationships and engage appropriately with the whole project team.
In the early stages of the implementation process, Glenn had attended his local IIBA Chapter monthly meeting. The speaker had talked a lot about “thinking and being agile” regardless of the SDLC. She challenged BA’s in any industry or SDLC framework to always seek better ways of working with people through empathy and understanding, and to have a full toolkit of techniques ready for use. During the meeting, Glenn thought about the challenges of the regulatory requirements artifacts he had to deliver and the risks of finding issues during UAT in ABC Pharma’s primarily waterfall SDLC.
While necessary for audit and compliance and despite the effort to write them, the lengthy requirements artifact documents posed challenges for business requirements sign-off, developer configurations and the QA teams test cases. They lacked the dynamics of the visualization and models. And typically, by the time issues were identified in UAT, it was too late to affect change without cost of time and/or money. Glenn had an idea to modify their process by demonstrating development work in progress on a regular bi-weekly cycle. The stakeholders would need to agree to and understand that the functionality was in progress, not ready for testing but at a point where things could be changed, within reason, and not delay delivery or add cost. The chance of catching any big gotcha’s early on decreased the risk of failure.
After the kick-off meeting, Glenn had scheduled a meeting with the core project team. He had included both business, technology and vendor team members, but only the “pigs” as they would say in Scrum, the ones who have skin in the game. “I have an idea that I’d like to talk about with all of you. I think it may help us, but only if we all work together and agree to open honest communication” was his opening statement as he posted this diagram on the screen:
He explained a process where they would work in iterations or sprints, at fixed time periods and scope. The business stakeholders on the core team would be involved throughout the process, not just at the end, so they had more visibility into the progress and increased opportunity to influence the final product. There would be some additional time investment on the front-end of the work effort, however, he was certain that it would pay off by the reduction of risk in the formal UAT testing phase and increase the stakeholder satisfaction level. Glenn asked everyone to take a few minutes to think about his proposal and jot down their questions, ideas and concerns. After a few minutes, he opened the space for safe dialogue inviting everyone to speak up.
“What about the regulatory documents?” asked Darcy, the audit stakeholder.
“I will continue to work on those as we progress. I believe the final documents will be a better product using this process.” Glenn replied. “And when you review the documents for sign-off, you will have a better understanding of what you are agreeing to”. Darcy smiled. “I like it, count me in”.
Sergey, the lead developer from the vendor spoke up. “We’re going to need data mapping with transformation rules from the source data fields to the target data fields. We also need to know which reports use the target data fields”.
“Yes”, Glenn responded, “those are over 75% completed. I’ll schedule time with you to review the artifacts and ensure that everything you need is included”.
Sergey nodded with approval and then added, “To be honest, I’m a little nervous about demonstrating our progress without the completed functionality. People will need to understand that it may not always look like a lot was accomplished. It’s kind of like constructing a building where the foundation and work under the covers isn’t always pretty, but I’m willing to try it too. Maybe we can find a way to demonstrate the foundation progress.
Glenn looked towards the business SME’s assigned to the project. Dr. Lee spoke up. “If I’m understanding this correctly, this may eliminate the blackhole feeling we have during development and the frustration we have in UAT when something doesn’t look like what we expected?”.
Glenn smiled. “Yes, that’s the plan” he replied. “We’ll work out a process to evaluate any changes you request during the demos and you’ll know right where we are”.
It appeared that everyone was onboard, however, Glenn wanted to get a deeper sense of where people really stood on the idea. Knowing their commitment to it would help him with future planning. He moved to the next slide and said, “Let’s seal it with a Fist to Five vote”.
Glenn breathed a sigh of relief. He didn’t get all 5’s, but he hadn’t expected to. If he had, he would have known that everyone hadn’t bought in to the safety and trust of their teamwork yet. With the 11 core team members, an overall average of 3.9 in the Fist to Five with no one under a 3 was a good sign. He had commitment. After the second demo, he planned to do another Fist to Five to keep his finger on the pulse of the team.
“We have a few more minutes so let’s cover one more thing” Glenn said as he looked across the team and pulled up one more slide. “We have agreed on a functional strategy” and he typed in the bullet points as he spoke, “Code deploy to vendor sandbox bi-weekly on Thursday morning. Vendor review with BA after deployment. Bi-weekly demos on Thursday’s at 1:30. Feedback will be documented. Any change requests will be prioritized by the business and evaluated by the technology team.” He then asked, “Does that sound reasonable?”. Everyone expressed agreement.
Glenn continued, “The culture is how we commit to working together, our core values. This is what will make the difference. I have two that I’d like to start with” typing as he spoke, “Periodic retrospection to improve. Honest, candid communication.”
“Ok, I have one” piped up Dr. Lee, “Ask questions to understand”.
“Don’t take it personally” Darcy said.
“I have one to add too” Sergey chimed in, “Remember that we share the same goal”.
“Great start! These Working Agreements help us to solidify our team culture.” Glenn said as he began the closing of the meeting. He reiterated the next steps and closed the meeting 3 minutes ahead of schedule. People tend to walk away from meetings that end early or at least on time in a better state of mind. This slide will be one of the first at the start of each demo as a reminder and to set the tone for the team’s exchange during the demo meetings.
This story demonstrates a great start to the project and the teamwork. It doesn’t always start this well, but it’s possible. For the most part, people like to work together successfully. Remembering to integrate an element of fun into the process contributes to a healthy team culture too. Glenn has facilitated improvements to team engagement and demonstrated leadership in his role as the business analyst.
In Scenario 2, we’ll see what happens next…