Project Mis-management in the Cynapse Corporation

Project Risk BACKGROUND

Cynapse Inc. is bio-technology company that develops drugs based on proteins and peptides. Many of their team's work "virtually" and yet often, projects are not completed on time or within budget. The growing company currently has one product approved by the U.S. government agency FDA (which must approve all new pharmaceuticals manufactured or distributed in the US), and two additional drugs undergoing clinical trials. There are about 700 employees at the company.

Due to the many scheduling risks, about half of the scientific and research staff are located near headquarters in San Diego, working as computational and pharmaceutical research scientists.

Since research is considered valuable IP (intellectual property) the Cynapse Corporation also has a large IT/information management department centralized in the headquarters office. Headed by Chief Information Officer (CIO) the IM department employs about 80 people and is charged with support of all communication, databases, cyber-security, software upgrades and computer systems used in company operations.

In addition to the IM professionals, Cynapse employs a number of highly skilled "computational scientists" who conduct research using mathematical models on a computer. These scientists are not members of the IM department, but use the IT systems extensively. They report to the Director of Computational Biology, who, in turn, reports to the Chief Scientific Officer (CSO). A majority of these computational scientists, and Director herself, hold advanced degrees, and are quite proficient in computer programming. Just like the IM professionals, many of the computational scientists have been with Synaptic for years. Many maintain close personal friendships with their colleagues. However, tensions are rising due to the many risks that management has at last identified which stem from unclear project scope, growing schedule risks, impacts to overall project budgets and lack of trained PMs (project managers) able to communicate effectively with upper management and IM specialists.

SITUATION AND INTERACTIONS

Because of the nature of their research, computational scientists frequently interact with the IM personnel, and there is some overlap in responsibilities. Traditionally, computational research projects are initiated in the Computational Biology group. Due to the nature of innovative research work, many of these projects are quickly abandoned. However, no one seems to have a centralized "project database" relating to % of project phases completed and impacts upon project budgets.

But those projects that do go on eventually require support from IT and even the Information Management procedures. There is no overall "Policy Manual" at Cynapse relating to IP risks or even cybersecurity enforcement. The IM (information management) teams may be asked to perform custom development, allocation of space on servers and databases, program execution and monitoring with periodic reports to the scientists as well as upper management. However, they are frustrated with lack of budgets or time to complete data updates and uploads, etc. Cybersecurity systems are slowly being installed.

However, the cultures of the Computational Biology and IM groups are quite different. Scientists value innovation, originality, and speed. Many of them prefer to work in solitude, and this practice, despite all politically correct references to the importance of teamwork, is not frowned upon in the company.

On the other hand, computer and IT professionals in the IM Department are concerned with stability, business continuity, documentation, and long-term planning, as well as understanding budget forecasts and working with upper management on such modeling and simulations. Also, IM has a very strong preference to make decisions in meetings regarding IT "best practices" to mitigate major risks and risk triggers. The cultural difference between the two departments may be traced back to the typical, diverse career tracks of biologists/pharmaceutical scientists and IT professionals. Tensions are rising.

IM managers are complaining that scientific software development is done ad-hoc and it follows no standards. To quote one of the IM directors, "They throw something together, then come to us and demand that we support it. Yet there is no documentation for it. And worse, even in many cases they do not consult us beforehand, only to discover later that it [the new project] is not compatible with the company IT architecture. How would you like to be asked to switch to a new line of servers, on an extremely tight deadline, without advance planning and without budget to buy any? How would you like to have your job dependent on it? And then they turn on a dime and ask you to drop everything and do something else."

Computational biologists, on the other hand, are equally unhappy with the IM's slow development pace and demands for documentation and governance that scientists perceive as bureaucratic and wasteful. "You can't get them to do anything. I need an upgrade to Oracle THIS WEEK to run my sequence database. The rest of the world has had it for years! Yet the IM tells me that they are on version 9, and it is the company standard and they won't upgrade. We call ourselves a high technology business, yet we are five years behind the technology curve. All they talk about is cybersecurity. We are ready to hire outside consultants to get something done faster in line with our research and competitors coming to market with new products each month."

PREVIOUS "SOLUTION" AND Risks

