Read this before anything else: the shape of the paper

Twenty three papers in a row follow the same skeleton. Once you see it, the paper stops being a surprise and becomes a checklist.

• Attempt All questions. There is no choice except inside the short notes question, so you cannot revise selectively and hope. You can, however, revise in the right ORDER.
• Roughly 8 to 16 questions for 80 marks, so the average question is worth about 6 marks and deserves about 12 minutes and roughly a page.
• One or two numericals, always. There has never been a paper without one. It is almost always a network diagram or earned value, and often both.
• A comparison question is near certain. Look for “Compare the followings” with four pairs at 3 or 4 marks each. Answer these in a TABLE, never in prose.
• Short notes closes the paper, worth 12 to 20 marks. Balanced scorecard has been an option in 20 of the 22 sittings. That is the single most reliable mark on the paper.

How the highlighting works

Repetition is marked quietly, so it informs you without shouting over the text you are trying to read.

• A pill after a heading says how many of the 22 sittings asked it, like asked 22× or asked 10× or asked 3×. Magenta is a near certainty, blue is common, grey is occasional.
• An untagged card is connective tissue. It has rarely been asked on its own, but the tagged cards around it do not make sense without it. Do not skip these on the first read. Skip them on the third.
• Examinable only in the sidebar hides everything untagged, which is what you want on the last night, and exactly what you do not want on the first day.

Definition, and the two words that carry it asked 20×

A project is a set of organised activities designed to fulfil a specific objective within a limited amount of time and with limited resources. Every project has a definite beginning and a definite end, and it is planned, executed and controlled.

Almost every mark in this topic hangs on two words. Temporary means it has an end date, not that it is short. Unique means the output has never been produced in exactly this form before. Lead with those two words and the rest of the answer writes itself.

Watch the phrasing. “Define project” wants two lines. “What is a project and what are its main attributes” (2069) wants the definition plus the characteristics list below. “Discuss the specific attributes that are specific to IT related projects” wants you to add intangibility, rapid technology change and high failure rate on top.

The nine characteristics asked 20×

This is the list the paper wants when it says “describe in detail about the characteristics of the project”, which it has said in almost every sitting. Give the name, then one line each. Nine at roughly half a mark apiece is a comfortable 4 or 5 marks.

1. Specific objective. A project defines its objective clearly, and succeeds when that objective is achieved.
2. Temporary. It has a life span, a birth and a death. It cannot run endlessly.
3. Unique. No two projects are exactly alike, even when they look similar.
4. Non-routine and non-repetitive. It is not the standing work of the organisation.
5. Planning and control. Every project carries a planning and control system.
6. Resource integration. It uses man, machine, money and minutes, and these must be integrated to be used efficiently.
7. Flexibility. Risk and change are unavoidable, so a project must be able to absorb them.
8. Constraints. It operates inside the limits of time, cost and quality.
9. Team work. A manager leads a team towards the goal.

Project versus operational work asked 9×

Asked as “how is project different from operational work” and as “key differences between project and process”. Both want the same table. Never answer this one in paragraphs.

The single best example to close with: building a road is a project, maintaining it is an operation. One sentence, and it demonstrates you understand the distinction rather than reciting it.

Scope, time and cost, and why one never moves alone asked 9×

The triple constraint, also called the iron triangle, is the model of project management: every project is bounded by scope, time and cost, with quality sitting in the middle as the thing all three trade against.

• Scope constraint: the work that must be done and the features delivered.
• Time constraint: the schedule available to complete that scope.
• Cost constraint: the budget, covering materials, labour, vendors and quality control.

The examiner almost never asks what the constraints are without also asking how a change to one affects the others. That second half is where the marks are, and it is the half students skip.

Close with the consequence: you cannot fix all three. Fix any two and the third must be allowed to move, and if you refuse to let it move, quality is what silently absorbs the difference. That sentence is worth a mark on its own because it shows you understand the model rather than the diagram.

Essential interpersonal and managerial skills asked 16×

This is one of the two or three most reliable questions on the paper. It appears as “essential interpersonal and managerial skills”, as “managerial and soft skills”, and as “different skill sets required by a project manager”. Same eight items every time.

The framing sentence to open with: the project manager must be a people manager. The technical work is done by the team, so what the manager contributes is soft skill.

1. Energised and initiator. Works continuously under pressure and in odd conditions, and takes the initiative to get a result.
2. Communication. Expresses ideas in written and oral form, simply, with feedback.
3. Influencing. Gets people to do what they would otherwise not do.
4. Leadership. Imparts vision, gains consensus on goals, establishes direction, inspires.
5. Motivator. Energises people to a high level of performance and past barriers to change.
6. Negotiation. Resolves conflict and reaches workable agreement.
7. Problem solver. Analyses the problem and deals with it rather than escalating it.
8. Perspective. Looks beyond the team and sees how the project fits the organisation.

What PMI is asked 16×

The Project Management Institute (PMI) is a United States based, not for profit professional organisation for project management. It is the body that publishes the PMBOK Guide, sets the professional standard, and certifies practitioners.

When the paper asks about “the roles of PMI for the development of the project management profession” (2080), answer with what a professional body does:

• Publishes the standard, the PMBOK Guide, so the profession shares one vocabulary.
• Certifies practitioners: PMP for experienced managers, CAPM for associates.
• Defines a code of ethics and professional conduct.
• Promotes research and publishes the body of knowledge as practice evolves.
• Treats the PMO as the catalyst for organisational excellence in projects.

PMBOK, five process groups and nine knowledge areas asked 16×

PMBOK is a collection of processes and knowledge areas generally accepted as best practice in project management. It is the sum of knowledge within the profession: widely used traditional practices, plus some innovative ones, offered as guidelines for managing individual projects. Following it is good practice applicable to most projects most of the time.

That last clause matters. Several papers ask you to “list down two processes of a project management process group with their inputs, tools and techniques and output”. The inputs, tools and outputs structure is the shape of every PMBOK process, so learn the shape once and you can answer it for any process.

• Inputs: documents, plans, designs, artefacts.
• Tools and techniques: the mechanisms applied to those inputs.
• Outputs: documents, products, services, knowledge.

Careful with the fourth group. It is Monitoring and Controlling, one group, not two. Writing six process groups is a straightforward lost mark.

The three levels, and why they are not the same thing asked 10×

The examiner is testing one idea: as you go up the levels, the question changes from “are we doing this right” to “are we doing the right things”.

The sentence the notes give, worth quoting: a project defines end goals and objectives, but a portfolio represents a strategic planning commitment.

Project portfolio management (PPM) is the analysis and optimisation of the costs, resources, technologies and processes across every project and program in the portfolio. It is carried out by portfolio managers or the PMO, and its goal is to balance risk and reward while making sure every outcome supports the organisation's strategy.

Key benefits of PPM, which the paper asks for by name in at least five sittings:

• Strategic alignment: projects that do not serve the strategy get stopped.
• Better project selection through cost benefit analysis, payback, NPV and risk level.
• Efficient resource use, because resources are allocated across the whole portfolio rather than fought over.
• Balanced risk and reward across the set rather than in one project.
• Visibility for senior management, one view of everything under way.
• Fewer failed and duplicated projects.

