Dependencies and Task Completion

nuddernuby

Please see the attached screenshot : Dependencies&Completion.jpg and consider the area ringed in red.

Here are 2 issues.

1. (Lesser issue) The two dependent tasks can be completed in one day - they have respectively 4 and 5 hours duration. The gantt creates the idea that they run concurrently which, of course, is wrong. We can still live with that.

2. (Serious issue) Note that the second task has been updated (completed) but the predecessor has not. This makes nonsense of the dependency principle. A task that is dependent on the completion of a predecessor should not be able to be updated in terms of completion % nor marked as complete - it cannot even start before the predecessor has been completed. If it could, it would not be a dependent successor.

As always, it would highly appreciated if someone could indicate how we should solve this.

At the same time, any task display page in the system should preferably show whether a task's predecessor has been completed or not. Not all views show the full hierarchy of tasks and, on big networks, having an overdue task displayed in red has very little value if management cannot immediately see whether predecessor(s) are the hold up or whether the problem lies with the specific task - ie where any management intervention should be directed. This is a simple addition that you may wish to consider.

Kind regards

nuddernuby

Further to the above, please see the attached screenshot:

scheduling.jpg

Compare the durations in the left hand panel with what is shown on the Gantt. (Ignore the top task - it stretches out to the left) There appears to be a serious disconnect.

Will be grateful for your advice.
Rgds

caseydk

caseydk

nuddernuby

Maybe I did not get this across clearly. Please compare the values in the table with values of the Gantt bar display. The last task has a duration of 32 hours ie 4 days - but it only shows one day on the Gantt.

??

caseydk

nuddernuby

I think we may be talking around the point here. At the risk of making myself unpopular, I need to share some ideas which have become clear as we were testing w2p - they might be helpful.

The unpleasant reality is that the current scheduling approach appears to be dysfunctional. There are other threads on the forum that also point to dysfunction in the task chain calculation. I suspect that it relates primarily to the foundation on which w2p is built.

1. It has to be decided whether w2p is just another diary system or whether it is a project management system. If the latter, then it has to (firstly) schedule on the basis of well defined principles and algorithm and (secondly) to provide management information.

OK so far?

2. If we allow users to arbitrarily change start or end dates, we destroy its primary function as a scheduling tool and by doing that we have just killed its raison d'étre - then it's just a diary system.

Please get this: Yes, there are many cases where things change - that happens all the time. But how the change is handled by the task manager is up to him/her and falls outside the scheduling algorithm. You don't change the functionality of the system to cope with a volatile environment.

3. This means that the system must calculate the chains of tasks based on a principle that will give the best-fit answer. The way it does that is the basic 'philosophy' of the particular system. At the moment I don't see that in w2p. One gets the impression that its trying to be everything to everybody - and in doing so it runs the risk of losing the ball entirely.

4. So, some key issues would include:

- Do proper resource modelling as a start (& understand abstract resources)
- Mark which days are non-working days, including holidays
- Schedule on the basis of logical and resource dependency
- Use task duration as the driver
- (Preferably) schedule from delivery point backwards
- Recalculate all chains continuously, at least with every change
- Most other elements in the system can be distilled from this base.

Anything else increases the risk of befuddling the issue and generating garbage (as reported in this thread). I would like to ask that you look at the above points carefully. They are not software issues - they are project management issues which need to be satisfied by the software solution.

Let's chew on this first, before we discuss the question of what management information the system should provide.

Looking forward to your response
Best regards

pedroa

nuddernuby,

Believe it or not, I just loved your comment Smile

1) It is (supposed to be) a Project Management System to be used on a enterprise Daily basis Smile

It is probably the fact that it is used in a Daily basis by users of all quadrants of a company that may cause an impact on the Project Management System side of things.

2) That's why we need a couple more dates on both the Projects and the Tasks objects.
The existing couples (project_start_date and project_end_date, task_start_date and task_end_date) are planning dates (whether original or adjusted), and we need real start/end dates, that track the real execution of projects and tasks.
Planning dates should be the Projects Manager realm, and the Real dates should be the users realm.
In order to track deviations between real execution and planned execution.
I am to add these things shortly.

3) I understand what you mean, and I don't take offense on your words.
We do try to keep the highest rate of users satisfied with our product, and we'll keep trying to get to your levels of satisfaction, that I understand are higher than the "average" web2Project user or Project Manager.
When I said that I loved your comment, was because the way you are feeling was the same way that I did when my needs got to that level too.
Thing is I am on the side of this Project where I see how hard it is to satisfy those needs, and keep everyone happy.
Other things like sponsorship determine where things are driven, also because they apply real professional concepts to the product.
Though I accept your positive criticism, because I know that they are based on your professional requirements, I must also point that in web2Project we are closer to that than we were on dP or on w2P itself when I started.
Sure this will not make you happy "out-of-the-box", as doing 90% of something is the same as not finishing anything at all.
At least we try.

