Case Study: The Shapes Of Fear At Trident Pharma. Business Computing Group.

Case Study The Shapes of Fear at Trident Pharma. Business Computing Group. Any resemblance to existing or fictional characters would be purely accidental.

1. The landscape “Trident Pharma” as insiders call it, is a medium size biotechnology company based in the Southwest of the United States that uses computational modeling to identify drug binding sites on the surface of complex proteins and design low toxicity compounds with desirable therapeutic effects precisely targeted for those sites. Trident generates income through licensing of compounds from its own drug discovery program and through cooperative agreements where Trident models new molecule candidates mapping to partners’ protein targets. Trident Pharma’s Information Technology Department is divided in three groups: - The Bio-Informatics group is focused on developing and applying Trident’s proprietary methodology and modeling tools to targeted proteins. - The Business Computing Group (B.C.G.) develops and maintains software applications necessary to run Trident’s day to day business, - The Network and System Administration group maintains Trident extensive computing infrastructure as well as its internal network and high speed Internet connections to external vendors and partners.

2. The Boss From its inception, Dr. Santosh Anand, one of the pioneers of the Bio Informatics field, has run the IT Department. Dr. Anand has authored numerous books and has developed or directly inspired a number of key software tools used at Trident. Dr. Anand managerial style can be characterized as “benign dictatorial”. Dr. Anand ‘s day is shared between executive meetings, long periods of time spent coding specific software components and design review meetings with specific developers. Dr. Anand is generally a mild mannered individual except when he looses his temper. At such times, Dr. Anand favorite sentence is: “This is how it is and if you do not like it, feel free to look for a job somewhere else.” Based on the uniqueness of the tools necessary for Bio-Informatics, Dr. Anand has had a long-standing policy of expanding the efforts necessary to build custom software than buying commercial software packages. As a result, Trident has never bought any significant commercial software package. This policy applies to Trident’s Bio-Informatics and to its Business Computing Group. Because of the nature of Trident’s business, under Dr. Anand’s stewardship, considerable care has been given to the design, testing and building of Bio-Informatics software. The same could not be said for software developed by the BCG.

1

3. The Business Computing Group The BCG is dominated by Dan Thomas. Mr. Thomas spent 12 years working as a software engineer at one of the US Army labs, where military style command was the preferred mode of operation. Mr. Thomas’s favorite put down for non conforming developers was: “this is no rocket science”, followed by accusations of building over-complicated, theoretical code directly copied from academic books with no contact with day to day business reality. As senior developer/architect in the BCG, developers felt compelled to follow Mr. Thomas’ software design instructions, even though they might be riddle with inefficiencies and devoid of any event logging and/or error handling and recovery capabilities. Trident BCG’s day-to-day reality was dominated by feverish efforts to meet deadlines imposed by Trident executives. Project commitments are made by IS Managers before detailed requirements are gathered and before a requirement analysis/design is performed. In this context, the BCG none-the-less managed to deliver 90% of its projects on time. Further analysis revealed that most of the projects delivered by the BCG were short to medium duration projects with levels of effort below the 100-man hour level. These types of projects were modifications to existing legacy applications with minor bottom line impact. Commitments for Enterprise projects were treated in a similar fashion as smaller projects: IS Managers would commit to a delivery deadline imposed by Trident executives before detailed requirements were gathered and before a Software Engineer could work through an analysis and a design of the project requirements. Typically, imposed deadlines on Enterprise projects had no relationship with the actual amount of work necessary to meet the deadlines. And typically, deadlines on large enterprise projects came and went without being met. Over time, some large enterprise web based projects were delivered although none of them ever met the original expectations of their customers. Software Engineers usually worked in isolation on smaller projects. Dan Thomas frowned upon developers that paired up to work a design or a specific issue as a team. When software development teams were created to tackle enterprise projects, they tended to operate in silo, isolated from other “project teams” working on interdependent projects. Soon, an attitude of “us vs. them” developed, further fueled by rampant finger pointing and public put-downs by project managers from interdependent projects.

4. Methodology and Technical Environment. No shared knowledge repository existed; no organized knowledge sharing practices existed and little to no application documentation was available. Although, software developers cooperated willingly together, knowledge of business rules, legacy database tables, and specific application process existed only in the head of specific software engineers.

2

