Is it the Right Choice for Independent Medical Practices?
Project management is nothing short of the application of 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, needless to say, every independent physician, whether employing a trained “Medical Practice Manager” or not are unconsciously following some form of project management scheme in their day to day practice.
Today, clinics that utilize formal 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 out there, 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 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 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, and 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 the requirements must be grasped 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– The right architecture for executing the requirements must be well explained.
Sixth and final– There needs to be enough calendar time-sequential progress.
In circumstances where 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.
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 various mixture of a specification-oriented, prototype-oriented, simulation-oriented, automatic transformation-oriented, or another approach.
Spiral Model Phases
Planning Phase
The planning phase involves determining the cost, schedule, and resources for the redundancy, which also involves understanding the system requirements for perpetual communication between the system analyst and the customer
Risk Analysis phase
Identification of potential risk is made while the risk mitigation strategy is planned and finalized
Engineering/ Development Phase
It includes testing, designing and deploying project at the client locality
Evaluation Phase
Evaluation of software by the customer. Also, includes identifying and monitoring risks such as schedule slippage and cost overrun
When to use Spiral Methodology?
Generally speaking, there are eight scenarios, where a spiral methodology can be useful. Those include:
1. The spiral methodology is particularly useful for large and extensive projects with high risk and unpredictability
2. When frequent releases are anticipated Spiral methodology can come handy
3. Need for creation of a prototype also establishes a logical usage for this methodology
4. Risk and costs evaluation are vital reasons as to why one should utilize Spiral
5. For medium to high-risk projects
6. When requirements are unclear and complex
7. When changes may require at any time
8. When long term project commitment is not feasible due to changes in economic priorities
Advantages and Disadvantages of Spiral Methodology
Although every project management tool can be useful if selected for the right project, nevertheless, understanding the significant obstacles and the advantages associated with the spiral methodology.
Generally speaking, Spiral methodology can add flexibility to its project by providing extra functionality and possibility for future changes. It renders the cost estimation much more manageable, particularly in large projects, by breaking it into smaller components. Such a fragmented approach will, therefore, serve as a buffer to the risk alleviation. Spiral also provides an opportunity for client feedback.
While the spiral method is useful for many project applications, however, it has its peculiar drawbacks. For instance, using spiral methodology may fall short on meeting a set deadline or budgetary threshold. It is best suited for large projects, which is why it may also require risk assessment expertise. Like some other project management tools such as Agile, the spiral methodology is inflexible and must be followed strictly. So, it requires comprehensive documentation, which also may add to the expenses.
The Four necessary Actions in every Spiral Cycle
Spiral methodology necessitates four distinctive actions that must happen in every cycle that includes:
1. Considering the win conditions or the stakeholder objectives and constraints.
2. Identifying and evaluating alternative approaches for satisfying the particular win conditions.
3. Identifying and resolution of the risks that originate from the chosen approaches.
4. And, to secure approval from all success-critical stakeholders, plus commitment to pursue the next cycle.
Risk Defines the Level of Effort Rendered
For any project activity from requirements analysis, design, prototyping to testing, the project team must determine how much effort is adequate. In a trustworthy spiral process cycle, individual decisions are made by lowering overall risk. For instance, spending extra time on the testing product or service plan frequently diminishes the risk due to the marketplace rejecting an imperfect output. Notwithstanding, additional measurement time might raise the risk due to a competitor’s early market entrance. Because, from a spiral model prospect, testing should be conducted until the entire risk is depreciated. That is why “Hazardous spiral look-alikes” that meddle invariant comprise evolutionary processes that disregard risk due to scalability issues and incremental processes that devote heavily in a technical architecture that must be redesigned or swapped to accommodate forthcoming increments of the product.
Risk Determines the Degree of Details
For the efforts rendered, any project artifact like requirements specification, design document, test plan, the project team must decide how much detail is acceptable. In an authentic spiral process cycle, these decisions are made by minimizing overall risk.
Considering requirements specification as an instance, the project should accurately designate those characteristics where risk is reduced through precise specifications. Conversely, the project should not quite specify those features where accurate specification increases the risk.
Use of Anchor Point Milestones in Spiral Method
Boehm’s original portrayal of the spiral model did not incorporate any process milestones. But, later upon many refinements, he interjected three anchor point milestones that serve as progress indicators and points of engagement. The anchor point milestones are distinguished by crucial questions; Life Cycle Objectives, Life Cycle Architecture, and Initial Operational Capability.
Life Cycle Objectives- Is there a sufficient definition of a technical and management strategy for satisfying everyone’s win conditions?
If the stakeholders approve, then the project has realized the Life Cycle Objectives milestone. Otherwise, the plan can be rejected, or the stakeholders can commit to another cycle to try to get to “Yes.”
Life Cycle Architecture– Is there a satisfactory definition of the adopted approach to satisfying everyone’s win conditions, and are all significant risks dismissed or alleviated?
If the stakeholders agree, then the project has also netted this Life Cycle Architecture milestone. Otherwise, the project is potentially abandoned, or the stakeholders can commit to another cycle that fits their objectives.
Initial Operational Capability– Is there adequate preparation of the software, site, users, operators, and maintainers to satisfy everyone’s win conditions by originating the system?
Once again, If the stakeholders agree to say “Yes,” then the project has cleared the Initial Operational Capability milestone too and is therefore launched. Or else, the project can be abandoned, or the stakeholders can assign to another cycle to try to get to “Yes.”
System Focus and its Life Cycle
This spiral invariant highlights the importance of the system as well as the long-term concerns across its entire life cycle. It rejects “hazardous spiral look-alikes” that places emphasis on the initial development, the type of rules which can result from following declared approaches to object-oriented or structured outcome analysis and design while ignoring other aspects of the project’s process requirements.
Spiral and its Utility in the Healthcare System
Spiral management methodology has been implemented with reasonable success in the healthcare arena. According to an article published in the International Journal of Science and Research (IJSR) in 2015, An online Multispecialty Hospital Management System was implemented utilizing spiral methodology. Online Multispecialty Hospital Management System provides the benefits of streamlined operations, enhanced administration & control, superior patient care, strict cost control, and improved profitability. The author implemented a fully computerized system in a hospital, with software taking care of all the requirements, while still both staff and patients could use the manual processes since they could not abruptly cope with the new system. Lack of IT-friendly medical personnel, along with A immense influx of patients visiting hospitals, makes the process of migrating to automated means highly tricky. Therefore, the Spiral project management tool was efficiently streamlined, taking into account the risks and limitations involved with the changes needed in the hospital system.
Another example, based on the particular circumstances about the healthcare system holds, such as confidentiality, authenticity, adaptability with external systems, and the complexity of the system, therefore necessitates a formal solution. The process model could be used when dealing with complex healthcare scenarios.
Due to the high volatility and risk within the healthcare system, Spiral can be particularly useful for cases such as Software development for physician practices. One can logically imagine utilizing Hybrid models of Agile and Spiral methodologies. For instance, when end-users of the medical software are using the product in practice, input validation could be very arbitrary depending on what the circumstances imply.
During the process of registration of a patient, some fields are required to fill out, however, when it comes to the emergency circumstances, the patient may not be able to satisfy the request base on the patient’s ailments. Therefore, solutions must be provided, such as minimize the required field of input, only submit the critical information, provide temporary references, or the option is given to the user to skip the area.
The Take-Home Message
In summary, the Spiral project management tool, in its pure form, is more suitable for an extensive healthcare system to implement a multifaceted automation process. Nevertheless, every circumstance, such as the scope of medical practice and its objectives, will ultimately drive the choice for the most fitting scenarios. In a high risk, a medical practice with high patient traffic and a multidisciplinary environment where staff are not well versed with advancements, the Spiral may be a reasonable option given the cost restraints. Even in that scenario, hybridizing it with an Agile scheme may render it more efficient.
