Streamlining Documentation

[LauraRa1]

Hi We currently have several document templates that are mandatory to fill out - Idea Request, Feasibility Doc and Business Case. We are thinking about streamlining this a little better by entering the data into workfront rather than in a word doc. Are any of you already doing this and if so how? Our idea request is entered in Workfront via a request queue and custom form but feasibility and business case are usually stand alone docs that we upload into the docs are of the relevant project. I think it should be possible to build on the idea request to create the feasibility and again for the business case. Thanks!

[Mohini__Mini_Si]

Hi Laura, We'd be interested in solution ideas for this issue as well. We have our project intake set up in a very similar fashion where project requests come in through a queue and related documents (Creative Briefs, scoping documents, business case, project charters, etc.) are stored as documents. A major pain point that we have (particularly for our Marketing Creative Team), is where to put final decisions on changes to the project scope, whether it should live in the custom form, an updates area, or in a document.

[SkyeHa]

Mini, I usually suggest to my users that custom form fields are for items that need to be quickly referred to by everyone or reported on (tracked as a metric) in some way. To us, documents are then the opposite of custom fields. They are useful as a container for historical data that doesn't have to be quickly referred to by the majority, or reported on/tracked as a metric. They also operate as a way to display chunkier content (think essays, or large spreadsheets). Updates for us, are only useful for quick "in the moment" news and as a historical timeline of all "in the moment" types of news (if you look at the updates area of a project you will see that it contains updates from all tasks, which makes it really unwieldy to wade through). Again, updates are not for chunky content -- there's definitely a limit on how much text you can expect people to read since you can't really format an update yet. If your final decision is of the type "yes/no" and you want to report on it, then put it as a custom form. If the decision only had to be referred to at one moment in time, it could live in an update on the project and get quickly lost at the bottom of the heap. If it's a lengthy essay, you might find it's best if it exists as a document--especially if it only has to be reviewed by the PM one time and never again.

[SkyeHa]

Laura, I usually ask the end user how many fields they would be willing to commit to filling in before they hit the submit button. In your scenario, I would be asking if it would be more comfortable for the user to create the idea request first, and then work on putting in the feasibility and business case after that request container is created. This gives them a little breathing space especially if they are the type who walks away from their desk every 5 minutes and then comes back and accidentally closes their browser before submitting the request. I'd create the feasibility and business case templates as separate custom forms, that the user could attach to the request at the point they are willing to fill in the info on those two pieces. Once R1 rolls out in April / May you can edit or add custom forms even while an object is pending approval. In this way, I would make an approval on the "New" status of a request and set it to the primary contact, who would add the two additional custom forms, and then "approve" to send off the request to the assigned worker.

[Mohini__Mini_Si]

Thanks for the guidance Skye. That's really helpful!!

[LauraRa1]

That's a great point you raise regarding the request - it has to be complete and submitted before they move on. Our current idea request form is quite detailed and I think we'll keep it that way but we'd like to pull the info from the request into the feasibility, whilst maintaining the original request as is. Not completely sure how we accomplish that yet.

[SkyeHa]

I'm sure you'll find something that works for you, Laura. We satisfied a similar need by replacing or adding custom forms after the request is submitted. The requestor sees only the custom form with the fields they need to fill in, and the people working on the request replace it with (or add) a custom form with those additional feasibility-related fields.