en
de

Top Ten Errors in Medical Projects – #9: Process versus Project

5 August 2016
| |
Reading time: 2 minutes

This is the second in a series of blog postings in which we present a top-ten list of common errors encountered in the context of medical projects. Of course, such a ranking depends on personal observations and individual experience – and hence has a subjective outcome. Please feel invited to tell us about your perspective in the comments section!

Organizations that pursue medical projects are expected to define, and adhere to, specific processes. The IEC 62304 standard, for example, demands processes for software development, maintenance, risk management, configuration management, and problem resolution. As a matter of principle, this should not be much of an issue:

  • Standards like IEC 62304 specify the requirements for the different processes in a concrete manner. Hence, when you need to define the respective processes for your organization, maybe 80% of the job can be done by simply reading the standard in question and translating it into a process definition on the fly, mapping one requirement to one paragraph at a time and adding details where appropriate.
  • There are many well-specified process frameworks out there – frameworks that subsume crucial learnings from thousands of real-world projects, that are designed in such a way that they can easily be tailored to any given setting, and that come with well-proven templates for all sorts of documents.
medical errors process versus project

Medical errors process versus project

Given these preconditions, one might expect to see nothing but lean, well-tailored, pragmatic processes in the real world. But that, alas, is not the case. More often than not, one encounters the following effects:

  • Most organizations define processes that are optimized only for their single biggest project and hence impossible to scale down, thus burdening smaller projects with excessive formal overhead.
  • In many organizations, the process definition is completely left to quality departments whose members are not in touch with the reality of development projects. This necessarily results in inefficient, unrealistic processes – and in templates that turn potentially helpful documents into some kind of maintenance nightmare.
  • Many process definitions out there are fundamentally flawed in so far that they simply do not reflect the life-cycle of real projects. Regarding software development, the most famous example for this is the waterfall process model, which (in its pure form) entirely ignores the importance of learning and feedback loops.
  • When individuals are asked to define processes, their fear of leaving something important out forces them to overfulfill the requirements. For obvious reasons, this especially holds for inexperienced personnel.

Considering the impact that processes have on project cost and time, these observations are surprising. Incredible amounts of man-years are wasted because people are asked to work in unnatural ways, to bend reality until it fits the model, or to write documentation in terrible templates and hostile environments. It is important to note that the absolute majority of this effort is neither required by the laws and standards nor helpful in the context of audits.

Coming up next: #8, Eager Beaver / Lazy Bum. See you there!

Read more:
Blogpost #10: Top Ten Errors in Medical Projects – #10: Clinical Something!

Comments (0)

×

Sign up for our Updates

Sign up now for our updates.

This field is required
This field is required
This field is required

I'm interested in:

Select at least one category
You were signed up successfully.

Receive regular updates from our blog

Subscribe

Or would you like to discuss a potential project with us? Contact us »