TOLOGIX - Infrastructure LawGuide (ILG)

Fields on Projects or Documents

Hi Morgan,

I'm following up on a question that has come up in Target Process from Anil.

He's raised the question whether the fields Public Partner, Private Partner, Debt/Equity Lender, Contractor/Subcontractor are associated with documents or projects.

My original understanding was that they were associated with documents. However, when I took a closer look at the P3 Prototype Master List spreadsheet, it looks like those 4 fields are associated with each project.

What is your thinking here? It could be done either way.

Scenario A Project
User sets up information against projects. This would require screens for managing projects.

Scenario B Documents
This is what was prototyped. The user sets up the information against each document. There is some duplication of data entry for documents that are on the same project, but I'm not sure if that's a dealbreaker at this point.

Thanks
Megan

Comments & Events

Morgan Maguire, CEO
Hi Megan,

Sorry for the delay in replying to the thread on TargetProcess. I missed it somehow.

The information Anil has highlighted is affiliated with the project, rather than the document. For the purposes of making the data entry process more efficient, it makes more sense to have the data entered in at the project level, and then this gets automatically associated with the documents within that project. Therefore we should make the appropriate changes to accommodate Scenario A. I know this adds additional complexity to the admin process. However, we went with the Scenario B in ISLG, and this ended up causing big headaches for data entry that we’ll have to deal within on the rebuild.

Thanks,

Morgan
Megan Goodacre, Industrial
Hi Morgan, Thanks for clearing that up. We'll make sure the requirement is fleshed out in wireframe, and will post an update here for you.


Thanks
Morgan Maguire, CEO
Great. Thank you Megan.

Morgan
Anil Vaghela
Thanks Morgan for the clarification.
Megan Goodacre, Industrial
Hi,

Can you confirm that we understand the structure of the project information?

A project has:
  • Project name
  • Project UIN (is this ID generated offline? or should the app generate it?)
  • Date of concession (date field)
  • Website (url)

A project also has, pulled from defined lists:
  • Jurisdiction (single value)
  • Public Partner(s) (single or multiple values)
  • Private Partner(s) (single or multiple values)
  • Debt/Equity Lender(s) (single or multiple values)
  • Contractor/Subcontractor(s) (single or multiple values)