4) I could not judge you unpopular by your views, specially when you provide well expressed ideas like these.
-"delivery point backwards", I'd say that this depends on the Dependency Chain, if you have the possibility to draw chains with other constraints other than Start-Finish relationships you can get "delivery point backwards" or Just In Time (JIT) plans.
-Duration is the driver. I totally agree with that, though there are people that loosely schedule their tasks to be done "around" some dates, and its duration would not be the whole period in between.
But if we are to handle Dependency Chains this "Duration is the driver" concept is mandatory. And it is the Duration that drives the Dependency Chain drawing in the system right now.
Also because people that loosely manage tasks are most certainly not going to use Dependency Chains.
------

Chewing is not the problem, the problem is to forge these concepts in gears that work with each other in a non-conflicting way.
That's what is happening with the Dependency algorithm at the moment.
That and the fact that the teams resources (time) are limited.

Thank you very much for your views, and your support.
Please keep hammering us when you get frustrated, it is really bad when we get used to our frustrations and keep swallowing the same old excuses with the purpose of doing nothing about the issues.

I got your "this s... isn't working quite exactly as it should/or as I want" idea Very Happy

Pedro A.

nuddernuby

Spoken like a true gentleman!

However, I would disagree with you on the following:

antonvdberg

Hi Guys,

I enjoy it when we interact as professionals and we articulate exactly what the requirements are.

I would like to support nuddernuby in his comments. We both hail from the rim of civilisation and therefore are required to pull world class results from whatever we can lay our hands on. W2B is just such a situation that we compelled to use it like 1st world persons would have had access to severely expensive commercial server and web based products with millions spend on R&D and the like.

Keith and Pedro, you seem to be the most active of the persons dealing with this product and although I am not exactly clear on how the project fits together in terms of sponsorship and other aspects like this, I have been impressed by the both the quality and speed of feedback.

That notwithstanding projects revolves around three separate entities – Plan, Actual and Forecast.

As a statement this sounds pretty simple, however it requires three tracking methods where planning is characterised by a moving baseline process, actual values are sometimes random and have an influence on the last element (which in my mind is the point of having scheduling tools) forecasting.

Unfortunately very few scheduling tools can actively differentiate between duration, work and calendar progress (which some people may think is the same as duration – e.g. a concrete floor takes 3 weeks to dry – Duration – but on the day of the pour, the concrete supplier was on strike and the pour was 3 days late – calendar progress.).

Hence each of these tools picks an element like duration and all calculations revolve around that. This has detractors, but in essence if you can provide that, as a basis, you will provide service on the same level as commercial offerings. But still you have to decide that you will use a singular calculation algorithm irrespective of the pressures from us and stick to it.

I hope that this is not seen as philosophical debate but rather an enhancement of the distillation of what exactly is the desired outcome.

Good luck to us all.

pedroa

pedroa

nuddernuby

I have just written a rather substantial reply to your last post. When I pressed the Submit button, the system threw me off and I had to log on again. The document disappeared. Is there any way of retrieving it? I have to admit that it would be difficult, timewise, redo it.

?

pedroa

nuddernuby

You definitely are a genius, my dear Dr Pedro. Here is the retrieved document:

I'll have to think about how to reply to this in the most efficient manner.

In the meantime, and before I tackle them individually, some general points:

- I prefer the definition of Tom Peters, which says:

“Project management is about outcomes, getting stuff done”

- Many of the above questions have been addressed in my various previous posts. I must have communicated badly.

- We should be careful not to get to a place where we can't see the wood for the trees. This thing is simpler than you think, if we can agree on what we need - the challenge is going to be to programme the engine.

- We should be careful not to try to re-invent the wheel. After half a century of failing project management techniques, a lot of progress has been made recently - most of these questions have been sorted. Unfortunately, a lot of garbage previously infiltrated the thinking and we'll have to rid ourselves of this pretty ruthlessly.

- Yes, indeed, Pedro, we need a rock solid algorithm and, yes, it needs rules. That is what I am asking the w2p team to do now: agree on the rules and set them down so that we can move forward.

As a departure point, let's see if we agree on some basic concepts:
(We have to agree on these issues otherwise we cannot set the rules and we will not move forward)

1. The objective is to deliver a project:

- on time (or early)
- within budget (or below)
- to specification (or above)

Of these, we accept that the time factor has the biggest impact on everything and is the most critical to get right. This is NB as it will affect how we structure the rest of our thinking. (We can explain this further if people are not on the same page.)

2. If I do a project that is expected to produce a revenue of, say, US$ 5 million per day (7 days a week) upon completion and commissioning, that equals around US$ 150 million of revenue per month. Every day that I deliver early, I gain revenue of US$ 5 million. Every day late means I lose US$ 5 million.

3. Now, do you seriously expect me to waste time on 'how far off' the project manager's first plan was? Honestly, nobody cares if he drew the plan on the back of a cigarette box or on his girlfriend's boobs. He will only be measured on whether the project is delivered on time (or early) or not -- and only then on the other two factors.

4. The tool we need must cater for this. How do we get to that? We distil only those factors that will directly affect this outcome. Everything else becomes largely irrelevant. Once we understand that, the debate about those other trivialities falls out of the window. Many of the points raised in previous posts are no longer an issue. (Eg leads and lags; Finish-to-Start debate, baseline, etc etc)