The five steps of the PPM process, if asked: define business objectives, collect project ideas, select the best projects (cost benefit analysis, payback, NPV, risk), validate portfolio feasibility, then execute and manage the portfolio.

Drivers and inhibitors of project success asked 10×

Asked as “drivers of project success”, “common enablers”, “key drivers according to the PMI framework”, and inverted as “inhibitors” or “factors that slow project success”. One list, learned once, answers all of them, because the inhibitor list is the driver list negated.

The four M's of appropriate resources are man, machine, material, money. Drop them in wherever resources are mentioned: it costs four words and reads as precision.

The project environment, internal, task and external asked 6×

“How the external environmental influences on ICT project” is close to a guaranteed question in some form. Projects are environment dependent: they do not run in a vacuum, and the environment classifies into three rings.

1. Internal environment: inside the organisation and largely controllable. Organisational structure and culture, management style, available resources, existing systems and standards, staff skills.
2. Task environment: the parties the project deals with directly. Customers, suppliers, competitors, contractors, regulators. Influenceable, not controllable.
3. External environment: the wide world, not controllable at all. Political, legal, economic, social and cultural, technological, and environmental or ecological factors.

For an ICT project in Nepal, the concrete external factors are: government ICT policy and the Electronic Transactions Act, import duty and foreign exchange rules on hardware, bandwidth and power reliability, the shortage of senior engineers, and rapid technology change that can obsolete a design mid-project. Naming real ones beats reciting PESTLE.

The phases, and the effort curve asked 14×

The project life cycle is the logical sequence of activities used to accomplish the project's goal. Every project has its own life: a beginning and an end.

1. Initiation. The idea is recognised and the project is authorised. Feasibility study sits here. Output: the project charter.
2. Planning. Determines the scope and the objective. It takes the initiation outputs as input and produces the input to execution. About 50% of the whole process.
3. Execution. Carries out the activities defined in the plan: managing stakeholder expectations, coordinating people and resources, producing the deliverables.
4. Monitoring, controlling and closing. Tracks, reviews and regulates progress against the plan, identifies deviations and determines preventive action, then closes.

Time and effort graph (2082 Baishakh asks for it by name). Effort starts low in initiation, rises through planning, peaks during execution, then falls away through closing. Draw it as a single hump skewed slightly right, with cost and staffing on the vertical axis and time on the horizontal. Add two labelled facts: risk and uncertainty are highest at the start, and the cost of changes rises steeply as the project proceeds. Those two curves crossing is the whole diagram.

Product life cycle versus project life cycle asked 12×

One of the most repeated comparisons on the paper. The idea that unlocks it: the product life cycle is the longer, outer thing, and one or more project life cycles live inside it.

SDLC, and the difference between a life cycle and a methodology asked 6×

SDLC is the process the software industry uses to design, develop and test high quality software: a framework describing the phases involved in developing and maintaining information systems, aiming to meet or exceed customer expectations within time and cost.

That one distinction is what the examiner is checking. Students write about waterfall when asked about SDLC and lose the definitional mark.

The methodologies, and how to compare three of them asked 6×

2082 Baishakh asks you to “compare three different methodologies”. Pick waterfall, iterative and incremental, and agile: they form a clean progression from rigid to flexible, so the comparison writes itself.

Waterfall. A sequential, linear model dividing development into predefined phases. Each phase must finish before the next begins, with no overlap, which is why it is drawn as a cascade. Stages: requirements analysis and definition, system and software design, implementation and unit testing, integration and system testing, operation and maintenance. Simple to understand and use, and everything is planned and scheduled before work starts.

• Good when requirements are fixed, well understood and unlikely to change, and the technology is familiar.
• Bad when requirements will move, because there is no cheap way back up the cascade, and no working software exists until very late.

Royce's conventional waterfall is the same model with feedback loops added between adjacent phases, acknowledging that you do discover problems late and must go back.

Iterative and incremental. The product is built in increments, each one a small slice delivered and reviewed.

Evolutionary. An initial implementation is shown to the user and refined through many versions until the system is adequate. Close cousin of iterative development, the difference being that the early versions are deliberately rough.

Agile. A combination of the iterative and incremental models. It breaks the product into small incremental builds delivered in iterations, each typically one to three weeks. Every iteration involves cross functional teams working simultaneously on planning, requirements analysis, design, coding, unit testing and acceptance testing, and ends with a working product shown to the customer and stakeholders.

Lean. Applies lean production thinking to software: eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity in, and see the whole.

For 2069's “explain any one of its kind that you prefer in developing an IT project, why?”, pick agile and justify it with a reason, not a preference: requirements in an ICT project in Nepal usually are not stable at the start, and agile turns that from a problem into the operating assumption.

The five groups, their overlap, and the mapping to knowledge areas asked 9×

You met the five groups in chapter 1 as IPECC. What this chapter adds is the three things the examiner asks about them.

1. They are not phases. A process group is a category of work, and all five recur inside every phase of the project. A phase has its own initiating, planning, executing, monitoring and closing. This is the point of 2081 Bhadra's “justify the overlaps of different life cycle stages and process groups within various project phase”.

2. They overlap in time. Draw them as five overlapping humps across one phase. Initiating rises and falls early; planning peaks next; executing is the tallest hump in the middle; monitoring and controlling runs flat across the whole width because it never stops; closing rises only at the end. Approximate effort: planning and executing dominate, with executing the largest single share.

3. They map onto the nine knowledge areas as a grid. Knowledge areas describe the processes in detail, and one knowledge area crosses several process groups. Integration management is the only area that touches all five.

The three forms, and the one thing that separates them asked 11×

Organisation structure is the division of labour plus the patterns of coordination, communication, workflow and formal power that direct organisational activities.

Every question in this topic reduces to one variable: how much authority does the project manager have, compared with the functional manager? Answer that and the advantages and disadvantages follow logically instead of being memorised.

Functional organisation. The organisation is divided into groups by specialisation: production, marketing, finance. Each head is a specialist over many workers. It is an upgrade to line organisation that fully exploits the principle of specialisation. The project manager has little or no authority, and projects are run inside departments.

Projectized, also called pure project organisation. The project is separate from the functional units. The project manager has his own line organisation with full project authority and responsibility, and projects report directly to the head of the organisation. Coordinating with departmental functions is the problem.

Matrix organisation. The modern type, built to face fast changing markets. It mobilises resources systematically and provides reporting lines both horizontally and vertically. It comes in three strengths.

Comparing them, and how structure influences the project asked 8×

“Functional vs. Matrix organizational structure” is a recurring comparison question. This single table answers it, and also answers “compare three different organizational structures”.

How structure influences projects (asked 2074, 2069): the structure is the top level view of the structure of ownership and the main line of reporting order for the project. It sets the project manager's authority, who controls the budget, whether the team is dedicated or borrowed, and how fast a decision can be made. The project manager cannot change the structure, so the practical answer is that they must compensate with a disciplined and definite approach and with negotiated authority rather than positional authority.

2069 asks you to justify “most of the project follows functional organizational structure. If you agree, justify.” The honest answer is agree with a qualification: most organisations are functional because their main business is operations, not projects, so projects are run inside existing departments. Then note the cost: weak project authority and slow decisions. A qualified agreement scores better than a flat one.

System view of project management and the three sphere model asked 6×

