Is it the Right Choice for Independent Medical Practices?
Project management is nothing short of applying knowledge, skills, tools, and techniques to activities to meet the requirements of a temporary endeavor or “project.” As every business within the healthcare realm can be labeled as a single project at a given time and place, therefore one can without difficulty assume that a medical practice is, in fact, an endeavor with multiple sub-projects.
Most clinicians probably are not familiar with various project management tools, as not routinely, it is thought within the scope of the medical school curriculum. However, every independent physician, whether employing a trained “Medical Practice Manager” or not, is unconsciously following some form of project management scheme in their day-to-day practice.
Today, clinics that utilize standard project management tools find themselves well-aligned with contemporary medical practice challenges. And those who don’t just pull themselves out of their Comfort zone and embrace the new way of tackling daily projects.
For the past few years, I have been studying various project management methodologies. And since almost all of them have merely originated from industries other than healthcare, I have been more enthusiastic about finding the perfect project management tool that would address the needs of today’s independent medical practice. The answer I found is as follows: There is always an excellent tool, but that perfect Project management methodology is not the perfect one for every practice and scenario.
In my earlier publications, I have summarized various project management tools that would come in handy in physician practice, such as Agile, Lean, and Waterfall methods. I have also indicated some hybrid models as well. In this piece, I would like to elaborate on another Project management tool, the Spiral Methodology.
The Spiral Project Management and its Origin
The Spiral concept goes back to a paper published by Barry Boehm in 1986, titled “A Spiral Model of Software Development and Enhancement.” Within his publication, he liberally used the term “process model,” referring to the spiral model as we know it today. Nevertheless, Spiral was also referred to as incremental waterfall, prototyping, and other approaches.
Boehm describes the spiral model as a “process model generator” in his later papers, where selections were based on a project’s risks as the driver of generating an appropriate process model for the project. Thus, the incremental, waterfall, prototyping, and other process models are exceptional cases of the spiral model that fit the risk exemplars of specific schemes.
Despite the common perception of his time holding that the first Spiral scheme is indeed oversimplified, Boehm finds it to the contrary. Instead, in support of his belief, he classifies Spiral based on several misconceptions. He speaks, amongst many, the most dangerous of the mistakes are that first, the Spiral is a sequence of waterfall increments. And that all project activities obey a single spiral sequence. He also rejects the fact that every operation in the spiral diagram must be completed and in the layout presented. Thus, to better recognize the genuine Spiral from “hazardous spiral look-alikes,” Boehm prepares six standard features of an authentic spiral application.
First- He believed we must grasp the requirements before the implementation of the Spiral.
Second- The requirements ought to be devoid of unfinished, high-risk ends, such as risks due to cost, schedule, safety, performance, user interfaces, organizational forces, etc.
Third- The essence of the requirements should not vary during development or evolution.
Fourth- The requirements should be agreeable with all the principal system stakeholders’ expectations, including users, customers, developers, maintainers, and investors.
Fifth- We must well explain the exemplary architecture for executing the requirements.
Sixth and final- There needs to be enough calendar time-sequential progress.
When these assumptions do apply, it is a scheme risk to avoid specifying the requirements and blindly proceed sequentially. The waterfall model thus becomes a risk-driven particular case of the spiral model.
Sequentially defining the actual vital products for a project often diminishes the possibility of developing a system that meets stakeholder objectives and constraints, also called “Win Conditions.”
This invariant excludes “hazardous spiral look-alike” processes that use a sequence of incremental waterfall omits in settings where the underlying presuppositions of the waterfall model do not apply.
Spiral is a Risk-Driven Project Management Methodology
The spiral model is merely based on the unique risk patterns of a given project; the spiral model guides a team to adopt elements of one or more process models, such as incremental, waterfall, or evolutionary prototyping.
The spiral model’s characteristic “risk-driven hybrids” of other process models’ hallmarks are already present. Today, risk-driven models of the spiral model steps provide the basis to hold a various mixture of a specification-oriented, prototype-oriented, simulation-oriented, automatic transformation-oriented, or another approach.