5. Dependencies are ALWAYS relevant, whether resource or logical. If not, you only need a calendar - i.e. w2p only needs the Events part. They are to be used in every scheduling run.

6. Once we have the scope (spec) defined, we need to have some plan in order to:
- Determine a feasible delivery date
- Determine the resources required
- Determine the expected cost (budget)

Yes, this can call for some very complicated iterations, combinations and 'what-ifs'. If you wish to use Monte Carlo simulations, Event Management and the like, that's OK, but they lie outside this software requirement.

SOFTWARE NEED NO 1: So, firstly we need an editing interface to enable us to set up the above plan - like MS Project or Mind Manager or similar - and it needs to be fast and efficient - especially important if we talk about server side processes.

SOFTWARE NEED NO 2: We need to be able to build the network by doing TWO things AT THE SAME TIME: model the logical dependencies AND apply the resources in such a way as to find the best pipeline of activities (i.e. build the chains properly) with cross-project consideration.

Yes, I expect that this is where the men will be separated from the boys.

SOFTWARE NEED NO 3: We need to work ONLY with Finish-to-Start relationships. (If this is not understood, we can explain later)

7. Once we have our 'Best Guess' for a Due Date we can decide whether we should move ahead to the execution phase or abort.

8. Remember, we now have a Spec (for the project AND for each task), a Budget and a Due Date. If we decide to go ahead and execute, we can throw away pretty much everything else. If you want to keep all your work for sentimental reasons, please be my guest. If you want to go to the bar and cry into your beer because task ABC took only 3 days instead of the planned 4 days, please be my guest. If a baseline makes you feel less insecure, please be my guest and keep one. If you want to evaluate the performance of your PM's based on how accurately they could predict the future, be my guest. If you (erroneously) think that people learn from their mistakes and will not repeat them in future, please be my guest and spend all your time analysing past performance - and good luck to you. ( I use the word 'you' generically here - I don't mean you, Pedro.)

We clearly live on different planets: I have projects to deliver.

SOFTWARE NEED NO 4: We need software to handle the execution phase and its main function will be to extricate the correct management information that will alert me about something that poses a risk to the delivery date - so that the PM can act accordingly and remove the risk/threat.

(The bonus here lies in the fact that, if we have this facility, we cut our meeting time by up to 60% - shown in practice.)

SOFTWARE NEED NO 5: We need estimated duration only for the planning phase. After that we only need (estimated) remaining duration for every task on (probably) a daily basis in order to assess risk. (Yes, Pedro, I have already added such a field to the database) Actual duration is IRRELEVANT, except to those guys who want to sit in the bar and cry into their beers.

SOFTWARE NEED NO 6: If we can add some financial control for the execution process, that would be a bonus. (I have already added some such functionality to our test programme)

SOFTWARE NEED NO 7: We probably need some graphical displays to convey the key info to management - such as scatter charts or similar -
and I don't mean Gantt charts.

SOFTWARE NEED NO 8: The output at operational level will need to be a prioritized To Do list with the facility to update tasks. (You will understand that, if we use remaining duration for the daily rescheduling process, the entire problem of someone deleting a task_log, and others, disappears.)

So, the above is all pretty simple,but these basic premises need to be agreed on so that the rules can be established. A few others may be added. I'm sure that a lot of it exists already. How to programme the 'rock solid algorithm' into the software? Well, I'm afraid that's where you experts come in.

And, alas, I shall now have to get down the big job of answering all those (silly) questions you raised in the post above, Pedro. Laughing

Best regards

pedroa

antonvdberg

Hi, I am responding first to nuddernuby (as this is his topic) and then Pedro.

SOFTWARE NEED NO 1: YES!!

SOFTWARE NEED NO 2: YES!!

SOFTWARE NEED NO 3: YES!!

Once we have our 'Best Guess' for a Due Date we can decide whether we should move ahead to the execution phase or abort. YES!!

We clearly live on different planets: I have projects to deliver. YUP that we do, some of us have to report on project progress to our clients. That means we “sold” a project based on all the values that you are now throwing away. We don’t need it analyse the past performance, however we need it to try and figure out how we are going to achieve the result “sold” with the resources at hand.

SOFTWARE NEED NO 4: YUP see above comment.

SOFTWARE NEED NO 5: NOPE – On larger projects some groups have grossly underestimated and others over – we need to identify this and correct if possible. Then there is reporting – management, clients and the like that would like to know what is going on. Actual duration would consist of all three elements (Work, duration and calendar progress) plans and schedules hardly ever consider the real world and when s…. happens, you need to know when and where as somebody ends up paying for it.

SOFTWARE NEED NO 6: Yes!!

SOFTWARE NEED NO 7: YES!! For this you need to be able to show actual against plan using something like an S graph as well as showing some statistics like SPIX and CPIX. These the managers (like me) can actually understand.