The system view says a project is not an isolated technical task but a system inside a larger organisational system. Taking it means looking at the whole, not just the software. The notes break it into three parts:

• Systems philosophy: an overall model for thinking about things as systems.
• Systems analysis: a problem solving approach that studies the whole system and the interaction of its parts.
• Systems management: addressing the business, technological and organisational issues before making a change to a system.

That third item is the three sphere model, and it is what the paper actually asks for.

Worth a closing line: most IT project failures are not technological. Teams over-attend to the technological sphere and under-attend to the organisational one, so a technically correct system arrives that nobody adopts. Say that and you have shown why the model exists rather than just listing it.

Feasibility study asked 7×

A feasibility study measures how beneficial the product development will be for the organisation from a practical point of view. It evaluates whether a proposed project or system should be attempted at all, and it sits in the initiation phase, before commitment.

Role of feasibility study in successful completion (asked 2076, 2070): it prevents the organisation from committing money to something that cannot work, sets realistic expectations of cost and time before the budget is fixed, exposes technical and legal obstacles while they are still cheap to solve, and gives the sponsor an evidence base for the go or no go decision. In short, it is the cheapest place to kill a bad project.

What integration management is, and why it exists asked 7×

Project integration management is the collection of processes and activities needed to identify, define, combine, unify and coordinate the various processes and project management activities within the process groups. It applies from the start of the project through to completion, and it is the reason a project manager must coordinate all the knowledge areas across the life cycle.

Those five verbs are worth quoting exactly. They are the definition, and they are also the answer to “why does this knowledge area exist”: the other eight areas each optimise one thing, and something has to make the trade-offs between them.

Need for integration management:

• 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 integration processes, which is the list to give when asked to explain them:

1. Develop project charter (Initiating)
2. Develop preliminary project scope statement (Initiating)
3. Develop project management plan (Planning)
4. Direct and manage project execution (Executing)
5. Monitor and control project work (Monitoring and controlling)
6. Perform integrated change control (Monitoring and controlling)
7. Close project (Closing)

Notice this list touches all five process groups. That is why integration is the only knowledge area that appears in every column of the mapping grid in chapter 2.

The project charter asked 10×

Almost always asked as a pair: what is it, and what are the inputs and tools and techniques used to develop it. Answer both halves or you lose half the marks.

What a charter should address (the “what information should be included” question, 2074): scope; objectives and deliverables; project team members; project risks; benefits or return on investment; budget; and the business case.

If you remember nothing else about the tools, write expert judgement. It is a tool in almost every PMBOK process, it is a recurring short note in its own right, and it is never wrong.

Integrated change control asked 6×

Part of the monitoring and controlling process group. Since changes are unavoidable, the better approach is to develop and follow a monitor and control strategy rather than to resist change.

The three objectives, which is the answer to “explain integrated change control in detail”:

1. Influence the factors that create changes, to ensure 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, and this is the part students miss:

Key features of change control on IT projects (2073): every change is requested formally, assessed for impact on scope, time, cost, quality and risk before any decision, approved or rejected by a defined authority, and if approved, the baselines are updated so the plan still matches reality. An approved change that does not move the baseline is how projects quietly go over budget.

Scope management and its six processes asked 10×

Scope is all the work involved in creating the products of the project and the processes used to create them. Project scope management is the set of processes involved in defining and controlling what is and what is not included in the project. The project team and the stakeholders must have the same understanding of what will be produced and what processes will be used.

That last sentence is the whole point of the knowledge area, and it is worth writing out: most scope disputes are not disagreements about work, they are two parties who each thought the other agreed with them.

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 project 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 project scope.

2069 asks you to trace scope “from information in a project charter to a project scope statement, WBS and WBS dictionary”. That is a chain, and the answer is that each step is more detailed and less negotiable than the last: the charter says roughly what, the scope statement says precisely what and what not, the WBS breaks that into deliverables, and the WBS dictionary defines each one down to a work package.

Project scope versus product scope asked 9×

A near guaranteed comparison. One sentence carries it: project scope is the how, product scope is the what.

The bridge example is the one the notes give and it is the fastest way to show you understand the distinction. Use it.

WBS, its levels, and the two rules that govern it asked 9×

A WBS is the process of systematically breaking down the major project work into smaller, more manageable components and subcomponents in hierarchical order. The task at the lowest level of the WBS is a work package.

Levels of a WBS: total program, project, task or activity, subtask, work package, level of effort.

Advantages of the WBS, which is the answer to “describe the need of WBS” and to “how does it affect the work estimate of tasks”:

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

On the estimating question specifically: a WBS improves estimates because small things are easier to estimate accurately than large things, and the errors on many small estimates partly cancel, while the error on one large guess does not. It also makes omissions visible, since a missing branch is obvious in a hierarchy and invisible in a paragraph.

What creating a WBS forces you to define, which is a neat six point answer: the work (what), the time to complete a work package (how long), a time phased budget (cost), the resources needed (how much), a person responsible for each unit of work (who), and the monitoring points.

Principles for creating a WBS and the WBS dictionary:

1. A unit of work should appear only once in the WBS.
2. The work content of a WBS item is the sum of the WBS items below it.
3. A WBS item is the responsibility of only one individual, even though many people work on it.
4. The WBS must be consistent with how the work will actually be performed.
5. Project team members should be involved in developing it, to ensure consistency.
6. Document WBS items in a WBS dictionary.

A WBS dictionary is the companion document defining each WBS element: what the work is, who owns it, its deliverable, its acceptance criteria, its estimated cost and duration. The WBS names the boxes; the dictionary says what each box means.

Worked example: a WBS for a library management system asked 4×

2082 Bhadra asks you to “prepare WBS for library management system development project”, and similar questions ask for an Engineering College MIS. Draw it as an indented hierarchy with numbering, not as prose. Three levels is enough, and the numbering is what shows you understand the structure.

Two things earn the extra marks. First, include project management itself as branch 1.1: the 100% rule says it belongs, and almost nobody remembers. Second, note underneath that each lowest level item is a work package sized between 8 and 80 hours. That connects your diagram to the rule and shows it was not drawn at random.

Activity sequencing: AON and AOA asked 5×

Sequencing matters because the order of the work, not just its total amount, determines how long the project takes. Two activities that could run in parallel but are wrongly made sequential add their durations instead of overlapping.

There are two ways to draw a network, and the paper uses both, so you must be able to read either.

Converting AOA to AON, which is the safest thing to do because all the float formulas below are written for AON: an activity depends on every activity whose final node equals its initial node. So if B is (3,5) then B's predecessors are every activity ending at node 3. Apply that rule mechanically and you have a normal predecessor table.

Four dependency types, if asked: Finish to Start (the default, and the only one the paper uses), Start to Start, Finish to Finish, Start to Finish.

Forward pass and backward pass asked 21×

This is the most examined procedure in the entire subject. Four numbers per activity, two passes, one rule each.

Notation warning: the paper writes these as EST, EFT, LST, LFT. They are the same four numbers as ES, EF, LS, LF. Do not be thrown by the extra T.

A useful check before you go any further: after the backward pass, at least one complete chain from start to finish must have LS equal to ES for every activity on it. If no such chain exists, you have made an arithmetic error, because every network has at least one critical path.

The four floats asked 14×