(I assume these need to be defined so the admin user doesn't type them in on the fly)

Defined lists needed in the app:
  • Jurisdictions (text, with the syntax Country - State or Province)
  • Public Partners (partner name)
  • Private Partners (partner name, owner name)
  • Contractors/Subcontractors (text)
  • Debt/Equity Lenders (text)

A document can then be related to a project, which means the user can see the project information related to a document. And it means that an admin can associate a project to documents without having to enter jurisdiction, public partner, etc, every time.

Are the partners on a document a subset of the Project partners?
For example, the project BC/0001 has 5 public partners.
But the documents for BC/0001 appear to only have 1 public partner. 

For example, as an admin, when I make document Amended and Restated RAV Concession Agreement, I would link Project BC/0001. I could then choose 1-5 public partners from 5 public partners.

Thanks
Megan
Morgan Maguire, CEO
Hi Megan,

My responses are highlighted in yellow below.

A project has:
  • Project name
  • Project UIN (is this ID generated offline? or should the app generate it?) - If we're able to create an online reporting system that replaces the offline master lists, I would be fine having the app generate the UIN with the ability for admin users (with appropriate permissions) to alter as they see fit. However, perhaps we should save this for post-prototype.
  • Date of concession (date field) - Date field with further field title customization available to certain admin users.  
  • Website (url)


A project also has, pulled from defined lists:
  • Jurisdiction (single value or multiple values) - it's conceivable that project has multiple jurisdictions. 
  • Public Partner(s) (single or multiple values)
  • Private Partner(s) (single or multiple values)
  • Debt/Equity Lender(s) (single or multiple values)
  • Contractor/Subcontractor(s) (single or multiple values)
(I assume these need to be defined so the admin user doesn't type them in on the fly) - Yes, the fields themselves will be defined.

Defined lists needed in the app:
  • Jurisdictions (text, with the syntax Country - State or Province)
  • Public Partners (partner name)
  • Private Partners (partner name, owner name)
  • Contractors/Subcontractors (text)
  • Debt/Equity Lenders (text)
Looks good. However, I'm uncertain why names are in brackets for partners and text for the rest. They will all be names.

A document can then be related to a project, which means the user can see the project information related to a document. And it means that an admin can associate a project to documents without having to enter jurisdiction, public partner, etc, every time. - Correct. When a document is associated with project, it will automatically assume all the characteristics of that project, and will be associated with all other documents within that project.

Are the partners on a document a subset of the Project partners?
For example, the project BC/0001 has 5 public partners.
But the documents for BC/0001 appear to only have 1 public partner.

For example, as an admin, when I make document Amended and Restated RAV Concession Agreement, I would link Project BC/0001. I could then choose 1-5 public partners from 5 public partners. - Yes, and no. An admin user should be able to select project partners to be associated as parties to a particular document; however, they should also have the ability to add additional parties that may not be associated with the project. 
Megan Goodacre, Industrial
Hi Morgan, 

regarding:
  • Date of concession (date field) - Date field with further field title customization available to certain admin users.  
Does this mean that an admin will enter a date, and they need to be able to specify what type of date it is? Is it usually Date of Concession Agreement?
Morgan Maguire, CEO
Hi Megan,

No, I was referring to the ability to alter the title of the field from "date field" to something else. However, now that I think about this more, let's keep it simple and call the field "Date of Concession Agreement".

Thanks,

Morgan
Megan Goodacre, Industrial
Hi Morgan, 

Here's our thinking on Projects. 


  • User can Add or Edit projects.
  • User sees the following fields for a project. Can you confirm which ones are required?
  • For Jurisdiction, Public partner, Private partner, Lender, Sub/Contractor, user can select multiple values from a defined list. 
  • As the user selects from the list, values they select no longer show on the list. (see Public partners below)
  • User can begin typing to filter the list.
  • After the user leaves the field, they can see the values they selected (see Jurisdiction below)
  • User can add values to defined lists on the fly by typing them in and then clicking Create. (Not sure yet how this will work for Contractors, which also have owners, we may need a modal for that)
Morgan Maguire, CEO
Looks good to me, Megan. Confirmed on the required fields you have listed. I like the way the defined lists works, and that the user can create new entries on the fly. However, how would a user modify a defined list item? For example, if there was a typo made or some other error. Will this be accessible somewhere else?

Thanks,

Morgan
Megan Goodacre, Industrial
Hi Morgan, Yes, we'll have to make these defined lists available in the admin for things like typos.

Adding on the fly does create a risk that a user makes two things that are similar with different spelling (eg, Province of British Columbia and Province of BC). If those partners were to be assigned to Projects, then it would require clean up of both the partner list and the projects. However, I'm assuming that the users who can define lists on the fly will be intermediate admins. 

I have some more wireframes for your feedback, will post in a moment. These will be for the project information on a document. 
Morgan Maguire, CEO
Hi Megan,

Understood. We've had a similar problem with some of our defined lists within ISLG, and cleaning them up here and there shouldn't be a big deal. However, we should build in protocols that allow an admin user to identify where a defined name has been used to make that process easier, particularly if a defined name needs to be deleted.

We have a feature in ISLG that does this. For example, if you attempt to delete a document, before it allows you to do so, it provides you with a notice of all the items referring to it. This forces the admin user to reassign those references before the document can be deleted. Something similar should probably be done in this instance.

Example: https://www.investorstatelawguide.com/CoreComponents/DeleteDocument?toc=deleteConfirm&docId=59

Megan Goodacre, Industrial
Okay, we will make sure to solve the problem of identifying related projects/documents on defined value lists to make clean up easier for admins.

Regarding the project info that is added to a document in the Edit document state. 

Previous versions of this functionality had the user typing in jurisdiction, partner, etc, each time. 

In this version:
  • User can select a project from a list of projects. I assume there would not be a use case for adding projects on the fly?
  • After the user selects a project, related project elements appear, already filled in. 
  • The Document UIN input appears, with an assistive placeholder showing the Project UIN and Document UIN syntax (eg, BC/0001/####). This could, in future, be auto generated, but for the prototype can be entered manually. 
  • If I understood your comment right, the user can modify the Public and Private partners associated with a document.
  • In that case Public and Private partners for a document would be prefilled with the project partners, but would be editable by the user. 


To save real estate, I suggest we put the document and project detail inside a collapsible accordion, with the accordion open by default. Don't know if I'm over-thinking this, and it's not clear to me how much of the meta data on a document is important to the document editor once they have entered it.

Morgan Maguire, CEO
Hi Megan,

Correct, no need to add projects on the fly from the document editing window.

On the project elements, I think we should segregate project details from documents details. Project details should be visible, but cannot be edited from the document editing window (perhaps there can be a link to a separate window to edit the project details). The only elements that can edited are the document details, which include the "Parties" to the document, not the "Partner(s)" to the project. Parties and Partners can come from the same defined list, but they will be separate meta fields for document/project purposes. The reason for this is that we want to be able to identify all the parties relevant to a document, which may not be the same as the partners to project. Make sense?

Thanks,

Morgan
Megan Goodacre, Industrial
Ah okay, thanks for the clarification. I was conflating Partners and Parties.

I'll modify the wires and upload them here. 

Assumptions/questions
  • The document uses the Project UIN in the Document UIN, but other than that, the project information on a document is informational only.
  • Document Parties can overlap with Project Partners, but not exclusively.
  • For the Document private and public parties, do you want those to be pre-filled from the Project private and public partners?
  • For Document Parties, does the admin need to be able to add notes to the Party Name?
    • For example, I see Province of Ontario as a Public Partner on a Project.
    • But I see "Province of Ontario (as represented by Ministry of Infrastructure, as represented by Ontario Infrastructure and Lands Corporation)" as a Public Party on a Document.
  • Do projects need customizable meta fields the way Documents do?

The fields for Projects/Documents:

Project
  • Project UIN
  • Project Name
  • Jurisdiction(s) (from defined list)
  • Public Partner(s) (from defined list of Public Sector organizations)
  • Private Partner(s) (from defined list of Private Sector organizations)
  • Debt/Equity Lender(s) (from defined list)
  • Contractor/Subcontractor(s) (from defined list)
    • which can have Owner(s) of Private Partner(s)
  • Date of Concession Agreement
  • Project url(s) (Would this ever be multiple)

Document
  • Document UIN
  • Document Name
  • Date of Agreement
  • Public Party(ies) (from defined list of Public Sector organizations)
  • Private Party(ies) (from defined list of Private Sector organizations)
  • Document url(s) (Would this ever be multiple)
+ Other meta fields that can be defined by admin
Morgan Maguire, CEO
Hi Megan,

My answers are highlighted in yellow:


Assumptions/questions
  • The document uses the Project UIN in the Document UIN, but other than that, the project information on a document is informational only. - Correct
  • Document Parties can overlap with Project Partners, but not exclusively. - Incorrect. Parties and Partners come from the same defined list of names. They may overlap and they may be used exclusively.
  • For the Document private and public parties, do you want those to be pre-filled from the Project private and public partners? - Yes, and use can only modify them through to project edit page.
  • For Document Parties, does the admin need to be able to add notes to the Party Name? - No notes are necessary. We can resolve this by adding additional parties. For example below, we could add the following parties: Province of Ontario, Ontario Ministry of Infrastructure and Ontario Infrastructure and Lands Corporation.
    • For example, I see Province of Ontario as a Public Partner on a Project.
    • But I see "Province of Ontario (as represented by Ministry of Infrastructure, as represented by Ontario Infrastructure and Lands Corporation)" as a Public Party on a Document.
  • Do projects need customizable meta fields the way Documents do? - Yes, we need these to deal with nuances that will inevitably arise with certain projects.
The fields for Projects/Documents:

Project
  • Project UIN
  • Project Name
  • Jurisdiction(s) (from defined list)
  • Public Partner(s) (from defined list of Public Sector organizations)
  • Private Partner(s) (from defined list of Private Sector organizations)
    • Owner(s) of Private Partner(s) (meta field for Private Partner(s) from defined list)
  • Debt/Equity Lender(s) (from defined list)
  • Contractor/Subcontractor(s) (from defined list)
  • Date of Concession Agreement
  • Project url(s) (Would this ever be multiple) - Maybe. Please provide that capability.


Document
  • Document UIN
  • Document Name
  • Date of Document
  • Party(ies) (from defined list of Public Sector organizations)
  • Private Party(ies) (from defined list of Private Sector organizations)
  • Document url(s) (Would this ever be multiple) - - Maybe. Please provide that capability.
I'm not sure if this is already integrated into the above, but I think it would make it easier if all the entity names came from the same defined list, and that meta data fields were available within the defined list to assign characteristics to the type of entities (e.g., public vs. private organization). It will be easier to keep track of the data, and then we can easily pull the data we need based on the meta data assigned to an entity. Make sense?

The flow above looks good!

Thanks,

Morgan

Megan Goodacre, Industrial
Hi Morgan, thanks for the notes.

For this:
 it would make it easier if all the entity names came from the same defined list, and that meta data fields were available within the defined list to assign characteristics to the type of entities (e.g., public vs. private organization). It will be easier to keep track of the data, and then we can easily pull the data we need based on the meta data assigned to an entity. 

Are entities any organization (ie, lender, partner/party, contractor) with possible types
Public
Private
Lender
Contractor

Or do you consider entities to be only the partner/party type organizations with possible types
Public
Private

I'm assuming the former.

And could an entity ever be more than one type? I assume they couldn't be private and public, but could they be, for example, Private and a Contractor, or Public and a Lender.
Morgan Maguire, CEO
Hi Megan,

Yes, entities would be any organization with possible types.

Yes, an entity can be multiple types.

The wireframes above look great.

Thanks,

Morgan