SOFTWARE NEED NO 8: YES!! Project members are allotted their tasks, they can add logs (for man-hour usage) estimate the amount of work completed (as %) and at best guess the duration required to completion (I am not very secure about this, experience has shown that the average person sucks at estimating). They should not be able to delete anything! They may request to cancel a task but this should be out of their hands.

If we agree that we prefer the definition of Tom Peters, which says: “Project management is about outcomes, getting stuff done” we can look at overcoming these issues rapidly.

The main reasons why the original plan is required are:
• This is what was sold and we have to continuously measure ourselves against the rate at which we get stuff done (on the timeframe agreed – not later than).
• If a change to the scope occurs, you need to be able to see what the effects are (to original plan and resulting actual).
• When reporting or measuring progress it should be relative to?
• When the stuff hits the fan, we need to be able to distil its impact and use the original plan, budget and QA standard to properly understand the constraints under which we need to overcome these events.
• It is the only measure I know of where you can show the project members where they are losing the plot.

If we can firstly agree on some of these, then we can move to how things are calculated etc.

OK?

Have a stunning day

nuddernuby

Thank you, antonvdberg, for your constructive contribution.

The main area of divergence in our thinking lies with NEED NO 5. Let's quickly look at this.

nuddernuby

I promised some comment on previous points. With your permission I shall copy the points and annotate for the sake of economy.

Batch #1

1) Task logs track the actual work done on a task, therefore the remaining Duration is the Tasks Duration less the sum of work done on the Task/Work logs. Should this be strictly that way?

---- No! It might be so arithmetically - it definitely isn't from a management perspective. Remaining Duration is the latest real time assessment of how much time is still required to complete the task. It usually applies to tasks that are in process. The information is needed to predict a possible delay in delivery - so that action can be taken in advance. The info can be fed into the system via a simple input text box.

Because as is, we are letting people add work logs regardless of what is defined on the Tasks Duration.

---- That is how it should be.

What if work/task logs duration sums go beyond the Tasks Duration? Should we update the Task Duration to the Sum of the Work/Task logs?

---- No. As stated before, the original task duration was only used to set the original Due Date. If the logs duration sums go beyond the Tasks Duration - that is precisely what we need to know in order to act in good time.

And what if after such an update a user deletes a work/task log, how can we remember the original Task Duration? Or should we just simply update the Task Duration to the new Sum of Durations of the Work/Task logs?

---- 1. No one should be able to delete a log.
2. We should clearly distinguish between task logs that record hours worked for the purpose of charging and task log that shows where management intervention is required to prevent a delay.
3. Correct handling of Remaining Duration will deal with this.
4. We shall require an extra field for this - either in the 'tasks' table or in the 'task_log' table.

2) So we have the planned dates (start/end), it is the Project Manager that drawn the Plan that defines those.

---- No. it is the system algorithm that has to determine this. It should be 'untouched by human hand'.

And the users are, during the execution of the plan, adding task/work logs and changing the Duration of the tasks, if the durations are shifting, then the original plan is also shifting?

---- No. the original plan is an historical document. What shifts is the project delivery date IF the task lies on a chain that is critical. And this is what the PM needs to know ASAP.

Isn't that going to ruin the original Plan (meaning the Project Managers work)?

---- Yes, of course. Did we think it was a holy cow? The purpose of the original plan is described properly elsewhere

How can we certify the Projects Manager Plan quality if we can't remember what was the original Plan?

---- By on time delivery. We know the original delivery date that was promised. It's all that matters.
If we need this info for other purposes, such as training or process improvement (to see where we went wrong), then we can refer back to the original plan. I've known very few people who actually do this in practice. Talk about it, yes. Do it? Ha ha.

How can we know how off was the original Plan from the reality?

---- Why exactly do we need to know this? Seriously, please think about the question.

Bottom line, how important is the Original Plan after all, if we know for sure no project goes as planned?

---- Now, here is a good point. It's not important.

Talking about durations, should we have a Planned duration and a Real Duration?
And should the Real Duration be based on the Task/Work logs?

---- As stated before: First we need an estimated duration for planning purposes - to calculate a feasible due date. Then we need a running update to see if we're running late. Two figures. How we enter it is debatable. Task/work logs should be OK.

Or should we have a Remaining Duration field instead of a Real Duration field? Or should the Remaining Duration be a simple calculation?

---- Simple field.

3) Dependency Chains must be more flexible to work with Real Projects on a daily basis.

---- I'm afraid I do not understand this statement. Dependencies are not flexible.

We will need the other 3 types of dependencies, Start-to-Starts, Finish-to-Finish, Start-to-Finish (JIT) with leads and lags.

---- No, we don't. We need only Start-to-Finish.

And then prioritize when dependencies step on each others toes.

---- Yes, this is exactly what the scheduling engine's job is. Also for resources (at the same time).

Making it rocket solid can be a nightmare.

---- Not necessarily, but the underlying principles and rules need to be very clear.

We already have a nightmare of our own because of these lack of priorities on our "simple" Finish-to-Start algorithm.

---- I think we are going to sort this out now. We need to understand cause and effect and to understand what drives the priorities.

And what about dynamic/umbrella tasks, should we let dependencies fall on them too? More algorithm nightmares.