Total float is asked almost every year. Free float appears regularly. Independent and interfering float appear in 2079 Bhadra and the CE 701 paper, so learn all four: the last two take one extra line each.

• TF = 0 defines the critical path. That is the entire definition, and it is what “identify the critical activities” is asking for.
• FF is never greater than TF. If you compute one bigger than the other, you have made a mistake.
• Slack and float are the same word. Some papers say “total network slack time”, which means the sum of the total floats of all activities.

Worked example: the standard CPM question asked 21×

Worked example: all four floats asked 2×

PERT: three estimates instead of one asked 6×

CPM assumes you know each duration exactly. PERT assumes you do not, and asks for three estimates per activity, then treats the activity duration as a beta distribution.

Then treat te exactly like a CPM duration. Run the forward and backward passes on the te values, find the critical path, and the project's expected duration is the sum of te along it. PERT does not change the method, it only changes where the numbers come from.

Probability of finishing by a target date asked 6×

This is the second half of every PERT question and the part most candidates lose. Four steps, always the same.

A short normal table, enough for every value the paper has ever needed:

Sanity check your answer against common sense. If the target is later than the expected duration the probability must be above 50%; if it is earlier it must be below. Getting 15% for a target beyond the expected finish means a sign error in z.

Worked example: PERT with a given variance asked 6×

Crashing: buying time with money asked 1×

Low frequency but high marks when it appears: 2081 Bhadra gave it 12 marks in one question. Crashing shortens the schedule by adding resources to activities, accepting a higher cost. Fast tracking shortens it by overlapping activities that were sequential, accepting higher risk instead.

The four rules of crashing, which are the method:

1. Only crash activities on the critical path. Shortening a non-critical activity buys nothing, it just adds float and cost.
2. Crash the cheapest slope first.
3. Recompute the critical path after every unit crashed. Crashing can make a different path critical, and from that moment the cheapest option changes.
4. When two paths are critical at once, you must shorten both, either by crashing an activity common to both or by crashing one on each and paying for two.

Cost estimating and its tools asked 7×

Cost estimating creates an estimate of the price of the resources required to finish the project's operations, and includes identifying and considering cost alternatives. It is part of the project planning phase.

Why software cost estimation is a bit complex (2075 Chaitra asks this directly, and the notes call these the typical problems with IT cost estimates):

• Estimates are done too quickly, often before the requirements are understood.
• People lack estimating experience, and the person estimating is often not the person who will do the work.
• Human beings are biased toward underestimation, systematically and predictably.
• Management desires accuracy that the available information cannot support, so a number gets committed that was never more than a guess.
• Software is intangible: there is nothing to point at and measure part way through, unlike a wall that is visibly half built.

The standard mitigation, and the word to use: a contingency reserve, an amount of budget held explicitly against these known problems rather than hidden inside individual task estimates.

The three numbers everything is built from asked 18×

Earned value management integrates schedule, cost and scope to measure project performance. That three way integration is the definition, and it is why EVM can tell you something that a simple budget comparison cannot: spending less than planned might mean you are efficient, or it might mean you have done almost nothing, and only EVM distinguishes them.

The formulas asked 18×

Worked example: the standard EVM question asked 18×

Worked example: working backwards from an index asked 6×

Several papers give you an index and make you recover a missing value. The trick is always the same: rearrange the formula you already know.

The S curve asked 5×

A recurring short note, and easy marks if you can draw it. An S curve is a mathematical graph of cumulative project cost against time, and it is an effective tool in project control.

Why it is S shaped: the start represents a slow, purposeful but growing acceleration, the middle is the steep section where execution consumes most of the budget, and the finish represents a slowing as the work runs out. Few resources early, most in the middle, few at the end, and cumulating that pattern gives an S.

That three curve version is what 2075 Chaitra means by “illustrate an EVA graph with your own values”. It turns the S curve from a decorative shape into the picture of earned value analysis, and it is the difference between two marks and five.

Defining quality, and the definition that scores asked 20×

Quality is how good something is compared with other similar things: its degree of excellence. The notes give it as a ratio, and quoting it is a fast way to open an answer:

That formulation carries a real idea: quality is relative to what was asked for, not absolute. A cheap product that does exactly what it promised is high quality; an expensive one that misses the requirement is not.

The PMBOK definitions worth pairing with it:

• Conformance to requirements: the project's processes and products meet the written specification.
• Fitness for use: the product can be used as it was intended.

Common misconceptions, which the notes list and which make a good opening paragraph: that quality is difficult to define but recognisable on sight, that quality is expensive, that quality is craftsmanship, that quality is luxury, and that quality is in short supply. Each is wrong for the same reason: they confuse grade with quality. A low grade product can be high quality, and that distinction is worth stating.

Project quality management includes all activities of the overall management function that determine the quality policy, objectives and responsibilities, and implement them through quality planning, quality control, quality assurance and quality improvement within the quality system. That sentence answers “what is project quality management” in one line, and names all four activities.

The three processes, and the QA versus QC distinction asked 20×

This is the most repeated question in the chapter, phrased as “how quality assurance and quality control are implemented in order to deliver a successful project”. It has appeared in at least eight sittings almost word for word.

Quality planning identifies which quality standards apply to the project and determines how to satisfy them. Its principles: quality is determined by the customer's requirements, and the expected level of quality can only be achieved through quality planning at project initiation.

Quality assurance is the process used to ensure the quality of products or services, with constant effort to enhance quality practices so continuous improvement is expected. A dedicated QA team defines the process and procedure to achieve and improve quality.

Quality control monitors specific project results to determine whether they comply with relevant quality standards, and identifies ways to eliminate causes of unsatisfactory results.

To answer “how are they implemented to deliver a successful project”, do not just define them. Walk the project: plan the standards before work starts, assure by auditing the process and training people while work happens, control by inspecting and testing each deliverable, and feed defect data back into the process so the same defect is prevented next time. That loop is the answer.

The seven basic tools of quality control asked 10×

Individual tools show up constantly as short notes and as comparison questions: Pareto chart, control chart, cause and effect diagram, histogram, box plot versus scatter plot. Learn the set once.

Two more tools the notes add: check sheets, a generic data collection and analysis tool adaptable to many purposes, and checklists.

Pareto chart, and why it is the one they ask about asked 7×

A Pareto chart is a bar chart of the causes of defects, ordered from most frequent to least, with a cumulative percentage line drawn over it. It is built on the Pareto principle, the 80/20 rule: roughly 80% of the problems come from 20% of the causes.

For a worked short note, invent a small example: on a college MIS, defects logged as 45 login failures, 30 report errors, 12 slow pages, 8 print issues, 5 others. The first two bars are 75 of 100 defects, so fixing login and reporting removes three quarters of the problem. Two named bars and a percentage make the answer concrete.

Total Quality Management asked 7×

TQM is an approach to project quality management that takes everything related to quality into consideration. The processes that produce services are thoroughly managed, minimising process variation and providing a predictable quality level, and all members of the organisation participate in improving processes, products, services and the culture in which they work.

That last clause is the definition's real content: TQM is distinguished from ordinary quality management by being everybody's job, continuously, rather than a department's job at the end.