In the past IM management attempted to reconcile this conflict by creating a formal business process to "transition projects from research into production". This effort was ultimately abandoned since scientists refused to follow the standard procedure, preferring informal communication instead. This triggered many IP (intellectual property) risks with data already developed on pharmaceuticals not yet ready for manufacture. Of course, schedules were severely impacted as well and virtual teams often did not respond until several days after projects ended abruptly.

As a result of these frustrations, some of the computational scientists lost faith in the IM and started to create their own information technology systems. In the most prominent example, one scientist, Steve Levitt, Ph.D.., hosted his programs on a high-end PC located in his office. He has his own Oracle database on that PC (he downloads the latest version of Oracle whenever it is available, but then submits an invoice). Everything he has ever worked on is on that computer. The information stored on his PC includes, among other items, software and data for one of the key computational biology business processes. His work is known to very few of his colleagues in the company, but not in sufficient detail to reliably operate his "modified" software.

When Steve goes on vacation, he leaves his cell number behind to call in case of "issues". Realizing how important Dr. Levitt's work is for the company, the corporate e IM manager repeatedly asked Steve to document his computational process, and to submit it for the "transition into production" process. Steve repeatedly took no action on these requests and attempts to avoid risks his manager pointed out at last backfired. Other scientists have started to follow some of the same IT practices in their daily work "since Steve does it".

The owners of Fast, Inc., a small consulting company that Cynapse retained to keep up with completing several of the "abandoned" projects were available for an interview. "We are former PhD research scientists ourselves, and so we know very well what scientists need. We operate lightning fast, and on most projects, we turn around so quickly, that they don't even know what hit them. Sorry, we don't have documentation ready: the Cynapse management never asked for that, and we will have to charge them next quarter. Our bill may be very high, but we can't forecast costs until the work is done."

The consulting company Fast Inc three owners acknowledged that speed of development comes at a risk of "cutting corners" when it comes to documentation. "But we maintain our own computational infrastructure in our own office, and we keep the data and software that pertain to our work with Cynapse right here, and we know it all intimately. And eventually, these ad-hoc projects develop into products, and when they do, they could be sold! We are excited about these horizons. What's more, because of our favorable agreement with Cynapse, we retain all rights to the software. It's amazing to be in bio-technology since several other clients and government agencies are interested."

Over the years, the relationship between the many diverse scientists and Fast Inc. became quite close. Fast's owners attend some of the research meetings on the latest intellectual property being developed for the FDA tough approval standards, and they have persuaded Cynapse's management to buy stock shares in Fast. The consultants mentioned their plan to eventually sell off Fast, Inc. completely, and to move on to other business interests.

BLACK SWAN CRISIS triggers RISKS

The first harbinger of possible future problems hit on Christmas Eve of 2018. A large number of errors were found in Cynapse's main database, and upon a two-month-long investigation, the errors were traced to Steve Levitt's calculations. It appeared that some parameters in Steve's process were changed as part of an experiment in the early days of Cynapse, but then both he and his supervisor forgot about it and failed to switch them back. The process operated with a wrong parameter set for nearly a year, invalidating much of the data accumulated for the past 13 months!

Cynapse's IM Director was asked to correct the problem, but without understanding of Steve's research and direct access to his software, the task proved extremely difficult. Ultimately, the CSO demanded that the Research IM Director be relieved of his duties: heads began to "roll" and this caused great concern throughout the IT divisions and Information Management project managers.

While the Chief Scientific Officer assumed his responsibilities on the stressful day that the IM Manager quit, in the interim, teams are unclear what will happen to enforcement of Information Management policies and procedures. Steve and his supervisor were not reprimanded, and they are now risking schedules set months prior.

The Chief Scientific Officer was available for a very short interview. When asked about his assessment of the database problem, he started by stating, "Ultimately, we all are to blame for these risks. If only we could have forecast these risks to our budget more carefully!"

To address the snowballing problems, the IM senior management decided to create an additional position. The new job would serve as a middleman "liaison" between the IM and the scientific group. It would require a degree in the biological sciences (to earn respect from the Computational Biology workers) along with multiple years of IT experience and even security clearance.

After their efforts to locate an individual with suitable qualifications failed, the Cynapse upper management team has contacted you, a consultant in independent practice, to develop a Risk Management Plan and make recommendations on standards to follow.

YOU, THE CONSULTANT: Project Management Risk Identification & Recommendations