---- Summary tasks are merely arithmetical conveniences. The dependencies are seated with the tasks that fall under them.
Please explain to me: For purposes of scheduling, why would we ever want an umbrella task that is NOT dynamic?

And what about constraints and deadlines, ASAP and ALAP, SNET and FNET, SNLT and FNLT, MSO and MFO?

---- One by one the short answers are:
We effectively have only two types of milestones: Project End and Contractual Milestones.
They will take care of most of your constraints (we can come back to this one if you wish)
We use ALAP (If all other factors are equal, this will be prescribed by the Time Value of Money)

Batch #2
So the suggestion is 3 couples of start/end dates and Durations.
1) Planned
2) Forecast (or the Original Plan mutation)
3) Real

---- No. I would suggest only two: 1. Planned 2. Continuous update

Now, and this is where it gets exciting, consequences/rules:
1) When a Task is created, the Forecast dates are copied from the Planned dates, and the Real dates are empty.

---- OK

2) The Real dates are always automatically calculated from the first task/work log in time and the last task/work log in time, as well as the Real Duration from the sum of task/work logs logged.

---- OK, but what management decision can I make based on this info???

3) Dependencies never apply to Real dates.

---- Dependencies always apply. Remember that we always only schedule from TIME(0) into the future.

4) Dependencies apply once on the Planned dates (not sure if what I mean is that a Project must be always based on a template here), and whenever necessary on Forecast dates.

---- The scheduling engine should calculate dates based on the rules and the dependencies - all the time. Simple. The rest may be garbage.

5) Forecast Durations are based on the Planned Duration firstly, and then on the Real Duration plus input by the users on a "Expected Remaining Duration" field on the Work/Task logs interface.

---- A duration is ALWAYS a planned/estimated duration - until the task has been completed. Then it is firm - and historical, meaning it no longer has any execution value.
---- The computer CANNOT calculate the remaining duration on its own. It needs to receive an input from the person who 'touches' the job.

6) Forecast Dependency date shift triggering are solely based on Forecast Duration changes.

---- Sorry, I don't understand the statement. Please explain to me what is meant here.

This is indeed a big change to w2P, because what was triggering this was a change to the end date, which is kinda nutz.

---- NB. No person should be able to change a date except for the Project Start or Project End date. The rest is the job of the scheduling engine. Changing a date manually is what you do for an event on the calendar.

Coffee time again.
Rgds

antonvdberg

Hi guys, not avoiding the subject.

Lot to process ....

From initial view would work excellent for man-hour centric projects.

I am thinking about the effects it would have on EPCM projects but need some time to effectively "test" the premise.

Hey, hey it's Friday

Enjoy

nuddernuby

You may wish to take the EPCM apart and consider each component separately, i.e. E, P, C and M.

My guess is that the most problematic section should be the Construction part, as always, with its (usually) high subcontractor component.

Let me know how you go.
Rgds

antonvdberg

Yup that's what i am doing and that is why it might take me the weekend.

I don't want to come back with stuff that we don't really need and I am just used to because of legacy.

Hope that is positive enough.

Enjoy the weekend.

nuddernuby

While antonvdberg is burning brain cells, and while we're on the subject of dependencies and task completion, let's use the opportunity to find common ground on what the task types are that we are likely to encounter and that we shall need to deal with.

And before we deal with that, it might be useful to recap our definition of "duration". Here is my understanding, as also pointed out by antonvdberg elsewhere:

Duration is the working time (in manhours or mandays) required to complete the work based on the number of resources employed.
It is NOT gross elapsed time (what some call calendar time).
Process time is usually a fixed lead time concept where the duration and the elapsed time are the same, like eg. concrete curing time, external contractual delivery lead time, fixed duration entries/tasks in a variable capacity file, etc.

QUESTION: Do we all agree on these definitions or should they be amended?

Here, then, are the task types that I'm aware of:

1. Ordinary tasks :
---Duration based on manhours required and number of resources applied.
---Can be adjusted during planning phase and during execution.

2. Dynamic summary tasks :
---Duration calculated by system only
---Can not be adjusted manually
---Note: There could be an unresolved issue here: Should a dynamic task be displayed as duration or as elapsed time? I think MSP shows it as elapsed time.

3. Buffer tasks :
---Duration calculated by system based on preset (but adjustable) rules
---Can be adjusted by PM, usually by adjusting the rules
---Could be actual (visible on gantt) or abstract.

4. Process time tasks :
---Duration determined by external factors.
---Fixed lead time, independent of number of resources applied.
---Can usually not be adjusted at any time or by anybody

The above have a critical impact on the scheduling process. Clearly, we would want to have as few as possible in order to avoid greater complexity.
QUESTION: Did I cover all? Leave anything out?
Look forward to your response.
Rgds

nuddernuby

Er.... has everyone gone to the beach?

pedroa

Still digesting the whole thing Smile

I started to write a reply on Friday but it is not finished yet Very Happy

But it is one of my windows around here.

Eventually it will get posted, so that you see what is my mental progress on it.

By the way the beach was good too Very Happy