Tools and techniques for TQM, which 2073 asks for by name: Pareto chart, scatter plot, control chart, fishbone or Ishikawa diagram, histogram, check list, check sheets, assessment of customer need, market analysis, competition analysis, workflow analysis, and logistic analysis.

Related improvement theories the notes cover, each good for a line:

• Lean production: cutting out waste while ensuring quality, on the principle that waste brings cost. Applies from design through production to distribution.
• Kaizen: continuous improvement in small increments, driven by everyone, rather than occasional large projects.
• Just in Time (JIT): producing or receiving material only as it is needed, so inventory does not hide problems.
• Six Sigma: a data driven methodology to reduce defects to about 3.4 per million opportunities, following the DMAIC cycle: Define, Measure, Analyse, Improve, Control.
• PDCA cycle, the Deming or Shewhart cycle: Plan, Do, Check, Act, repeated. Plan the change, Do it on a small scale, Check the result against expectation, Act by adopting or abandoning it, then plan again. It is the engine underneath continuous improvement, and it is a recurring short note.

Steps to improve quality in an ICT project asked 9×

Asked in almost every sitting as the second half of a quality question: “how to improve quality management in ICT project?” The notes give eight steps, and they are the answer:

1. Define quality to match user needs, not internal opinion.
2. Broadcast simple quality metrics so the team can see them.
3. Fine tune goals to include quality, so it is not traded away silently.
4. Get the requirements right, since most defects originate there.
5. Test smarter to test less, targeting where defects actually cluster.
6. Design applications to reduce bug risks.
7. Optimise the use of testing tools, automating the repetitive parts.
8. Use a maturity model such as PMMM or CMM.

Testing of IT systems, the six levels, useful whenever the answer needs concrete quality control activities:

• Unit test: each individual component, to ensure it is defect free.
• Web test: a series of HTTP requests for testing websites.
• Integration testing: between unit and system testing, on functionally grouped components.
• System testing: the entire system as one entity.
• Load testing: stress testing under various loads, network types and client configurations.
• User acceptance testing: performed by the end user before accepting the delivered system.

The balanced scorecard asked 20×

This is the single most reliable mark on the paper. It has been an option in the short notes question in 20 of the 22 sittings, and short notes are worth 3 to 5 marks each. It takes twenty minutes to learn properly and it will almost certainly be there.

Origin, worth one sentence because it explains the whole idea: in 1992, Robert Kaplan and David Norton set out to fix the problem that financial measures are a lagging report. They tell you what happened last quarter but cannot look forward, so Kaplan and Norton looked for leading indicators that could predict performance instead of recording it. It was developed for for-profit companies and later adapted for non-profits and government.

What the balanced scorecard balances, which is a neat four point answer:

• Financial against non-financial measures.
• Short term against long term measures.
• Performance drivers (leading indicators) against outcome measures (lagging indicators).
• It should contain just enough data to give a complete picture of organisational performance, and no more.

Why use it, per the course slides: to achieve strategic objectives, to provide quality with fewer resources, to eliminate non-value-added effort, to align customer priorities and expectations, to track progress, to evaluate process changes, to continually improve, and to increase accountability.

Steps to build one:

1. Establish a clear vision of the future.
2. Define strategic objectives.
3. Determine the critical success factors.
4. Choose indicators to measure and monitor performance.
5. Set goals, action plans and initiatives.

The three uses: to bring an organisation's strategy to life so people can make decisions with it; to communicate the strategy across the organisation, which is where the strategy map is critical; and to track strategic performance through monthly, quarterly and annual reports.

For an ICT project example, sketch the four rows with one metric each: Financial, project delivered within a 10% cost variance. Customer, user satisfaction above 4 of 5 after go live. Internal process, defect density below 2 per thousand lines. Learning and growth, every developer trained on the new stack. Four concrete metrics turn a definition into an application.

Importance, and the numbers that make the point asked 22×

Project communication management is the collection of processes that make sure the right messages are sent, received and understood by the right people. All three verbs matter: a message that was sent but not understood has not been communicated.

Why it is specifically a problem in ICT projects, which is what the paper keeps asking:

• The culture of IT professionals has not traditionally made them good communicators.
• Research shows IT professionals must communicate effectively to succeed in their positions, and strong verbal skills are a key factor in career advancement.
• IT deliverables are intangible, so progress cannot be seen and must be described, which puts the whole burden on communication.
• Projects are cross functional: technical staff must explain to business stakeholders who do not share the vocabulary.
• Project managers must understand good communication as a means of achieving project success, not as a soft extra.

Keys to good communication: focus on needs, both group and individual; mix methods, formal and informal; and set the stage for communication early in the project.

The communication model asked 5×

Five parts, and the paper expects all five. This is also the structure that lets you explain where communication fails, which is the harder half of the hazards question.

Factors determining which communication technology to use: availability, project environment, project length, urgency, and preparation level.

Communication methods: face to face, telephone calls, electronic mail and other electronic tools, radio broadcasting, social media networking, paper advertisement. Any method can be used based on need and experience.

The four processes asked 12×

Communications planning determines who needs what information, when they will need it, and how it will be given to them. Those three questions are the process in one line. Every project should include a communications management plan, and a stakeholder analysis for project communications aids the planning.

Information distribution makes needed information available to stakeholders in a timely manner. It implements the communication management plan and responds to unexpected requests. The phrase the notes give, worth quoting: getting the right information to the right people at the right time and in a useful format. Considerations include using technology to enhance distribution, and mixing formal and informal methods, where formal means a project report and informal means face to face conversation.

Performance reporting keeps stakeholders informed about how resources are being used to achieve project objectives. It includes the latest status reports, progress reports and forecasting. Common report types: Gantt charts, S curves, histograms and tables. The work performance measures communicated have impacts throughout the knowledge areas, including scope, time, cost and quality.

Communication channels, and the one formula in this chapter asked 4×

Communication requirement analysis totals up the stakeholders' requirements. Project managers should treat the number of potential communication channels as an indicator of the complexity of a project's communication.

Information needed to determine communication requirements: organisational charts; the project organisation and stakeholder responsibility relationships; disciplines, departments and specialities; logistics and personnel; internal and external information needs; stakeholder information; and the project scope and project management plans.

Running an effective meeting asked 8×

Nearly always the second half of a communication question: “how to run the effective meeting in the project?” The notes give eight steps, and the first one is the one that makes the answer look thoughtful.

1. Determine if a meeting can be avoided. Before organising one, ask whether you really need it, who needs to attend, and how much time you need.
2. Define the purpose and intended outcome of the meeting.
3. Determine who should attend.
4. Provide an agenda to participants before the meeting.
5. Prepare handouts and slides ahead of time.
6. Start the meeting on time.
7. Run the meeting professionally. Keep to the agenda, manage the discussion, record decisions and actions.
8. Build relationships with attendees.

Close with what happens afterwards, which the list omits and examiners like: circulate minutes with named action owners and dates within a day. A meeting whose decisions are not written down and assigned has not finished.

Why a reporting system is required, and the hazards of communication error asked 8×

This exact pair has been asked in at least six sittings: “why reporting system is required in a project? Explain the hazards of communication error in a project.” Answer it in two clearly separated halves.

Why a reporting system is required:

