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.”

4 Programming Languages You Should Learn Right Now (eClinical Speaking)

I am a strong believer that learning a new language makes you better at the others, but I am not a “learn to code” advocate since a foreign language (I know 3 languages and currently learning my 4th and I have a “to learn” language including Italian and Arabic, if I ever find some free time) or even music (I love to play drums) are equally beneficial. But if you want to obtain a job in the pharmaceutical industry, here are the list of programming languages you should learn:

  1. C#:

What it is: A general-purpose, compiled, object-oriented programming language developed by Microsoft as part of its .NET initiative.

Why you should learn it: If you are looking to become a Medidata Custom Function programmer or Oracle InForm EDC Developer then you should.

2. Python:

What it is: An interpreted, dynamically object-oriented, open-source programming language that utilizes automatic memory management.

Why you should learn it: If you are like me always looking to learn new technology, love Google platforms and perhaps want to become a Timaeus Trial Builder, you should learn it. It is used on a lot open-source technologies.

Everyone should learn to code

3. PL/SQL or SQL:

What it is: PL/SQL stands for Procedural Language/SQL.

Why you should learn it: If you are like me additive to databases then Oracle should be your choice. If you want to become an Oracle Clinical programmer or Database administrator, you should learn Oracle PL/SQL.

4- SAS

What it is: SAS stands for “Statistical Analysis System” (software). It is the most powerful and comprehensive statistics software available.

Why you should learn it: SAS skills are in high demand nowadays. If you are able to obtain the SAS Certification and a few years of experience in the Pharmaceutical industry, you will be in good shape. If you are new and looking for training there are several options available from SAS Institute to private vendors such as Clinovo to even learning on your own. I most warn you as it will be difficult to obtain a job without experience. Nevertheless, once you are in, it can only get better.

Remember that your job is not just to code but to solve real problems. Your ability to code covers a lot of range of skills: from critical thinking, problem analysis & solving, logic, etc.

So which one are you going to give a try?

Let me know what is your preference. Happy Programming!

The best thing about a boolean is even if you are wrong, you are only off by a bit.(Anonymous)

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.

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

SAS Institute
Learn PL/SQL

How to Manage Sites and Users in InForm Trial?

So you created your first InForm Trial and now what? Before you can actually enter data into your trial, you need to set up a user management system which assigns permissions to different users in your system depending on their job “role”.

In InForm, this is accomplished by using a tool called ‘User Management Tool’ or simple UMT. This tool allows sponsor to manage sites and users once the trial have gone live. There may be many different user groups with different levels and ranges of permissions.

Creating an InForm Trial – UMT:

  1. Create your InForm trial in the UMT. I won’t go into details on how to actually do this and depend upon the contract agreement with the vendor (i.e. Oracle/PhaseForward); they will perform this task for you.
  2. Select Trial Version = latest InForm version (i.e. 5.0)
  3. Select Countries where this trial will take place
  4. Select Status. Each InForm trial has 4 main statuses.
    1. Fast Start = Pre-Go Live
    2. Fast Forward = Trial is now live
    3. Fast Lock = Trial is lock
    4. Decommission = Trial is completed/archived

Managing users and groups can be a tedious task but tools such as UMT makes them easier to manage.

Roles: Roles (e.g. CRA, PI, System Administrator, etc) are used to assign specific permissions to individual users or groups, typically to perform specific functions in the InForm system.

The system allows you to either manually enter a role or import using a template called ‘MUL’ or Masters Users List. If you decided to upload your rights and roles via MUL, the system will generate a log file. It is imperative that you check this file and check any errors before proceeding.

Once the roles have been added to the UMT, you need to approved them before you build your clinical trial. The system also comes with defaulted and approved rights and roles.

Another option available is to create what is called as ‘signature groups’. If you are familiar with Medidata Rave system, this is equivalent to checking the ‘Signature required’ box and setting the investigator signature in Architect project main page.