Cheers,

Pedro A.

antonvdberg

Hi Guys,

No beach for me Crying or Very sad

Running around with other work.

Strangely the construction portion wasn't that bad. It is when you have for and on behalf of procurement and value engineering where significant paperwork and reporting seems most required.

If I stand back and look at it from a distance, the detail in communication is dependant on two factors; the amount of parties involved and secondly the complexity of the task itself (here insert schedule, cost, logistic, documentation etc.) that drives the requirement for detailed progress reporting.

Will let you know more when i have more.

Pedro, hope your tan is now up to date.

nuddernuby

It would probably make sense for us to really discipline our minds to take a re-look only at the scheduling capability itself at this stage. From other contributions to this forum it is clear that a solution needs to be found for precisely how the chains are calculated. (Large fries and others have made this very clear.)

From all the discussion above, let me try to summarize one or two things that need to happen. Let’s go right back to the core issues.

1. What does the PM/network planner do?

1.1 Before he even starts, he does the resource modelling (abstract and physical) for the company, in conjunction with the Resource Manager/HR, and defines the calendar, as a base for what happens next.

1.2 He designs the network for a project, based on logical dependency and assigns the expected duration for each task, in this process creating (an infinite number of) chains that all culminate in one point: The Project End milestone. He does this by planning backwards from the Project End in order to ensure that all predecessors (dependencies) are accounted for and that none are missed – using the well tested and proven guideline phrase [ In order to…….. I have to……] in the process.

Fine. Up to here we only need an editing interface like MSP.

2. What does the system (software) do?

2.1 It takes the abstract resources developed in 1.1 and the calendar and then plots a Start Date and End Date for each task based on the resource levelling that will be achieved by doing a zillion iterations to reach that particular ‘mix’ that will provide the earliest completion date(s) for the project(s).

This is its main function, I believe, and this is what needs to be established now. I don't believe we can define it much simpler than this. (With ANY change, it has to run through this entire process again)

2.2 In a multi-project environment, it does this across projects.

2.3 In the process it also considers all second and third tier factors that get added, such as relative project priority, dollarday values, contractual milestones, etc, etc.

I don’t mean to oversimplify things, but it appears that we need to ask ourselves: Can this algorithm be built (programmed)?

If No, then we all say goodbye and really go to the beach.

If Yes, this base actually has to be built - before all the bells and whistles are added.

Maybe it’s already 99% there. I don’t know. The big brains will have to speak now.

Anybody need sunblock?

nuddernuby

Oops!
Point 1.2 above:

The PM/Network Designer also assigns the abstract resources to each task.

Sorry about that.
Rgds

antonvdberg

Yup,

That would absolutely be the next step.

I concur.

The only possibility that I would like to keep open (for R&D Projects) it the concept of an “unknown end date”.

This means that we can create an artificial end date and plan backwards. However when the abstract resources are replaced by real ones, the project should be able to exceed the project end milestone - Based on optimum resource levelling.

We can address next issues when we get there – this is a good start.

Pedro & Keith – Please address the subjects……
Laughing

nuddernuby

If you will just give me a minute to wipe some sand off the b**bs around here and clean the sunblock off my project planner, we can add another thought to the above. This will be short.

CHAINS & INTEGRATION POINTS

While the engine does the basic work mentioned earlier - and that includes resource levelling - it is also busy calculating chain lengths. In order to do this it has to recognise the integration points in the schedule. These, needless to say, are the points (tasks or milestones) that have more than one predecessor.

Why is all this important? For a number of reasons. Remember, in cases where resources are limited (and that means virtually all cases), the resource levelling process will by necessity introduce slack into the network. Now the chain length becomes an expression of elapsed time – it can not be a simple sum of durations. It will also mean that there will usually be one 'most constraining' resource.

We now have to 'calculate through' the integration points to find the critical path and 'calculate along' the constraint resource to find the critical chain. The latter, as you all know, does not run along a dependency chain but runs across chains - it is more abstract. But in practice, this is the most important item that the PM has to watch. A delay/disruption here will (most certainly) delay the project and will (most probably) desynchronise the project. So, the system has to find these from the word go.

Also, at every integration point the system must determine whether any chain is integrating with the critical chain. If so, voilá, the exact place for a buffer has been found and the system can calculate the buffer size and insert it. The buffer is sized according to the length of the chain. So, we see that the system has to know the length of all chains at all times.

When we go into execution – guess what? – it has to do exactly the same with every daily update. Why? To see if any chain is now going to ‘push past’ the end date of the last task. If we use a buffer system, it will show if any chain is pushing past the last task and into the safety buffer. If it is, then it has to trace back along that specific chain and identify the culprit that is causing the problem. This is what the PM wants to be warned about so that he can intervene immediately and work his magic. If a task runs late but does not consume buffer, the PM is ready for the beach or the movies.

Boundaries? The limits are set by the resource pool. The system should be able to calculate all chains and tasks that draw on one resource pool. Naturally, this can cut across projects. Normally this also means that companies will be discreet, i.e. a different company will have a different resource pool and a different network.

