The Synaptic Case Study written by V.Makarov reviews a “biotechnology company that develops drugs based on proteins and peptides.” The organization has approximately 1200 employees, refers their their IT department as Information Management (IM), and has a department for computational biology. The IM staff consist of about 100 employees, but we do not know the size of the computational scientists employed by the organization.
Over the years a conflict has escalated between the two departments. The computational scientists have a different world view and production model than the information management department. And how could you blame them? The IM department has to ensure that communications in a very high tech business remain up and running amongst its 1200 employees. Due to this heavy requirement they’ve developed a very defined and rigid methodology to ensure that what they deploy will meet expectations. Working yourself into a dead end is not an option.
Science is similarly methodical, but also much more tolerant of failure. Working yourself to a dead end in order to explore possibilities is a part of the heritage of scientists carry forward. From Marakov’s write up it appears that these professionals are no different.
While cultural challenges are a large part of the problem the role of the reader is to step in and function as a consultant/project manager and develop solutions for the organization. Project management deals not just with the discipline of managing results structured to reach a desired end state (deliverable), but also managing the people whose talents must be employed to move the project forward. For this paper, in the role of the consultant/PM, I will present my perspective as I would to the client. I feel the best way to do this is to discuss risks associated with the three project dimensions, Resources, Schedule, and Scope. It is certainly not the most detailed framework in the discipline. I do believe that for the audience at hand, it is highly transferable and therefore an effective tool.
In much of the PM literature these three dimensions are charted out creating a nice triangle shape. In the case of synaptic their diagram doesn’t doesn’t have a true closed off shape, but rather a destructive spiral that increases in size as the project over time. This destructive spiral is true of most out of control projects. There are no set definitions because there is no agreement on what the project is and how it helps move the organization towards its goal.
In order to manage the organization’s resources, the organization’s goal needs to be clearly defined and defined in a way that doesn’t have a terminus. Once the organization’s goal is defined then the organization can be retooled to a balanced matrix organization which will keep the formal divisions within the organization, while empowering the PM to work across the organization’s boundaries to effect change.
Resources are the first area to tackle. They are both a physical constraint and a logical one. Different people and cultures have different views of resources and their purpose to any particular function. In Synaptic’s case the IM team views resources as fragile commodities where failure is severely destructive. Their world is ruled by uptime. The scientists’ world is not. Science is in part the quest for understand of different observable pieces of information. It’s not the quest for an uptime quota, it’s the quest for understanding. Certainly the field does have its absolutes, but it doesn’t have an expectation for zero risk, or zero failure scenarios. The very process of proving/disproving a hypothesis involves not merely observing failures, but actively seeking them out.
With these differing world views come different expectations of the purpose of resources. In both cases resources are a means to an end, but the scientist is trained for acceptable losses/failures/creative destruction with the resources under his care. That is why the first solution to implement isn’t just to define the resources arbitrarily, but define them by literally handing the science department its own separate set of assets to use in building out their projects. In order to move the company towards its goal (making money) it has to continue to innovate and this innovation cannot occur without the department responsible for innovating having resources.
In the case study a particularly destructive example was highlighted that cost a year’s worth of research time and essentially infected the information relied upon by other systems. With proper resourcing inside the CS department this problem could be isolated and mitigate the risk to the rest of the organization.
Project schedule is generally understood as “an output of a schedule model that presents linked activities with planned dates, durations, milestones, and resources.” Synaptic’s lack of a project schedule is a clear indication that they are dealing with the destructive project spiral illustrated above. In order to properly mitigate risk, the project schedule must be clearly defined. No risk mitigation measures can occur in Synaptic without some agreement to a schedule for production. The case study’s narrative gives the PM a great opportunity to commit all stakeholders to a schedule. Losing a year’s worth of data isn’t just an unfortunate event that could be mitigated by isolating the risk to other systems. It’s also a large waste of time and money. This loss to the company, this movement away from the company’s goal, is clearly a justification for change.
Committing development to a schedule can be difficult where projects are developing new technologies. One example of this is ZFS’s history which includes four years of development without a clear announcement date to develop against. While the PM does have to deal with the reality of an unclear deliverable schedule, they can minimize lost time through inefficiencies such as improper calculations by committing to audits and other quality control measures during the life of the project. In this way the schedule’s delivery date may be undefined, but the project will have routine reviews to document progress as it evolves. Moving the quality control mechanisms along the production chain will reduce the level of the overall risk for the project. Allowing the team to address it in smaller segments throughout the life of the project instead of at the end isn’t one of the strategies listed by Watt, but my experience indicates that this is an effective strategy.
The final area to address is the project’s scope. This isn’t because it’s the least important. On the contrary its significantly important to managing the people in the organization and managing progress towards the goal. This is the last area to address because problems with resources and schedule give opportunity to fix the organizational changes that will allow the project’s scope to be defined. Agreement on the project’s scope requires open communication between all stakeholders and that open communication is not achievable without addressing the organizational issues that more readily affect resources and schedule.
Again the destructive spiral illustrated earlier is at play in this dimension as well. As resource requirements and schedule increase so does the project’s scope. Symptoms of its ambiguous nature are evident in the description that the projects at Synaptic are ad-hoc (Makarov, n.d.). While the process of discovering new drugs will involve experimentation the process of project management cannot be conducted in an ad-hoc fashion. The scope of each project needs to be defined. Then it can be resourced and scheduled properly. If the project’s scope is determined to be untenable, then it will need to be turned off. If the organization streamlines their process for initiating and executing projects it will develop techniques to make this process as efficient as possible. None of this is possible without refocusing the individuals within the organization to recognize their role in moving the organization towards its goal.
The intent of this paper was to analyze the risks to projects conducted with the Synaptic organization. The largest risk to projects is with the organization’s leadership dealing with the competing world views of the different organizational departments. Once these parts have been recognized and the organization restructured as a balanced matrix, risk solutions can begin in earnest. I chose to address the areas that are issues along the dimensional terms used in much of the PM literature. Under the project’s resources I advocated for establishing a resource pool within the computer science department to minimize the impact of failures inherent in the creative process as well as to empower those innovating towards the organization’s goals. In the project schedule dimension I discussed the opportunity to leverage the lost time caused by poor PM practices as a way to implement routine reviews of progress. While innovation can’t always be attached to a deliverable date, reviews of its progress can. For the last area, project scope, I discussed how this area, while listed last, was important but could not be addressed without establishing a the baseline for organizational operation through the first two dimensions. The discussion on scope highlighted the need for specific scope and an efficient PM progress that would allow untenable programs to be turned off quickly.
While it appears I’ve spent a large time discussing divergent world views instead of focusing on the details oriented to the project, I believe that a PM who ignores the audience he’s managing can damage his long term success over time. The long term risks to the organization are larger than any one specific project. A specific project review would result in a more specific checklist of risks following the Identify, Assess, Plan model. This case study requires more of what Goldratt describes as his five focusing areas and his three crucial leadership questions, “What to change? What to change to? And “how to cause the change?”
Project management isn’t just about working the deliverable to its scheduled date, but its also about managing the people who’ll be working projects for the long term and that is where the greatest risk lies with Synaptic and where the solutions need to be focused.