Tag Archives: project management

Clinical Programmer Available for Consultancy projects.

Clinical Programmer Available for consultancy projects – Medidata Rave Certified.

Rate: Negotiable

Hours: part time or full time

Contracts: 1099 or Corp-2-corps only.

Where in the World is Ana?

First, I want to say thank you for reading my blog, connecting with me on LinkedIn or following whenever I go [thank you NSA].

Many of you, for months, have asked me if I was going to write more articles related to clinical trials. For sometime now, I have taking time-off from this EDC blog and concentrated on some other projects of equal importance. I will share some new insights and information as I get myself back on track.

So what is a girl who has a master’s degree in project management and computer networks doing as a programmer? It’s not that I didn’t like project management, per se. And entering in the IT network business years ago was quite difficult for girls like me in a world dominated by men. It’s basically that I didn’t find myself with the same passion for project management or computer networks that I have for programming and technology in general.

Because I am so interested in technology and programming, I tend to spend a lot more time than my peers in learning new technologies, and enhancing my existing skills. Many of my co-workers and ex-collega (Dutch) have commented on their admiration that my skill level is as high as it is, and that I am able to learn new technologies so quickly. But beyond just learning new technologies and APIs, I’m passionate about becoming a better overall programmer. Reason why in the last few months, I spent time learning IOs development (iPhone and Android apps). I am actually working on an app to ‘hack’ into my own car. 🙂 Well, not exactly. I want to be able to open my car and do some other basic command (like opening the garage door) using an APP.

Given my degree in project management, it should be clear that I have useful skills beyond the programming world. In fact, having a project management background has helped me interface with various groups in various organizations in which I’ve worked.

I have installed, maintained, and designed numerous relational databases and small networks. As a freelancer, I have worked in projects doing data analysis, project support and computer training.

Now you know a little about me personally. If you think I might be the type of developer you’re looking for, feel free to browse my resume and contact me.

Anayansi Gamboa
Resume / CV .

Comments? Join us at {EDC Developer}

P.S. I will be releasing some training videos / training material for several EDC tools in the near future including tips and best practices. Price has not been setup yet. All training will be web-based, password protected. If you wish to consult with me for a face-to-face training or on-site training, please contact me to discuss further.

