Project management and scope: function points, timeboxing, WBS

Once feasibility in the planning phase says “let’s do it”, the project manager steps in. Their question: “How big is this job, how many people, how many months?” The exam heart of this week is the function point calculation: count the components, weight them, correct for complexity, and convert to lines of code, effort and schedule. Alongside come the definitions of scope creep, timeboxing and WBS.

Golden rules:

1. The size, time, cost triangle. If one changes, at least one other changes.
2. Function points in four steps: TUFP → APC → AFP → effort and schedule.
3. Memorize the weight table, or if it is given on the exam, use the right row.
4. Scope changes in writing. A change request comes as a document, and its impact is calculated.

What is project management?

Project management is the work of planning, organizing, monitoring and controlling in order to deliver the system at the desired time, budget and quality. The project manager’s four main jobs:

1. Estimating project size (size, effort, time).
2. Creating the work plan (tasks, durations, dependencies).
3. Making the staffing plan (how many people, which roles, reporting structure, motivation).
4. Coordinating and controlling the project (CASE tools, standards, documentation, risk management, scope management).

These four jobs are done by balancing size, time and cost. If the boss says “we want the system in 3 months”, the project manager has to propose either narrowing the scope or enlarging the budget.

Estimation method 1: industry standards

The simplest method: look at what percentage of the total effort the phases took in similar projects. A commonly used ratio table:

When planning is finished you know the actual planning effort, and you estimate the rest by the ratios. If planning took 3 person-months, the total is 3 / 0.15 = 20 person-months: analysis 4, design 7, implementation 6. A quick but rough method.

Estimation method 2: function points

Function points measure the size of the system from the functions the user sees, not from lines of code. It is independent of the programming language.

Five components

EI, EO, EQ are transactions; ILF and EIF are files (data groups).

PITFALL · EO versus EQ. Both show data to the user. The difference: an EO contains a calculation (total, average, report). An EQ only retrieves stored data. “Show order status” is an EQ, “monthly revenue report” is an EO.

Weights

Each component is counted at low, average or high complexity:

Steps

1. TUFP (total unadjusted function points): in each cell count × weight, add them all up.
2. PC (processing complexity): rate the 14 general system characteristics (data communications, distributed processing, performance, online data entry, ease of use, reusability, etc.) from 0 to 5 and add them. PC is between 0 and 70.
3. APC (adjusted processing complexity): $APC = 0.65 + 0.01 \times PC$.
4. AFP (adjusted function points): $AFP = TUFP \times APC$.
5. LOC: AFP × the language-specific “lines per function point”.
6. Effort (person-months): $\text{effort} = 1.4 \times \text{KLOC}$ (KLOC = thousand lines).
7. Schedule (months): $\text{schedule} = 3.0 \times \text{effort}^{1/3}$.

Worked example: CampusEats

An app for ordering from cafeterias inside the university. The analyst produced these counts:

Step 1: TUFP.

EI : 6x3 + 4x4 + 2x6   = 18+16+12 = 46
EO : 3x4 + 2x5 + 1x7   = 12+10+7  = 29
EQ : 4x3 + 2x4 + 0x6   = 12+8+0   = 20
ILF: 2x7 + 3x10 + 1x15 = 14+30+15 = 59
EIF: 1x5 + 1x7 + 0x10  = 5+7+0    = 12
                          TUFP    = 166

Steps 2-3: APC. The scores of the 14 factors were added: PC = 32.

APC = 0.65 + 0.01 x 32 = 0.97

Step 4: AFP.

AFP = 166 x 0.97 = 161.02

Step 5: LOC. The app will be written in Java, and the team measured 60 lines per function point in past projects:

LOC = 161.02 x 60 = 9,661 lines  (9.661 KLOC)

Step 6: Effort.

effort = 1.4 x 9.661 = 13.53 person-months

Step 7: Schedule and team.

schedule = 3.0 x 13.53^(1/3) = 3.0 x 2.383 = 7.15 months
team ≈ 13.53 / 7.15 = 1.89 → about 2 people

Interpretation: a team of 2 would finish this app in about 7 months. If management wants 4 months, the project manager proposes narrowing the scope (for example leaving the EIF, that is the external payment integration, to a later version) or timeboxing. Just adding people does not shorten the time proportionally.

TIP · cube root. On a calculator, type x ^ (1/3) for $x^{1/3}$. If you forget the parentheses, x^1 / 3 is computed.

Work plan and WBS

The work plan is a dynamic schedule that shows all the tasks of the project, their durations, owners and dependencies. Its basis is the work breakdown structure (WBS): dividing the project hierarchically into small tasks.

1 CampusEats
  1.1 Planning
      1.1.1 System request
      1.1.2 Feasibility
  1.2 Analysis
      1.2.1 Cafeteria interviews
      1.2.2 Use case model
  1.3 Design
      1.3.1 Database design
      1.3.2 Interface sketches
  1.4 Implementation
      1.4.1 Coding
      1.4.2 Testing

A WBS can be built in two ways: by SDLC phases (as above) or by products (order module, payment module, reporting module). For each lowest-level task: duration estimate, responsible person, dependencies, deliverable. If a task takes longer than a reporting period, it is split further. After the WBS, the schedule is drawn with tools like Gantt and PERT (week 4).

Scope management

Scope creep

Scope creep is the unplanned growth of requirements after the project has started. The sentence “what if we add this too, it’s a small thing” is the most dangerous sentence. A feature added during design or coding is many times more expensive than one added during analysis.

Ways to control it:

• Gather requirements early and completely (JAD, prototype).
• Put the requirements in writing and get them approved.
• Accept changes with a change request: who asked, why, the impact on time and cost, approval.
• Postpone unapproved or low-priority requests to the next version.

Timeboxing

In timeboxing the delivery date is fixed, and functionality is made flexible:

1. Set the delivery date and freeze it.
2. Prioritize the requirements.
3. Build the most important core features.
4. When the date comes, deliver whatever is finished (without compromising quality).
5. Move the remaining features to the next “timebox”.

The sprint in agile is also a timebox.

Team and risk

Staffing plan: Dividing effort by schedule gives the average team size. As the team grows, communication channels increase as $n(n-1)/2$: 6 channels with 4 people, 28 with 8. That is why large teams are split into subgroups and a reporting structure is set up.

Risk assessment: For each risk, a probability, an impact and a mitigation plan are written. Example: “The payment provider’s API may change; probability medium, impact high; write an adapter layer.”

Standards and documentation: Documentation standards, coding standards and change request forms keep the project consistent. The project binder stores all the deliverables.

Common mistakes