When the Villagers Stormed the Castle: A tale of our process improvement journey 
Shari Forvendel, Software Developer; Sue Carroll, Principal Software Quality Analyst
 SAS Institute Inc.

Introduction:

It's often said that when it comes to implementing process you have to start from the top. Managers are the ones that must be the cheerleaders and the enforcers of process. But what happens when the project team revolts against current methodology and demands a better way – right now? How do you handle the mob, update the process, and manage the project all at the same time? The Pharmaceutical Solutions department of SAS Institute Inc. has always had a strong, documented software development process. It is necessary to do business within the FDA-regulated pharmaceutical industry – and of course it makes good sense. But what we had lost along the way, quietly and without much notice, was process maintenance. There was no team, no individual, no project identified as being responsible the health of the process. But no process, regardless of how well-defined or how well received it starts out to be, can stand forever. It will require continuous evaluation and maintenance to remain relevant. Our talk outlines our journey back to process maintenance.

Learning Objectives:

  • The attendee will be able to recognize the importance of listening to the people who actually use the process
  • The attendee will be able to evaluate the possibility of completely overhauling their software development process
  • The attendee may be able to avoid the disruption of their software development efforts caused by an outdated process

Outline:

  • PROLOGUE
  • THE TALE
    • Unlawful Assembly
      • Development team endures nightmare project
      • The villain is identified: The Process
      • Lots of good ideas – no way to channel them
    • Addressing the Crowd
      • Process Improvement Initiative is launched
      • The people have their say – process by (very big) committee
      • Lesson(s) Learned
        • The importance of listening without reacting
        • The more people involved, the harder it is to get consensus
    • The Drawbridge is Raised
      • Process Improvement Team sets up camp inside the walls
      • Software Development Team waits outside
      • Lesson(s) Learned
        • Process improvement – it's not as easy as it sounds
        • It is hard to estimate the time needed to fill a black hole
        • The failings of solitude
    • The Torches are Lit
      • The next software development project starts; updated process isn't ready
      • Declaration: New project to use old process
      • Process team and Project team sharing resouces: Process Initiative takes the backseat
      • Lesson(s) Learned
        • Even process can't stop progress
        • You have to manage consumer expectations – whether it's software or process
    • Storming the Castle
      • Software development team rejects old process; improvises process changes
      • Meanwhile, back at the castle: the process team continues with its own plans
      • Lesson(s) Learned
        • Process changes can impact the timelines
        • Process Team is independent of the project team – and cannot enforce project goals
    • Putting out the Fire
      • Process Improvement Team goes full-time; pulls it together
      • Project-to-Process communication line established
      • Lesson(s) Learned
        • Overhauling a SDLC Process is not a part-time job
        • How to break out of analysis paralysis
        • Simplify, simplify, simplify – get rid of the obstacles
        • Process needs to serve the product first, auditors second
        • Don't be afraid to make radical changes
    • Lowering the Drawbridge
      • Training Day: Rolling the new process out in one shot
      • Official Pilot-project launches
      • Lesson(s) Learned
        • Communication between project efforts and process owners has to flow both ways
    • Rebuilding the Castle
      • Process Improvement Initiative launches the Process Maintenance team
      • Lesson(s) Learned
        • The advantage of starting over from scratch
        • Changes are continual even after the launch
  • EPILOGUE
    • The other castle: A New Document Management System
    • Lesson(s) Learned
      • The pitfalls of changing too much at once
  • THE MORAL OF THE STORY

Biography:

As a principal software quality analyst at SAS, Sue Carroll worked in quality assurance for 15 years and now works in software quality process and research where she defines and documents internal processes, maintains external documentation about these processes, encourages internal process improvement, performs internal audits for SAS Drug Development and acts as a liaison with customers about their research and development quality and process questions. She interacts with external software quality organizations to provide sources for internal innovation. Mrs.. Carroll is an ASQ Fellow and a member of ASQ's software, biomedical and food, drug and cosmetic divisions. She is the Editor-in-Chief for Software Quality Professional Journal which is published quarterly. She has attained the Certified Software Quality Engineer certification from the American Society for Quality (ASQ).

Shari has been a software engineer for 19 years, the last 13 having a focus towards the pharmaceutical industry. Since 2000, her duties have expanded beyond programming and validation to include participation in defining, implementing, and maintaining the software development process used in the development of SAS ® Drug Development software. In support of those efforts, Mrs. Forvendel has received training in the Capability Maturity Model through CISE ( Carnegie Mellon University ) and attended multiple SEPG conferences. This preparation culminated in Shari leading a year+ process improvement initiative designed to analyze, renovate, and reinvigorate the software development process utilized by the Pharmaceutical Solutions division of SAS.