Automatic Project Finish Date

You can use dependency and dates for all tasks in the project. If you change any date the whole schedule will shift according that and you see always the end of the project.

Agree with Lukas. Also, double-check to see if the date roll-up is enabled (via Table view) on the project finish date. Without that, your tasks will update but the project finish date will not.

Lukas Flatz I use dependencies for my due dates, however, each time task due dates move, the project finish date doesn't move. You have to change it manually.

Aloi Calvert  Sounds like you don't have Project roll-up dates enabled, which will make the overall project dates match the date range of all tasks within it. This will automatically adjust your end date based on the last task end date. Hope this helps.

Jason Pontius This is what I am talking about. Even I enabled roll-up, yes all dependencies move automatically but not the finish date. I  update it, each time last task in the project is moved or re-scheduled. Is there any setting that I missed? TIA

Aloi Calvert   Just to confirm, are you enabling roll-up on the project not the tasks? This is the place to check this setting on a project.

Once you have enabled it, the dates on the project should be grey, not black:

You might also find it helpful to measure project progress in addition to enabling the rollup as Jason suggested. You can enable it by clicking the percent icon in the top right of the project window. This way you can see the percent complete in a project dashboard widget, tables, and reports without having to look at all the individual tasks. The AI will also color code it so you can see the project risk. I use this feature all the time; it's very helpful when managing a large list of projects.

That's a good thought as well, Jessie Stith. However, I find the project progress to be highly inaccurate unless you do a lot of little tasks. Because it basis the AI on tasks completed, not effort performed to date, the value is misleading. For example, let's say you have only a few tasks, but they are very long in duration, the project progress will be almost useless. You may have performed 80% of the effort hours on the project, but because the tasks are long, still in progress, and are not completed, the progress will show a very low value, say 10% or 20%.  You have to complete tasks for the progress to reflect any realistic picture. For us, it does not reflect a realistic measurement.

If you have a large number of short tasks where you start and complete tasks regularly, then you have a large data set that is dynamic along the path of the project, and the project progress will be much more reflective. 

It's a good idea, but just not implemented in a way that always is representative of projects. Wrike has several features that lack in the understanding of actual effort completed versus tasks completed.

Another example is the Analytics view of a project. Again, this is just a chart of how many tasks are active, completed, past due, etc.  It's only a count of tasks. It does not analyze the amount of effort completed versus planned versus the calendar, etc.  It only counts task statuses. So, if I have a 6-month task with say 500 hours of effort, and you're in the 5th month and have completed 447 hours, the Analytics does not take this into consideration. It is only looking at if the task is new, in progress, done, late, etc. In this case, the task is in progress.

Take this a step further. Let's add to this 2 other tasks that are really short; say 2 weeks each with 40 hours effort for each one. Now you have 3 tasks, 2 of which are short and 1 very long task with a lot of effort. If you complete the 2 short tasks right away and the 1 long task is in progress for multiple months, Analytics will show you that you have completed 67% of your tasks. While this is technically true, it does not reflect that the majority of your actual workload has yet to be completed.

Jason Pontius interesting point of view. I've found that depending on the project I will change how the progress is measured so if some tasks are meant to take longer and are scheduled as such, the percentage will reflect accordingly.

That being said, I specifically have my team avoid single tasks that have say 500 hours of effort. I've found tasks like that make it difficult to track actual progress - for the exact reason you mentioned of it either being active, in review, or complete. I would setup the system so that something that work intensive would have subtasks with reasonable deadlines for each of those "checkpoints". In the short term, it's much easier to leverage other features such as the Workload chart so that it's clear what people are working on both "in the moment" and long term. 

I agree, the percentage track isn't perfect. And it'd be great if they added an option that took booked effort into account. But it's still better than having to click into every single project and look at every single task. It certainly helps to understand everything you mentioned, so if you know how the system is keeping score then you're not misrepresenting the data if you needed to present it to a stakeholder. Again, it's not perfect, but it does have an "at a glance" level of simplicity that my team finds very beneficial.

Jessie Stith Thank you for the feedback. The type of work that we do is often not effectively broken into tiny chunks. We are a service-based company and have a handful of typical tasks on an average project, such as On-Site Programming to deliver a project to the client. Our team will log time against this task, but trying to break this into a bunch of individual tasks of "do this on this day" and "do this on the next day" is inefficient, creates a lot of overhead, and confuses the team as to which task they should be logging time on. It just isn't how we work.

So a small project for us may include some prep programming work in the office, and then going on site to deploy it. There could also be some project management, travel, documentation, and maybe a few other tasks. This type of project just doesn't make use of the project progress very well.

Nor does Wrike really give indication if it's on track (effort used to date versus planned). I have created a collection of formula custom fields to help give better indicators than the project progress AI. I just wish Wrike looked more at the hours and less at the count of task status. A number of things would have better results and better analytics if they did.

This is really interesting. We have the reverse issue. We only track tasks, not hours. Right now we have too many smaller tasks that push the finish date out too far when using dependencies with durations. It creates an artificial schedule creep. As the sole PM with 150 projects, I am removing durations for now to at least keep the triggers from one task to the next. I also have a team that is 2/3 new team members. The learning curve is intense over here. 😀

Kelly R I don't use this very often, but sometimes I enter a decimal for a task duration. Since duration defaults to days as the length of time, if cascading tasks need to be done on the same day I've experienced the schedule creep you're talking about. For example, task 1-3 need to be done by different people and so are entered separately because they have their own review processes and workflows. Task 2 is dependent on Task 1 and 3 on 2. They all need to be done the same day though as this is when the team has the information to complete the work. If you enter them normally, the system will have them take up 3 days instead of 1 on the schedule. If you manually adjust the duration for each task to be something like .3, it will keep the dependency chain and the due dates intact where you want them to be on the schedule.

Another team I work with chose the task-sub task approach. So all the subtasks are just due the same day and then then the Wrike Bot will automatically notify the person assigned to the parent task when they are all complete so they know the work is ready. This method is particularly helpful for marketing because then we can have the parent task represent the day a communication goes "live" and use that due date to populate a marketing calendar. You don't have the same dependency chain, but for the marketing group this turned out to be easier to manage and keeps the Project Finish date intact as well.

That is a great strategy, Jessie. Thanks! 
The schedule creep was getting the better of me.