No process existed to evaluate software development practices and tools. No organized software development training program or continuous education curriculum was offered to BCG developers. No differentiation of roles between developers existed, nor was any career path defined or offered. Software engineers were expected to be their own business analysts, their own designer, their own coder and their own testers for their projects. Typically, a scope document was written and approved by stakeholders. Often but not always, end users would be in charge of providing requirements for the proposed system. Software Developers rarely provided Design and Analysis documents. Often end-users would drastically change requirements mid-course through a project development phase. Design reviews and code reviews occurred sporadically. Prior to deployment in the production environment, new software went through unit testing and variable levels of internal customer acceptance testing on development servers. No system or integration testing was performed since no test plans were ever written as part of the initial application design documents and since no automated testing tools were available. Interestingly, this free wheeling environment existed only in Trident’s Business Computing Group. BCG Managers justified the expediency of organization’s mode of operation by the urgency and the pressure put on them by Trident’s business executives. It was public knowledge that Trident was a “mature” start-up and that the next two years were critical to the company emerging into the rarified ranks of established biotechnology firms. The two years time range was predicted based on Trident Pharma “burn-rate”. This was a make or break situation: either Trident would generate sufficient cash-flow to be profitable and function as a fully independent Biotech company or it would be sold to a larger pharmaceutical group and lose its independence. In an effort to minimize computing costs, Santosh Anand bought used servers and “offthe-shelf” Intel based servers and, a few years back, had decided to move from UNIX to the Linux platform. With that decision, Java and JSP were the new logical choice as preferred development language at Trident Pharma. Legacy applications were written using C and PowerBuilder. It is important to notice that new functionalities were continuously added to existing legacy applications. In spite of Dan Thomas’s best efforts to build Java based applications, core business functionalities were provided by legacy applications.

5. Impact of Trident Pharma BCG culture and mode of operation 1. Most individual software developers chose to simply submit to Dan’s design decisions even though they disagreed with those decisions. The rationalizations given for this position included: - Expediency: considering the pressures for delivering the application, the proposed design is the shortest road to meeting the imposed deadline. - Let’s not rock the boat: this is how it is being done here.

3

2.

3.

4. 5.

Other software developers chose to comply while resenting that decision. These individuals mentioned that they knew the proposed designs were fundamentally flawed and felt powerless in affecting the situation in the absence of any manager or any forum in the department where their point of view would be heard. Finally, another developer chose to avoid open conflict with Thomas by concealing the fact that the applications he built did not include any of Thomas’s design recommendations. Because of the speed and reliability with which applications were built in PowerBuilder, legacy applications kept growing and expanding further delaying and rendering more complex the task of replacing client-based legacy applications by more modern and efficient web based applications. Occasional trainings to new technology were organized. However, because of the continuous expansion of legacy applications, developers working with legacy technology were not getting an occasion to practice and improve their newly acquired skills. Rumors were running rampant among BCG developers. Turnover rate among BCG developers was high. About a third of the staff had to be renewed over a typical year.

Over time, the culture of the BCG became a mix of free-for-all, rigid, and fear-based culture paying little attention to methodology, new concepts, practices or tools. The chaos created by the absence of consistent methodology and processes was compensated by software developers’ willingness to sacrifice inordinate amounts of their personal and family time to get applications in production. Although BCG managers routinely criticized existing practices, they also held strongly to the belief that a culture change was not possible. The issue confronting Trident Pharma’s management today is how to move from a paradigm where software engineers are unproductively developing applications in isolation to successfully developing and deploying large-scale enterprise applications that are designed, built, tested and deployed by teams.

6. Ten questions to think about: 1. What are all the factors that build fear in the mind of the BCG staff members? 2. What is the impact of that fear on BCG staff members and managers ? 3. How would you get this situation “unstuck” and moving? How would you bring about a culture that rewards learning and efficiency ? 4. How do you move the BCG from software applications developed by isolated individuals to team based enterprise software development? 5. How do you go about moving from a chaotic to an orderly development process? 6. How to you make people feel safe in a chaotic environment? 7. What do you think is the impact of each new alarming rumor on software engineers’ productivity? 8. In that context what do you do to retain your software engineers? 9. Does anything that you read in this fictional business case feels familiar to you? Any similarities with a situation that you are currently living in?

4

10. Of course, the BCG needs to be disciplined about software development methodologies such as the Software Engineering Institute’s Capability Maturity Model Integration (CMMI). How do you move this group to start to consider implementing CMMI?

5