• It gives stakeholders a consistent, comparable view of progress instead of ad hoc updates.
• It creates an early warning system: variances show up in a report before they show up as a crisis.
• It provides an audit trail and a record of decisions, which matters for contract and for lessons learned.
• It supports management by exception, so senior people spend attention only where the numbers deviate.
• It reduces the interruption load on the team, because information is published rather than asked for repeatedly.

Hazards of communication error:

• Wrong requirements built. A misunderstood requirement becomes working software that solves the wrong problem, and it is found only at acceptance.
• Duplicated or omitted work, when two people each assume the other is doing it, or neither does.
• Schedule and cost overrun, because problems reported late are problems corrected expensively.
• Conflict and loss of trust within the team and with the client.
• Wrong decisions by management, taken on stale or optimistic information.
• Scope creep, when informal verbal agreements are never written down or costed.
• Loss of reputation and of the client, in the worst case, and legal dispute where the contract is involved.

Formal versus informal, horizontal versus vertical asked 6×

Two comparison questions that recur, and both want a table.

On “degree of formalness”, which 2073 asks about specifically: vertical communication is generally more formal than horizontal, and upward communication is the most formal of all, because it is going to someone with authority over the sender. That asymmetry is also why the upward channel filters bad news, and why a project manager must actively go looking for problems rather than waiting to be told.

Defining risk, and the two halves people forget asked 22×

Two things distinguish a strong answer here:

• Risk includes opportunity, not just threat. Most candidates define risk as something bad. PMI is explicit that risk is uncertainty in both directions, and risk management includes maximising the results of positive risks as well as minimising negative ones. That single clause is often the difference between three marks and four.
• Risk is about the future. A problem that has already happened is an issue, not a risk. Once a risk occurs it stops being a risk and becomes an issue to be managed.

Characteristics of risk: loss and uncertainty. A risk is an event that may or may not occur, and if it occurs it generally causes loss.

Related terms the paper asks about:

• Risk tolerance: the amount of acceptable risk.
• Risk averse: someone who does not want to take risks.
• Risk factors: probability of occurrence, range of possible outcomes, expected timing of the event, and anticipated frequency of risk events from that source.
• Risk audit: the process of evaluating and documenting how well risk responses address recognised hazards and their root causes, and how effective the overall risk management process is. Note that a risk audit examines the process, not just individual risks.

Types of risk, and sources in IT projects asked 11×

Two different lists, and the paper uses both. Know which one is being asked for.

Types of risk, the seven from the notes:

1. Project risk: arises from the technical aspect of the work or the work product.
2. Process risk: arises from the formation and processes of the project or the methodologies used.
3. Product or technical risk: affects quality, performance, or even whether implementation is possible.
4. Business risk: affects the organisation developing or procuring the software.
5. Known risks: easily uncoverable.
6. Predictable risks: extrapolated from past project experience.
7. Unpredictable risks: may or may not occur and are extremely difficult to identify.

The last three are a different axis from the first four: they classify by how knowable a risk is rather than by where it comes from. Saying that explicitly shows you understand the list rather than copying it, and it sets up a good closing line: known risks get a response plan, unpredictable risks get a contingency reserve, because you cannot plan for something you cannot name.

Common risks in IT projects, the five categories, which is the answer to “sources of risk in IT projects”:

For a Nepal specific answer add: power and connectivity reliability, engineers leaving for jobs abroad mid-project, and procurement delays under the Public Procurement Act. Naming a real local risk lands better than a generic list.

The PMI risk management process asked 10×

2072 Kartik asks you to “illustrate the Risk management model with block diagram according to PMI Project Risk Management process”. Draw it as six boxes in a line with a feedback arrow from the last back to the first, because risk management is a loop, not a one-off.

A risk management plan is the description of the procedure that will be followed to manage risk. It is part of the project planning phase.

Risk identification techniques asked 9×

Asked directly in at least six sittings as “describe the risk identification techniques in ICT project”. Six named techniques, and the paper sometimes asks for brainstorming and Delphi specifically.

The problem tree approach, which 2079 asks about: a diagram with the core problem in the middle, its causes as roots below, and its effects as branches above. It forces you past symptoms to root causes, and it inverts cleanly into an objective tree where each negative statement becomes the positive outcome the project should deliver.

The risk register asked 6×

A risk register is the tool used to identify and track potential risks in a project or organisation. It contains the outcomes of the risk management processes as they are conducted, and the electronic form of it is called a risk database.

Contents: the list of identified risks, the list of potential responses, root causes of risk, and updated risk categories. Per risk it records:

• Risk ID: risk name or identifier
• Risk description: a brief explanation
• Risk category: schedule, budget, technical, external, and so on
• Risk analysis: the probability and impact
• Priority derived from probability and impact
• Status: open, ongoing, closed
• Risk response: the mitigation or other strategy
• Risk owner: the team member responsible for deploying and supervising the response

Worked example, which is what 2076 Chaitra and 2082 Baishakh want when they ask you to prepare a risk register for a College MIS. Draw the table, do not describe it:

State your assumptions above the table, since the question invites them, and make sure your responses use the named strategies below (mitigate, transfer, accept, avoid) rather than vague verbs. That is what shows the register came from a method.

Qualitative versus quantitative analysis asked 8×

A recurring comparison question. Risk analysis is the process of analysing identified risks, their probability of occurrence and their impacts, and the results are stored in an updated risk register containing the priority of risk to be dealt with.

Probability and impact matrix: a tabular representation of risk level based on the possibility of occurrence and the potential harm to the project. Typically a 3 by 3 or 5 by 5 grid with probability on one axis and impact on the other, colour banded into high, medium and low. Its output is the priority order.

A watch list is a list of risks that are low priority now but are still recorded and reviewed periodically, because a low priority risk can become a high priority one as the project changes.

Top Ten Risk Item Tracking keeps the ten highest risks visible, reviewed at every status meeting, with their rank this period and last period recorded so movement is visible.

The quantitative tools asked 9×

These appear both inside risk questions and separately as short notes and comparison questions, so each is worth knowing on its own.

Risk exposure. The basic quantitative measure.

Decision tree analysis. A diagram of decisions and their possible consequences, used to choose between options under uncertainty. Square nodes are decisions you control; circle nodes are chance events you do not. Each branch carries a probability and a payoff, and you compute the expected monetary value.

Simulation, usually Monte Carlo. Instead of one estimate per variable, you model the whole project many times with randomly drawn values, and get a probability distribution of outcomes. The notes give the procedure:

1. Identify the variables.
2. Determine the probability distribution of each variable.
3. For each variable, select a random value based on that distribution.
4. Run a deterministic analysis, one pass through the model.
5. Repeat steps 3 and 4 many times to obtain the probability distribution of the model's results.

Sensitivity analysis and the tornado diagram. Sensitivity analysis varies one input at a time to see how much the outcome moves, identifying which variables matter most. A tornado diagram presents that result: one horizontal bar per variable showing the range of outcome it causes, sorted longest at the top, so the shape narrows downward like a tornado. The variables at the top are where management attention belongs.

SWOT analysis itself, a frequent short note: a structured review of internal Strengths and Weaknesses against external Opportunities and Threats. Internal factors are things you control, external ones are not. The notes give a worked example of four people starting a film business: strengths are industry contacts and strong sales and technical skills; weaknesses are no accounting experience, no marketing strategy, little money and no website; opportunities include a potential large client project.

