Understanding Objects in Workfront

Transcript

All right, I appreciate the introduction, appreciate being here and I’m happy to share this information with you guys. Again, we want to help you understand what objects are within Workfront. It’s important so that you understand how to work within Workfront. So let’s start by understanding the Workfront basic structure. All right, so the basic Workfront structure, the basis of work, how work is structured, that basis is projects and projects are the overall deliverable that we need to complete, right? That is the overall goal. Projects in Workfront actually house the work that gets done. Those tasks and issues or requests must exist within a project. This is extremely important that we understand this. You won’t be able to create a task or an issue in the system if it doesn’t exist within a project. Remember, projects are the overall deliverable, tasks are the planned work that we need to complete and when you see the issues and requests, those are like, you know, little issues that might pop up or a little roadblock that popped up, essentially unplanned work that popped up that must be completed for the overall deliverable to come to a close. Now as I’m going through this, I’m talking about projects, tasks, issues, portfolios, with the understanding that your organization might refer to these differently. There is different terminology. However, you might be referring to these as a campaign or a job or a task, a request, things like that. So just factor that in. This structure is still important. Portfolios, programs, projects, task, issues. That is how we refer to them in Workfront. Factor what you see on the screen, maybe consider what you are calling them so that you have an understanding of what we’re going through. All right, so the reason we focus on that structure is because Workfront is an object-oriented database. Essentially what it means is these objects have autonomous, they have their own identity, their own names, their own fields, their own dates, their own owners, things like that. But all of these objects can have that relation to each other, right? Projects house tasks. There’s a relationship there. Each task will have a parent project. Each task will have an owner. That’s an user object. So again, factor that in. Even though it’s an object-oriented database, they can have and relate to each other. And you have an understanding that each of these will have their own items, their own reports, their own custom forms, their own fields of information. However, again, those relations can work and you can use those relations to report better on the work we do. Again, what you’re seeing on the screen is an example, right? The project table that you’re seeing on the screen essentially has all these little smaller items or fields or collection of fields, all these information that yes, can exist at the task level, but for the task object. So factor those in. This is an example of how they can exist separately and individually with all their identity, but essentially still be related to each other. So again, those relations allow us to gather more information and have a better understanding of how all of this work relates to each other. What you’re seeing on the screen are examples of how a portfolio will have its own notes, its own updates. It’ll have its own custom forms, its own issues, projects, tasks can have issues. They can have issues existing within them. A task will have an owner. A project will have an owner. A portfolio will have an owner. Anyone who manages all of those projects, yet they are in the end separate objects. Now, even though they are separate objects, work flows through them. Like you’re seeing on the screen right now, a custom form or an intake form will collect all the data that we need to start work. Essentially after we collect all that data on a custom form, that custom form could exist at the issue level. At the issue level, we collected that information, but it allowed us to create a project which exists now under a program and a portfolio. And all of these are gathering data on the work that we are doing. How much money is being spent, how much, how many hours are being logged, how much work is being done. And in the end, all of them will flow all that information into reports. Now again, these custom forms can exist and will exist individually at each of those objects. So that custom form will exist for the portfolio object. It can exist for the project object or for the document. Well in the end, reports do the same thing. The report can be four portfolios or four projects or four tasks. So again, each of them will have their own individual objects or custom forms or reports, but in the end, all the work flows through them and is linked and it communicates and it relates to each other. And in the end, we can report on all of that information and provide really good data on how work is progressing. Do we need more resources? Are we hitting our timelines and things like that? Now an object can have a relation to a lot of other objects. For example, the same you’re seeing on the screen, the project itself can have that relation to the company. We know that this project is being worked on for company XYZ. It is owned by the marketing department or the marketing group. It exists within the digital marketing portfolio. And in the end, under the, you know, maybe digital program that is under that marketing portfolio. So in essence, one project, one object can have a relationship to all of these areas. Yet in the end, the object itself is what does the work. The object itself is what carries all that data and transfers it over to all of those items. Now as we understand the structure of all that work that we’ve done, that we’ve put in place, how a project, right? The overall deliverable has all these tasks that we’ve planned and has, you know, every once in a while, an unplanned item that pops up in order to complete it. We need to understand how the structure of users and the company works in order to get the work completed and again, report on it. So we’re going to talk about companies, groups, teams, and those job roles. So company essentially is the overall organizational unit that houses users, had houses, groups, essentially your organization. However, it can be also an organization that you do work for, or that works with you that exists within your instance. These are essentially used to not just organize users and organize org charts, but you can relate work that is being done for them, right? So essentially we can have a group of projects that is done for company XYZ, and we have another group of projects that is done for company ABC. Essentially we can then later report. We did all this work for this company. We gained all this revenue from this company, or if it’s all the work for our own organization, we’re able to determine, you know, how much did all this cost us? Because again, it is directly linked to the organization. After that, the next organizational unit that’s important to understand are groups. Groups is in essence, mirror your organization’s departmental structure. So essentially marketing is a department, and then you have customer success as another department. Finance is another department. So essentially they become a group within Workfront. Groups have the ability to have subgroups underneath them. So essentially you can have the entire departmental structure exist within Workfront. And that way allow us to understand, yes, this is a project that overall was done for marketing, but it was done under the digital marketing department. Overall this was done for customer success, but in the end, this was very specific to training, right? So this allows us to understand where are the hours going? Who’s logging the hours? Who’s doing the work? Who’s costing this, right? So we’re able to understand by group how things are done. Groups allow us to organize work, how that group does it, or that department. It’s obviously we’re not going to have a marketing department doing work exactly like a product department does, or doing work like a legal department does. Each of them can have their own work structure and their own work processes. Being able to create these groups within Workfront and then giving a group administrator the ability to manage the way the department’s groups or their work structure and processes are done allows for that autonomy to exist. It allows us to then later report on the work being done by each department and understanding who’s making money, who’s losing money, who needs resources, who’s doing things successfully, who has the proper processes in place. And then other departments can then mirror if it’s super successful in customer success, why not have legal do follow some of the same processes? Again, creating these groups and subgroups and then allowing a group administrator to exist will allow us to understand how those objects that they’re working on are being done correctly through a department or incorrectly or what can be fixed. So this is very, very important to structure the organization the exact way that it exists. You know, mirror it in the system through groups. Again, every 100 users, you want to have a group administrator. Your system admins cannot do all the work. They need these group administrators because the group administrator is a direct link to your department or that department, which allows them to have a real understanding of how processes and work should be structured for them. So very, very important aspect to understand and be able to create and organize in your organization. So this is an example, right? You have a marketing department or a digital marketing department, and essentially these or our crew, sorry, it’s divided into groups, right? So the, you know, video department or video group, social department, social group, and you can see that it’s divided further, right? Because within that department, it has other departments. And so essentially what you’re doing is creating groups and subgroups. You’re creating a structure so that we have an understanding. Note that if we put somebody in the ad group or ad department, they are automatically going to gain access or be a member of the groups above it. So if somebody is in the ad group automatically, they’re also a member of the Facebook group, the social group, digital marketing group, and overall marketing groups. So it’s an understanding that you do gain, you know, access or membership to the groups above from that group alone. Now this structure can, you know, be pretty in depth. You can really dive into it and really, really structure it. However, you are limited to 14 levels deep. You can go as wide as is needed. However you are limited to 14 levels deep. All right. The next organizational unit that we want to talk about are teams. Now teams are super, super important. Teams mirror your daily work group, essentially your group of users that normally work together to accomplish something. That is what teams refer to. Groups can have projects associated with them. Teams can actually have tasks assigned to them. So teams actually do work. So even though we might have say a video group, a department, right, which has maybe six, seven individuals who work together to edit and, and, you know, record videos and things like that. Essentially they are not the overall department. They might work with people with other departments who develop content. So essentially the team that creates the video isn’t necessarily comprised of all members from the video department. So a video team can have members from other departments that worked with them together to accomplish and deliver a video for you in the end. So essentially teams are important, not just because they can actually do work and get work assigned, but they actually will allow you to organize that group of users that will work effectively to complete work. So on a project on some point, they can make that assignment to the team, having the knowledge and confidence that that team has the members necessary to deliver on that request or on that assignment. So teams are very, very important. Just remember, you can assign work to teams. This is the organizational unit that you can use to assign work to a group of users. You can assign layout templates. So everybody on the video team sees work the same way. You can simplify it for that team. Maybe they don’t need to see areas of the system that just aren’t necessary for them to do their work. And you can drive user adoption and get work and the processes of work in place correctly, manage them correctly, have, again, overall success if you, again, create a layout template to simplify things for them. So again, in the end, what you want to do is you want to create teams. You want to talk to your departments. Who normally works together to produce, say, artwork? Or who normally works together to, in the end, produce this specific part of the product? And that way you can create that team, organize them together, and then, again, use that team for assignments, for communication, and ensuring that they all see work front the same way. Very, very important. So again, this is another example. Essentially, you had like the group structure, right? And all of these were interdepartmental things. However, again, like my example, video team could have members from production and post production and could have maybe somebody from the Facebook post team because essentially they’re creating a video for a Facebook post. And all of them work together to provide that video. So in essence, you would have a team of people, either from this video department or cross departmental that works together to accomplish that. The last and important, I guess, organizational unit that gets overlooked are job roles. It is extremely important that your organization has a conversation and an understanding of what do we need to accomplish work on this work item, this task? Who needs to work on it? And we’re not talking about what individual needs to work on it. We’re talking about what skill set is needed to complete this work item. Once you have those conversations, then you’ll have an understanding on how’s going to do the work. Essentially, at some point, I’m going to need a photographer. I’m going to need a videographer. I’m going to need a graphic designer. I’m going to need a CSM, right? A customer success manager or, you know, content developer. At some point, that’s what I need to get this task accomplished. That is the skill set needed. So knowing that that’s the skill set needed allows your organization to, ahead of assignments or ahead of resourcing, being able to put those placeholders in place. You’re able to say, I need a photographer here. I need a graphic designer here, a content developer here. And then you’re able to create that as a template, right? That department knows this is what our project template should look like. All our projects should have a photographer assigned at this point and a videographer here, right? The works, whatever is needed. But essentially, once that’s in place, it’ll save time for all of your project managers. They go, they grab that template, they create the project, and then when it comes to resourcing, all they have to do is click on that photographer and then the system will look for anybody in the system that has that job role or photographer assigned to them. And if that resource is available, they can make that assignment very quickly. So again, job roles are not your, I guess your user’s job title, right? I’m a senior delivery specialist. That’s not my skill set. That is my job title. As a senior delivery specialist, I can deliver content. I can also help in the creation of content. So I’m essentially a content developer. I can also help in the recording of videos like this one right here. So essentially there are a lot of things that I can do. Those are my skill sets. That is the job roles. Those are the job roles that my system administrator or group administrator is going to want to create in the system and get assigned to me. So that later on, when my team is looking for, let’s say I need a content developer or I need help as a content developer and I don’t have anybody else. Oh, it looks like Roy can help me with that. That is part of his skill set and they can get me assigned to it. So job roles are extremely important because they’re not just placeholders. They inform the system what a user can actually do. So have those conversations. Get a hold of your department heads. Those that understand how work needs to happen. Sit them down and say, all right, we have Joe Schmoe. What can Joe Schmoe actually do? What does he do? Not his job title. What are the skill sets that he has that can be applied to work? Then get those created in the system and apply to all the users that match that skill set. That way, when it comes down to resourcing all the work you’ve planned out, the system can understand there’s all these users that can be assigned to this work item. And again, the user structure, those that can be assigned, whether it’s an individual user, their job roles or their team will factor into, again, those object identity. We’ll have an understanding that this task requires this skill set. These users have that skill set. We’re going to assign those users later on. That user is going to log hours on it. They’re going to log updates. They’re going to upload documents. And again, they all relate to each other. Overall they all work together to deliver the project. The overall deliverable can come to a close, complete. We can report on it and we can work together with those reports to better our processes, to perfect them. In the end, what we want to do is not just simplify work, not just give our users part of their life back, right? A work-life balance is to allow them to be productive and allow them to perfect those processes that allow them to be more productive with less time. So I appreciate your time. Remember the job structure is important. They all communicate with each other. We are here to help answer some of those questions. So if I left anything out or you’re unclear on something, go ahead and ask me. I’m here to help you. That was great, Roy. Thank you. And I love your backdrop by the way. Thanks. Took a while to build it, get it up there. I bet. Yeah. Well, thanks for being here to answer questions. We’ve had a lot of great questions come through. So let’s go ahead and dive in. Yeah, let’s go. So this first question comes from Christy. Do most Workfront customers create separate projects for each deliverable? Great question. I would say most of them do. Each deliverable gets its own project, its own tasks, its own work flow to it. So I would say most do. They do create project templates to make it easier to build those over and over. But yes, I would say most deliverables get their own project and timeline. And templates help to ease that process in. Okay, excellent. This is from Patty. When converting an issue into a project, why doesn’t the sponsor convert over rather than us having to manually add them? Also a great question. And I can understand what you’re referring to. Essentially, the person requesting that the job get done, that the project get done doesn’t automatically transfer over. And that’s because that person requesting it isn’t always the project sponsor. And so it might be, depending on the organization, some organizations have the project sponsor always be the department head, right? So even though someone else is requesting it, it’s being done by someone else, that person might not always be the person that is going to be the sponsor. And so it doesn’t automatically transfer. That’s why it requires that manual selection of who that sponsor is going to be. But great question. Yeah. Okay, great. This one is from Anzelica. Can custom form include mandatory attachment? Short answer, no. However, there is new functionality that came out just this past Friday that allows an organization to add images to a custom form. However, those images aren’t necessarily there to receive an asset or anything like that. So you can create any custom form, a specific field, right? A description or a field that literally says, we will need you to upload a document, right? But unfortunately, you cannot make that document upload a required section. So I would say that best practices or my recommendation here would be to actually create it in the custom form where you create part of the description, we will need you to submit the documentation necessary in order for your request to be processed. You can let them know that as part of that description field that if they don’t, it will slow down the process. Things like that. That communication is important as a requester sees it. They see the importance of it. You can even add little asterisks at the front of it and at the end of it so they know the importance of it. We find that when you place that on there, most requesters actually do get that uploaded. Great. Yeah. Communication is so important. Super important. This one from Todd. If a completed project has a minor edit, can you reopen the original project and add tasks to get it updated? That’s a really good question. That does depend on how your organization set up the system. There are global settings that can allow an organization to add tasks and issues after a project’s been completed. However, if your organization has actually turned those off, it will limit that process. If that is the case, it would, at that point, would require you to reopen the project in order to be able to add those tasks. However, reach out to your system administrator to see if those settings are set up globally. Maybe your governance committee has set it up for a reason. Maybe you have a case for turning that back on. That way they can understand that you need it. At that point, if that is turned on, at that point, once your project is closed, it goes to a complete status. Something can come up later. It will still allow you to create a new issue or a new task as needed and get that completed without needing to change the status of the project back into in progress or being worked on. That is, again, a global setting that will allow you to do so. Either way, you have an option, right? Option one, it’s already in there. Settings good. Add a task as needed. Or option two, if your organization has that turned off, just on an individual project basis, you can switch that back to an in progress status where you’re actually working on it, add that new task, get it worked on, and then mark it complete. You have some options there, but the one you are referring to is a global setting. Great question. Okay, fantastic. This one’s from Greta. Is there a way to clear documents from a Q project without removing them from the individual project or a way to prevent them from being added to the Q project? I see what you’re saying. Short answer, no. So I guess the intake process would require them to submit a document, right? Like that question that was asked earlier. You would need that document in order to actually process the request and turn it into a project and do the work needed. What you’re referring to is that I submitted my request with that documentation. It goes into a project, then it gets converted into a separate project. You’re referring the issue does remain on that other Q project with its documents. There isn’t a way to prevent that from happening. And again, you could see how that could limit and affect work being processed from the get go. And I guess there isn’t a way to get those removed easily without removing it from the issue. Again, at conversion, you can get that information transferred over to the project and manage it there. But I see where you’re coming from as far as it does remain on the request itself. Great. This one is from Sierra. My organization primarily uses Workfront as a ticketing system for web design requests. We are currently using issues for the requests. Should we use tasks instead? What would be the benefit? I wouldn’t necessarily recommend using tasks. The ticketing system works well, you know, receiving that issue. You can, however, if you’re not necessarily converting all those requests into projects, you can still convert that issue into a task, especially if you have a running project where you work those on. As far as the benefit, it’s really up to your organization how you want to track those. If you are wanting to track those as actual, essential planned work, then yeah, convert those to a task on a project because essentially you’re receiving a request that you are then planning work for. At that point, it becomes planned work. That’s where you, I would recommend converting that to a task. That’s really, I would say the only benefit that you have there. If the issue is essential or request is essentially becoming planned work and you want to track it as planned work, remember that that task is those planned work items on a project that lead you to the overall deliverable. At that point, I would recommend converting those issues to tasks. But if you’re just working them as unplanned work, you know, an issue comes in, we just solve it, we just complete the work on it, then there isn’t necessarily a benefit. So it really is up to your organization. Again, final point, if you’re wanting to track it as planned work, then at that point, I would recommend converting those requests that come in into tasks. Great. Again, great questions from everybody. Thank you. And you learned from the master, everybody. And Roy, thanks for being with us today. Thanks. It’s my pleasure.