Click a heading to collapse it, and use that

Every topic heading folds. That is not just tidying: it is the retrieval tool.

1. First pass, everything open. Read the chapter as prose, in order, including the untagged cards. Do not take notes. Just read.
2. Second pass, hit “Collapse every topic” in the sidebar. The chapter becomes a list of bare headings. Go down it and say the answer out loud, or on paper, before you open the card. The gap between what you produced and what is inside is your real revision list.
3. Third pass, examinable only. Now the untagged material is gone and you are drilling the cards that carry marks.

What each card is showing stays remembered, so a half folded chapter is still half folded tomorrow.

The recall prompts are the spacing, and they are deliberately awkward

Scattered through the chapters you will find dashed boxes like the one below. Each one asks about something from an EARLIER chapter, not the one you are reading, which is the interleaving. The answer is hidden until you ask for it, because reading an answer is not retrieval and does almost nothing for memory.

Answer it before you open it, even when you are sure. Being sure and being right are different, and the whole value is in finding out which one you are.

Where mnemonics are used, and where they are not

Some answers must come out word for word: the nine knowledge areas, the five process groups, the four scorecard perspectives, the response strategies for risk. You cannot paraphrase a list and expect the mark. Those get a mnemonic card.

• Ordered lists get a sentence or a letter string, because both preserve sequence. Unordered lists get a single pronounceable word, which is faster to retrieve.
• Rude, absurd or Nepali flavoured beats tidy. Unusual material is remembered better than ordinary material, so the mnemonics here are chosen to be slightly ridiculous rather than elegant. That is the point, not a lapse of taste.
• Every mnemonic card shows what it stands for and why it is shaped that way, so if one does not stick you can build your own on the same skeleton.

Mnemonics are for the exact lists only. For everything else, understanding the mechanism beats memorising a string, and the examiner can tell the difference.

Numericals: how they are worked here

Every numerical in this guide was computed by a program first, then written up. Nothing was solved in prose and hoped over.

• Each worked example names its source paper, so you know it is a real question and not an invented one.
• The method is separated from the arithmetic. The method is what earns marks even when a number goes wrong, so the steps are written to be copied under exam pressure.
• Where a question is genuinely ambiguous, it says so and states the assumption it makes. Several past questions omit a value they then ask you to use. Writing “assuming BAC is X because Y” is a correct answer to a broken question.
• They are gathered in one place as well. The numericals page lists all 39, the formula sheet first, with each solution closed until you ask for it, so it can be worked through as a practice sheet.

Sources, and one warning about the question paper file

• Notes: the complete ICT Project Management notes by Prabin Gautam, 187 pages, plus the merged course slide set.
• Questions: 23 scanned papers. The scans have no usable text layer, so every page was read and transcribed by hand. Question wording here is verbatim, including the occasional typo in the original, because recognising the exact phrasing is worth marks.
• One paper in that file is not your subject. The 2070 Ashad paper on CE 701 Project Engineering is for BCE, BEL and B.Agri. Its questions on EPS, book value and capital structure planning are not on the CT 701 syllabus. It is kept in the bank, clearly marked, so you are not thrown if you meet it in a shared drive.

These are revision notes, not the official course. Copyright in the original notes and papers rests with their authors. Any error in the writing up is mine.

The nine characteristics of a project asked 6×

A characteristic is a feature every project has. Read each as an answer to “how would I recognise a project?”

1. Specific objective: clearly defined; the project succeeds when it is achieved.
2. Temporary (life span): cannot continue endlessly; has a birth and a death.
3. Unique: no two projects are exactly alike.
4. Non-routine and non-repetitive: not the day-to-day work of the organisation.
5. Planning and control: an effective planning and control system for efficient completion.
6. Resource integration: the four M's, man, machine, money and minutes (or materials), integrated for efficient use.
7. Flexibility: risk and change are unavoidable, so it must absorb them.
8. Constraints: works within the limits of time, cost and quality.
9. Team work: a manager leads a team to the goal.

The slides add

• Unique requirements delivered within the project's boundaries.
• Its own resources and budget.
• Progressively elaborated: detail is added step by step as understanding grows.
• For a customer.
• Cross-functional: often draws people from several departments or organisations.

Project versus operational work asked 6×

