Historical Data of Projects

Major Quantities: (Piping ID, Concrete M3, Structural Steels TON, Electrical M)

Project Location (country)

Planned Period of Completion (number of months)

Actual Completion Period (number of months)

Planned Manhours

Actual Manhours

Contracted Quantities

Actual Quantities

Risks/Delay Events

Hello Friends,

- Project Deliverables - Understand and compare the scope of project and any key deliverable that you missed in your prior projects.

-Activity Duration - Actual duration vs forecast, this will come really handy, if you have prior knowledge about activities duration and sequencing.

-Man power productivity & Critical  Procurement delivery 

- Project planning and cost allocation based on expectation of commercial department.

- Contractor performance review of previos project is very useful.

- Risk register of previous project is vital to avoid delay and securing company from past mistakes.

Hope it helps!

Regards,

Rahul Sharma

Anoon,

I have other experience. We have many clients that use Reference-books (databases of project parameters like resource productivity on typical activities, material requirements per volume unit on typical activities, etc.) and Fragment libraries for many years. Today an ability to learn from the past and adjust future schedules accordingly is called Artificial Intelligence though I don't see anything artificial in this natural feature.

Automatic resource leveling is based on the data entered by people. And so it cannot determine if activity dependencies are right. Network analysis may show activities that do not have predecessors or successore but not wrong or missed dependencies. Fragment libraries help a lot but still people shall enter dependencies between activities of different fragments and so the errors may happen. Resource leveling itself is easy, finding the best way of schedule crashing and optimal set of project resources may require skills and experience.

Vladimir, yes, we should learn from our errors. That's why perhaps project owners just simply change contractors (without knowing that the new contractor might commit exactly the same mistakes or even worse). And unlucky contractors just perhaps go bankrupt and never got any chance to learn from their mistakes. It's just a cycle (survival of the fittest), as projects are just one time endeavors. Old ones were just changed with new ones who uses exactly the same principles of "Short-cuts". That's why perhaps the eternal existence of "out-of-sequence activities", as new schedules were just simply copied from historical data of old flawed schedules, and the same mistakes were exactly repeated all over again. "Best Practices" seems never exist. Is it because "Fragments Library" is missing? And "resource leveling" remains a nightmare for schedulers? By the way, automatic resource leveling can never resolve out of sequence activities.

Anoon,

out of sequence events show what was missed in the past schedule and so shall be considered when the new schedules are created,

resource productivity on typical activities that are met in other projects may be used in new schedules,

risk events happened in the past shall be considered when the list of other project risks is created, etc.

We shall learn from our errors and past experience.

The only useful data are: As-built Drawings (even thieves shall be interested for it); Operating Manuals / Instructions. Schedules? Who cares about what you did in the past, and how many out-of-sequence activities you have rectified? And besides, scope, rates, schedules, costs, always varies from projects to projects. So why keep records of variables? New project simply means new risks, which shall need new strategies.

Mike,

it is always done automatically by Spider Project that keeps the whole history of project development creating and storing new project versions with each update. Each version includes Performance Archive that keeps the records of all entered actual data.

And so the user can open project version for any past date, compare it with versions for any other date and create reports on the history of changes for any project parameter (we call this trends).

Hi Benjamin

The As Built record should be a database of all the programme tasks with the information Who did What When and Where set down on a spreadsheet - in columns - on a weekly basis.

It never happens of course but it should be aimed for.

Best regards

Mike Testro

Resource productivity on typical activities

Risk events and their impacts

Out of sequence events and their reasons

planned durations vs actual durations so that you can start to build a historical database of durations for typical activities. 

Risks, that is, events that occurred that had not been considered when preparing initial estimates.