Please enable JavaScript.

Coggle requires JavaScript to display documents.

SU3: PROJECT PLANNING - Coggle Diagram

- - - - Basic Rules for Project Networks:
        
        Flow Direction – Networks usually go from left to right (timeline style).
        
        Dependencies – A task can only begin after its previous tasks are complete.
        
        Arrows – Show the order of tasks and how they depend on each other.
        
        Crossovers – Arrows may cross, but flow must remain logical.
        
        Unique ID – Each activity must have a unique number to avoid confusion.
        
        Sequence Rule – IDs should increase as tasks move forward (e.g., Task 1 before Task 2).
        
        No Loops – Activities can’t circle back to earlier ones (e.g., not A → B → A again).
        
        No Conditions – You cannot use "if/else" conditions in the diagram (e.g., “If approved, do X”).
        
        Multiple Starts – If several tasks start together, use a common starting point for clarity.
      - Activity :-on-Node Method:
        
        A way to draw project schedules where each activity (task) is shown as a box (node).
        The arrows between boxes show the order or dependency (what must be done first, and what comes after).
        
        Three Key Relationships:
        
        Predecessor activities → Tasks that must finish before another can start.
        
        Successor activities → Tasks that come immediately after another.
        
        Parallel activities → Tasks that can happen at the same time.
  - - - LF (Late Finish): Latest it can end.
      - Critical Path: The longest path where delays directly delay the project.
      - Slack/Float: Extra time a task can be delayed without affecting the project finish date.
      - LS (Late Start): Latest a task can begin.
    - - EF (Early Finish): Earliest it can end.
      - Project Finish: Found by following the longest path of tasks.
      - ES (Early Start): Earliest a task can begin.
- - - - Project Structure & Organization:
        The way the project is organized (Functional, matrix, projectized) influences time and costs.
      - Padding Estimates:
        Teams sometimes add "extra" time or cost as a safety net. This reduces risk but can make projects look longer/more expensive than they really are
      - People & Stakeholders:
        The quality of input depends on the people giving it. Different stakeholders can make estimates better or worst.
      - Organization Culture:
        Company culture shapes how people estimate (optimistic, pessimistic, cautious )
      - Project Duration & New Technology:
        Longer projects or projects with untested technology are harder to estimate and risk errors
      - Other Factors:
        External issues like:
        
        public holiday
        
        legal restrictions
        
        equipment downtime
        
        can also impact accuracy
      - Planning Horizon:
        The further into the future, the harder it is to estimate accurately. Near term estimates are more reliable
- - - - Function Point Methods:
        
        Common in software projects. Estimates based on number of features or functions
        
        Example: Each feature in an app (like login, search, payment) has a cost/time value; total adds up to the estimate
      - Learning Curves:
        
        Assume tasks get faster/cheaper as people gain experience
        
        Example: If it takes 10 hours to produce the first unit, by the 10th unit, it may take only 6 hours because the team improves
      - Apportion Methods:
        
        Break overall costs into percentages for different parts.
        
        Example: If the project budget is $1M, 40% may be allocated to design, 30% to construction, 20% to testing, 10% to training
      - Ratio Methods:
        
        Use ratios from past projects
        
        Example: If building a warehouse previously cost $1000 per square meter, then a new 500m2 warehouse will cost about $500000
      - Consensus Methods:
        
        Experts discuss and agree on an estimate
        
        Example: A group of managers agree that the building a new app should take about 6 months
    - - Parametric Procedures:
        
        Use formulas or equations to calculate estimates
        
        Examples: Cost = $100 x number of task. If 50 task, it will cost $5000
      - Template Methods:
        
        Use estimates from past similar projects as a template
        
        Example: If last year's website project took 4 months, use that as a base for this year's similar website
      - Range Estimating:
        
        Instead of one number, give a range (best case, worst case, most likely)
        
        Example: "This task will take 3-5 days, but most likely 4 days)."
    - - How it works:
        
        Start Broad (Macro Estimate) > At the beginning, you give an overall estimate
        
        Refine per Phase (Detailed Estimate) > When moving into a specific phase (like design or production), you break down into detailed estimates
        
        Repeat > As you complete each phase, you refine the estimates for the upcoming ones
        
        Example:
        At the start, you only know it might cost $2M and take 18 months. (Macro estimate)
        When you reach the Design Phase, you gather more info and refine: "Design = 3 months , $200K
        Then, in the Development Phase, you refine further: "Development = 9 months, $1.2M."
        By the time you reach Testing and Delivery, the numbers are much more precise.