You have just visited Cynapse offices where you've met, and interviewed individuals described above. You have been offered a contract this month as a consultant to Cynapse. You have been told that your ultimate job is to identify risks and make recommendations to management.Hence, in a 5-page overview (no Appendix), you are asked to:

1. You will Create a Risk Register identifying major project management risks and
2. Make managerial recommendations for both teams at Cynapse

From the practical standpoint, it is not likely that you would have an authority to hire and fire top managers, or to perform mergers and acquisitions, so proposals involving any of these are not likely to be accepted by the client organization. No organization charts are required. You need to first address the risks facing the Information Management/IM process. You also must address the growing IP risks!

As a UMUC Graduate School student, base your understanding, recommended methods and best practices, on our readings assigned this semester only in PMAN 637, sessions 1-5. Please use the current version of the PMBOK Guide (PMI, 2017) only. See grading criteria under "Content" and writing instructions for paper format under "Content"/Writing Instructions.

Session 5 "Risk Checklist" Team Exercise 5 points

During a Team meeting, discuss how the domains in this Checklist could be useful in analyzing the Cynapse case. Post your team "Checklist Comments" as an attachment or write them in the "checklist comments" boxes: no full sentences, thank you.

All members can reflect upon your Team's draft of the Checklist during the week if it is posted under "discussions". Your discussion of each domain is key to understand phases and methods of risk analysis. Soon, you will begin to outline the individual Case Analysis paper on the hypothetical Cynapse case, full of project risks. Study the 'domains' as well as articulate as many risks as you can with your team!

CHECK		Description	PMAN 637
Initiating the Project: Scope Phase	Checklist Comments
	1.1	Project goals
	1.2	Deliverables defined
	1.3	Project management processes clarified
	1.4	Project schedule, budget, resources & constraints - interaction w/stakeholders
	1.5	Risk Register and database created
	1.6	Project strategy
	1.7	Project deliverables clarified
	1.8	Resource requirements
	1.9	Project budget & schedule risk identification
	1.10	Formal project charter document - approval decisions
Planning the Project: Scope and Scheduling
	2.1	Project requirements - interaction w/stakeholders
	2.2	Work breakdown structure
	2.3	Resource management plan
	2.4	Project time & cost estimates
	2.5	Project risk breakdown
	2.6	Project plan
	2.7	Project plan approval
Executing the Project: Work, Implementation, Risk Monitoring
	3.1	Commit project resources - utilizing a work authorization system
	3.2	Implement project plan phases
	3.3	Manage project progress - reporting, analysis and measurement techniques
	3.4	Communicate project progress to stakeholders
	3.5	Implement WBS and update if there are gaps
Controlling the Project: Monitoring and Contingency Planning
	4.1	Measure project performance
	4.2	Refine risk ratings and escalate if necessary for rapid mitigation
	4.3	Perform timely corrective action
	4.4	Evaluate effectiveness of corrective actions
	4.5	Ensure compliance with change management plan and all deliverables
	4.6	Reassess project control plans and practices if scope creep occurs; perform risk mitigation
	4.7	Recognize and respond to risk event triggers
	4.8	Monitor project activity in schedule's critical path
Closing the Project: Documenting the Project Risks Encountered; Mitigation Strategies
	5.1	Obtain final acceptance of deliverables from stakeholders
	5.2	Document lessons learned
	5.3	Facilitate administrative and financial closure
	5.4	Preserve essential project records and required tools
	5.5	Release project resources and document

UMUC PMAN student response from session 5:

I think that the discussion was a great team exercise because it showed commitment and critical thinking even though it may require a long meeting (or two short ones) to cover every domain. For absent members, we just 'assigned' them a domain and kept going on our team conference call. This is a great way to both review a checklist and USE one! As a team we identified scope gaps, intellectual property risks,risks in lack of the use of tools we just studied, like a Risk Register, RBS and risk ratings, and much more. We also concluded that although the Checklist is a great tool it should be used in conjunction with other project management tools if we were real-world consultants. According to Heldman, "don't rely solely on checklists for the "Identify Risks" phase of any project, because you might miss important project risks. It isn't possible for a single checklist to be an exhaustive source for all projects" (Heldman, 2013, p. 260). However, this was a great Team Exercise for 5 points, since we each now understand the key phases of a project and use of a checklist when identifying risks in complex cases.