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 “off-
the-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
 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.
2. 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.
3. 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.
4. Rumors were running rampant among BCG developers.
5. 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?