Fair Use Notice: This video contains some copyrighted material whose use has not been authorized by the copyright owners. We believe that this not-for-profit, educational, and/or criticism or commentary use on the Web constitutes a fair use of the copyrighted material (as provided for in section 107 of the US Copyright Law. If you wish to use this copyrighted material for purposes that go beyond fair use, you must obtain permission from the copyright owner. Fair Use notwithstanding we will immediately comply with any copyright owner who wants their material removed or modified, wants us to link to their website or wants us to add their photo.

Disclaimer: The EDC Developer blog is “one man’s opinion”. Anything that is said on the report is either opinion, criticism, information or commentary, If making any type of investment or legal decision it would be wise to contact or consult a professional before making that decision.

Disclaimer:De inhoud van deze columns weerspiegelen niet per definitie de mening van {EDC Developer}.

Disclaimer: The legal entity on this blog is registered as Doing Business As (DBA) – Trade Name – Fictitious Name – Assumed Name as “GAMBOA”.

End-of-Project Lessons Learned

Below is an example agenda for a half-day lessons learned meeting at the end of a project (sometimes called a Project Closeout Meeting). It includes:

  • who should attend.
  • meeting objectives.
  • meeting deliverables.
  • agenda items showing a suggested sequence of team discussion, brainstorming, and analysis by which the team can agree upon what went well on the project, what didn’t, and what should be done differently next time.

Meeting Objectives:

  1. Understand how this project performed against its original goals (time, resources, scope)
  2. Identify “lessons learned” and recommendations for future projects.
  3. Set actions to ensure lessons learned are considered during planning of next project.

The only way to avoid problems happening yet again in the future is carefully consider what went wrong and why, and make sure there is a way to transfer related recommendations forward

Deliverables from Meeting:

  • Report including:
    • Review and analysis of plan vs. actual milestone achievement and state of what we delivered vs. the original requirements
    • Team’s brainstorm list of wins and challenges
    • Team’s list of derived recommendations for achieving the wins and avoiding the challenges on future projects
    • Open issues list and action items
  • Key items will be turned into templates and checklists for use during projects.
Agenda Item Facilitator(s) Time
Introduction, agenda review, ground rules Stakeholder 5 min
Wins and challenges

Project retrospective: Review planned vs. actual on major milestones and how what we released mapped to original major requirements

Round-robin brainstorm: Go around the table and record a win or challenge from each person. Keep going until no one else has items to add.

Map back to major project issues—which challenges contributed most to milestone and Vision shortfalls? Which wins contributed most to what the project accomplished?



xx min
Create lessons learned recommendations

Wins: what do we think other projects should do to achieve these wins?

Challenges: how should future projects avoid each issue we identified?

Stakeholder xx min
Next steps

Review action items and finalize assignments.

Stakeholder xx min.


Global Brain Inc.’s Quality Rapid Product Development QRPD methodology

What Are We Building Again?

When I first started project management classes in 2007, I came across this article and I saved it on my favorites folder. I want to share this experience with you.

Below are some situations I have run into working on projects. Have you ever experienced anything like this?

      New items proposed for the project require hours of excruciating debate because “I can’t tell from the scope document whether that is in scope or not.”
      The project team is convinced that one of the requirements will be very painful to realize. So they determine it is out of scope based on an incredibly obscure interpretation of the scope document.
      When confronted with a change request, the project team resists via slavish devotion to the scope document. (“Yes, that seems like the best place to implement that requirement, but changes to that system were not in scope, so we’ll have to create this really nasty workaround instead.”)

Ok, I may have exaggerated a little, but truth be told, stories like that play out on projects every day. For some reason, not knowing what a project is really supposed to accomplish is a common problem. Scope issues can lead to bigger problems down the road on the other two sides of that infamous Iron Triangle—schedule and budget.

All We Have to Do is Define a Detailed Scope…

Scope is notoriously hard to define in a useful manner, mainly because when it is initially defined the team does not know much about the project yet. Usually, someone with influence identifies the need for a project. They speak with the appropriate people or fill out the appropriate forms, with a flowery story explaining why this particular initiative is the most important activity the organization can do in the next twelve months. A project team is assigned to the initiative. They in turn talk to the requestor, and other experts identified by the requestor, to find out what the initiative entails. A large wish list is created that usually serves to confuse rather than illuminate the problem space. Some of these items are extremely specific, but most of them are very general; mainly because the project team does not have sufficient information to be extremely precise.

After some work down this path, the team looks at the ever-growing list and realizes that if they do not limit the items in some way they will never complete the project. They begin to make arbitrary divisions in the work: they limit the locations to which the project results will be made available, the business units provided access to the project results, the deliverables that will be provided, or a combination of these and others. Meanwhile the customers of the project are frantically dreaming up all possible deliverables, situations, and scenarios in the hope of getting them on the list before the scope is “frozen.” After all, nobody wants to be a scope creep.

Any client requested work falling outside the scope of this contract will be billed at €xxx.

While the divisions in the work seem to make sense at the time, they are usually based on factors related to how difficult (or more often how easy) it would be to deliver particular groupings. What teams often fail to take into account is a rather crucial piece of information—the vision of the project.

Clarifying that Blurry Vision

For those of you that I just caught in mid groan at the mention of the V-word, stop. The vision I am speaking of is much more practical than the Mission, Vision, Purpose discussions that organizations sometimes find themselves in. Stated simply, the vision seeks to capture what the project is supposed to accomplish. Or in other words, “What are we supposed to build again?”

Consider for a minute a project undertaken by an organization’s internal IT department. The vision of this project simply identifies the business problem the project is trying to solve. This statement does not have to be long; in fact the more concise that it is, the better it is. But here is the key: everyone involved in the project has to understand, support, and believe in the ultimate vision. How do you get to that to happen? You gather the entire project team together and ask them to collaborate on a shared vision.

On planning – What is truth today may be falsehood tomorrow. Never confuse your plan with truth. – Woody Williams

Gathering the entire team together to build a shared vision has several benefits. First of all, the job of communicating and achieving buy in of the vision is much easier. Even better, the entire team has a better picture of what the project is actually supposed to accomplish, so determining and working within scope is that much easier.

You want this vision to be understandable and very concise. These characteristics make defining the vision difficult, and as a result the conversations in these sessions become rather illuminating. The project team must focus on the really important aspects of the project so there is some inherent prioritization. But it is prioritization that is based on what is most important for the business.

So How Do We Get There?

Once the team has established their project vision, they need some guidelines for accomplishing that vision. That’s where scope comes in. Scope is a conceptual description of what the project will deliver in support of the vision. If described in the terms of problem and solution, the scope describes possible solutions and constraints on realizing those solutions.

So even with a vision established, how do you avoid the scope traps described above? First of all, the vision provides some general guidelines as to what should even be included in scope. If an item is brought up that seems like a great idea but does nothing whatsoever to accomplish the vision, do not include it “in scope.” In the same vein, if something comes along that is obviously critical to achieving the vision, that particular item will more than likely take on a higher priority.

The next trick comes in the way you represent scope. Remember those long lists that project teams get lost in and manage to interpret in ways that allow them to avoid annoying activities? Those lists are usually made up of statements formatted in a variety of ways and sourced from emails, conversations in the hallways, previous scope lists from failed projects, and pronouncements from various members of the organization’s leadership. The statements are vague, and often not very useful. One way to get around that problem is to define some structure for recording the scope statements. The format I find useful was originally suggested by Mike Cohn as a way to record User Stories, a form of recording requirements used in agile software development. (See User Stories Applied for Agile Software Development.) The format is straightforward:

So for example, in a project focusing on a new payroll system, the following could be an example scope statement:

AS A Payroll administrator

I WANT to be able to manually adjust payments for miscellaneous reasons
SO THAT I can process payroll in a timely manner
Sure, this statement is still pretty vague, but at least there is some information regarding who wants the feature or deliverable and why they want it. These types of statements are intended to be placeholders, reminders of future conversations that need to take place, which makes them a perfect format for capturing scope.

Wait a second, you say, that looks an awful lot like requirements. Yep. Requirements typically define the scope of a project, so why should they be defined separately? Save some time and record scope as you would requirements, expecting to further flesh out the information as you proceed with the project.

The final trick in avoiding the scope traps above is to take an iterative approach to realizing the scope items. Instead of trying to deliver all of the scope items applicable to a particular geography or business unit, pull those scope items into a “phase” list. Then break the effort into deliverable-focused iterations. Select a subset of scope items, deliver them, and learn from that experience. Then select the next subset of scope items and repeat the process, applying the lessons. This approach allows the project team to react to new understandings and adjust what they are doing accordingly.

Trying to manage a project without project management is like trying to play a football game without a game plan. – K. Tate

I Can See Clearly Now…

Project Vision and Scope should be great tools that help the project team accomplish what they are really trying to achieve. Unfortunately these tools can also distract from focus if it takes an inordinate amount of time to create them, or if the discussions and results cause more confusion than clarity. Relying on an unfocused, Easter egg hunt approach to gathering scope statements virtually guarantees these problems. The key is for the project team to define together what they are really trying to accomplish, and to maintain focus on that vision while identifying the details of how they are going to get there.

Reference: Author Kent McDonald

Disclaimer Under Section 107 of the Copyright Act 1976, allowance is made for “fair use” for purposes such as criticism, comment, news reporting, teaching, scholarship, and research. Fair use is a use permitted by copyright statute that might otherwise be infringing. Non-profit, educational or personal use tips the balance in favor of fair use.”

Data Management Plan in Clinical Trials


The preparation of the data management plan (DMP) is a simple, straightforward approach designed to promote and ensure comprehensive project planning.

The data management plan typically contains the following items. They are:

  1. Introduction/Purpose of the document
  2. Scope of application/Definitions
  3. Abbreviations
  4. Who/what/where/when
  5. Project Schedule/Major Project Milestones
  6. Updates of the DMP
  7. Appendix

The objective of this guidelines is to define the general content of the Data Management Plan (DMP) and the procedures for developing and maintaining this document.

The abbreviation section could include all acronyms used within a particular study for further clarification.

e.g. CRF = Case Report Form
TA = Therapeutic Area

The Who/What/Where/When section should describe the objective of the study specific data management plans for ABC study. This section provides detail information about the indications, the number of subjects planned for the study, countries participating in the clinical trial, monitoring guidelines (SDV) or partial SDV, if any CROs or 3rd party are involved in the study (e.g. IVRS, central labs), which database will be used to collect study information (e.g. Clintrial, Oracle Clinical, Medidata Rave or Inform EDC).

The Appendix provides a place to put supporting information, allowing the body of the DMP to be kept concise and at more summary levels. For example, you could document Database Access of team members, Self-evident correction plan, Data Entry plan if using Double-data entry systems or Paper-Based clinical trials systems.

Remember, this is a living document and must be updated throughout the course of the clinical trial.

If problems arise during the life of a project, our first hunch would be that the project was not properly planned.

Reference: Role of Project Management in Clinical Trials
Your comments and questions are valued and encouraged.
Anayansi Gamboa has an extensive background in clinical data management as well as experience with different EDC systems including Oracle InForm, InForm Architect, Central Designer, CIS, Clintrial, Medidata Rave, Central Coding, OpenClinica, Open Source and Oracle Clinical.

To hire me for services, you may contact me via Contact Me OR Join me on LinkedIn

Disclaimer: The legal entity on this blog is registered as Doing Business As (DBA) – Trade Name – Fictitious Name – Assumed Name as “GAMBOA”.

A Big Project from Initiation to Closing – a Canal: Panama

Apart from wars, this is the most expensive undertaking in the world. It was a huge engineering project that started in the mid-1800’s and that employed thousands, cost millions of dollars, and took years to complete.

We will follow the story of the Panama Canal project as documented in Identifying and Managing Project Risk by Tom Kendrick. We will also discussed the latest canal expansion project to be completed by the year 2014.


Part 1: Anatomy of a Failed Project:
The first Panama Canal project was a failure. The work the began on 1881 by Ferdinand de Lesseps, the builder of the Suez Canal, which triumph earned him the nickname “The Great Engineer,” but this project was abruptly stopped 8 years later.

It has been said that the canal failure was due to improper Risk management planning. It is important to pay attention and take into account lessons learned on projects from the past and not just plan for the future. Mistakes were made for a long, long time until finally it failed.

Risks were not identified effectively or were ignored, and the primary risk management strategy seems to have been “hoping for the best.”

Planning for the project was also a low priority. De Lesseps paid little attention to technical problems. Many engineers voted against the canal project due to technical difficulties but De Lesseps ignored the views of those who disagreed with him. He believed that need would result in innovation, as it had at Suez, and that the future would take care of itself.

The original estimates of the volume of excavation required started to rise, to 120 million cubic meters-almost triple the estimates provided in the original plan. As the magnitude of the effort rose, De Lesseps made no public changes to his cost estimates or to the completion date.

About Panama:
Panama is in the tropics, and torrential rains for much of the year created floods that impeded the digging and made the work very dangerous. The frequent rains turned Panama’s clay into a flowing, sticky sludge that bogged down work, and the moist, tropical salt air combined with the viscous mud to destroy the machinery. There was also the issue of elevation. The continental divide in Panama is not too high by North or South American standards, but it does rise to more than 130 meters. For a canal to cross the central portion of Panama, it would be necessary to dig a trench more than fifteen kilometers long to this depth, an unprecedented amount of excavation. Digging the remainder of the eighty-kilometer transit across the isthmus was nearly as daunting.

Funding for the work was a problem, as only a portion of the money that was raised was allocated to construction (most of the money went for publicity, including a very impressive periodic Canal Bulletin, used to build interest and support).

Diseases like malaria and yellow fever were also troublesome and killed many workers. Eventually, thousands of workers died, creating a negative publicity and the idea of a sea-level canal doomed.

Project Status:
the Canal Bulletin reported good progress (regardless of what was actually happening). As the project continued, many changes were made but not disclosed or reported out. The opening of the canal eventually delayed and millions of more dollars spent for less than 1/5 completion.

Failures to raise funding, De Lesseps liquidated his company and the project ended. The French empire collapse with the most costly project in history.

With no post-project analysis, the French and many investors lost over $300 millions, decade of work and no canal including many lost of lives (workers who came to Panama).

In conclusion, while it seems as the possible idea of a sea-level canal became the impossible task; nevertheless, the project management practices of those years could have been beneficial with the appropriate objective, better communication and the appropriate risk management plan.

You can not effectively manage the resources, time and money in a project unless you actively manage the project scope.

Identifying and Managing Project Risk by Tom Kendrick
Wikipedia-Panama Canal

Part2: U.S.A Construction of the Panama Canal

Part3: Future-Building the New Canal


Role of Project Management and the Project Manager in Clinical Data Management


The Project Manager is responsible for the development, oversight of implementation, and communication of clinical research studies.

So what is a Project?

A project is a work effort with a definite beginning and end, an identifiable end result (deliverable), and usually has limits on resources, costs and/or schedule.

What is Project Management?

The application of knowledge, skills, tools, and techniques to project tasks in order to meet project requirements.

In order to be a successful project manager, you need to understand the “Tripple Constraint” and how they affect your project. Let’s look up the WBS-edit checks:

Note: I will refer a project = clinical study

Scope: What is in the contract? How many edit checks, SAS checks and manual checks are required in this study? What is the effort per edit check, SAS check and manual check?

The goal is to convert the idea of data management to that of statistical analysis – an analyzable database.

Time: What are the deliverables and timelines? What resources are needed?

Cost: What are the budget restrictions? Are there any risks associated with any changes?

Project Planning: During the planning of a clinical study, we identify the project scope, develop the project management plan and we identify and schedule the clinical study activities.

Some questions might arise during the project planning phase: how many sites/subjects and pages will be collected?Who will attend team meetings? what study fields will be code (i.e. Adverse Event term)?

Other important activities that the project manager and clinical team members will need to be involved:

Work Break Down (WBS) – it is the list of activities that will be performed during the course of a clinical study.

Resourcing – it is important to assign the right person to a particular task based on skills, education and experience.

ICH Guidelines ‘…all personnel involved in clinical trials must be qualified and properly trained to perform their respective tasks…’

Estimating Cost – look at historical data as well as good estimates from effort per unit and units using your WBS as references.

Scheduling and Budgeting – you will be able to build schedules and budgets that transform project constraints into project success after you successfully construct your Work Breakdown Structures (WBS) and network diagrams and estimate task durations.

Projects managers used techniques for employed to establish project. Project Manager can decide which activity can be delayed without affecting the duration of the projects. They help improving quality and reduce the risks and costs related with the projects.

A recent survey by the Project Management Institute provided 10 challenges affecting project managers. This research intended to identify key factors affecting project team performance:

  1. Changes to Project Scope (Scope Creep)
  2. Resources are Inadequate (Excluding Funding)
  3. Insufficient Time to Complete the Project
  4. Critical Requirements are Unspecified or Missing
  5. Inadequate Project Testing
  6. Critical Project Tasks are Delivered Late
  7. Key Team Members Lack Adequate Authority
  8. The Project Sponsor is Unavailable to Approve Strategic Decisions
  9. Insufficient Project Funding
  10. Key Team Members Lack Critical Skills

Another question to ask is what tools are available to help you get the job done?

  1. Resource allocation (and the software’s ability to easily display staff who were overallocated)
  2. Web-based/SaaS option
  3. Cost/Price of the system (big one!)
  4. Contractual terms we could enter into (i.e. 6 months, 12 months, month to month)
  5. Ability to demo the software and for how long
  6. What sort of customizations could be made to the software after purchase
  7. Types of customers the software has served
  8. Report types
  9. Ability to sync with accounting software and which ones, if so
  10. Timeline generation capabilities and import function with MS Project
  11. Ability to create template projects
  12. Ability to alert on early warning signs (i.e. budget overruns over 10%)

It is suggestted that you review each suggestion on project management tool very, very carefully to determine how it fits your processes.

Your organization’s processes are unique to your organization; no other organization anywhere has quite the same processes. So what may work for one organization may not necessarily work for you. Your organization developed its processes to suit your particular corporate culture, the particular collective character attributes of the employees (their experience, etc.), the type of projects that you execute and the particular types customers/clients that you have (especially the regular ones).

You now have to make sure that the tools you choose work for you and your particular processes. Do not change your processes again to suit whatever workflow (process) is dictated by the fancy tool that the fancy salesman sold to you; you are likely to find that the tool-dictated workflows do not work that well in your organization, with the result that the employees will give up following processes and/or give up using the tool, throwing everything into chaos again.

Be careful if you are looking at tools that offer to do a number of different functions or can be made to do any function you want it to do. They seldom do the job that you bought it for particularly well. For example, I have worked with a tool that was advertised as a combination issue tracking and defect/bug tracking tool. It was used as a defect tracking tool but it was very poor; it was tremendously difficult to make it prepare useful reports. A hand-written tool set up in a spreadsheet (e.g. Microsoft Excel) or database (e.g. Microsoft Access) would have worked better.

That said, there are tools out there that are specific to one particular function but do offer flexible workflows – they may be modified to match whatever processes your organization already follows.

If your organization has just started to organize the PM processes and PMO that would mean processes & other related areas are not explicitly defined. So there may be a huge risk trying to adopt an integrated and centralized project management system. It is more likely to offer you a very comprehensive, complex but expensive solution wherein your problem is still not defined completely. In such a case you are just not ready with the environment and process maturity that an integrated tool requires prior to implementation.

A more efficient approach should be iterative, incremental and adaptive in nature. That means you shall use simple, not so expensive tools with limited scope to begin with; they can be tools with basic functionalities of WBS, scheduling, traceability and custom datasheets. These tools should have capability to exchange data both ways with more commonly uses tools like MS Excel, MS Project, and Word etc. The processes are likely to mature over time and we will then know the real effectiveness of these basic tools in the context of company requirements. That may be the time to analyze and switch to more integrated solutions.

One important key to remember. The role of project management in clinical trials is evolving. There is a debate about who should be the ‘project manager’ for a particular clinical study. CRA or Clinical Data Manager or an independent project manager? Let’s review their roles within data management.

Clinical Research Associate (CRA): main function is to monitor clinical trials. He or she may work directly with the sponsor company of a clinical trial, as an independent freelancer or for a Contract Research Organization (CRO). A clinical research associate ensures compliance with the clinical trial protocol, checks clinical site activities, makes on-site visits, reviews Case Report Forms (CRFs) and communicates with clinical research investigators. A clinical research associate is usually required to possess an academic degree in Life Sciences and needs to have a good knowledge of Good clinical practice and local regulations. In the United States, the rules are codified in Title 21 of the Code of Federal Regulations. In the European Union these guidelines are part of EudraLex. In India he / she requires knowledge about schedule Y amendments in drug and cosmetic act 1945.

Clinical Data Manager (CDM): plays a key role in the setup and conduct of a clinical trial. The data collected during a clinical trial will form the basis of subsequent safety and efficacy analysis which in turn drive decision-making on product development in the pharmaceutical industry. The Clinical Data Manager will be involved in early discussions about data collection options and will then oversee development of data collection tools based on the clinical trial protocol. Once subject enrollment begins the Clinical Data Manager will ensure that data is collected, validated, complete and consistent. The Clinical Data Manager will liaise with other data providers (eg a central laboratory processing blood samples collected) and ensure that such data is transmitted securely and is consistent with other data collected in the clinical trial. At the completion of the clinical trial the Clinical Data Manager will ensure that all data expected to be captured has been accounted for and that all data management activities are complete. At this stage the data will be declared final (terminology varies but common descriptions are Database Lock and Database Freeze) and the Clinical Data Manager will transfer data for statistical analysis.

Clinical Data Management (CDMS) Tools: (we will review each of them on a separate discussion)

  • Standard Operating Procedures (SOPs)
  • The Data Management Plan (DMP)
  • Case Report Form Design (CRF)
  • Database Design and Build (DDB)
  • Validation Rules also known as edit checks
  • User Acceptance Testing (UAT)
  • Data Entry (DE)
  • Data Validation (DV)
  • Data Queries (DQ)
  • Central Laboratory Data (CLD)
  • Other External Data
  • Serious Adverse Event Reconciliation (SAE)
  • Patient Recorded Data (PRO)
  • Database finalization and Extraction
  • Metrics and Tracking – see BioClinica article on Metrics
  • Quality Control (QC)- see discussion on A QC Plan for A Quality Clinical Database

In conclusion, a key component of a successful clinical study is delivering the project rapidly and cost effectively. Project managers must balance resources, budget and schedule constraints, and ever-increasing sponsor expectations.


To hire me for services, you may contact me via Contact Me OR Join me on LinkedIn
Anayansi Gamboa has an extensive background in clinical data management as well as experience with different EDC systems including Oracle InForm, InForm Architect, Central Designer, CIS, Clintrial, Medidata Rave, Central Coding, OpenClinica Open Source and Oracle Clinical.


Cartoon of the Day – RMS

Revenue Management Systems by various Cartoonist

“Copyright Disclaimer Under Section 107 of the Copyright Act 1976, allowance is made for “fair use” for purposes such as criticism, comment, news reporting, teaching, scholarship, and research. Fair use is a use permitted by copyright statute that might otherwise be infringing. Non-profit, educational or personal use tips the balance in favor of fair use.”

Cartoon of the Day – RMS

Revenue Management Systems by various Cartoonist

“Copyright Disclaimer Under Section 107 of the Copyright Act 1976, allowance is made for “fair use” for purposes such as criticism, comment, news reporting, teaching, scholarship, and research. Fair use is a use permitted by copyright statute that might otherwise be infringing. Non-profit, educational or personal use tips the balance in favor of fair use.”

Cartoon of the Day – RMS

Revenue Management Systems

“Copyright Disclaimer Under Section 107 of the Copyright Act 1976, allowance is made for “fair use” for purposes such as criticism, comment, news reporting, teaching, scholarship, and research. Fair use is a use permitted by copyright statute that might otherwise be infringing. Non-profit, educational or personal use tips the balance in favor of fair use.”