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
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
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
Thanks
Morgan
Can you confirm that we understand the structure of the project information?
A project has:
A project also has, pulled from defined lists:
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
My responses are highlighted in yellow below.
A project has:
A project also has, pulled from defined lists:
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.
regarding:
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
Here's our thinking on Projects.
Thanks,
Morgan
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.
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
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:
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.
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
I'll modify the wires and upload them here.
Assumptions/questions
Project
Document
I believe this is the correct flow for linking a project and editing a document.
User selects a project:
User sees project information and document form.
User can collapse/expand project details.
User edits document details.
My answers are highlighted in yellow:
Assumptions/questions
Project
Document
The flow above looks good!
Thanks,
Morgan
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.
To allow users to add multiple project urls and to add project meta fields
User can keep or edit pre-filled Public and Private parties
User can add multiple document urls
Yes, entities would be any organization with possible types.
Yes, an entity can be multiple types.
The wireframes above look great.
Thanks,
Morgan