I know this is all rather basic, but only the software geniuses will know how to write the code. Maybe we should take a naughty peek – no, Pedro, not at the b**bs – at the way the available commercial systems handle this. It’s all been done before, I guess.

Let me go and sharpen my pencil before I lull you all to sleep.
Rgds

antonvdberg

Good Morning Mr. nuddernuby,

Have we been deserted by kings of the system Question

Pleeeeaaaase Pedro and Keith, address the loyal subjects Wink

, we await your views with hope and anticipation Mr. Green

.

Enjoy the day.

pedroa · Last edited by pedroa on Wed Sep 09, 2009 1:15 pm; edited 1 time in total

To antonvdberg 1st:

I have been reading all these and here is where I am at, and please try to mold my mind as I go, because ultimately I am the moron that will try to teach the computer what the dumb ass will do:

1) We need to keep the Original Plan.
I know nuddernuby doesn't like the idea, and that it is not an imperative factor to get stuff done, but it is important, not for the history of it, but to optimize the learning cycle and to better forecasts on future

projects.
That's one of the functions of Management... Control and prevent future mistakes.
(http://en.wikipedia.org/wiki/Control_%28management%29)
So the idea is not how it helps to get "this" stuff done, but "other" future stuff done Smile

And, like it or not, when things go bad, everyone wants to know who's to blame. Life is a * and then you die.

Some ideas from the top of my head:
1.1) When creating a project based on a template, we should be able to identify what is a placement in time constraint for the project.
What I mean is, if you select a template project from the "Import Tasks from" combo on the Project Creation

Interface, you must provide only one of the dates, Start or Finish:
1.1.1) If Start, we are on ASAP (As Soon As Possible) mode, so the tasks will be positioned from the Start

date of the project onwards. Projects Target Finish date will be calculated.
After that you won't be able to edit the Start and Finish date. From there after Original Dates will only

change if you add more tasks to the Original Plan.
1.1.2) If Target Finish, we are on ALAP (As Late As Possible) mode, and the tasks will be placed in time from the Target Finish date backwards. Start date will be calculated, After that... blah blah blah.

Whether the Original plan is transparent to the user or not, I am still thinking about it.
What I mean is, we are not interested in the Original Plan for our daily work, we are only interested in the Original
Plan for our learning cycle.
So the Original Plan is nothing more than a photography of what we have designed for a given project considering our earlier experience, our ideal design if everything went perfectly.

So it is an immutable (during the course of the project) snapshot.
Imagine that you could have a button on the project view interface that would say:
"Take a Snapshot of this Project and consider it the Original Plan"
It may well be done that way, and once you click it the Original Dates (project and tasks) no longer can be changed.

2) We need the Forecast/Adjusted Plan.
This is the most important, it is this one that nuddernuby is most interested in.
This is where the PM will actually work, where he does is daily job of adjusting the Plan according to what is
really going on, on the course of the project, redefining the durations, dependencies and so on.
And here, the Durations are the rulers. A shift in duration will lead to task chain recalculation.
A change of the start or the end date only leads to recalculation if they stand first in the chain of dependencies.

3) We need to store the Real Plan
The Real Plan should be totally automatic and transparent to the User.
Therefore it should be totally based on the Task/Work logs.
What I mean is, the Tasks Real start date will be based date of the first log in time, the Tasks Real end date will be based on the last log in time. And then the Project Real start date will be based on the date of the first Real Task start date and so on.
The Tasks Real Duration will be based on the Sum of Work Duration logged for each Task.
Therefore totally automatic.
No freaking dependencies apply to Real Dates. (That will lead to some crazy Real dates Gantt Charts, that will be very interesting to watch and learn from).
Having or not having a Real Plan, will be each owns decision of using Task logs or not using Task logs.
(Though we may create an unobtrusive interface to let the users edit the Real Project, Real Task Dates and

Durations, something DHTML to show/hide it on the Tasks edit interface)

Cheers,

Pedro A.

pedroa

nuddernuby:

Sorry for not replying earlier, but whenever you say b**bs, my brain freezes...
That and the fact that we have a v1.1 coming up and some late bugs had to be dealt with.

It is nice to see here two people with some different perspectives and attitudes towards PM.

You want results and work on a ALAP/deadline model.
But don't forget the ASAP people kind Sir Smile

We need to come up with a solution for everyone, and there are people that, still, can afford not working against a deadline (thank God!).
I understand the benefits of designing on an ALAP mode, it has the immediate result of showing you that you are probaly not going to make it on time right away.
Or that you should have already started two months ago Very Happy

Now here is what I am thinking as far as Resource leveling is concerned:
We need Resource calendaring.
Each resource must have its own calendar, so that for any given date, and any given hour we have a percentage of assignment.
Picture it as the yearly calendar we have now (index.php?m=calendar&a=year_view&date=20090909), and some coloring going from green to red considering how unavailable a resource is for that day.
Then click on that day and you will be able to see which hours are green/yellow/red (available/half available/unavailable) for that resource.
For each hour you'd be able to see what the resource will be doing (task/event/holiday/maintenance....)
Assigning a user to a task would store on this calendar its usage, events would do the same.
There would be the need to define other absentism reasons like holidays, vacations, sickness....
This would help the PM balance the resources by giving him enough information to assign the resources.
Even if we don't get to an automatic way of leveling the resources, at least we give the PM tools to guide him in the process.