Common use of Signatures in clinical trials are at the form level (i.e. 1 signature per form or at the subject level or studybook = 1 signature per subject).

Item Groups: Items groups is used to overrides or restrict a particular user access to a form or field. This is equivalent to ‘Restrictions – View/Entry’ in Medidata Rave.

One good example of display override usage is the coding fields restrictions. If only Clinical Coders are allowed to view / entry data on those items, you will limit access to all roles but the coders role.

Here’s a snippet of the code in .XML:

<!–?xml version=”1.0″?>–>
<MEDMLDATA xmlns=”PhaseForward-MedML-Inform4″>
/*some other code goes here*/
GROUPNAME=”Hidden Coding Items”
GROUPDESCRIPTION=”Hidden Coding Items”>
<!– Insert ItemRef Names –>

Two other important groups that you need to be aware of is the Query and the Report Groups. The former, as the name entails, allows a user to open, answer, reissue and close queries during the course of a clinical trial. The latter, allows a particular user to run reports.

For example, an Ad Hoc User can access Ad Hoc reports via Cognos. The roles associated to this group could be your project manager, Clinical Research Associate (CRA) or your Lead Data Manager (LDM/CDM).

Once you have completed your basic setup, you will need to prepare or cook those xmls files onto your clinical trial. The rights/roles we discussed needs to be in an approved status. You also want to make sure you ‘lock for QC’ or lock the trial to prevent anyone from making changes to already added sites/users.

Sites and Users marked for upload to InForm will automatically be cooked into your trial.

Last step we need to take is to generate the XML files by selecting the link ‘Generate InFormXML.’ Now, your UAT trial is created, your URL is set up and you are ready to perform User Acceptance Testing.

Remember to validate your XML files, especially if your clinical trial is running across several countries. I have found issues with foreign languages symbols or special characters entered in the UMT system. Avoid at all cost any special characters.

Source: User Management Tool Reference Guide from PhaseFoward

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.

Central Designer – Troubleshooting Tips

If an edit check or function fails to behave as expected, it is time to use your ‘troubleshooting’ skills. The following tips may help you when you are troubleshooting rules in InForm:


  • check if rules are running
  • check the rule logic
  • check Rule Dependencies: a rule on a form has access to items on that form, but not other forms or other visits
  • check InForm machine’s Application Event Log

Though some vendors will correct major problems with their products by releasing entirely new versions, other vendors may fix minor bugs by issuing patches, small software updates that address problems detected by users or developers.

Check the release notes for Central Designer for known problems. The release notes provide descriptions and workaround solutions for known problems.
Remember that there is a report available you can run “Data Entry Rule Actions Report”. This report outputs all data entry rules in CSV format and can be formatted into an edit check specification documentation for QA testing.
A rule can be written in more than one way, which makes it difficult to impose any restrictions:
Scenario: Route item has 3 choices. OP, SC and IV. Query should fire if the user does not choose either OP or SC. This rule could be written in many ways:

–Value = route.Value

If (value == 3)

–Value = route.Value == 3

If (value == true)

–Value = !(route.Value == 3)

If (value == false)

–Value = (route.Value == 1 || route.Value == 2)

If (value == false)

–Value = route.Value !=1 && route.Value != 2

If (value == true)

Keep it consistent across the trial. Do not overuse the conditional statements when a simple range check should be program.

Note: Be aware that if you want to reuse a rule that uses data from a logical schema in another study, the other study must also contain the logical schema.

If you have explored most of the obvious possibilities and still
cannot get your rule / edit check to work, ask someone in your team to peer review the build.


  • unit test your code
  • context available for defining test cases
  • Site name, date/time, locale; Form associations; Empty values; Unknown dates; Repeating objects
  • test case results: Pass or Fail based on expected results
  • perform formal QA / QT

Remember to check the Event log via Control Panel -> Administrative Tools -> Event Viewer

Reference Document : Central Designer – Rule Troubleshooting.pdf

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.