Hello, is there anybody out there?
"Add new Workitems to Baseline" function
Once you have a baseline, new workitems that are created after the baseline do not have a baseline. That leaves you with two options:
1) Accept that new items will not have a baseline - bad option
2) Reset the entire baseline and in fact, loose the baseline - very bad option
I suggest to add a function: "Add new Workitems to Baseline" this will set a baseline just to those workitems that have created after the last baseline creation.
Please sign in to leave a comment.
Sorry for the delay in response we have been experiencing high volume of posts and since transitioning to the new Success site and we have been playing catch up.
Your change request was logged. ID: CR-278961
After discussing with Product team, this functionality you are requesting would not be a best practice as it would 'break' the baseline. Currently Baseline creation date is stored at the project level only. Without adding Baseline Creation date per Work Item, you'd have no way of knowing when exactly a new item was mini-baselined.
There is a big potential to cause big confusion, I'd go so far to say this runs the risk of data corruption and faulty calculations. Also, the new tasks are not part of the original baseline and adding new tasks would require you to update the baseline. Adding it on the fly basically means re-baselining.
Thanks for taking this to Product.
Here's the business case, happens in each and every project – I wonder what is Clarizen's answer / best practice for this:
Assume Milestone 'M':
Original Start: April 4, Original Due: July 4
By July 5th Milestone 'M' is past due, so Clarizen marks it as "Off Track"
The project manager sets a new Due Date: July 15. Now Clarizen marks Milestone 'M' as on track although there is an 11 days delay from the original Due Date.
Project manager says to himself, that's OK, I can use the Baseline Due Date to track the delay, but alas, Milestone 'M' is not in the baseline!!!
Why is Milestone 'M' not in the Baseline?
Because when the project was kicked off 10 months ago and the baseline was created no one thought that Milestone 'M' would be needed. In fact, Milestone 'M' was added to the project 3 months ago, 7 months after Kick-Off.
When the project was Kicked Off, and the baseline was created, the WBS in Clarizen comprised of 120 workitems. Now, 10 month later, the WBS contains 600 workitems, 480 of them don't have a baseline.
Well, what if the project manager will reset the baseline?
If he does that, then the PM will lose the existing baseline for the 120 workitems. Their dates will be reset to the current dates and any trace of delay on those 120 items will vanish.
Clarizen only has one baseline at any given time, and that is a known problem, other products solve this problem by allowing multiple baselines.
What is the Clarizen's solution / best practice for tracking delays on workitems that were created after the baseline setting, without resetting the baseline?
No one ever gave Arnon a response on best practice. I have a project with several hundred items and we discovered an error in the plan months after the baseline was saved. I would like to update the baseline for the area to correct the problem, but I can't do that without resetting the base line for every single task which would erase the tracking.
So I don't really have an option to correct this scenario. This scenario and other similar scenarios occur all the time where I just need to reset a portion of the project, not the entire project. Is there a way to do this? Even if the only solution is creating my own baseline field, I want to know what Clarizen would suggest. (I probably would not do this, but I want to know what constraints I need to work within)
Indeed I never got a proper answer, but I know Clarizen released an app called "Baseline Versions" http://www.clarizen.com/appsmarketplace/item/baseline-versions.html
Perhaps it is useful. I did not have time to research if this app resolves the problem we discussed here.
I'd love to hear what you think of this app.