The essential knowledge for the PRINCE2 foundation exam. All bullet points are very brief, for details you better refer to the excellent PRINCE2 foundation training manual by Management Plaza.
Some essential abbreviations:
- BC: BC
- CPM: Corporate/Programme Management
- PID: Project Initiation Document
- PB: Project Board
- PM: Project Manager
- PMT: Project management Team
- PPD: Project Product Description(s)
- PP: Project Plan
- SU: Starting Up phase
- TM: Team Manager
- WP: Work Package
- projects introduce change, are unique and bring a certain amount of uncertainty
- have defined start and end (temporary), cross-functional (involve people from different departments)
- PRINCE2 definition: project is a temporary organization created for the purpose of delivering one or more business products according to an agreed BC
- program: set of related projects
- principles
- themes (what items must be addressed, e.g. BC, Organization, Quality, Change)
- processes (what activities and by whom)
- tailoring (the project environment)
framework for good project practice for those involved in a project:
- continued business justification (throughout the project lifetime)
- learn from experience
- defined roles and responsibilities (who does what, what to expect from others)
- manage by stages (separated by decision points, manageable chunks)
- manage by exception (when things go outside the agreed tolerances)
- focus on products (everyone has the same idea of the product)
- tailor to suit the project environment (different paperwork depending on size, environment, complexity, ...)
- timescales (the "when")
- costs (budget)
- quality (usable product)
- scope (defined scope, stakeholders involved, what is mandatory and what is not)
- benefits (the "why", ROI, measurable)
- risk (what risks, how many, how to manage)
...or in short BCQRST. These variables need to be continuously monitored.
- themes: knowledge areas of the project
- aspects of project management that need to be adressed continuously throughout the project
- core activity and need to be defined whenever a project starts
- BC: The "why"
- Progress: The "Where are we now? Where are we going? Should we carry on?"
- Organization: The "who"
- Plans: The "how", "how much" and "when"
- Quality: The "what"
- Risk: The "what if"
- Change: "What's the impact?"
- Lessons learned
- Tailoring
- document describing how, when and by whom a target can be achieved
- Project Plan gets updated in every stage and is compared to the baselined PP
Three major plans
- Project Plan (high level, mainly for PB)
- Stage Plan (day-to-day-work of the PM, focused on products)
- Team Plan (for TM)
- insufficient product definitions (lead to wrong product)
- lack of communication
- poor estimation of time and cost
- established for long tine in the industry, common vocabulary
- applicable to any project
- gives a structure for roles and responsibilities
- always focused on the product
- viability of project is constantly checked
- purpose: BC theme provides structure to judge whether BC is desirable, viable, achievable and worth the continued investment
- used to document justification for project based on estimated costs against anticipated benefits
- one of the first things of a PM: ask for the BC (although many projects don't have one)
- continuously maintained throughout the project (because changes in requirements can also lead to changes in the BC, e.g. if additional staff is needed)
- needs to be verified by PB before project starts
- Executive is responsible for the BC and for securing funding
- Customer and Supplier will both have a BC (so there are min. 2)
So what do you get?
- output: what product will be delivered (for specialist users)
- PRINCE2 distinguishes products between management (documents for communication) and specialists (given to users)
- outcome: what can users do better with that product (result of change derived from output)
- benefits: measurable improvements by using this product (advantages, usually by at least one of the stakeholders)
- identify benefits and how/when they can be measured, must include a timeline (if you can't measure it, don't claim it)
- senior user (represents all users) is responsible for specifying and realizing the benefits (continued commitment to the project)
- Executive Summary
- reasons for project, estimated costs, risks (summarized) and expected benefits and dis-benefits
- also includes timescales (project start/end, when will benefits be realized) and an investment appraisal (ROI calculation, costs vs. benefits) and major risks
- three business options: do nothing, do the minimum, do something
- purpose: define and establish the project's structure of accountability and responsibilities (or: the "who")
- responsibilities are assigned to roles
- one person can have multiple roles
- stakeholders need to be informed, decision makers need to be on the board
- stakeholders may oppose the project
- CPM: Comissioning the project (appoint Executive)
- Direction level: PB (make decisions, approve resources, plans, deviations)
- Management level: PM (run the project according to the goals)
- Delivery level: TM (create products with a certain quality within timescale and costs)
PMT includes the levels 2-4.
- represents Executive/Business, User and Supplier stakeholders
- includes CPM, PB, Business/User/Supplier Assurance, PM, TM, Change Authority and Project Support
- PRINCE2 is based on customer/supplier environment: customer specifies the result and pays, supplier provides resources/skills and delivers the results
- customer/supplier can be inside the same company
- usually the executive represents the business role
- PMT has defined responsibilities for directing, managing and delivering the project
- defined responsibilities for directing, managing and delivering
- have a strategy to manage communication between stakeholders
- consists of Customer/Executive, Senior User and Senior Supplier (decision makers)
- only one Executive, but potentially multiple senior users/suppliers
- users are in the PB to make sure that the correct product is developed in good quality (senior user, connects PMT and users), supply benefits information
- executive owns BC and has the final word on decisions
- PB need to agree stage tolerances (WP tolerances may be set by TM)
- PB is accountable for success/failure of the project and provides a unified direction to project and PM
- responsible for communication with stakeholders
- business assurance vs. user assurance = value for money vs. product works as expected
- PB provides resources and funds, supports the PM, ensures effective communication
- PB may delegate responsibility to a Change Authority (person/group)
- not necessarily approved by CPM
- PM manages on day-to-day-basis and usually comes from the customer (preferred by PRINCE2)
- needs to be proactive, may take roles Project Support, Team Manager and Change Authority
- stakeholder management: identify and communicate effectively with people that have interest in project outcome
- defines roles needed for the project (but doesn't assign people to these roles)
- TM is optional, may be needed for geographical reasons or when the project is big or complex/highly specialized
- PM may be supported by PMO/project support (administrative tasks, Configuration Management)
- document describing how communication will be done (what, to whom, how often, internal/external)
- essentially the rules of engagement of communication (flow of information)
- much of it may come from Corporate guidelines
- Project Brief, Risk and Issue registers are reviewed and Project Assurance is consulted
- responsibility of the PM during Initiating a Project
- contains information on communication methods, tools/techniques, reporting, timing, roles & responsibilities, stakeholders, needed information
- purpose: define and implement the means by which the project will create products that are fit for purpose
- product needs to meet the expectations and can be used as intended, ensure that benefits of these expectations are realised and achieved
- product descriptions must include quality criteria and tolerances (e.g. dishwasher-proof, keeps color for 20 years) to get some details
- quality: total amount of features/characteristics of a product
- provides a method to specify quality, carry out quality control, explain how to get quality approved and facilitates quality management during the project
- Quality Planning
- Quality Control: implement and track quality methods
- Quality Assurance: focus on quality in the organization, independent review, complies to company standards, quality processes are in place
- Project Assurance: inside the PMT, duty of the PB (will delegate to make sure project runs smoothly regarding performance in user, supplier and business areas), useful to double-check the affirmations of PM and may act as an "eye" of the PB, confirms Stage and Project progress against tolerances
- identifying the products to control
- writing a product description for them (product description containing composition, format, development skills, quality criteria/tolerances/methods/acceptance procedures/responsibilities)
- agree on acceptance criteria with PB (quality is assured by PB)
- communicate agreements to stakeholders, common understanding
- establish how quality can be controlled (baseline and tolerances)
- get the quality expectations (e.g. from the client)
- typical questions: budget for critical issues, what needs to be ready on launch, what's the cost for the company if product cannot be used
- customer and supplier agree on acceptance criteria that the product must satisfy when complete
- can be a simple list with the criteria itself, its priorization (MoSCoW) and the current status (Yes/No)
- responsibilities: PM collects inspection/survey and other documents, executive confi
- project and manufacturing, Senior User is responsible for all other acceptance criteria
- defines quality requirements and control methods for all products in a project
- defines how quality standards are applied ("how quality will be done")
- typical topics: what system/standard, tools and techniques, who is responsible for documenting and approving/confirming, timing of activities
- created for all products as part of the planning activities (before PP is completed)
- needs to contain quality criteria, acceptance methods and acceptance responsibilities
- Stage Plan contains the concrete (and final) product descriptions
- typical content: identifier, title (of the product), purpose, composition (parts), quality criteria, quality tolerance, quality method, quality skills (e.g. knowledge for testing), quality responsibilities
- PPD (one document) is the description of the main product and more like an overview and is created in the SU phase
- what does the product need to deliver to get accepted (defines acceptance criteria)
- identify roles and sources of information for project/product
- usually 2-4 pages with a lot of quality-related information
- diary of quality events during the project
- usually maintained by Project Support (just like other administrative tasks)
- may be a spreadsheet with these columns: product id, name, producer, reviewer, approver, target/actual review date, target/actual approve date, result
- four roles: chair (host), presenter (represents product producers), reviewer (reviews, asks, confirms), administrator (admin support for chair) or CRAP
- objectives: assess products against criteria, involve stakeholders, provide confirmation, sign off the product (create baseline, no more changes)
- output: decision to quality-approve products or not (complete, conditionally complete or incomplete)
- presenter requests approval for the product
- Quality Register gets updated with a summary and date of a follow-up meeting
- purpose: facilitate communication and control by defining the means of delivering the products (Why, What, Who, When and How much)
- plan always needs to show that targets are achievable, includes dependencies, budget and schedule but no named resources
- plan theme provides a framework to design, develop and maintain project plans
- failing to plan is planning to fail
- three levels of planning to reflect different management level needs:
- PP: direction level (high-level), used by Project Board, shows major products, resources, activities, their cost and when they will be delivered, approved by executive
- will be baselined for later reference
- Stage Plan: management level, created for each stage with more detail (near the end of previous stage), used by PM day-to-day
- Team Plans: delivery level (team manager), plan the work in WPs
- there may be Exception Plans (when out of tolerances, get project back on track, replaces project/stage plan, PM must inform PB)
- there will be a Benefits Review Plan (part of BC)
- typical contents of plan: prerequisites, assumptions, incorporated lessons, budget, monitoring and control information, tolerances, product descriptions
- types of management products: baseline, records and reports
Products are identified first and then activities, dependencies and resources required to deliver these products
Tasks:
- write PPD (describe main product, SU phase, Senior User/Supplier provide information)
- create product breakdown structure (hierarchical list all products, e.g. Mind Map, but no sequence)
- write product descriptions (for required products)
- create product flow diagram (product flows/interdependencies, sequence of creation of products, a bit like an IKEA assembly diagram)
A product checklist lists all major products and delivery dates.
- Initiation Stage Plan for the first stage is created by PM
- Product-based plans are created by PM and/or TM, used in SU, IP and SB processes
- Stage Plan is created by PM during SB process
- Stage Plan gets updated as soon as actuals are received from a WP
- project plan needs to be approved by PB, is also updated in SB process and at the end of project
- team plans are optional, created by TM
- Executive approves project plan
- purpose: identify, assess and control uncertainty (improve ability of project to succeed)
- risk = set of events which will have an effect on achieving the project objectives / improve the ability of project to succeed
- all projects introduce something new and uncertainty is risk
- risks are communicated in all major reports (also Lessons and End Project Reports)
- risk may be either threat or opportunity
- risk management is one of the main tasks of the PM
- three steps to Risk Management: identification (describe), assess (likelihood, impact) and control (respond)
- risk appetite: how much risk is a company willing to accept
- risk tolerance: acceptable/unacceptable deviations from what is expected
- risk owner: responsible for managing, monitoring and control of risk aspects assigned to him
- risk actionee: carries out risk response action
- document that defines project procedures for Risk Management
- how risks will be identified, assessed, controlled and communicated (techniques and standards to be applied)
- template may already exist in the company/programme, other sources are BC and Project Brief
- captures and maintains information on all risks (threats/opportunities)
- record of risks with their history
- can be a spreadsheet with those columns: identifier, author, date, category (e.g. quality, network, legal, supplier), description (cause/event/effect), probability impact (high/medium/low), proximity (when, e.g. long term or early), risk response category (which one), response, status, owner, actionee
five steps:
- Identify (complete RMS document first, identify context, use checklists and lessons learned from other projects and brainstorm with specialists)
- Assess (probability and impact)
- Plan (steps for response)
- Implement (carry out responses from step 3)
- Communicate (stakeholders, use existing reports)
or I Ate Peaches In China.
- risks are expressed in cause (Volcano eruption in Iceland) / event (wind brings ash into UK airspace) / effect (80% flights delayed/cancelled)
- or: due to X, there is a risk of Y that could result in Z
- estimating is about assessing the probability, impact and proximity for each risk (e.g. via Expected Value or Pareto)
- evaluating is to group all risks and get a risk value for entire project
- each thread/opportunity must be understood regarding probability, impact, proximity and how impact may change over time of project
- existing reports are used for communication, e.g. Checkpoint/Highlight/End Stage/ End Project/Lessons reports
- threats: avoid, reduce (probability or impact), fallback (contingency/plan of actions), transfer (to another party, e.g. insurance), share (common in customer/supplier), accept
- opportunities: exploit (use it), enhance (improve likelihood), share, reject
- money that is put aside to deal with threats/opportunities, fund responses
- cannot be used for anything else
- purpose: identify, assess and control any potential changes in products that have been approved/baselined
- handle change requests and issues that arise during the project (issue and change control)
- don't prevent changes, but get them agreed and approved before executing them
- issues should be prioritized following MoSCoW
- Request for change: on a baselined product
- Off-specification: agreed to be done but not offered by supplier (missing product / product not meeting spec)
- Problem/Concern: anything that the PM needs to resolve or escalate, can be positive/negative
- Configuration Management Strategy: document describing how issues and changes will be handled (e.g. identify/control products, tools, data to keep, responsibilities, scale for priorization/severity),impact assessments
- Configuration Items Records: provide a set of records for each product (metadata, list of attributes like owner, item type, stage, users, source, version), identify user access, relationships and status
- Product Status Account: report on state of products (e.g. on stage level), checks the current version, picture of progress made against the baselined products (usually produced by Project Support)
- Daily Log: diary/notes for all informal information, useful to prepare Risk / Configuration Management Strategy
- Issue Register: document to capture and maintain issues (formal), contains reporter, raised (date), prio, severity
- Issue Reports: describes issue(s) in detail, lists related issues, recommendation, issue type, raised by, impact assessment, decision
- sum of money that customer/supplier agree to use to fund requests for change / change analysis
- Change Authority (assigned by PB) manages this budget, review/approves RfC
- PM can always refer to the change process (e.g. via form) for all change requests, never has to say "no"
Maintain and control changes for each product, two activities at project start:
- Planning: To what level will Change Management be done? Which documents/information do we need?
- Identification: how to identify each product uniquely (file name, e.g. project-product-owner-version-date)
three activities during project:
- Control: Nothing moves and nothing changes without authorization (baselining, archiving, distribution copies, ...)
- Status Accounting: reporting current/historical data for each product in product Status Account format
- Verification & Audit: Are products in line with Configuration Items Records?
- Capture: determine issue type and if formal/informal
- Examine: assess impact on project objectives
- Propose: actions to take (identify options, evaluate, recommend)
- Decide: someone approves/rejects the recommended solution
- Implement: take corrective action
or CEPDI.
- data can be stored in Daily Log, Issue Register and Issue Report
- issues are always escalated to level above (e.g. PM > PB)
- purpose: establish mechanisms to monitor/compare actual achievements against the planned ones, provide a forecast for project objectives, control unacceptable deviations
- Exception: deviation beyond agreed tolerance levels
- PM may set tolerance levels and manage minor deviations himself
- there are Work Package, Stage- and Project tolerances
- delegate authority from one level to the next
- divide project into management stages, authorize only one stage at a time
- time-driven and event-driven progress reports (e.g. Highlight Reports)
- raising exceptions: alert above layer if big issue occurs
Delegating authority:
CPM >>> Project tolerances >>> PB >>> Stage tolerances >>> PM >>> WP tolerances >>> TM
TM >>> WP progress/issues >>> PM >>> Stage progress/exceptions >>> PB >>> Project progress/exceptions >>> CPM
So PB gets (regular and Change/Exception) reports and authorizes Stages while PM get Checkpoint reports, reviews Progress and authorizes WPs.
- chance to check viability, review, authorize
- equate to commitment of resources and authority to spend
- decision points for PB between stages, never overlap
- PM may manage on behalf of PB
- at minimum are two stages in project (Initatiation, Delivery Stage)
- number of stages depends on duration, key decision points, risk, amount of control by PB, confidence, product sensitivity to plan
- stages should be short when there is a lot of risk/complexity
- how companies/teams work, usually linked to skills (e.g. design/build/implement/test)
- grouping work together (by techniques or products)
- may overlap each other and span a Management Stage Boundary
- event-driven controls take place when something happens (e.g. Exception Report)
- time-driven controls take place at pre-defined intervals (e.g. Highlight Report every two weeks)
- Checkpoint Reports: TM reports to PM, progress compared to agreed team plan, status of WP, frequency is defined in the WP
- Highlight Report: PM reports status of stage compared to Stage Plan (not much detail, 1-2 pages)
- End Stage Report: PM creates at end of stage, PB decides whether to authorize, modify scope or stop the project
- End Project Report: PM creates during Closing process and PB authorizes closure, provides overview what went well and what not, review of benefits
Relevant documents for PM:
- PM checks progress via Checkpoint Reports (from TM) and
- Quality Register (maybe also Lessons Log from previous projects)
- PM keeps track of progress via Daily Log, Issue Register, Product Status Account, Quality Register and Risk Register
Structured set of activities to accomplish a specific objective
- Starting Up (SU)
- Initiating a project
- Directing a project
- Controlling a stage (CS)
- Managing product delivery
- Managing a Stage Boundary (SB)
- Closing a project
lifecycle for most important themes:
- BC: created in SU, completed/baselined in Initiation, updated in SB, final update in Closing
- Plan: PPD in SU, plan created/baselined in Initiation, updated in SB, final update in Closing
- before the actual project starts, contains Starting Up and Directing a project
- first, create a project mandate document (trigger for SU, what is desired)
- verify that project is worthwhile (prevent poor projects from starting)
- PB reviews the Project Brief and decides to initiate the project
- purpose: gives direction and scope of project, forms the "contract" between PB and PM
- define product quality, project timeline, costs, risk analysis and commitment of resources
- assemble PID, PID contains almost all project information to date (Project Plan, BC, Strategy documents, Risk Register, Team Plan)
- create BC and Benefits Review Plan
- create project and stage plan
- project board gets the PID and authorizes the project
- PM accepts products and gets approval for them
- close the project by comparing project with the original plan, write End Project Report, plan post-project benefits reviews and deliver Lessons Learned report
- PB revises data and authorizes closing
- responsibility of PB and Executive, occurs before project starts, should be brief (avg. time could be one week depending on size and complexity)
- purpose: reasons for project are established, PMT is assigned, authorities exist, Stage Plan for Initiation is created (do we have a worthwhile and viable product?)
- objectives: create outline BC, obtain advice from other projects, choose/appoint PMT, create Project Brief (information of scope of the project), create PPD, create Stage Plan (for Initiation)
- also the general project approach should be defined (update existing product / from scratch / off-the-shelf solution, internal / external)
- project mandate will be expanded to Project Brief
- Project Brief also contains scope, roles & responsibilities and performance targets
- responsibility of PB, runs from start to end, starts on completing SU
- PB authorizes stages and applies Management by Exception
- purpose: enable PB to be accountable for the project by making key decisions, have overall control and delegate day-to-day work to PM
- objectives: provide authority to initiate the project, deliver products (start delivery stages) and close the project, provide direction and control (PM can seek advice anytime), be the interface to CPM, ensure that benefits will be reviewed
- decisions about tolerances for stage exceptions are made (PB)
- main outputs are approvals (e.g. Stage Plan, Exception Plan, PID), authorizations and notifications
- purpose: understand work that needs to be done to deliver required products (build correct foundation for all stakeholders, necessary for the organization to know before approving)
- objectives: what are reasons, benefits and risks, scope (MoSCoW), time of delivery, ensure quality, identify risks, issues and changes, monitor progress and inform whom and how often
- activities: prepare Risk/Configuration/Quality/Communication Management Strategy, setup project controls, create Project Plan, complete the BC, assemble PID (contains information from most documents created to date)
- begin with the strategy documents, complete BC after Project Plan (since PP contains time and cost information)
- PB needs to "allow" the project to continue via signing off the PID
- purpose: assign and monitor work (review WP status), deal with issues, take corrective action, report progress to PB/stakeholders (communication)
- objectives: focus on delivery, control risks and issues, keep BC under review, deliver products to agreed quality within cost and time and achieve benefits
- main input documents are Stage Plan and PID
- monitoring via Checkpoint Reports and Quality Register (and other registers)
- report to PB via Highlight Report (PB authorizes/reviews)
- PM also maintains logs, registers and Configuration Items Record document
- purpose: manage and control work between PM and TM by placing formal requirements on accepting/executing/delivery of products
- objectives: products are authorized and agreed, team is aware and understands expected effort, time and cost, deliverables are within tolerances, TM provides progress information
- TM needs to demonstrate that products meet their quality criteria (e.g. via Quality Review Meeting) and work gets done
- Team Plan is updated once WP is returned
- also covers acceptance and execution of project work by external suppliers
- WPs have three activities: accept, do and deliver (update Quality Register)
- purpose: provide overview of performance of the current stage, assure PB that products were completed in stage, update project Plan and BC, create Stage Plan for next stage
- objectives: products need to get approved, review documents (PID, BC, Project Plan, Risk Register, Lessons Log), request authorization to start next stage
- End Stage report and next Stage Plan are submitted to PB, BC is updated
- report the performance of the existing stage (PB evaluates against Stage Plan), products and benefits have been delivered (continued business justification)
- for exceptions: prepare Exception Plan, seek approval and replace PP/Stage Plan with Exception Plan
- record information/lessons for later projects
- purpose: fixed point to check if the project reached its objectives and products were accepted
- objectives: verify user acceptance, ensure products are supported after the project, review performance, assess benefits (now and future), address open issues and risks with follow-up action recommendations
- ownership of the project gets transferred to the customer (handover)
- update Lessons Log, Configuration Items Records, Benefits Review Plan (evaluate the project)
- to enable audits, all project information is secured and archived
- prepare project for closure by creating End Project Report, Lessons Learned Report and Acceptance Record
Sources:
- PRINCE2 foundation training manual by Management Plaza
- Flashcards
- http://www.prince2primer.com/key-prince2-foundation-and-practitioner-exam-learning-points
As a minor update I want to add some best practices that are not related to PRINCE2 at all and just summarized for later reference. They may make it into a further (independent) guide.
Goals are often unclear - if you don't ask, executives/board will assume that things are fine. So better ask for details right away. If you don't get them, ask for someone who might know.
Relations matter - if people estimate too defensively it might make sense to get other opinions or bypass them.
To find out whether a goal is realistic, tests can help. They can also build a certain acceptance (e.g. for new software tool). These tests can (and sometimes need to) be a central part of the project.
Often different business units have completely opposing goals. Negotiating is always hard, but it's impossible once there is nothing to negotiate. So try to find a compromise by setting a target corrider (e.g. 30-50% increase in production).
Nobody wants to hear "that is completely unrealistic". If you think so, summarize the (approx.) efforts for all participating business units - once that is done people will be aware of the consequences and get rid of (typical but unfounded) optimism.
Prepare and discuss options like
- more people
- less features (80/20)
- outsourcing (people or 3rd party products)
- postponed deadline
Typical dialogue representing optimisim
CXO
We need a new software tool for purpose X
Internal business unit:
Three years, nothing less!
CXO:
We'll need it in one!
External supplier:
No problem!
Now for time & material projects, external supplier won't make it in a year but has the job and gets the money since the tool is needed. For fixed-price, he won't get more money in this case, but will argue on every tiny feature that is not precisely described since he also won't work for free.
Workaround: Document possible requirement changes for the external supplier that are part of the contract. This may lead to more realistic estimations.
Projects > 2 years are problematic, 18 months should be reasonable for anything.
Track progress by methods you've agreed on during kick-off (status reports, meetings).
Rule of thumb: as soon as 7 people are working on a project full-time than PM is also a full-time job.
A matrix-based project plan is like a team-based Gantt chart. It's easier to read for most people. See this example:
If you need to classify/weighten different projects, consider
- strategic purposes (market, focus)
- time (long/short)
- effort (money, people)
- benefits (realistic/optimistic)
Those aspects should be ordered so they sum up to 100%.
Practice "walking around". Be with the teams when they start their part of the project and at least once/week. Ask if they need support.
Don't try to solve the teams' problems even if you could (roles need to be clear - don't play the guru). You might know better about some aspects, but the team members are the experts in their matter. Use that competence. Always ask critical questions though.
If team members aren't up to the tasks you'll unlikely get more senior ones - so document the effects and communicate to the stakeholders.
If requirements are added now (customer/executive) be positive about it but document and communicate consequences regarding deadlines, costs and staff. Demand a decision. Do the same once team members are pulled out - escalate quickly.
PMs have the burden to raise problems to the board early. So if events have an effect on
- goals
- time
- costs
- staff
raise them quickly. If you don't it'll only get worse. Even if you know you won't reach the goals don't do any fingerpointing. Stick to the facs and find solutions (see Time).
Sometimes you need a decision but don't get it. Before escalating, document the effect of this. Prepare different options in advance. Also make sure you know absences of executives. If you don't get a meeting with all executives, approach them one-by-one.
"Emigrated" colleagues should be able to give feedback in 1-on-1s. Aks them (as any other colleague) for aspects where they see room for improvement. Don't disagree with them directly (even if you do), instead try to discuss concrete examples to find out where their attitude comes from. Demonstrate that they have a (positive) impact to the project ad their work matters.
Meetings should follow a given structure and should be time-based if possible. Good example for a topic:
- 15 minute presentation
- 10 minute discussion
- 5 minutes to summarize and agree on required actions
Agenda and protocol is mandatory and needs to be reviewed. Give hints/links for preparation, otherwise no one will do. Try not to be the hosts since you'll have a preference/opinion on topics as well.
Never invite more people than necessary. If discussions become endless, a host should interrupt and ask people to note their opinion on a card so that the topic can be structured and the discussion becomes fruitful again.
Always do some closing event (Microsoft ship-It award) to get valuable feedback (documentation mandatory) to avoid that your project becomes a "submarine".
Scrum became the most relevant software development method. In this addendum some best practices are briefly aggregated.
- best team size is 7+/-2 developers (+ PO and Scrum Master), more than 9 members increase coordination effort
- aim for as less turnover as possible
- new colleagues shouldn't be added to a team for short time, instead better do QA or handling of incidents
- accept three conditions:
- you'll never have all requirements at the beginning of a project
- all requirements will change
- time & money will never suffice - there'll always be more to do
- during a kick-off (with team AND stakeholders):
- explain all relevant aspects of a project
- note open questions
- give outlook on next steps
- clarify/define collaboration in the team, meetings, reporting intervals
- define DoR/DoD
- establish a (public) impediment backlog
- also helpful: things-that-matter matrix for the big picture across all backlog items
- backlog grooming shouldn't be forgotten so everyone is aware of future storis, shortens planning, disadvantage: during planning usually devs will have forgotten about the items already (time gap)
- never add unfinished items to a review (before QA verified functionality), be cautious about comments like "99% done", "works for me" etc.
- retrospectives are the most important meeting since they help us to improve the way we work
- always check for the previous retrospective (what has been accomplished, where are we stuck)
- consider adding a release sprint for major versions, following tasks may be part of it:
- provide final code for production
- final testing in production (blue/green)
- migrate data
- setup administration/monitoring systems
- prepare release organisationally (inform), trigger marketing
- update system documentation
- hand over the product to ops/customer
- schedule training
- projects should have a general retrospective meeting as well regarding team, processes and the way the project went
- following information should be prepared:
- general information: vision, milestones and events, members, roles, relationships, duration, costs, quality aspects
- general successes accomplished and mistakes made
- organisational impediments and their impact
- KPIs: which targets were met and not, what has been modified
- which problems were solved during the project
- technical excellence: which progress was made, what became daily routine, which errors happened and how were they solved, test coverage
- team charts: release, velocity, DoD, DoR
- figures: how many users, customer feedback, sales
- result should be processed into "lessons learned"
- Definition of Done (DoD): clarify the completion of a ticket/story
- example criteria: at least two devs worked on the story (if possible), existing code was refactored, automated tests have been added and run, documentation was updated (also inline), all tests green, PO and/or QA verified the story
- Definition of Ready (DoR): summarize requirements on a backlog item
- example criteria: business value is clear, requirement is defined, research effort is limited (fits into sprint) so estimation can be done, external dependencies are outlined, acceptance criteria exist so test cases can be extracted, visual designs are complete, text and translations are present, risks (and consequent actions) are clear
- story map: divide epics into user stories, prioritize them (MuSCoW)
- walking skeleton: minimal system, tiny implementation of a end-to-end functionality (highlighted in grey)
- stories need to be split up so they can be estimated (fibonacci 1-13 story points), multiple ways to do so:
- vertical: split by business aspects (affects all architectural layers)
- workflow: split user story by the steps of a workflow (e.g. 3-step wizard)
- business rule: each (complex) rule gets an own story, e.g. "for leap years, my calendar shall display a special notification"
- complexity: keep user story in simplest form and add new stories for edge cases (e.g. validation)
- data type: e.g. if different media types can be attached and different actions may follow it is best to define one story per type (summarize in epic)
- input: one functionality can be used in various ways (mouse/keyboard/touch) so start with the easiest and make new stories for each additional way
- effort: if choices can be made for an action (e.g. choose credit card) you may create stories for each card type, however complexity will be big for the first and little for all others. Therefore it may be better to create one story for the default choice and a second one for ALL alternatives.
- comfort: put multiple levels of comfort into different stories (e.g. creating appointment in calendar - API call/web interface/Outlook import)
- role: different UI feedbacks for different user roles can be put in different stories
- performance: simple first implementation that ignores all performance aspects, follow-up story improves the experience
- research: for big uncertainty, create one story that answers open questions and another one for the implementation
- splitting is good if parts of the stories can be ommitted (80/20) and/or if user stories have a similar size
- estimation is usually done based on time (X hours) or story points (SP) - SP are more "abstract" but people generally estimate better relatively than absolute - for the velocity of a team the estimation unit usually doesn't matter
- estimation is usually done via planning poker (with ALL team members)
- estimating subtasks of a story is generally old-fashioned, simple rule: each subtask shouldn't take longer than a day, story matters anyway (finishing subtasks has no business value)
- code reviews are usually "forgotten" during estimation, consider adding a subtask for them
- alternative is a "team estimation game" (generally faster):
- each backlog item gets a card
- one dev picks a (random) card, reads it out loud and puts it on the wall
- second dev reads next card and puts it before (simpler) / under (same) / after (more complex) on the wall
- third dev may decide to read the next card OR change complexity of one of the existing cards (including an explanation)
- once all cards are read team discusses all items on the wall and may change complexity
- another method is the "magic estimation":
- each dev gets a random card and assigns it to a T-shirt-size (XS,S,M,L,XL,XXL) individually, may ask PO questions, but no disucssion in the team
- now everyone looks at the card and may decide to move one (explain)
- estimation is finished once no one wants to move a card anymore