Response strategies asked 12×

Asked constantly, both as “how a project manager develops a risk response plan” and as “what are the response strategies for negative risk”. Risk response planning is the process of creating options to improve chances and cut down obstacles to project goals, thus lowering total risk. Typical resolution actions: research and review, eliminate and review, reduce and protect, accept and protect.

Contingent response strategies, which apply to both positive and negative risks: develop a contingency plan, create a contingency allowance procedure, and plan for alternative development. A contingency plan is executed only if a defined trigger occurs, and naming the trigger is what makes it a plan rather than an intention.

Worked answer: three typical software risks and two countermeasures each asked 1×

2073 Shrawan gives 8 marks for exactly this. It is a structured answer, so structure it: name the risk, say why it happens, then give two named countermeasures using the MATA strategies.

Notice that every countermeasure is labelled with its strategy. That is a small move which shows the answer came from the framework rather than from common sense, and it costs one word each.

Definitions, and the vocabulary the paper uses asked 21×

Procurement means buying goods or services from a third party. It is the group of processes required to purchase the products, services, goods or results needed from outside the project team to perform the work.

The words “from outside the performing organisation” are the definition. If the work is done by your own staff it is not procurement, it is resource management.

Organisations or individuals providing procurement services are called suppliers, vendors, contractors, subcontractors or sellers. Supplier is the most widely used. Most organisations do some form of outsourcing to meet their IT needs, and spend most of that money within their own country.

Why procurement is needed, which 2080 Bhadra asks directly:

• Skills the organisation does not have, and cannot economically build for one project.
• Capacity: internal staff are committed elsewhere.
• Cost: buying is cheaper than building for non-core work.
• Speed: a ready product ships faster than a built one.
• Risk transfer: a fixed price contract moves cost risk to the seller.
• Focus: it lets the organisation concentrate on what it is actually good at.

The six procurement processes asked 21×

Plan purchases: the make or buy decision. This is the first real decision, and the notes give both columns:

The two inputs the notes emphasise:

• Organisational process assets (OPA): valuable information, documents and knowledge tools accumulated over time, essentially the lessons learned from the past, including the organisation's procurement history.
• Enterprise environmental factors (EEF): conditions of the marketplace, what is available, from whom, and under what conditions.

Plan contracting produces the procurement documents. Two you must distinguish:

A contract statement of work describes the work required for that particular contract. It is a type of scope statement, and a good one gives bidders a better understanding of the buyer's expectations.

Request seller responses gathers bids, quotes and proposals. Three advertising options: approach the preferred vendor, approach several vendors, or advertise to anyone interested. Two tools:

• Bidder conferences: meetings with vendors held before bids are prepared, to ensure all prospective sellers have a clear and common understanding of the procurement. The goal is to give equal chances to all potential sellers. Fairness is the whole point: a bidder who understood the requirement better because of a private conversation has been given an advantage.
• Advertising in newspapers or specialised media, which increases the size of the existing list of potential vendors.

Selecting a seller asked 7×

Part of the execution phase. Organisations do an initial evaluation of all proposals and bids, develop a shortlist for further evaluation, and shortlisted sellers often prepare a best and final offer (BAFO). The final output is a contract signed by the buyer and the selected seller.

Source selection criteria should be developed before releasing a formal RFP or RFQ. The warning the notes give is worth quoting: avoid accepting ideas just because they appear good on paper; consider previous performance and management style too.

Bidder A wins on 760 against 705, despite being more expensive, because technical approach and past performance carry more weight than price. Stating why the winner won is the part that earns the mark.

Contract types, and who carries the risk asked 8×

A contract is a mutually binding agreement that obliges the seller to provide the specified products or services and the buyer to pay for them. Because contracts are legally binding, there is more responsibility to deliver the work exactly as stated.

Point of total assumption (PTA): the cost at which the contractor bears full responsibility for every extra rupee of contract cost. Contractors have a financial motive to limit overruns because they do not want to reach it.

Tender versus quotation (2076 Ashwin) and quotation based versus tender based purchase (2072): a quotation is a simple price request for a well defined, usually low value item, decided mainly on price and often from a short list. A tender is a formal, publicly advertised, sealed bid process for high value or public procurement, with published criteria, a deadline, a formal opening, and a documented evaluation. Tender is slower and far more transparent, which is why public money uses it.

Step by step procurement in a Nepali government office asked 1×

2080 Baishakh asks for this specifically, worth 5 marks. It follows the Public Procurement Act 2063 and its Regulations, and the answer should be a numbered procedure, not an essay.

1. Prepare the annual procurement plan and confirm budget authority for the financial year.
2. Prepare the specification, cost estimate and procurement documents, including the bill of quantities where relevant. Estimated value decides the method used.
3. Choose the procurement method by threshold: direct purchase for very small amounts, sealed quotation, national competitive bidding, or international competitive bidding for the largest.
4. Publish the notice in a national daily newspaper and on the office and PPMO portal, with the legally required minimum bid period.
5. Sell or issue the bid documents, hold a pre-bid meeting if required, and issue any clarification to all bidders equally.
6. Receive sealed bids up to the deadline, with the required bid security.
7. Open the bids publicly at the announced time, in the presence of bidders' representatives, and read out the prices.
8. Evaluate in two stages: preliminary and technical responsiveness first, then financial comparison of responsive bids only.
9. Award to the lowest evaluated substantially responsive bidder, issue the letter of intent, and allow the statutory period for complaint or review.
10. Sign the contract after performance security is provided.
11. Administer the contract: inspection, progress payments, variation orders where permitted.
12. Complete, inspect and hand over, release the performance security, and close the contract with the records retained.

Two details that show real knowledge: the Public Procurement Monitoring Office (PPMO) is the regulator, and the award goes to the lowest evaluated substantially responsive bid, not simply the lowest price. A bid that is cheapest but non-responsive is rejected before price is even considered.

Contract closure, and how it differs from project closing asked 9×

Closing procurements is part of the project closing phase. The project team should determine whether all work was completed correctly and efficiently, and update records to reflect final results, because keeping records helps in future. The formal approval and closing requirements should be specified in the contract itself.

Early termination is a special case of contract closure, brought about either by agreement of the parties or by one party's default.

Tools to assist in contract closure:

• Procurement audits, which identify lessons learned in the procurement process.
• Negotiated settlements, which help close contracts more smoothly.
• A records management system, to organise, find and archive procurement documents.

How to manage contract closure smoothly, since 2081 asks that too: keep the acceptance criteria in the contract from the start; inspect and accept deliverables progressively rather than all at the end; keep complete records of correspondence, changes and payments throughout; settle claims by negotiation before they become disputes; run a procurement audit; and issue formal written notice of closure. Almost every difficult closure is the result of something not written down months earlier.

The closing process and why it matters asked 9×

2081 Baishakh asks for the need of the closing process and its importance with an example of a mega project. Close project is part of the closing process group. To close a project, all tasks associated with every process group must be complete, the project team must be disbanded, and the project must be approved by the client.

Why closing is needed:

• Formal acceptance converts “we think it is done” into a documented fact, and it is what allows final payment.
• Resources are released to other work, instead of being quietly held by a project that has effectively finished.
• Contracts are closed, ending liabilities and warranties on a defined date.
• Lessons learned are captured while the team still remembers them. After the team disbands, that knowledge is gone.
• Records are archived for audit and for future estimating.
• Handover to operations happens deliberately, with documentation and training, rather than by abandonment.

Administrative closure is the communication side of it: generating, gathering and circulating information to formalise phase or project completion.

The need for monitoring, evaluation and controlling asked 4×

Three related but distinct activities, and distinguishing them is the answer:

The project control cycle, which the CE 701 paper asks for and which is worth knowing anyway, is a four step loop: set the baseline, measure actual performance, compare actual against baseline to find the variance, then take corrective action and update the plan. Then measure again. Drawing it as a closed loop is the diagram.

For a local example, 2079 Baishakh asks for one: a road or drinking water project where monthly physical progress is measured against the schedule, payment is released against verified measurement rather than claimed progress, and a mid-term evaluation decides whether the design still fits what the community needs. That is monitoring, controlling and evaluation in one example.

Named methodologies asked 6×

Organisations invest heavily in training project managers in general skills, yet managers often still do not know how to adapt those methods to the organisation's specific needs. That is the problem an internal methodology solves. The phases used are the familiar five: initiation, planning, executing or production, monitoring and control, and closing.

PRINCE2, Projects in Controlled Environments, originally developed for IT projects. It has eight process groups, and that number is what the paper is checking:

1. Starting up a project
2. Planning
3. Initiating a project
4. Directing a project
5. Controlling a stage
6. Managing product delivery
7. Managing stage boundaries
8. Closing a project

The distinction worth adding: PMBOK is a body of knowledge, PRINCE2 is a method. PMBOK describes what you should know; PRINCE2 prescribes what you should do, with defined roles, stages and management products. That single sentence is often the whole question.

Rational Unified Process (RUP) is an iterative software development process focused on team productivity, delivering best practices to all team members. It is a process for object oriented models, also called the Unified Process Model. Three reasons for using it: it is iterative; its practices provide an example structure for doing and explaining object oriented analysis and design; and it is flexible, applicable in a lightweight and agile way.

Six Sigma improves output quality by identifying and then removing the causes of defects, using quality management methods that are both empirical and statistical. A staff member with Six Sigma expertise is usually hired to monitor the process. Two methodologies:

• DMAIC: Define, Measure, Analyse, Improve, Control. Used to improve an existing business process.
• DMADV: Define, Measure, Analyse, Design, Verify. Used to create a new process or product.

The name comes from the target: six standard deviations between the mean and the nearest specification limit, which corresponds to about 3.4 defects per million opportunities. Quoting that number is what turns a vague answer into a precise one.

Why IT projects need custom processes asked 5×

2081 Baishakh asks “why custom processes need for IT projects?” for 5 marks, and 2075 Chaitra asks it as a short note. The notes give seven reasons, and they are specific enough to be worth learning verbatim:

1. The customer's role is dominant.
2. The environment is more dynamic.
3. Tasks are mental, unique and complex, not physical and repeatable.
4. Society is more democratic and educated, so instruction alone does not work.
5. Individuals have higher aspirations and expectations.
6. The government's role is less clear, and its performance more closely scrutinised.
7. Sources of knowledge are different: tacit knowledge held by the practitioner rather than written procedure.

Tailoring provides the necessary adjustment of project activities to reflect the uniqueness of the project while keeping the project's goal in mind. Since every project is unique, an organisation's processes will usually need tailoring to ensure success.

A customised SDLC: the multi-pass model. It is not a full development methodology but a merge and fit of the iterative and incremental model with the agile model. Its logical phases: outline the initial requirements and focus on the mission; sort out major requirements, prioritise by business need and develop an initial stable solution the iterative and incremental way; increase client involvement and develop more functional solutions the agile way; then finalise requirements, enhance design, develop the complete solution and test rigorously the iterative and incremental way.

Barriers to implementing tailored project management, a clean eight point list:

• Lack of sustained top management commitment
• Insufficient training on integrated project management
• Lack of planning
• Lack of resources
• Lessons learned and good practices not shared across projects
• Not invented here syndrome
• Poor incentives or award criteria
• Over-extended reviews

Project management maturity asked 4×

Project management maturity is a formal tool used to measure an organisation's project management maturity. Once the initial level and the areas for improvement are identified, it provides a logical path for progressive development. It follows the Software Engineering Institute's Capability Maturity Model with five evolutionary levels, and examines maturity across the ten knowledge areas.

PMI certifications, sometimes asked alongside: CAPM, Certified Associate in Project Management, for those beginning; PMP, Project Management Professional, the main credential for experienced managers; and PMI-PBA for business analysis.

ICT code of ethics asked 5×

A frequent short note. Ethics is a set of principles that guides decision making based on personal values of what is considered right and wrong. Making ethical decisions is an important part of a project manager's personal and professional life.

How to create a code of ethics:

1. Decide why you are writing it. To inspire employees, or to spell out expected behaviour?
2. Begin with an introduction explaining the purpose and what you hope to achieve.
3. Add the items, covering interpersonal relationships, behaviour expected around customers and clients, and items specific to your company or industry.
4. Decide how you will implement it, since a code nobody enforces changes nothing.

Enablement and empowerment, the two related ideas the notes attach to project excellence: enablement means people's knowledge and abilities are promoted and developed, with personal interest and career development supported; empowerment means they work in an environment that allows and motivates them to apply their skills, talent and creativity, acting in coordination and taking initiative.

Future trends in project management asked 6×

Asked as a short note in several sittings, including “future trend of ICT project” and “trends in cloud computing”. Give six or seven with one line each.

• Artificial intelligence and automation in scheduling, estimating and risk prediction, with historical project data used to forecast rather than expert opinion alone.
• Cloud computing: infrastructure bought as a subscription instead of a capital purchase, which removes procurement lead time, converts capex to opex, and scales with demand. For a Nepali project it also removes the data centre and power problem.
• Agile and hybrid approaches spreading beyond software into general project management, with hybrid becoming the norm rather than pure agile or pure waterfall.
• Remote and distributed teams as standard, and the communication tooling and trust practices that require.
• Data driven decision making: dashboards and real time metrics replacing monthly status reports.
• Emphasis on soft skills and emotional intelligence, as the technical work is increasingly automated and the manager's value moves to people.
• Sustainability and social responsibility as explicit project objectives, not side constraints.
• Outsourcing, off-shoring and the gig economy reshaping how teams are assembled.

For “how are you going to manage an IT project that demands regular updates with new trends in market” (2070 Chaitra), the answer is structural, not a list of technologies: choose an iterative life cycle so the plan can absorb change, keep the architecture modular so a component can be replaced without a rewrite, use rolling wave planning with the near term detailed and the far term outlined, build change control that is fast rather than obstructive, and release frequently so the product meets the market before the market moves again.

How to use the bank

• Work backwards from the newest paper. 2082 Bhadra is the most recent, and the pattern repeats, so the last three papers are the best prediction of the next one.
• Every question links to its answer. The links after each question go to the topic cards that contain the answer. If a question has three links, the full answer needs all three.
• Numericals are marked with a tag, and each one is worked in full in chapter 4 or chapter 5.
• Search works here too. Type a phrase into Find a topic and the bank filters with everything else.