• Operational work: the ongoing execution of activities after a product exists, producing the same result or service again and again (a bank's daily transactions, a production line, a helpdesk).
• Project: the one-off effort that creates something new; operations then take it over.
• Also asked as “project versus process”: the notes call the management of operations business process management.

Project objectives and SMART asked 1×

• No objective, no project: defining it is the first step in a project's life.
• The end: a project ends when its objective is achieved.
• What a good objective does: confirms the right target, builds team commitment, involves every interested party.

How to define objectives (notes)

• Uniquely and specifically.
• Focus the team on what the project is about.
• Create commitment and agreement in the team.
• Involve all interested parties.

SMART: the test for an objective

• Specific: clearly defined, not ambiguous; answers what, why, when, who, where.
• Measurable: has metrics: how much, how many, how will I know it is done?
• Achievable: within the team's skill and ability, agreed by all members.
• Realistic (slides: relevant): fits the resources, experience, knowledge and time, and the organisation's long-term plan.
• Time bound: a stated deadline; without one it will not be completed.

• Your own final year project, all nine characteristics and all five SMART tests worked out: end of this chapter.

Nine bases of classification asked 1×

• Why classify: it tells a manager what organisation, funding, speed and risk to expect.
• How to read the table: each basis is a question about a project; the categories are its possible answers.

• Crash project: run at maximum speed, paying extra to finish sooner (like crashing in chapter 8).
• Disaster project: responds to an emergency, such as earthquake reconstruction.
• Mutually exclusive: alternatives; choosing one rules out the other.

The slides' shorter classification

• Objectives: social development, economic growth.
• Sectors: agriculture, public health, IT, private, government.
• Number of key purposes: single, multi.
• Relationship: independent, mutually exclusive.
• Nature: emergency, fixed budget, fixed time.

IT projects: types, how they are built, and their challenges asked 5×

The four types of IT project (notes and slides)

1. System integration: brings diverse ICT products and services together into one working system. Example: a nationwide WAN.
2. Facilities management: takes full responsibility for establishing and operating the customer's IT facility without taking ownership. Example: an automated security and disaster control centre.
3. Software application development: building software. Example: an ERP application.
4. Services consulting: a specific consulting service, which may or may not end in a product. Example: ICT training and counselling.

How IT system development proceeds (notes 1.10)

• Communication: requirement analysis, feasibility analysis, proposal.
• Planning: scheduling, cost estimation, quality, change and risk management.
• Modelling: analysis and design.
• Construction: coding and testing.
• Deployment: maintenance and feedback.

Challenges in IT projects, with the slides' remedies

Why projects fail (slides, chapter 3 section)

• Improper requirement analysis.
• Poor project management.
• Lack of executive level support.
• No linkage to business strategy.
• Wrong team members.
• No measures to evaluate project success.
• No risk management.
• Inability to adapt to change.
• Lack of control and visibility.
• The key reason for IT project failure (notes p. 81): poor project scope management. Good scope management is the foundation of success (chapter 7).

The same causes as surveys of IT projects report them (the Standish Group's CHAOS reports), useful to widen the answer

• Users: lack of user involvement.
• Requirements: incomplete or unclear, then changing, with scope creep.
• Support: lack of top management support.
• Expectations: unrealistic time frames and budgets.
• People and resources: too few, unskilled, or leaving.
• Planning: poor planning and estimation; unclear objectives.
• Technology: new or immature technology.
• Communication and risk: poor communication; no risk management or methodology.
• Nepal adds: brain drain mid-project, unreliable power and connectivity, procurement delays, shifting government priorities.

What makes IT projects different

• Diverse in size, kind and technology.
• Mixed teams: hardware, software, networks, databases, business analysis.
• Fast-changing technology.
• Intangible product: progress is hard to see.
• Moving requirements and a high failure rate.
• Full lists (IT attributes, why IT PM is necessary): end of this chapter.

The project life cycle, phase by phase asked 7×

The four phases in the notes (the “project development life cycle”)

1. Formulation: identify the idea and set evaluation criteria.
   • Project identification: creative ideas from the environment and from internal and external resources.
   • Project evaluation: identify constraints; fix the objective; develop the proposal after a pre-feasibility study and prototype design.
2. Planning: a detailed plan with time, cost and quality.
   • Feasibility study: technical, economic, market, management and environmental analysis.
   • Appraisal and estimation: judge the chance of success; compare with similar projects; develop the requirements and implementation plan.
3. Implementation: activities carried out and controlled.
   • A proper team is formed; the PM monitors and supervises.
   • Inspection and testing from time to time; progress reviewed regularly.
4. Termination: the work is complete; the project is evaluated and handed over.
   • Operation and evaluation: review the outcome and results; return to an earlier phase if required.
   • Handover: to the client; resources released; success evaluated.

The same life in PMI's words (slides): initiation, planning, execution, closure, with monitoring and controlling running through

• Same life, two vocabularies: formulation = initiation; implementation = execution with monitoring and control; termination = closure.
• Planning takes about half the effort, and never fully stops: revise the plan until the work is done.

Effort over the life cycle

• Shape: low in initiation, rising through planning, peak in execution, falling fast at closure.
• Draw it: effort or cost up the side, time along the bottom: one hump skewed right.
• Add: risk and uncertainty highest at the start; the cost of change rising steeply.

Why understanding the phases makes management effective (2082 Baishakh)

• Gates: each phase ends in a deliverable and a go or no-go decision, so failure is caught early.
• Staffing: effort can be planned for the execution peak.
• Early planning pays: changes are cheapest early.
• Early risk work: uncertainty is highest at the start.

The feasibility study asked 4×

The four types in the notes

1. Technical: are the hardware, software and technology enough? Does the team have the skills?
2. Economic: cost and benefit analysis; will it pay off financially?
3. Operational: does it meet the service requirements; how easy to operate and maintain?
4. Legal: is it lawful? Data protection, copyright, licences.

• A fifth, from textbooks: schedule: can it be delivered in the time available?

Areas of feasibility analysis (slides)

• Market: potential market and market share.
• Technical: technical viability and a rational choice of technology.
• Financial: financial risk and economic return.
• Socio-economic: costs and benefits in shadow prices; economic and social impact.
• Ecological: environmental damage and restoration measures.

How a feasibility study is performed (notes' diagram)

1. Generate project ideas.
2. Initial evaluation: is the idea promising? If not, stop.
3. Plan an in-depth study.
4. Market analysis and technical analysis.
5. Financial analysis.
6. Economic and ecological analysis.
7. Second gate: is it worthwhile? If not, terminate; if yes, prepare the funding proposal.

• In an IT project: the technical analysis covers platform, architecture and team skills; the financial analysis covers development, licence, hosting and maintenance cost against the benefit.

Key benefits of a feasibility study (slides)

• Focus: improves the team's focus.
• Opportunities: identifies new ones.
• Go or no-go: gives valuable information for the decision.
• Alternatives: narrows the business alternatives.
• Reason: identifies a valid reason to undertake the project.
• Success rate: raised by evaluating many parameters.
• Decisions: aids decision making on the project.
• Stop signals: identifies reasons not to proceed.

Its role in the successful completion of a project

• Stops money going into something that cannot work.
• Sets realistic cost and time expectations before the budget is fixed.
• Exposes technical, legal and market obstacles while they are cheap to solve.
• Gives the sponsor evidence for the go or no-go decision.
• In one line: it is the cheapest place to kill a bad project.

The project proposal asked 2×

The seven key elements (notes)

1. Reasons for the proposal: the problem or opportunity.
2. Project planning matrix: goal, purpose, inputs and outputs.
3. Solution of the problem.
4. Implementation plan: estimates, cost benefit analysis, resources, schedule, risk and contingency plan, milestones, deliverables.
5. Plan for technical and administrative support.
6. Budget or financial plan.
7. Relevant past experience: why this team can deliver.

• Technical and financial proposals: large bids split into what will be done and what it will cost: end of this chapter.

What is unique to project management, and the five areas of expertise asked 3×

Some of PMBOK belongs to project management alone; some is shared with other management.

• Unique to project management: tools such as the critical path method (CPM), PERT and the work breakdown structure (WBS).
• Shared with general management: planning, organising, staffing, coordinating, leading and controlling an organisation's operations.
• Shared techniques: financial forecasting, organisational behaviour, planning.

The five areas of expertise PMI says a project team needs, with the manager where they overlap

1. The PMBOK Guide: process groups, knowledge areas and project tools.
2. Application area knowledge, standards and regulations: the field the project is in (software, construction, banking), its standards and the laws that apply.
3. Understanding the project environment: cultural, social, political and physical setting.
4. General management knowledge and skills: planning, organising, staffing, controlling, finance, procurement.
5. Interpersonal skills: communication, influence, leadership, motivation, negotiation, problem solving.

The project environment: internal, task and external asked 7×

• How the environment acts on a project: through complexity, uncertainty, competition for resources, the need for flexibility, and rapid technological change.
• Three layers: internal, task (operating), external; control falls as you move outward.

1. Internal environment: inside the organisation, under its control, giving the project its strengths and weaknesses

• Project objectives: the desired end results; work stays within them, and the project ends when they are met.
• Constraints: time, cost and quality, which set the scope and boundaries.
• Structure: the project is temporary and works within its structure.
• Resources: human and non-human, usually with its own budget.

How it affects the project in practice:

• Staff: even capable people fail when politics and internal conflict take over.
• Budget: limited cash restricts hiring, equipment and spending; money gives flexibility.
• Corporate culture: the values staff follow; cooperation builds, internal competition turns toxic.

2. Task environment (the slides: operating environment): the stakeholders the project deals with directly

• Who: client, contractors, consultants, suppliers, government, competitors, financiers, media.
• Key feature: their interests and impacts are interrelated; each can help or hinder, depending on how the project affects them.
• Control: can be influenced, not controlled.

3. External environment: outside the organisation, beyond its control, but able to force internal change

• Economy: inflation, interest, unemployment and exchange rates; a bad economy can sink a well-run organisation.
• Competition: every organisation except a monopoly fights for market share.
• Politics: government policy, taxes, laws and stability.
  • Notes' example: since the 1950s, tobacco companies have had to print warnings, lost television advertising and faced smoking bans, and their market has shrunk.
• Customers and suppliers: a supplier's power comes from how unique its goods are; a customer's power, from being free to choose a competitor.
• The slides' grouping: economic, political, socio-cultural, technological.
• What to do: monitor it continuously and adapt; ignoring it is a damaging mistake.

How the external environment influences an ICT project in Nepal

• Economic: exchange rate and import duty raise hardware and licence costs mid-project.
• Political and legal: ICT policy, the Electronic Transactions Act and data rules change requirements; instability delays approvals.
• Socio-cultural: users' language, literacy and trust in digital services decide adoption.
• Technological: a platform can go obsolete before launch; power and bandwidth shape the design.
• Market: a competitor launches first, or a vendor with a unique product holds the price.

• PMBOK's related terms (chapter 4): enterprise environmental factors, the conditions a project cannot control, and organisational process assets, the processes and knowledge the organisation already has.

Solving problems with problem trees asked 1×

• Why use it: the team sees at a glance how many complex issues feed one problem, and how that problem branches into effects.
• How it is arranged: causes and consequences in order of hierarchy: roots below, effects above.

Steps for developing a problem tree (notes)

1. Identify the major problems within the stated problem area.
2. Analyse their interrelationships, and pick the core problem.
3. Write the causes of the major problems.
4. Write the effects of the core problem.
5. Draw the tree: causes, problems, effects.
6. Review it for validity and completeness; repeat from step 2 if needed.

• Brainstorming supplies the ideas: a method of generating ideas and sharing knowledge to solve a problem, with participants encouraged to think without interruption.

The schematic

The example in the notes

Applied to a project management issue: an IT project keeps missing deadlines

• Core problem: late deliveries.
• Major problems: rework after testing; idle time waiting for decisions.
• Causes: unclear requirements; an absent sponsor.
• Contributing factors: no requirement sign-off; no escalation procedure.
• Effects: penalty payments; an unhappy client.
• Lesson: longer hours treat a symptom; requirement sign-off attacks a root.

General management skills, and project management versus general management asked 2×

A project manager is first a manager, so the classic functions of general management apply.

The eight general management skills (notes)

1. Planning: deciding in advance what to do. Its steps:
   • Determine the objectives; set planning premises and constraints; decide the planning period.
   • Collect, classify and process information; list alternative courses of action.
   • Evaluate the alternatives and select the best plan.
   • Prepare supporting plans for the master plan, and plans for controlling it.
2. Organising: arranging work, people and resources into a structure.
3. Staffing: filling positions with the right people, and developing them.
4. Directing: guiding and instructing people in the work.
5. Motivating: creating the will to perform well.
6. Controlling: measuring performance against the plan and correcting deviations.
7. Coordinating: making separate parts work together.
8. Communicating: passing information so everyone understands and acts.

• The slides' shorter list: planning, organising, staffing, executing, controlling.

Project management versus general management (notes)

The project manager: role, and effective versus ineffective managers asked 4×

The role of the project manager (notes and slides)

• Responsibility: overall responsibility for project success; keeps perspective on the whole.
• Planning: develops and maintains the detailed plan; delivers on time against it.
• Scope and progress: manages the scope; monitors progress and performance.
• Coordination: coordinates partners and working groups; resolves cross-functional issues.
• People: recruits project staff; manages resource use and performance.
• Issues: records and manages project issues.
• Standards: sets and maintains the project's standards and policies.
• Stakeholders: builds a win-win situation for everyone.
• Who fills it: a senior manager or a general manager.

Effective and ineffective project managers (notes and slides)

How to be an effective IT project manager: the left column, plus what IT demands

• Technical understanding: enough to judge estimates and risks, and earn respect.
• Bridging: translate between technical staff and business users.
• Scope and change control: IT requirements keep moving.
• Visible tracking: make progress on an intangible product measurable.
• Early risk work: security, integration, technology choices.
• Tools: scheduling software, version control, issue trackers.

The project management office (PMO)

• A successful PMO combines good people, processes and tasks.
• PMI's view: the PMO is a major catalyst for organisational excellence.

Benefits of a PMO (notes)

• Strategic planning and governance.
• Best practices and processes.
• A common language and culture.
• Resource management.
• Project artefacts and tool set, created and maintained.

Types of PMO (notes)

• By organisational exposure: enterprise PMO; organisational (departmental) PMO; special-purpose PMO.
• Functional PMO: serves one functional area, such as information systems; main goal is resource management; may or may not manage projects.
• Corporate (strategic) PMO: serves the whole company on corporate and strategic issues; manages projects only for cost reduction.
• Customer group PMO: clusters common customers or projects for better customer management; acts like a company within a company, with permanent project managers.

The thirteen functions of a PMO (notes)

1. Standardises estimating, planning, scheduling, controlling and reporting.
2. Simplifies project management roles and responsibilities.
3. Develops project management templates and methodology.
4. Improves the methodology: recommends and implements changes.
5. Identifies standards of project management.
6. Identifies best practices.
7. Strategic planning for project management.
8. Training: coordinates or runs project management training.
9. Knowledge transfer through coaching and mentoring.
10. Assesses risks in projects.
11. Plans disaster recovery for projects.
12. Portfolio management: performs or takes part in it.
13. Guards the organisation's project management intellectual property.

What it owns

What it does

Drivers and inhibitors of project success asked 5×

• Drivers (enablers): the conditions that push a project towards success.
• Inhibitors: the conditions that slow it down or sink it. Most are a driver turned upside down.

The eleven drivers of project success (notes and slides)

1. Top management support.
2. Clear goals and objectives.
3. Client support.
4. Realistic plan.
5. Appropriate resources: the four M's: man, machine, material, money.
6. Ownership.
7. Formal methodology.
8. Hard-working, focused staff.
9. Standard and structured ICT support infrastructure.
10. Effective communication.
11. Experienced project manager.

The inhibitors of project success (notes, with the slides' additions)

• Communication and leadership: poor communication; lack of leadership; lack of teamwork.
• Goals: unclear expectations; conflicting objectives; changing business strategies.
• Planning and analysis: poor up-front planning; poor feasibility study; poor requirement analysis.
• Support: poor top management (executive) support; an inbuilt negative attitude towards IT.
• Resources: inadequate resources; financial limitations; lack of historical data.

Drivers and inhibitors side by side

• Use the four M's wherever “appropriate resources” appears: four concrete words score better than one vague one.

Success criteria for projects, and obstacles asked 2×

• Success criteria: the measures by which a project is judged a success. The notes split them into two families.

Obstacles to project success (notes)

• Planning: poor project planning and direction.
• Communication: insufficient communication.
• Management systems: no change, risk, financial or performance management.
• Stakeholders: failure to coordinate with them.
• Management: ineffective involvement of management.
• People: lack of skilled team members.
• Tools: poor or missing technology and tools.

Project management, and why it pays

The ten advantages of project management (notes p. 34, slide 53)

• Resources and money: increased control of financial, physical and human resources; increased profit margins; lower costs.
• Output and customer: higher quality outcome; enhanced reliability of solutions; improved customer relations.
• People and work: improved productivity at work; better internal coordination; higher work morale.
• Time: shorter development time.

Every advantage is something going up (control, quality, reliability, customer relations, profit, productivity, coordination, morale) or down (development time, cost). Recall them by the four groups above.

Why a project cannot run in isolation (notes p. 34)

• Broad environment: a project operates inside a wider organisation, next to other projects, departments, customers and regulators.
• Systems thinking: the project manager must see the project as one part of the whole organisation (the systems view of chapter 2).
• Business fit: senior managers must make sure the project keeps supporting current business needs; a project that drifts away from them gets cancelled.

Project management context as per PMI asked 2×

The three terms PMI’s context is built on (slide 54)

• Project phase: a division of the project, made so that uncertainty falls; each phase ends when one or more deliverables are complete.
• Deliverable: a tangible, visible, verifiable work product, such as a feasibility report, a design document or working code. The notes: a product or service produced or provided as part of the project.
• Project life cycle: a rational collection of project phases, with a definite beginning and end, which links the project to the ongoing operations of the performing organisation.

Stage gates (slide 56)

• Also called phase exits or kill points.
• At the end of each phase management reviews the key deliverables and the project performance.
• The review decides whether the project continues to its next phase, and corrects errors if required. A project that no longer makes sense is killed here, cheaply, instead of failing later, expensively.

• Estimates sharpen phase by phase: preliminary, then budgetary, then definitive. That is uncertainty falling, exactly what the phases are for.
• The project manager’s perspective moves from formation, design, estimation and planning early on, to maturity, evaluation and termination later.

The five phases in brief (notes pp. 35, 36)

• Initiation: decide what the project should accomplish. Two activities: develop the project charter and identify stakeholders (recorded in the stakeholder register). Once the charter is approved, the project is officially authorised.
• Planning: about 50% of the whole process. Sets the scope and objectives, takes the outputs of initiation, and its outputs feed execution. Do not execute before the initial planning is finished, and keep revising the plans until execution starts.
• Execution: carry out the activities defined in the project management plan: manage stakeholder expectations, coordinate people and resources. Actions here may change the plan and its documents.
• Monitoring and controlling: track, review and regulate progress against the objectives; check that what is built follows the plan; spot changes from the plan and decide preventive action.
• Closing: the notes group it with monitoring and controlling. The work is accepted by the customer and the lessons learned are recorded (the last column of the table).

Characteristics of the project life cycle asked 3×

The characteristics (notes p. 37, slide 56)

1. Passes through every phase: a project should successfully pass through each phase in order to continue on to the next.
2. Each phase ends in a review of the key deliverables and project performance: the phase exit, stage gate or kill point, where management decides whether to continue and corrects errors.
3. Cost and staffing: low at the start, higher toward the end (peaking in execution), and dropping rapidly as the project closes.
4. Risk and uncertainty: highest at the start, because the probability of success is lowest then; they fall as the project proceeds and more becomes known.
5. Stakeholder influence: the stakeholders’ ability to influence the final characteristics of the product and its final cost is highest at the start, and gets progressively lower as the project continues.
6. Cost of change: low early, rising steeply as the project goes on (the notes’ diagram).
7. Phases usually overlap (notes p. 40): they are rarely clean handovers.

Points three to six are one idea from four angles: early is cheap and uncertain, late is expensive and certain. Remember that sentence and you can regenerate them.

The life cycle in different fields, and the representative software life cycles

• Every field names its phases differently, but the shape is the same: check the idea, design it, build it, hand it over and support it.

Project life cycles in different fields (notes p. 37)

Representative software life cycles (notes p. 41)

• Spiral: proof of concept cycle; first build cycle; second build cycle; final cycle. Each cycle is one loop of the spiral model.
• Waterfall: concept; analysis; requirements; design and development; programming; testing; verification; maintenance.
• The IT product development life cycle in the syllabus is the SDLC.

Product life cycle versus project life cycle asked 7×

• The idea that unlocks it: the product life cycle is the longer, outer thing, and one or more project life cycles live inside it.

The five stages (slides 60 to 63)

• Development: begins when the company develops a new product idea.
• Introduction: the new product is first distributed and made available to buy.
• Growth: sales start climbing quickly. Maturity: sales growth slows or levels off. Decline: sales fall.

It follows a life, birth to old age, so it needs no mnemonic: develop, introduce, grow, mature, decline. The notes call the last stage retirement.

The project life cycle, for contrast (notes p. 40)

• Phases: initiation, planning, executing, monitoring and controlling, closing: the five process groups of chapter 2.

The differences (notes p. 40)

Product versus project, as the slides put it (slide 57)

The SDLC, and its role in ICT project management asked 2×

• Phases and their order: the SDLC describes the phases of the software cycle and the order in which they run (slide 66).
• Deliverables chain: each phase produces deliverables required by the next. Requirements become design, design becomes code, and testing verifies the code against the requirements. The testing team follows the software testing life cycle (STLC).

The six stages (notes p. 39)

1. Planning and requirement analysis: the most important, fundamental stage. Plan the basic approach and study product feasibility in the economic, operational and technical areas; the technical feasibility study picks approaches with minimum risk.
2. Defining requirements: define and document the product requirements and get the customer’s approval, in the SRS (software requirement specification).
3. Designing the product architecture: the design approach defines the architecture models of the product.
4. Developing the product: actual development starts; developers write the code for the modules.
5. Testing the product: the code is compiled into a build and tested; defects are reported, tracked, fixed and retested until the product meets the quality standards in the SRS.
6. Deployment: the tested product is released to the market and feedback taken; then it is maintained for the existing customers.

What the slides add (slides 68 to 71)

• Requirement gathering asks: who will use the system, how will they use it, what data goes in, what data comes out? The result is a requirement specification document.
• Design: system design specifies hardware and system requirements and the overall architecture; testers write the test strategy (what to test, how).
• Implementation: work is divided into modules and coded; the longest phase.
• Testing: unit, integration, system and acceptance testing, plus non-functional testing.
• Deployment: customers first do beta testing; bugs are fixed, then final deployment. Maintenance: the real problems appear in use and are solved from time to time.
• Every software process has four activities (slide 65): specification, development, validation, evolution.

The role of the SDLC in ICT project management (built from notes pp. 38, 39 and slide 66)

• Structure: it breaks the work into phases in a fixed order, so the project can be planned, estimated and scheduled phase by phase.
• Control points: every phase ends in deliverables the next phase needs, which gives natural points to review, approve and monitor progress.
• Scope control: requirements are written in the SRS and approved by the customer before design, so everyone builds the same thing.
• Lower risk: the feasibility study in the first stage chooses the approach with minimum risk before money is spent.
• Quality: testing against the SRS continues until the quality standards are met.
• Triple constraint: its aim is software that meets customer expectations within time and cost estimates.
• Coordination: developers, testers (STLC) and managers share one map of the work.
• After release: deployment and maintenance are planned, not improvised.

Predictive and adaptive SDLC (slide 109)

• Predictive: assumes you can predict the complete workflow. The final product is fully understood, and cost, scope and timeline are fixed in the early phases. Waterfall is the common example: phases one at a time, no overlap.
• Adaptive: a mix of incremental and iterative development. Features are added incrementally and refined from feedback, so the work adapts to changing requirements. Agile and the other iterative methods are adaptive.

What a methodology is, and the existing methodologies asked 1×

The existing methodologies

• In the notes (p. 41): waterfall; Royce (conventional waterfall); iterative and incremental (evolutionary); agile; lean.
• In the slides (slide 72): waterfall; V-model; incremental; iterative; spiral; prototype; Rational Unified Process (RUP); Microsoft Solutions Framework (MSF); agile methodologies.
• The agile family (slides 89 to 108): Scrum, Kanban, lean software development, extreme programming (XP), feature driven development (FDD), test driven development (TDD), DSDM and Crystal.

Sequential models: waterfall, Royce and the V-model

Waterfall model (notes pp. 42, 43, slide 74)

• What: a sequential model that divides development into pre-defined phases. Each phase must be complete before the next begins, with no overlap: a linear-sequential life cycle model. The cascade from phase to phase gives it its name.
• Plan driven: all activities are planned and scheduled before work starts; each phase produces documents that must be approved before the next begins.

1. Requirements analysis and definition: all requirements captured and documented in a requirement specification.
2. System and software design: the system design is prepared from the requirements; it specifies the hardware and system requirements and the overall architecture.
3. Implementation and unit testing: the system is built as small programs (units), each tested for its functionality.
4. Integration and system testing: the units are integrated and the whole system is tested for faults and failures.
5. Deployment: after functional and non-functional testing, the product is deployed in the customer environment or released to the market.
6. Maintenance: issues found in the client environment are fixed by releasing patches.

• The slides add: little customer involvement after the specification; no way to see or try the software until the last phase. Use it only when requirements are completely understood and unlikely to change radically.

Royce model: the conventional waterfall (notes p. 44)

• What: the waterfall model, but with feedback.
• How: each step (evaluation, requirements, analysis, design, development, validation, deployment) can feed back to the step before it, and complex feedback loops reach further back.
• Why it matters: it admits that problems found late must travel back upstream.

V-model (slide 76)

• What: an extension of the waterfall model. Instead of moving down in a line, the steps bend upward after coding, forming a V.
• The point: it pairs each development phase with its testing phase: requirement analysis with acceptance testing, system design with system testing, architecture design with integration testing, module design with unit testing. Each test is designed while its design phase happens.
• Axes: left to right is time or project completeness; top to bottom is the level of abstraction, coarsest at the top.

Iterative and incremental models: incremental, iterative, evolutionary, spiral, prototype

Incremental model (slide 78)

• What: the product is designed, implemented and tested incrementally, a little more added each time, until it is finished, meaning it satisfies all its requirements.
• How: each increment passes through requirements, design, coding and testing, and each release adds function to the previous one.
• Roots: it combines the waterfall model with the iterative philosophy of prototyping, and it covers both development and maintenance.

Iterative model (slide 80)

• What: it does not start with a full specification. It starts with a simplified set of user features, which gains complexity and features until the system is complete.
• How: build part of the software, review it to find further requirements, and repeat, delivering a new version each iteration.
• Documentation: light projects may let the code be the main documentation; critical ones still need a formal specification.

Evolutionary methodology: iterative and incremental together (notes pp. 44, 45)

• What: combines the iterative design method with the incremental build model.
• How: start with a comparatively small task or component, and add increments in each cycle until the desired product is reached.

Spiral model (slide 82)

• What: a model built for risk handling, drawn as a spiral with many loops.
• Loops are phases: each loop is one phase of development. The number of loops is not fixed; the project manager decides it from the project risks, so the manager’s role is central.
• Each loop runs four quadrants: determine the objectives and alternatives; identify and resolve the risks; develop and test the next version; review and plan the next phase.

Prototype model (slide 84)

• What: before the actual software is developed, a working prototype is built: a toy implementation with limited functionality.
• Why: users evaluate the developers’ proposals and try them before implementation, get the “actual feel” of the system, and understand their own requirements better.
• Suits complex and bigger systems.

Process frameworks: RUP and MSF

Rational Unified Process, RUP (slide 86)

• What: a software development process from Rational, a division of IBM.
• Four phases, each involving business modelling, analysis and design, implementation, testing and deployment:

1. Inception: the idea is stated; the team decides whether the project is worth pursuing and what resources it needs.
2. Elaboration: the architecture and the required resources are evaluated further; possible applications and costs are considered.
3. Construction: the software is designed, written and tested.
4. Transition: the software is released to the public, and final adjustments are made from end-user feedback.

Microsoft Solutions Framework, MSF (slide 88)

• What: a set of principles, models, disciplines, concepts and guidelines for delivering IT solutions, from Microsoft.
• Not only applications: it also fits deployment, networking and infrastructure projects.
• Methodology neutral: it does not force waterfall or agile; the team decides.
• Its cycle (slide 87): envisioning, planning, developing, stabilising, deploying, each closed by a milestone: vision and scope approved, project plans approved, scope complete, release readiness approved, deployment complete.

The agile model

• Small builds: the product is broken into small incremental builds, delivered in iterations.
• Short iterations: each typically lasts one to three weeks.
• Cross-functional teams work simultaneously in every iteration on planning, requirements analysis, design, coding, unit testing and acceptance testing.
• A working product is shown to the customer and important stakeholders at the end of each iteration.
• No big bang: requirements, plans and results are evaluated continuously, so the team responds to change quickly (slide 90).

The Agile Manifesto: four core values (slides 91, 92)

The twelve principles (slide 93, from the principles behind the Agile Manifesto)

• Customer: customer satisfaction first; welcome changing requirements; frequent delivery.
• People: business and development working together; motivated individuals at the heart of projects; face-to-face as the prime communication method.
• Progress: working software is the primary measure of progress; aim for sustainable progress; continuous attention to what matters.
• Team: keep it simple; create self-organising teams; make time for reflection.

Agile methods: Scrum, Kanban, TDD and FDD

Scrum (slides 94 to 101)

• What: a lightweight framework, based on agile principles, that helps people, teams and organisations generate value through adaptive solutions for complex problems.
• How: the product owner orders the work into a product backlog; the team turns a selection into an increment of value during a sprint of one to four weeks; the team and stakeholders inspect the result and adjust for the next sprint; repeat.
• Why: building incrementally and iteratively reduces risk, raises visibility and exposes hidden problems early.

• Three pillars (slide 95): transparency, making the important parts of the process visible to those responsible for the outcome; inspection, timely checks of progress toward the sprint goal to catch unwanted variances; adaptation, adjusting the process as soon as possible to limit further deviation.
• Five values (slide 96): courage, focus, commitment, respect, openness.
• The team (slide 97): product owner (manages the product backlog, optimises the product value); Scrum master (manages the Scrum process, removes obstacles); development team (self-organising, interdisciplinary).
• Five events (slide 98): the sprint, sprint planning, the daily scrum, the sprint review, the sprint retrospective.
• Three artifacts (slide 99): the product backlog, the sprint backlog, the product increment.

Kanban (slides 102, 103)

• What: Japanese for “visual card” (literally signboard). A method of just-in-time delivery that does not overload the team.
• How: the whole process, from task definition to delivery, is displayed on a board for stakeholders to see, and team members pull work from a queue when they have capacity.
• Principles: visualise the workflow; just in time (build only what you need); limit work in process (WIP); manage and optimise the flow (cut lead time, make policies explicit, improve together).
• Not an inventory control system: a pull scheduling system that says what to produce, when, and how much.

Test driven development, TDD (slide 107)

• What: test cases are written first, to specify and validate what the code will do. If a test fails, new code is written to pass it, keeping the code simple and bug-free.

Feature driven development, FDD (slide 108)

• What: development organised around designing and building features, with short, specific phases per feature: domain walkthrough, design inspection, promote to build, code inspection.
• Five activities: develop an overall model; build a feature list; plan by feature; design by feature; build by feature.

The lean model

• Origin (slide 105): lean began in manufacturing, to optimise the production line, minimising waste and maximising customer value. Software shares the conditions: a repeatable process, quality standards, and a group of specialised workers.

The seven principles (notes p. 47)

1. Eliminate waste: deliver only what the end user needs; remove anything that adds no value, such as unnecessary code or quality issues.
2. Build in quality: tactics such as pair programming and test driven development.
3. Amplify learning: knowledge one engineer gains is shared with the whole team, through code review and meetings.
4. Decide as late as possible: experiment and learn before committing to irreversible decisions.
5. Deliver as fast as possible: launch quickly, get feedback fast, improve; fail fast and learn.
6. Motivate the team (the slides: empower the team).
7. Optimise the whole (the slides: see the whole): examine the process from start to finish so the whole value stream is efficient.

Choosing a model: requirements and technology

• Two questions decide it (notes p. 41, slide 110): are the requirements stable or unstable, and is the technology well known or novel?
• Stable requirements, well-known technology: plan based iterative model.
• Stable requirements, novel technology: agile and plan based iterative model.
• Unstable requirements, well-known technology: lean and plan based iterative model.
• Unstable requirements, novel technology: agile and lean based iterative model.
• The pattern: novel technology brings in agile, unstable requirements bring in lean, and plan based work stays wherever something is stable or known.

Comparing three methodologies, and the one you prefer asked 2×

• Pick waterfall, iterative and incremental, and agile: they run from rigid to flexible, so the comparison writes itself.

“Explain any one you prefer in developing an IT project, and why”

• Prefer agile for a typical ICT project, and justify it with the project’s features, not with taste.
• Requirements move: clients in an ICT project rarely know every requirement at the start; agile suits fixed or changing requirements.
• Early, visible progress: a working product every one to three weeks, shown to the customer, so misunderstandings surface in weeks, not at the end.
• Lower risk: each short iteration tests the riskiest parts first.
• Lean on resources and easy to manage (notes p. 46), with flexibility for the developers.
• Know its limits: it needs an involved, clear customer and some documentation for maintenance. For a small system with fixed, well-understood requirements, waterfall is the better choice, and saying so earns marks.

Project influencers: organisational process assets and environmental factors

Organisational process assets, OPA (notes p. 48)

• What: valuable information, documents and knowledge tools the organisation accumulates over time; simply, the lessons learned from the past.
• Grows with experience: the more projects an organisation runs, the more assets it has: processes, directives and procedures, and a business knowledge base.

Enterprise environmental factors, EEF (notes pp. 48, 49)

• What: the forces that drive change in the business.
• Internal factors: arise inside the organisation: its events, people, systems, structures and conditions; corporate mission, culture and leadership style; staff and budget.
• External factors: arise outside but cause internal change: customers, competition, the economy, technology, political and social conditions, resources, suppliers.
• Linked to chapter 2: the project environment.

Key project members and their responsibilities asked 2×

• Project team: a group of people performing activities to accomplish a common goal, made of skilled workers from various domains (notes p. 49).
• The right mix: a successful team needs the right combination of skills, abilities and personality types.
• No project moves in the required direction without each of its key members (slide 111).

Project sponsor (notes p. 49, slide 111)

• Resources and money: assures the availability of essential resources; approves the budget.
• Authority: leads the project board; has the power to make decisions and settle disputes and conflicts.
• Support: rallies support from stakeholders and executive management for the team.
• Most involved during initiation and planning.
• Typically: executive director, director finance.

Project manager (notes p. 50, slide 112)

• Overall responsibility for project success, keeping perspective.
• Plans: develops and maintains the detailed plan; detailed planning and control; delivers in time with the plan.
• People and partners: recruits project staff; coordinates partners and working groups.
• Issues and scope: records and manages project issues; resolves cross-functional issues; manages scope.
• Performance: monitors progress and performance; manages resource use; sets and maintains project standards and policies.
• Win-win: makes sure every stakeholder gains.
• Typically: senior manager, general manager.

Functional manager (notes p. 49, slide 114)

• Support services: provides the support the project needs, including purchases.
• Administration: manages HR and administration of the performing organisation.
• In IT projects the finance manager often does this job.

Project team member (slide 113)

• Delivers: contributes to the overall objectives; completes individual deliverables; provides expertise.
• Works with users to establish business needs, and documents the process.

System administrator (notes p. 50)

• Technical operation: data migration; interfaces with other systems; reporting configuration and deployment; set-up and maintenance of security.
• Testing and strategy: develops and runs technical testing programs; contributes to technical strategy, policy and procedures.

Project champion (notes p. 50, slide 113)

• Technical voice: helps focus attention on the project from the technical perspective.
• Who: someone with a great deal of technical expertise and industry knowledge: technical manager, CTO, technical lead.

Recall the six by what each does for the project: pays (sponsor), runs (project manager), supports (functional manager), builds (team member), keeps the systems (system administrator), champions (champion).

Project stakeholders and stakeholder management asked 2×

• In a project: the sponsor, project manager, team, functional managers, customers and end users, suppliers, and anyone the project affects.
• Their needs and expectations are the starting point of PMI’s framework (chapter 3).

Types of stakeholders (notes p. 69)

• Primary: involved in the organisation’s monetary transactions (customers, shareholders, employees).
• Secondary: invested in its social transactions (communities, media, the public).
• Key: help the organisation make strategic decisions, minimise risk and grow; they have significant influence or importance within it.

Stakeholders through the project

• Identify them in initiation: identifying stakeholders is one of the two initiation activities, and they are recorded in the stakeholder register (notes p. 35).
• Analyse them: stakeholder analysis identifies the individuals or groups likely to affect or be affected by the proposed system, and sorts them by impact (notes p. 68).
• The analysis records: name and organisation; role on the project; unique facts; level of influence and interest; suggestions for managing the relationship and the nature of reports.
• Plan communication: who needs what information, when they need it, and how it will be given to them (notes p. 143).

• Communication methods (slide 277): face to face; telephone calls; email and other electronic tools. The choice depends on each stakeholder’s intentions, likings and experience.
• Issue log: each stakeholder issue is recorded, given an owner and a date, and tracked until resolved.

The power and interest grid (a standard tool, not in your notes: it plots the “level of influence and interest” the notes’ analysis records)

The system view of project management asked 5×

• Organisation: a group of people with different knowledge and skills, working together to achieve an organisational goal (notes p. 51).
• No project runs in isolation: it operates in a broad organisational environment, so the project manager must take a holistic, system view: understand how the project sits inside the larger organisation (notes p. 51, slide 117).

The general project system

With constraints and mechanism

The three parts of the system view (notes p. 51, slides 119, 120)

1. Systems philosophy: view things as systems: interacting components working within an environment to fulfil some purpose.
2. Systems analysis: a problem-solving approach that requires:
   • defining the scope of the system;
   • dividing it into components;
   • identifying and evaluating its problems;
   • examining alternative solutions;
   • identifying a satisfactory solution.
3. Systems management: addressing the business, technological and organisational issues before creating or making changes to systems. This is the three sphere model.

The three essences of the system view (notes p. 51, slide 121)

• Structured approach: an organisational structure.
• Disciplined approach: coordinated management processes.
• Defined approach: purposefully defined inputs and outputs for each process.

• Example: a hospital information system is not just software. Seen as a system, it touches billing and funding, the doctors and nurses who must use it, and the servers and network it runs on. Missing any one of these sinks the project.

The three sphere model for systems management asked 5×

• Business sphere: what are the answers to the business goals?
  • How much will it cost? Where are the funds?
  • Who are the stakeholders? What will the profit be?
• Technological sphere: the hardware and software issues to be resolved.
  • Which technology will be used, and why? Which software, hardware and network are required?
  • Proven or obsolete technology? Where will technical support come from? How will the project cope with technological change?
• Organisational sphere: the issues involving the stakeholders.
  • What are the tangible and intangible benefits? The long and short term effects?
  • What skills and facilities are required? How will resources be mobilised? What resource development (training) is needed?

• Example: a college gives every student a laptop. Business: what does it cost, who pays, will it attract students? Technology: which laptops, what network and software, who repairs them? Organisation: how do teachers change their classes, who trains the students, who supports them?
• Why the model exists: teams attend to the technology and neglect the organisation, so a technically correct system arrives that nobody adopts. Many IT failures are organisational, not technical.

Organisation structure, and its forms asked 4×

• Division of labour: work is subdivided into separate jobs assigned to different people.
• Coordinating work activities: so that everyone works together harmoniously.

The forms (notes p. 52, slide 122)

1. Functional organisation: grouped by specialisation; projects run inside departments.
2. Projectized (pure project) organisation: projects are units of their own.
3. Matrix organisation: project lines cut across the functional departments; weak, balanced or strong.
4. Composite organisation (slides 122, 129): a mixed structure. For example, a mainly functional organisation sets up a dedicated, projectized team for one critical project while its other projects stay inside departments.

• One variable separates them: how much authority the project manager has, compared with the functional manager. Answer that and every advantage and disadvantage follows.

Functional organisation asked 2×

• What: a common type of structure in which the organisation is divided into smaller groups by specialisation: production, marketing, finance and so on (notes p. 53).
• An upgrade to line organisation: it overcomes line organisation’s weaknesses by fully using the principle of specialisation.
• Functional authority: one person heads many workers, and each head is a specialist in the job.
• In a project (slide 123): the head of department acts as the project manager, or a project coordinator is named with very limited authority.

Projectized organisation

• What: also called the pure project organisation. Unlike the functional form, the project is separate from the functional units (notes p. 54).
• Full authority: the project manager has a line organisation of their own, with project authority and responsibility; projects report directly to the head of the organisation.
• Resources: most of the organisation’s resources are involved in project work; team members report directly to the project manager or provide support services to several projects (slide 124).
• The weak spot: coordinating with the departmental functions.

Matrix organisation, and its types asked 3×

• What: the modern type, set up to face the challenges of fast-changing markets; it mobilises the organisation’s resources in a systematic manner (notes p. 55).
• Two directions: reporting lines run both vertically (functions) and horizontally (projects).
• Two bosses: each employee reports to at least one project manager and one functional manager. The functional manager has the administrative duties; the project manager is responsible for work assignment (slide 125).
• Best of both: it takes the advantages, and some weaknesses, of both the functional and the projectized structure.

The three types of matrix (notes p. 55, slides 126 to 128)

• Weak matrix: the project manager is a project coordinator with limited authority, who facilitates the project. The functional manager assigns the work; the project manager negotiates.
• Balanced matrix: power is balanced between the project manager and the functional manager. The project manager assigns staff to the project according to its needs; the functional manager provides all the support.
• Strong matrix: similar to a projectized organisation. Full-time project managers with considerable authority, and full-time project administrative staff; the project manager rules, though members still sit under functional managers.

Comparing the structures asked 4×

Functional versus matrix (built from notes pp. 53 to 57 and slide 130)

Three structures side by side

How organisational structure influences projects asked 2×

• The structure is the frame: it is the top-level view of the “structure of ownership” and the “main line of reporting order” for the project (notes p. 57).
• It sets the project manager’s authority; whatever that authority, the project manager still needs a disciplined and definite approach.

• Sources: notes p. 57 (authority, team members, role, title, staff) and slide 130 (authority, resource availability, budget, role, staff). They disagree only on the balanced matrix’s administrative staff; either is accepted if you name it.

How each type shapes practice and outcome, with examples

• Functional: the project manager is a part-time coordinator and decisions travel up the functional line. Example: the finance department upgrades its accounting software with its own staff. Outcome: strong specialist quality, but any work needing other departments is slow.
• Weak matrix: staff from several departments, but the coordinator must negotiate for every hour of their time. Example: a bank’s IT and marketing staff build a mobile app part-time. Outcome: cheap, but delays whenever the departments’ own work comes first.
• Balanced matrix: the project manager plans and assigns work, the functional managers supply the people. Example: a software company runs several client projects that share its testers and database experts. Outcome: specialists used efficiently, but two-boss conflicts need settling.
• Strong matrix: a full-time project manager with budget control borrows specialists. Example: a telecom operator rolls out a new billing system. Outcome: fast decisions, while staff keep a functional home.
• Projectized: the project manager has a dedicated team and full authority. Example: a contractor builds a hydropower plant, or an IT firm runs a years-long national ID system. Outcome: focus and speed, but duplicated facilities and job insecurity at the end.
• What changes with the structure: authority and decision speed, how resources are obtained, who controls the budget, the communication lines, the team’s motivation and career path, and the kind of conflict the project manager must handle.

How the process groups overlap in a phase, and where the time goes asked 2×

• Process groups are not phases: a phase is a stage of the project in time; a process group is a kind of work. All five groups run inside every phase: each phase has its own initiating, planning, executing, monitoring and controlling, and closing.
• They overlap in time (notes p. 59, slide 134): initiating rises and falls first; planning peaks next; executing is the tallest curve in the middle; monitoring and controlling runs across the whole phase; closing rises only at the end.

• Why they overlap: the output of one group is the input of the next, so each starts before the last has finished; planning keeps being revised while work is executed; monitoring and controlling never stops.

Percentage of time spent on each process group (notes p. 59)

• Executing takes most of the time: 82% for ordinary project managers, 69% for the best (“alpha”) project managers.
• The best plan twice as much: 21% of their time on planning, against 11%. Good planning saves execution time.
• The rest is small: initiating 1 to 2%, monitoring and controlling 4 to 5%, closing 2 to 3%.

Mapping the process groups to the knowledge areas asked 4×

• Knowledge areas give the detailed description of the processes; process groups say when in the flow of the project each process happens (notes p. 60).
• One grid: every process belongs to exactly one knowledge area and one process group. The knowledge areas cross several process groups.

The mapping in your notes (notes p. 60: PMBOK 2000, nine knowledge areas, 39 processes)

The mapping in your slides (slides 135, 136: PMBOK sixth edition, ten knowledge areas, 49 processes)

What the grid shows

• Planning is the biggest group: 21 of the 39 processes in the notes’ version, 24 of 49 in the slides’ version. Every knowledge area has planning work.
• Controlling appears almost everywhere: nearly every knowledge area is monitored and controlled.
• Integration ties it together: in the slides’ version it is the only area in all five groups.
• Initiating and closing are small: a charter and stakeholders at the start, closing the project and its contracts at the end.
• Which version to draw: the notes’ version matches the nine knowledge areas of chapter 2; the slides’ version is the current PMBOK, which adds stakeholder management as a tenth area. Either earns the marks if you name it.

Two processes with their inputs, tools and techniques, and outputs (slides 209, 220)

• Others with their inputs, tools and outputs in the slides: scope definition (slide 154), cost budgeting (218), quality planning (238), perform quality control (253), communications planning (260), manage stakeholders (276).

Project integration management and its processes asked 7×

• Start to finish: these actions apply from the start of the project through completion.
• All knowledge areas: the project manager must coordinate all of them throughout the life cycle; each integration process has its inputs, tools and techniques, and outputs.

Why integration management is needed (notes p. 61)

• Manage change and communication.
• Reduce project time and cost.
• Involve stakeholders early and often.
• Make results visible.
• Identify problems and solutions early.
• Use relevant experience as early as possible.

The seven integration processes (notes pp. 62 to 74, slides 139 to 145)

1. Develop project charter (initiating): formally authorises the project.
2. Develop preliminary project scope statement (initiating): the high-level objectives and boundaries.
3. Develop project management plan (planning): the plan that guides execution and control.
4. Direct and manage project execution (executing): perform the work in the plan.
5. Monitor and control project work (monitoring and controlling): compare actual performance against the plan.
6. Perform integrated change control (monitoring and controlling): approve or reject every change.
7. Close project (closing): finalise all activities and hand over the result.

• All five groups: in this list integration touches every process group, from the charter to closing.

Each group’s integration process and its main output (notes p. 61)

Inputs, tools and outputs of the other processes (slides 140 to 145, notes pp. 67 to 73)

The statement of work (SOW) asked 4×

• Business need: why the organisation needs the project.
• Product description: what the project will produce.
• Strategic plan: how the project supports the organisation’s strategy; organisations often run a SWOT analysis for it, with managers from outside the IT department helping.

The notes’ SWOT example (notes pp. 63, 64: four people starting a business in the film industry)

• Strengths: many contacts in the film industry; two have strong sales and interpersonal skills; two have strong technical skills with filmmaking software.
• Weaknesses: no accounting or financial experience; no clear marketing strategy; little money to invest; no website and little use of technology.
• Opportunities: a potential client wants a bid on a large project; the film industry keeps growing; two major conferences to promote the company.
• Threats: others offer the same services; customers may prefer established firms; the film business is high risk.

The sections of a SOW (notes p. 64)

1. Introduction: the basics: is it a service or a product, and who are the parties?
2. Project overview and objectives: why the project is being done.
3. Scope of work: the work needed to complete the project.
4. Task list: the tasks, broken into phases.
5. Project schedule.
6. Project deliverables.
7. Adoption plan: how the deliverables will be put into place.
8. Project management: payment and administrative work.
9. Success criteria and sign-off.

A SOW for an Engineering College MIS (the 2078 Bhadra question; the assumptions are ours, as the question invites)

1. Introduction: the college (client) engages a software firm (vendor) to build a web-based management information system: a product, with training as a service.
2. Overview and objectives: replace paper records; give one source of student, academic and financial data; cut report preparation from days to minutes; go live before the next academic session.
3. Scope of work: modules for admissions, student records, attendance, examinations and results, fees and accounts, library, staff records and reports; web access for students, teachers and administration. Out of scope: payroll and hostel management.
4. Task list: phase 1 requirements and design; phase 2 development of the modules; phase 3 testing and data migration; phase 4 deployment and training.
5. Schedule: six months: requirements by month 1, design by month 2, development by month 4, testing and migration by month 5, go-live and training in month 6.
6. Deliverables: SRS and design documents, the working system on the college server, migrated data, user and administrator manuals, source code, and trained staff.
7. Adoption plan: pilot in one department, then all departments; old and new systems run in parallel for one month; a help desk for the first three months.
8. Project management: a steering committee chaired by the principal; fortnightly progress reports; payment of 20% at signing, 30% after design, 30% after testing, 20% after acceptance.
9. Success criteria and sign-off: all modules pass user acceptance tests, reports are produced in under a minute, 95% of staff are trained; the principal signs the acceptance certificate.

Expert judgement asked 3×

• Why it matters: anyone who has worked on a large, complex project knows how much good decisions depend on it.
• Consult experts on: what methodology to follow, what programming language to use, what training approach to take (notes p. 66).
• Where it is used: a tool in almost every process: developing the charter, the preliminary scope statement and the plan, monitoring work, change control, closing, scope planning, cost estimating (slides 139 to 145, 149, 209).
• Who the experts are: other units of the organisation, consultants, stakeholders including the customer, professional and technical associations, industry groups, and specialists on the team.
• When it helps most: where hard data does not exist: new technology, first-time estimates, risk identification, evaluating bids.
• Its weakness: bias and over-confidence; ask several experts and combine their views, for example with the Delphi technique.

The preliminary scope statement, the project management plan, and execution

Develop preliminary project scope statement (notes p. 67, slide 140)

• What: an output of initiation; its purpose is to identify the high-level project objectives, which must be clear, actionable and measurable.
• It includes: objectives, constraints and assumptions; product requirements; initial risks; the preliminary estimated cost; approval requirements.
• The slides add: acceptance criteria, project boundaries, deliverables, and an initial WBS.

Develop project management plan (notes pp. 67, 68, slide 141)

• What: part of the planning group; its purpose is to guide project execution and control the project’s progress.
• Uses: document the assumptions and decisions, help communication among stakeholders, and record what was approved.
• Includes: the project charter, the management approach, the scope statement, and the budget, schedule and resources.
• Common elements: introduction and overview; project organisation; management and technical processes; work to be performed (scope); schedule and budget information; references to other planning documents.

Baseline management (notes p. 69)

• Baseline: a fixed reference point to measure and compare the project’s progress against, so performance can be assessed over time.
• Four baselines: schedule, cost, scope, quality.
• Steps: set measures; record progress; calculate the variance; take remedial action.

The project planning matrix, or logical framework (notes p. 68)

• What: a planning tool for a well-designed, objectively described and evaluable project; a summary of the project design.
• Vertical logic runs from activities up to the goal; horizontal logic runs from the narrative summary to the important assumptions; each cell is linked to the next by cause and effect.

Direct and manage project execution (notes pp. 69 to 71, slide 142)

• What: part of the executing group: manage and perform the work described in the project management plan.
• Planning and execution are inseparable: the plan drives the work, and the work updates the plan.
• Work performance information it produces: schedule progress; completed, pending and incomplete deliverables; how far quality standards are met; resource use; lessons learned; conflicting issues to address.

Monitor and control project work asked 2×

• What: part of the monitoring and controlling group: comparing actual project performance against the project plan (notes p. 71, slide 143).
• Why: changes are mostly unavoidable, so the better approach is to develop and follow a monitor and control strategy.
• How: collect, measure and circulate performance information.
• Goal: watch all the activities so the project meets its performance objectives.
• Inputs, tools, outputs (slide 143): project management plan, requested changes and work performance information go in; PM methodology, PMIS, earned value management and expert judgement are applied; recommended corrective and preventive actions, recommended defect repair, forecasts and requested changes come out.
• The control loop (baseline steps, notes p. 69): set measures, record progress, calculate the variance, take remedial action, and repeat.

Integrated change control asked 4×

Its three objectives (notes p. 71)

1. Influence the factors that create changes, so that the changes that do happen are beneficial.
2. Determine that a change has occurred.
3. Manage actual changes as they occur.

The four types of control (notes pp. 72, 73)

• Change control system: a formal, documented process describing when and how official project documents and work may be changed, who is authorised to change them, and how.
• Change control board (CCB): a formal group of people responsible for approving or rejecting changes. It gives guidelines for preparing change requests, evaluating them, and managing the implementation of approved changes.
• Configuration management: ensures the descriptions of the project’s product are correct, complete and consistent; it identifies and controls the functional and physical design characteristics of the products and their documentation.
• Version control and build management: version (source) control tracks and manages changes to software code over time, keeps the history and supports rollback; build management needs a formal check-in and check-out policy to guarantee code quality.

Inputs, tools and techniques, and outputs (slide 144, notes p. 72)

Key features of change control on IT projects (built from notes pp. 71 to 73)

• Formal requests: every change is requested in writing through the change control system.
• Impact assessed first: its effect on scope, time, cost, quality and risk is judged before a decision.
• A defined authority decides: the change control board approves or rejects.
• Configuration management keeps requirements, design and code documents consistent with each other.
• Version control and build management: every code change is committed with its history, can be rolled back, and follows a check-in and check-out policy.
• Baselines updated: an approved change updates the plan, so the plan still matches the work.

Close project asked 2×

• What: part of the closing group. To close a project or phase, finalise all activities and transfer the completed or cancelled work to the appropriate people (notes p. 73).
• Main outputs: the final product, service or result transition; organisational process asset updates.

The main steps in closing a project (notes p. 74)

1. Phase end activities: help the team move from one phase to the next: peer review, release management, review meeting, updating the plan for the next phase, status reporting, end-user education.
2. Administrative closure procedure: make sure the plan has budget and time for closure, and populate the project archives: formal acceptance by the client, recommendation from sponsors and the support organisation, maintenance and upgrade, training, lessons learned.
3. Contract closure procedure: verify the contract requirements; formal acceptance by the client; performance evaluation of the contract by the buyer and by the seller; procurement audit; update the project files and historical databases.
4. Update organisational process assets: formal acceptance documents, project files, project closure documents, historical information and lessons learned. Archiving is the last step.

• Inputs, tools, outputs (slide 145): project management plan, contract documentation, work performance information, environmental factors, process assets and deliverables go in; PM methodology, PMIS and expert judgement are applied; the administrative closure procedure, the contract closure procedure and the final product, service or result come out.
• Administrative closure (communications, notes p. 143): generating, gathering and circulating information to formalise phase or project completion.

Project scope management and its processes asked 4×

• Shared understanding: the project team and the stakeholders must have the same understanding of what products will be produced and what processes will produce them. Most scope disputes are two parties who each thought the other agreed.

The processes of project scope management (notes p. 76)

1. Initiation: beginning a project, or continuing to the next phase.
2. Scope planning: developing documents that provide the basis for future project decisions.
3. Defining scope: reviewing the charter, requirement documents and organisational process assets to create a scope statement.
4. Creating the WBS: subdividing the major deliverables into smaller, more manageable components.
5. Scope verification: formalising acceptance of the project scope.
6. Scope change control: controlling changes to the project scope.

• The slides (slide 148) list five: initiation, scope planning, scope definition (which there means the subdividing, so it absorbs creating the WBS), scope verification, scope change control.

Scope planning (slides 149, 150)

• What: progressively elaborating and documenting the project work; it identifies the objectives and deliverables and forms the basis of agreement. It starts in planning, using the outputs of initiation.
• Inputs, tools, output: PM plan, environmental factors, process assets, charter and preliminary scope statement go in; expert judgement and templates, standards and forms are applied; the project scope management plan comes out.
• Understanding requirements: functional requirements (the day-to-day needs of users) and non-functional ones (performance, usability, reliability, security, financial, legal, operational).
• Capturing them: interviews, questionnaires, in-depth observation, domain expert suggestions.
• Documenting them: from the SMART rule to the MoSCoW rule (must have, should have, could have, would have), then a system requirement specification (SRS) with business and use cases.

The scope statement (slides 151, 152)

• What: the document used to develop and confirm a common understanding of the project scope.
• Components: project justification (the need; cost-benefit and cash flow analysis); the project’s product (its specification); project deliverables (the major outcomes); project objectives (SMART); and what determines success (key success factors).

Scope definition (slide 154)

• What: subdividing major project components into smaller ones, to improve the accuracy of cost, time and resource estimates, define a baseline for performance measurement and control, and make responsibility clear.
• Inputs, tools, outputs: PM plan, environmental factors, process assets, charter and preliminary scope statement go in; product analysis, alternative identification and stakeholder analysis are applied; the project scope statement, requested changes and an updated scope management plan come out.

From charter to WBS dictionary: scope gets more detailed

1. Project charter (slide 139): formally authorises the project, with its goals and the basic scope.
2. Preliminary scope statement (slide 140): objectives, acceptance criteria, boundaries, deliverables, constraints, risks and an initial WBS.
3. Scope statement (slides 151, 152): justification, product, deliverables, SMART objectives, success factors, agreed with the stakeholders.
4. WBS (slide 155): the deliverables decomposed into work packages.
5. WBS dictionary: describes each WBS component (notes p. 79): its work, owner, deliverable, cost and time.

• The pattern: each step is more detailed, and less negotiable, than the one before; scope planning is progressive elaboration (slide 149).

Project scope versus product scope asked 5×

• One sentence carries it: project scope is the how (the work), product scope is the what (the features).

• Sources: notes p. 75 (rows one to four, and the example) and slide 147 (measured against, defined in).
• An IT example: product scope of a college MIS is its modules and features (fee payment, result publishing); project scope is the work to deliver them (requirements, design, coding, testing, training).

The work breakdown structure (WBS) asked 5×

• Decomposition: subdividing project deliverables into smaller pieces.
• Work package: a task at the lowest level of the WBS.
• Levels: total program; project; task (activity); sub-task; work package; level of effort (notes p. 77).

Why a WBS is needed: its advantages (notes p. 76)

• Planning can be performed easily.
• Costs and budgets can be established.
• Schedules can be established.
• Responsibility can be assigned to each activity.
• Risk of each activity can be analysed.

What creating a WBS identifies (notes p. 76)

• What: the work.
• How long: the time to complete each work package.
• Cost: a time-phased budget for each work package.
• How much: the resources each work package needs.
• Who: the person responsible for each unit of work.
• Milestones: the monitoring points for measuring success.

How the WBS affects the estimates of tasks (notes p. 81, slides 153, 154)

• Smaller tasks are easier to estimate, so estimates made on work packages are more accurate than one estimate for the whole project.
• Estimation errors add project risk, and a WBS makes missed work visible: a missing branch shows in a hierarchy, not in a paragraph.
• Estimate by the team, adjusted by experts, and estimate the work effort per person, not the task duration.
• Order of estimating: scope or size first, then time, then cost.
• It sets the baseline: subdividing improves the accuracy of cost, time and resource estimates and defines a baseline for measuring performance (slide 154).

WBS inputs, tools and outputs (slide 155)

• Inputs: project scope statement; scope management plan; organisational process assets; approved change requests.
• Tools: WBS templates; decomposition.
• Outputs: the WBS; the WBS dictionary; the scope baseline; updated scope statement and scope management plan; requested changes.

Approaches to developing a WBS (notes p. 77, slide 158)

1. Using guidelines: some organisations provide guidelines for preparing WBSs.
2. The analogy approach: review the WBS of a similar project and customise it.
3. The top-down approach: start with the largest items and break them down.
4. The bottom-up approach: start with the specific tasks and roll them up.
5. Mind mapping: branches radiating out from a core idea to structure thoughts and ideas.

Principles for creating a WBS and its dictionary (notes p. 78)

1. Once only: a unit of work appears only once in the WBS.
2. Sum of the parts: the work content of a WBS item is the sum of the items below it.
3. One owner: a WBS item is the responsibility of only one individual, even if many people work on it.
4. Realistic: the WBS is consistent with the way the work will actually be done.
5. Team built: project team members help develop it, for consistency.
6. Documented: each WBS item is described in the WBS dictionary.

The two rules (notes p. 78)

• The 100% rule: the WBS includes 100% of the work defined by the project scope and captures all deliverables, internal, external and interim, including project management itself. It is one of the most important principles for developing, decomposing and evaluating a WBS.
• The 8/80 rule: the lowest level of work should be no less than 8 hours and no more than 80 hours.

Finalising the WBS with a cost-benefit analysis (slide 157)

The responsibility assignment matrix (RAM) and the OBS asked 1×

• R, responsible: who does the task?
• A, accountable: who signs off on the task, or has authority for it?
• C, consulted: who has information needed to complete it?
• I, informed: who needs to be told of its status and results?
• Size matters: on smaller projects assign individual people to WBS activities; on very large projects assign the work to organisational units or teams.
• One A per row: several people can be responsible, but if two are accountable, nobody is.

A RACI chart (slide 159)

Organisational breakdown structure, OBS (notes p. 77)

• What: a type of organisation chart that links cost, activity and responsibility.
• It allows: work definition, assigning owners to work packages, and assigning budgets to departments.
• How they fit: the WBS breaks down the work, the OBS breaks down the organisation, and the RAM is the grid where the two meet.