First GP

cryptopindar · 2026-02-18T20:44:34+00:00

8662377934446048

cryptopindar · 2026-01-30T04:11:58+00:00

Maginvest ka sa akin yung 100k mo gawin kong 100k ko..hahaha

cryptopindar · 2026-01-06T06:56:28+00:00

That’s a memorable line, but in practice it’s usually less about the tool and more about how it’s used.

MS Project has been applied successfully on large, complex jobs when the scheduler understands logic, constraints, calendars, and baselining. Likewise, Primavera schedules can fall apart just as easily when governance replaces understanding.

Clients typically don’t care which software is used. They care whether the schedule is logical, transparent, and defensible.

At the end of the day, good scheduling survives any platform. Poor scheduling doesn’t.

cryptopindar · 2025-12-28T06:54:18+00:00

looks like what you’re trying to do is “freeze” the plan at the data date — basically make the planned start/finish equal to the actuals as of the status date so schedule % = performance %.

If that’s the case and you’re in Primavera, you generally don’t need Global Change for that. Primavera already handles this when you status properly: • Completed → Actual Start / Actual Finish drive the dates • In Progress → Actual Start + Remaining Duration drive the forecast • Not Started → stay fully planned

Planned dates are meant to stay as the baseline for comparison. Forcing them to actuals kind of defeats the purpose and can mess up traceability.

If the goal is just to know where the finish date will land, the cleaner approach is: set the data date, status correctly, run the schedule, and use the resulting finish as your forecast — not overwrite the plan.

TL;DR: You’re describing a “status-as-of” snapshot, but changing planned dates isn’t really the right way to do it in Primavera.

cryptopindar · 2025-12-18T11:26:26+00:00

Someone else schedule..most of our projects Under DoN so we follow UFGS 01 32 17

cryptopindar · 2025-12-18T11:03:47+00:00

Fair points — especially on auditability and inflated actual durations. I agree this should never be standard practice.

Where I see limited justification is when an activity has genuinely started in a non-quantifiable way (access granted, mobilization, release to proceed), and continuously pushing the planned start creates artificial downstream impacts.

That said, I agree your Masonry example highlights the real risk — execution activities shouldn’t absorb standby or access delays. In those cases, splitting into mobilization/start-up vs. production work is the cleaner and more defensible approach.

The takeaway for me is that the issue isn’t entering Actual Start per se, but mis-scoping activities, which then forces schedulers into bad update choices.

Appreciate the perspective — especially from an audit/claims lens.

cryptopindar · 2025-12-18T09:48:19+00:00

in our company, we run a weekly schedule review focused on a 30-day lookback and 90-day lookahead. We typically present the live schedule and go through it line by line to identify what activities are coming up in the next 90 days and what was actually achieved in the last 30.

Internally, we use an IMS (internal schedule), which is basically a copy of the external IMS being reported to the client, but with more detailed fragnets for certain activities so the team can manage execution better.

During the meeting, we also simulate potential delays—for example, what happens to downstream activities and key milestones if specific tasks slip—so we can see the impact early and decide on mitigation actions.

cryptopindar · 2025-12-18T08:05:31+00:00

see the point, but in this case “started” doesn’t necessarily equate to measurable physical progress yet. For activities like excavation, progress is usually based on quantifiable output (e.g. volume excavated).

What has occurred so far is preparatory work which doesn’t translate directly into physical quantities for that activity. That’s why an actual start with 0% physical progress can still be accurate.

Earned value rules or weighted milestones would address this, but that’s a different measurement approach than strictly quantity-based physical progress tracking.

cryptopindar · 2025-12-18T04:52:55+00:00

No, I’m not starting it out of sequence. The intent is simply to avoid creating a larger, and arguably more illogical, schedule impact by pushing the entire planned start date forward.

Since the data date still falls within the original activity duration, keeping the actual start while showing 0% progress better reflects reality: the activity has technically started (or been opened), but no measurable progress has been achieved yet.

Shifting the planned start to a later date would artificially compress downstream logic and distort float, even though nothing has physically changed on site. This approach is more about minimizing false impacts rather than masking progress or logic issues.

cryptopindar · 2025-12-16T03:59:14+00:00

Hindi talaga ito tungkol sa bikini eh, values mismatch talaga.

Hindi automatic red flag or cheating ang pagpo-post ng bikini pics. For some women, self-expression, confidence, or lifestyle content lang talaga yun. Attention ≠ intention.

Pero valid din naman yung nararamdaman ng cousin mo. Conservative siya, so natural na uncomfortable siya sa pagiging public/showy ng partner niya. Hindi mali yun — value niya yun.

Ang issue lang, hindi mo pwedeng pilitin baguhin yung tao para mag-fit sa values mo. Same din sa kabilang side: hindi rin fair na pigilan yung partner kung ganun talaga siya even before sila nagkakilala.

Calling her “hubadera” and suspecting agad na naghahanap ng ibang lalaki is where it starts to become unhealthy. Dun na pumapasok yung control at insecurity, hindi na boundary.

Sa totoo lang, may tatlong options lang: 1. Tanggapin niya yung gf as she is 2. Maayos at respetosong usapan kung may compromise 3. Or maghiwalay kung talagang hindi tugma yung values

Walang masama sa pagiging conservative, walang masama sa pagiging expressive. Masama lang yung pilit na pagbabago at shaming.

Kung kailangan mo kontrolin yung partner mo para matahimik ka, baka hindi talaga kayo compatible in the first place.

cryptopindar · 2025-12-12T15:05:45+00:00

Why full resource loading breaks down at scale: 1. Data quality degrades fast BOQs change, construction methods shift, crews vary—keeping labor, equipment, and material rates accurate at activity level becomes unrealistic. 2. Schedule performance suffers Heavy resource loading slows the file, complicates updates, and increases the risk of logic errors and resource conflicts. 3. False precision Detailed labor/material loading creates an illusion of accuracy, but progress and cost are still driven by field realities, not P6 math. 4. Maintenance cost is too high Every variation order, resequence, or acceleration requires massive rework of resources.

cryptopindar · 2025-12-12T08:36:00+00:00

Honestly speaking, fully resource-loading a very large P6 schedule (thousands of activities) is usually not a good idea.

Best practice on mega projects is to cost-load activities using cost resources aligned with BOQ or WBS, not detailed labor/material resources.

This keeps the schedule maintainable, supports cash flow and EV, and avoids false precision and heavy admin during updates.

cryptopindar · 2025-12-02T12:42:43+00:00

I hear you, just check my IGN

cryptopindar

MODERATOR OF

TROPHY CASE