Forum Discussion
Export .mpp to .xml, modify and re-import
I have a web app that imports a ms project .xml. Users of the web app can then change the following properties: Notes, Physical Percent Complete and Finish Date. The project .xml can then be exported with only the mentioned altered. When the updated xml is imported back into ms Project the 3 properties: Percentage Complete, Notes and Finish Date update fine, however the duration remains the same and thus the start date alters to accommodate. How can I lock the start date during the import and force the duration to dynamically change? Because I am altering only the Finish Date and nothing else time related, I was surprised that the import didn’t error in the first place (since there would be conflicts in my xml). I need to learn how importing an xml works, what are the limits.. how to change certain properties whilst maintaining others and letting ms Project do it magic where necessary.
5 Replies
Here is what is happening. When tasks are scheduled normally (i.e. linked logic network with each task having at least one predecessor and successor), all dates are "as-soon-as-possible". The plan is dynamic. If you manually enter a start or finish date, a constraint is set. In you case by entering a new finish date a "finish-no-earlier-than" constraint is set. Since the duration is unchanged and the start date is dynamic, (i.e. "as-soon-as-possible"), the start date will move to whatever is dictated by the new finish date and the duration.
So, why are you updating by entering a new finish date? What is the end goal?
John
- Thanks for the reply. My ambition is to allow users, who manage their assigned tasks, the ability to adjust the finish date of their task(s) as they see it at particular instances during the project lifecycle. The project manager captures the project state at those instances and brings that into the .mpp to see the full picture of the project at that time. I guess what I care about is to change only the Finish Dates of tasks and then let ms Project re-establish a new predecessor/successor timeframe based on a ‘only start when predecessor has finished’ basis. In this way the Start Date of tasks that have dependencies will be dynamic. In the end I only care about what date project members think their tasks will be finished by, and then everything else falls into line from that. If a task is isolated and has no dependencies, then the original start date should stand and therefore the duration would change. Think of it like this, if the project is released in state ‘A’, but after 3 months in state ‘B’, project members reevaluate when their current tasks are actually likely to end those tasks should not have their Start Date changed, only the Finish Date.. since the start date already happened so shouldn’t change after the fact. Tasks up stream of the time this re-baseline is happening would be pushed left or right but not compressed or expanded. What I’m finding is that lots of things move around that shouldn’t… user A says task 1 that is currently being worked on will now finish 1 week later, this should only push the start of the successor out by one week, but what I see is the start of task A change which is incorrect. My web app is a communication tool for members of a project. As well as communication it also allows members to update the PM about the likely finish date of in-work tasks. The app is currently in development, so I’m trying to establish the best way to work with ms Project.
- jdineley,
Okay, thanks for that expanded explanation. You gave us a new very important piece of information. Here is how it boils out.
1. If the task is a future task (i.e. hasn't started) and you want the start date to stay but the finish date is pushed our (or pulled in), the the parameter to change is the duration.
2. If the task has started but is delayed or moving faster than expected such that the finish date is moved out or pulled in, the start date is "nailed down" by entering a date into the Actual Start field. Then you can either enter the new expected finish date or change the duration to achieve the desired finish date. I strongly recommend the latter, as manually changing the finish date will set a constraint and that limits Project's flexibility to dynamically schedule the plan. Entering a new duration will not set a constraint but will move the finish date.
Just for reference, do you set a baseline for your plan? If not, you definitely should as that gives a reference point by which to measure plan progress against the original plan.
John
