Custom fields in “Project for the Web”
Custom fields in newly released “Project for the Web” at both project level and task level.
Thanks for all of your feedback and votes on this. We are planning to build custom fields so you can work with even more flexibility in your projects!
Feel free to continue to give feedback on how you would use custom fields, and what information you’d put in them.
I know Project for the web is supposed to be basic, but can you implement the possibility to add $ costs and consumption calculations (not just resourse usage?) per line item as a new field? It would be a great help to be able to calculate burndown consumption at a given date during the plan.
Is there any idea of an ETA on this?
Brandon Casas commented
This is definitely a necessary option if our team is to consider Project for the Web. Thanks for planning it. Hope to see this feature soon.
Chak Tukkadi commented
Thanks for considering our feedback. I hope you are planning to build Project level and Task level custom fields. Project custom fields are helpful to manage project metadata like "Project cost center, Project budget, Department name" etc. One of the usage of task custom fields I think as below:
As we know, there is no baseline feature, so PMs can define additional custom fields to track the variance of task against standard fields like start date and finish date etc.
Process will be, prior to project execution, PM enters same date in both fields task start date and also on custom date field (Example: "Base Start"). This the where PM and client agree for project timeline. As project progress, PM will make update to default field start date as needed without changing Base Start. This way, we can see the variance of task. Similar process will apply to other fields. This way we can replicate baseline functionality in Project for Web.
Agree with those saying, it needs to be flexible, but to give you an idea, we need to include the functional group that is doing the work. Something may be assigned to a person, but we need to be able to indicate whether that person is on Operations, Creative, etc.
We use custom fields extensively, both internally and for clients. I have yet to see a client who did not require a custom field in Project Online, and we consistently see them at the Project, Task and Resource Level. Gotta have custom fields!
Definitely on Projects to indicate project status according to desired frameworks (prince2 stages etc).
Every organization is different and has slightly different needs and naming conventions. Custom fields allow great flexibility and also allow for helping with change management by keeping familiar names. We use them 100% of the time!
Custom fields help us with all sorts of different projects/tasks/resources. Not all of our users should be expected to go into the PowerApp/CDS to make all these sorts of changes. Defeats the purpose of having an easy to use project tool.
Duncan Griffin commented
I think that the solution could too add custom fields in a PowerApp against a "Project" entity in CDS. Once we are not limited to only having one "Project" entity in the default Power App environment we could add fields against Project, Task (and resource if available), then have "Project for the web", include the custom columns within the Project Home when creating/updating projects
I would like to add custom fields to calculate the predicted% of progress of tasks and projects. In order to have more reporting options with BI.
Rolly Perreaux commented
Without sounding too condescending, the same reasons why we currently use Custom Fields in Project Online (PWA). In either of these tools, we create and use custom fields to track anything that is not accounted for in using the standard Project/Task fields.
Tony Hitchcock commented
Custom fields would be great at Project level. This would allow an area to capture and report on more specific Project information (budget, project type, cost, Status).
Make the whole grid as flexible as Excel. One of the the reasons Excel is so amazingly popular is that its flexibility allows users to make use of it in ways/scenarios far beyond what Microsoft themselves could ever envision.
Microsoft should have a subset of fields are are required and locked down for scheduling (Start, Finish, Duration, Effort, etc) users then should be able to define and add whatever else they want. If we don't want scheduling we should be able to turn it off.
If you add this flexibility your clients creativity will see Project for the web become the standard across organizations just like Excel has and no one will be able to compete.
If you insist on locking it down and telling us what to do and how to do it (when the effort changes so does the duration) it feels like you aren't listening.
James Ward commented
I'll add that the roadmap needs more narrative - I'm looking to move our Excel-based NPI roadmap to this platform and it's not useful without a description of the project and ideally an image too to allow us to review with stakeholders
Andrew Sun commented
Custom fields to help group portions of work.
For example: A major customer project has 3 major deliverable products. Each of these will contain their own sets of tasks. The grouping will allow the project manager to group project by the deliverables, and in the end easily report on them individually or together as whole.
Another custom field usage is marking critical path/tasks.
Chris Kegler commented
It seems to me custom fields can be added in the CDS entity that is being used by Pftw. I, for myself, added various fields on Project level.
Chak Tukkadi commented
I agree, task level custom fields must to have for user adoption. I demo P4W in our organization and users are so excited to use this tool for small projects, but when they came to know there is no capability of adding custom fields at task level, now we are on hold. Please add this feature.
Tamara Frey commented
For most PM scenarios custom fields are necessary to ensure a proper Reporting / Classification / Grouping.
Though I understand that P4W should not become a copy of Project Online, at least the possibility to add project and task level custom fields to capture additional information not part of the standard setup for more sophisticated scenarios would be required to make customers use P4W
Antti Pajunen commented
Custom fields should go on projects and tasks at a minimum. Some data that is frequently in requirements: related entities (for example project risk custom entity), financials, customer field, milestone yes/no, EAC, ETC etc.