Using Projects vs. Tasks for Website features
Hi, I would be curious if there is any sentiment about potentially using projects, not tasks, to represent website features. My team builds websites on a common platform. We have "components" in a typical Mid-tier level that are shared across the websites we have, so for example a component to search the contents of each of the sites is the same.
I assumed it would be best to use tasks to represent individual features of each of the webpages on the front end of our sites. Not tasks for the webpages, but for the features. Each webpage, for example the homepage of site x, is a folder. On that home page I have some "features" - the aforementioned search functionality, an email sign-up box (which needs to interact with the mid-tier because that is where the Emails are generated), a "suggested content" box that will update and deliver links to the user, depending on whether she/he is logged in or not. These are features.
I had thought initially that I'd represent the features as tasks, and that I'd set up a "closed" status that would say something like "in production" or another permanent-sounding term, as these tasks should not fall away as in essence I am using tasks here as something permanent, kind of like when tasks are clients if Wrike is used as a CRM.
However I am stuck on one element of this set-up: In some cases I have multiple versions of the same webpage. This may be because the visitor comes from a different source, or is logged in and the page changes. Each page "version" has a slightly different set of features displayed. So I initially was thinking the fact that I can nest subtasks to multiple parents would be useful, as I could create the versions and then just add the common features under each, and the one feature different would be only included in the particular page on which it was different. So say three versions:
- one with 5 features, the default
- one with 4 the same, the 5th changed
- one with features 1 - 3 same, 4th changed, 5th the same.
I would represent this by having three tasks, one for each version, and the common features would each nest under these three tasks as subtasks.
What I'm wondering about is whether there is any reason to go "big" and actually use projects for these features. This would leave me a ton of projects across Wrike, but is that a bad thing? Projects are so lightweight, one of the main pluses of Wrike I've found, that they in a lot of ways function as just bigger tasks. The big thing here I thought I'd accomplish is the ability to create folders under the projects, to better group things like these three versions. With the folders, I can keep the main folder of the webpage a bit cleaner, for example if in the future I needed to add feature requests to the page and want to list them separately.
Many thanks for any tips here!
Hi @Al,
This sounds like a really cool way of structuring. The closest thing I can compare it to is the COE in my team's workspace - I created a main resources folder and added backlogged tasks to house entries on various topics. Then I added subfolders to group resources by types and help with search / navigation. So, for example, you could find a task entry for social selling under the main resources folder, and it would also be double-tagged to relevant subfolders, such as "trainings", "social media resources", etc. For me, tagging tasks to multiple folders was easier to work with than dealing with subtasks under parent tasks.
Is there a reason you want to use projects for some features, rather than folders? I feel like folders and projects have many of the same options, but I chose subfolders because I didn't have start and end dates to consider. If applicable, you could use folders to show page hierarchy / organization that doesn't really change, and then include projects when you're actually looking to update certain features.
Let me know what you think!
Regards,
Carolanne
Carolanne, thanks for responding to me. I have since thought this through and I am thinking about using folders more readily as you suggest, with a more "pure" implementation of tagging tasks with the folders, which then allows me to take advantage of what is possibly the biggest plus of Wrike for me - the fact that tags are organized in Folders and hierarchies, whereas in other Project Management apps they are simply one big list.
You also raise another point of how you enter backlogged tasks for various stuff. One of the main reasons my team chose Wrike was the ability to enter just about "anything" we want to work on, be it a bug, an idea, a goal, etc. in relative quick fashion, then later discuss and figure out whether its a task, a project, a "goal" for which we'd have a folder and track long term, something like "reduce costs" etc. Ideally I'd like to be able to transition these items to various data types, first and foremost from a task to an idea. There's a big thread discussing this, which was even moved to "coming soon," but sadly, is no longer in that state:
https://help.wrike.com/hc/en-us/community/posts/115000310005-Convert-a-Task-into-a-Project%20?page=5#comments
I'd be curious as a fellow green belt to hear your take on this capability of Wrike. Perhaps we can rally some support for this issue, it would be huge for me to see it released!
Thanks again!
@Al Yup, I've been following that request. While my team doesn't have many use cases for converting tasks to projects, it's likely because we've placed the burden on them to always define what they're going to need from the start. Happy to comment in that post with another example.