Then we need the dependencies working properly, considering the algorithms we discussed earlier.
I am afraid we will need them to satisfy the other users that work on an ASAP model.

Sorry if I am not discussing Task Chains integration points right now. Lets try to be good at doing the "basic" stuff first.
It will stay here for future reference and we can get back to it later.

Please try to put your ideas in a web2Project perspective, something like... "I'd love that it'd do this..." (this part you do very well) "... and in web2Project it would work if you'd made this here and then this there and so on and so forth" Smile

Thank you so much for all your input so far,

Cheers,

Pedro A.

antonvdberg

Hi Pedro,

1) We need to keep the Original Plan.

YUP - There are reasons why we would like to do this including reporting, measurement, learning and change management (doesn't matter now). As long as we keep it and it is "locked" (for now until we have progressed to the point where we can manipulate it again). – Sorted.

1.1) In its entirety

YUP - The photo idea sounds good as long as the data lives in some table somewhere (from the above; we may want to stuff with it again, but that later); should call the snapshot a baseline (but again more of that later).

2) Forecast/Adjusted Plan - I think we (me and nuddernuby) have agreed to some extent that this may not be required. (If we leave conditions under which we can manipulate the “original plan” - to be addressed later.)

3) This will initially be a copy of the “original plan” which can now allow addition of real resources. The schedule logic and dependencies would be in existence already as they would have been required to do the “original plan”. – (No freaking dependencies apply to Real Dates. (That will lead to some crazy Real dates Gantt Charts, that will be very interesting to watch and learn from)) err? Not so sure about that.

Otherwise totally automatic as stated.

On your second response:

We need Resource calendaring.

YUP - Availability on a daily basis - hourly (if a guy is booked for a meeting, the hours for the meeting not available for scheduling) daily start time, daily end time – that’s it. Non working days can then be managed as meetings or other projects where we simply run them as very important (would require unmovable date option for that).

Then we need the dependencies working properly, considering the algorithms we discussed earlier. I am afraid we will need them to satisfy the other users that work on an ASAP model.

As in 3 above, the logic is already in the “original plan”.

I would like to propose that we agree to stop it here first. If we can get the resource levelling working, then we get stuck into other areas?

Smile brothers, the suns shines on all of us..
Rolling Eyes

nuddernuby

Thanks, guys, for your good inputs here. If you will allow me I’d like to add one or two small comments:

Original plan:

Please keep a baseline by all means. I am not saying you should not keep the original – but I have seen in practice that some PM’s think that once they have drawn up a good plan their job is done and now they are good PM’s. I’m trying to push the pendulum over to the other side a bit, so that we all understand that the real value proposition of the software must lie in the execution performance. This is where you’ll make your mark.

Deadline: (Here we may have misunderstood one another.)

We should not confuse ALAP with deadlines. Use JIT if it helps. One of the remarkable developments in recent thinking has been to move away from deadlines as far as possible. I do not use deadlines at all, except for the two types of milestones mentioned before, and they will be preceded by buffers. If you have a good system (and that is what I believe w2p should become) then the system output will be a starting date for each task. IOW, the system tells John that he has to start working on this job ABC today. He GETS NO DEADLINE. He works at a reasonable rate and updates the remaining duration daily. From there the system takes over. (This works in all types of environments. Unfortunately, it’s a whole subject all on its own - not enough space here.)

ASAP/ALAP: (Here we may have misunderstood one another.)

Have BOTH. It should be the kind of thing the user simply toggles. In big networks we usually see 3 stages in network design:

1. The big white board or paper wall stage. The whole network is sketched out in rough – major brain storming with all involved – and lots of scratching.

2. The network is transferred to electronic medium. Here we use ASAP to establish the basic network, starting arbitrarily from today because we have little/no idea of total duration.
(We can also use programmes like Mindmanager to straddle steps 1 and 2).

3. Once total cycle time has been established, we can finalise, add buffers etc. Now we use ALAP (JIT), which is where we want to end up (as explained before).

Resource Calendaring:

Of course, but keep it as simple as possible.

General:

I expect that we’ll need to calibrate our terminology as we move forward – but we’ll sort that out step by step. Maybe, Pedro, it would be useful to understand exactly what you mean when you use the terms ‘Original’, ‘Forecast/adjusted’ and ‘Real’- and what their exact applied purpose would be.

Great sharing thoughts with you guys. Hope it doesn’t only stay there.

pedroa

nuddernuby

Thank you for the kind words and good luck with the launch!

pedroa

Keith is taking care of the launch and I am at the beach right now Cool

Cheers and Thanks,

Pedro A.

nuddernuby

Don't suppose I should be asking this but is there a firm launch date yet?

pedroa

Today/Tomorrow depending on your timezone.

Cheers,

Pedro A.