-
Notifications
You must be signed in to change notification settings - Fork 6
/
summary.html
838 lines (782 loc) · 39.8 KB
/
summary.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
<!DOCTYPE html>
<html>
<head>
<title>README</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<style type="text/css">
/* GitHub stylesheet for MarkdownPad (http://markdownpad.com) */
/* Author: Nicolas Hery - http://nicolashery.com */
/* Version: b13fe65ca28d2e568c6ed5d7f06581183df8f2ff */
/* Source: https://github.com/nicolahery/markdownpad-github */
/* RESET
=============================================================================*/
html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, b, u, i, center, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td, article, aside, canvas, details, embed, figure, figcaption, footer, header, hgroup, menu, nav, output, ruby, section, summary, time, mark, audio, video {
margin: 0;
padding: 0;
border: 0;
}
/* BODY
=============================================================================*/
body {
font-family: Helvetica, arial, freesans, clean, sans-serif;
font-size: 14px;
line-height: 1.6;
color: #333;
background-color: #fff;
padding: 20px;
max-width: 960px;
margin: 0 auto;
}
body>*:first-child {
margin-top: 0 !important;
}
body>*:last-child {
margin-bottom: 0 !important;
}
/* BLOCKS
=============================================================================*/
p, blockquote, ul, ol, dl, table, pre {
margin: 15px 0;
}
/* HEADERS
=============================================================================*/
h1, h2, h3, h4, h5, h6 {
margin: 20px 0 10px;
padding: 0;
font-weight: bold;
-webkit-font-smoothing: antialiased;
}
h1 tt, h1 code, h2 tt, h2 code, h3 tt, h3 code, h4 tt, h4 code, h5 tt, h5 code, h6 tt, h6 code {
font-size: inherit;
}
h1 {
font-size: 28px;
color: #000;
}
h2 {
font-size: 24px;
border-bottom: 1px solid #ccc;
color: #000;
}
h3 {
font-size: 18px;
}
h4 {
font-size: 16px;
}
h5 {
font-size: 14px;
}
h6 {
color: #777;
font-size: 14px;
}
body>h2:first-child, body>h1:first-child, body>h1:first-child+h2, body>h3:first-child, body>h4:first-child, body>h5:first-child, body>h6:first-child {
margin-top: 0;
padding-top: 0;
}
a:first-child h1, a:first-child h2, a:first-child h3, a:first-child h4, a:first-child h5, a:first-child h6 {
margin-top: 0;
padding-top: 0;
}
h1+p, h2+p, h3+p, h4+p, h5+p, h6+p {
margin-top: 10px;
}
/* LINKS
=============================================================================*/
a {
color: #4183C4;
text-decoration: none;
}
a:hover {
text-decoration: underline;
}
/* LISTS
=============================================================================*/
ul, ol {
padding-left: 30px;
}
ul li > :first-child,
ol li > :first-child,
ul li ul:first-of-type,
ol li ol:first-of-type,
ul li ol:first-of-type,
ol li ul:first-of-type {
margin-top: 0px;
}
ul ul, ul ol, ol ol, ol ul {
margin-bottom: 0;
}
dl {
padding: 0;
}
dl dt {
font-size: 14px;
font-weight: bold;
font-style: italic;
padding: 0;
margin: 15px 0 5px;
}
dl dt:first-child {
padding: 0;
}
dl dt>:first-child {
margin-top: 0px;
}
dl dt>:last-child {
margin-bottom: 0px;
}
dl dd {
margin: 0 0 15px;
padding: 0 15px;
}
dl dd>:first-child {
margin-top: 0px;
}
dl dd>:last-child {
margin-bottom: 0px;
}
/* CODE
=============================================================================*/
pre, code, tt {
font-size: 12px;
font-family: Consolas, "Liberation Mono", Courier, monospace;
}
code, tt {
margin: 0 0px;
padding: 0px 0px;
white-space: nowrap;
border: 1px solid #eaeaea;
background-color: #f8f8f8;
border-radius: 3px;
}
pre>code {
margin: 0;
padding: 0;
white-space: pre;
border: none;
background: transparent;
}
pre {
background-color: #f8f8f8;
border: 1px solid #ccc;
font-size: 13px;
line-height: 19px;
overflow: auto;
padding: 6px 10px;
border-radius: 3px;
}
pre code, pre tt {
background-color: transparent;
border: none;
}
kbd {
-moz-border-bottom-colors: none;
-moz-border-left-colors: none;
-moz-border-right-colors: none;
-moz-border-top-colors: none;
background-color: #DDDDDD;
background-image: linear-gradient(#F1F1F1, #DDDDDD);
background-repeat: repeat-x;
border-color: #DDDDDD #CCCCCC #CCCCCC #DDDDDD;
border-image: none;
border-radius: 2px 2px 2px 2px;
border-style: solid;
border-width: 1px;
font-family: "Helvetica Neue",Helvetica,Arial,sans-serif;
line-height: 10px;
padding: 1px 4px;
}
/* QUOTES
=============================================================================*/
blockquote {
border-left: 4px solid #DDD;
padding: 0 15px;
color: #777;
}
blockquote>:first-child {
margin-top: 0px;
}
blockquote>:last-child {
margin-bottom: 0px;
}
/* HORIZONTAL RULES
=============================================================================*/
hr {
clear: both;
margin: 15px 0;
height: 0px;
overflow: hidden;
border: none;
background: transparent;
border-bottom: 4px solid #ddd;
padding: 0;
}
/* TABLES
=============================================================================*/
table th {
font-weight: bold;
}
table th, table td {
border: 1px solid #ccc;
padding: 6px 13px;
}
table tr {
border-top: 1px solid #ccc;
background-color: #fff;
}
table tr:nth-child(2n) {
background-color: #f8f8f8;
}
/* IMAGES
=============================================================================*/
img {
max-width: 100%
}
</style>
</head>
<body>
<h1>PRINCE2 Foundation summary</h1>
<p>The essential knowledge for the PRINCE2 foundation exam. All bullet points are very brief, for details you better refer to the excellent <a href="http://www.mgmtplaza.com/elearn/dirBooks/P2FPM42.pdf">PRINCE2 foundation training manual by Management Plaza</a>.</p>
<p>Some essential abbreviations:</p>
<ul>
<li><strong>BC</strong>: BC</li>
<li><strong>CPM</strong>: Corporate/Programme Management</li>
<li><strong>PID</strong>: Project Initiation Document</li>
<li><strong>PB</strong>: Project Board</li>
<li><strong>PM</strong>: Project Manager</li>
<li><strong>PMT</strong>: Project management Team</li>
<li><strong>PPD</strong>: Project Product Description(s)</li>
<li><strong>PP</strong>: Project Plan</li>
<li><strong>SU</strong>: Starting Up phase</li>
<li><strong>TM</strong>: Team Manager</li>
<li><strong>WP</strong>: Work Package</li>
</ul>
<h2>Core aspects</h2>
<h3>Projects in general</h3>
<ul>
<li>projects introduce <strong>change</strong>, are <strong>unique</strong> and bring a certain amount of <strong>uncertainty</strong></li>
<li>have defined start and end (<strong>temporary</strong>), <strong>cross-functional</strong> (involve people from different departments)</li>
<li>PRINCE2 definition: project is a temporary organization created for the purpose of delivering one or more business products according to an agreed BC </li>
<li><strong>program</strong>: set of related projects</li>
</ul>
<h3>PRINCE2 structure / core elements</h3>
<ul>
<li>principles</li>
<li>themes (what items must be addressed, e.g. BC, Organization, Quality, Change)</li>
<li>processes (what activities and by whom)</li>
<li>tailoring (the project environment)</li>
</ul>
<h3>PRINCE2 core principles</h3>
<p>framework for good project practice for those involved in a project:</p>
<ol>
<li>continued business justification (throughout the project lifetime)</li>
<li>learn from experience</li>
<li>defined roles and responsibilities (who does what, what to expect from others)</li>
<li>manage by stages (separated by decision points, manageable chunks)</li>
<li>manage by exception (when things go outside the agreed tolerances)</li>
<li>focus on products (everyone has the same idea of the product)</li>
<li>tailor to suit the project environment (different paperwork depending on size, environment, complexity, ...)</li>
</ol>
<h3>six aspects of PM / variables / tolerances / performance targets / goals</h3>
<ul>
<li>timescales (the "when")</li>
<li>costs (budget)</li>
<li>----------(usable product)</li>
<li>scope (defined scope, stakeholders involved, what is mandatory and what is not)</li>
<li>benefits (the "why", ROI, measurable)</li>
<li>risk (what risks, how many, how to manage) </li>
</ul>
<p>...or in short <strong>BCQRST</strong>. These variables need to be continuously monitored.</p>
<h3>PRINCE2 themes</h3>
<ul>
<li>themes: knowledge areas of the project</li>
<li>aspects of project management that need to be adressed continuously throughout the project</li>
<li>core activity and need to be defined whenever a project starts</li>
<li><strong>BC</strong>: The "why"</li>
<li><strong>Progress</strong>: The "Where are we now? Where are we going? Should we carry on?"</li>
<li><strong>Organization</strong>: The "who"</li>
<li><strong>Plans</strong>: The "how", "how much" and "when"</li>
<li><strong>Quality</strong>: The "what"</li>
<li><strong>Risk</strong>: The "what if"</li>
<li><strong>Change</strong>: "What's the impact?"</li>
<li><strong>Lessons learned</strong></li>
<li><strong>Tailoring</strong></li>
</ul>
<h3>PRINCE2 plan</h3>
<ul>
<li>document describing how, when and by whom a target can be achieved</li>
<li>Project Plan gets updated in every stage and is compared to the baselined PP</li>
</ul>
<p>Three major plans</p>
<ul>
<li>Project Plan (high level, mainly for PB)</li>
<li>Stage Plan (day-to-day-work of the PM, focused on products)</li>
<li>Team Plan (for TM)</li>
</ul>
<h3>common project failures</h3>
<ul>
<li>insufficient product definitions (lead to wrong product)</li>
<li>lack of communication</li>
<li>poor estimation of time and cost</li>
</ul>
<h3>PRINCE2 benefits</h3>
<ul>
<li>established for long tine in the industry, common vocabulary</li>
<li>applicable to any project</li>
<li>gives a structure for roles and responsibilities</li>
<li>always focused on the product</li>
<li>viability of project is constantly checked</li>
</ul>
<h2>Themes in detail</h2>
<h3>Business Case</h3>
<ul>
<li>purpose: BC theme provides structure to judge whether BC is desirable, viable, achievable and worth the continued investment</li>
<li>used to document justification for project based on estimated costs against anticipated benefits</li>
<li>one of the first things of a PM: ask for the BC (although many projects don't have one)</li>
<li>continuously maintained throughout the project (because changes in requirements can also lead to changes in the BC, e.g. if additional staff is needed)</li>
<li>needs to be verified by PB before project starts</li>
<li>Executive is resposible for the BC and for securing funding</li>
</ul>
<p>So what do you get?</p>
<ul>
<li>output: what product will be delivered (for specialist users)</li>
<li>PRINCE2 distinguishes products between management (documents for communication) and specialists (given to users) </li>
<li>outcome: what can users do better with that product (result of change derived from output)</li>
<li>benefits: measurable improvements by using this product (advantages, usually by at least one of the stakeholders)</li>
</ul>
<h4>Benefits review plan</h4>
<ul>
<li>identify benefits and how/when they can be measured, must include a timeline (if you can't measure it, don't claim it)</li>
<li>senior user (represents all users) is responsible for specifying and realizing the benefits (continued commitment to the project)</li>
</ul>
<h4>Content of the BC</h4>
<ul>
<li>Executive Summary</li>
<li>reasons for project, estimated costs, risks (summarized) and expected benefits and dis-benefits</li>
<li>also includes timescales (project start/end, when will benefits be realized) and an investment appraisal (ROI calculation, costs vs. benefits) and major risks</li>
<li>three business options: do nothing, do the minimum, do something</li>
</ul>
<h3>Organization</h3>
<ul>
<li>purpose: define and establish the project's structure of accountability and responsibilities (or: the "who")</li>
<li>responsibilities are assigned to roles</li>
<li>one person can have multiple roles</li>
<li>stakeholders need to be informed, decision makers need to be on the board</li>
</ul>
<h4>four levels of project organization</h4>
<ol>
<li>CPM: Comissioning the project</li>
<li>Direction level: PB (make decisions, approve resources, plans, deviations)</li>
<li>Management level: PM (run the project according to the goals)</li>
<li>Delivery level: TM (create products with a certain quality within timescale and costs)</li>
</ol>
<p>PMT includes the levels 2-4.</p>
<h3>Project Management Team</h3>
<ul>
<li>represents <strong>Executive/Business</strong>, <strong>User</strong> and <strong>Supplier</strong> stakeholders</li>
<li>inlcudes CPM, PB, Business/User/Supplier Assurance, PM, TM, Change Authority and Project Support</li>
<li>PRINCE2 is based on customer/supplier environment: customer specifies the result and pays, supplier provides resources/skills and delivers the results</li>
<li>customer/supplier can be inside the same company</li>
<li>usually the executive represents the business role</li>
<li>PMT has defined responsibilities for directing, managing and delivering the project</li>
<li>defined responsibilities for directing, managing and delivering</li>
<li>have a strategy to manage communication between stakeholders</li>
</ul>
<h4>Project Board</h4>
<ul>
<li>consists of Customer/Executive, Senior User and Senior Supplier (decision makers)</li>
<li>only one Executive, but potentially multiple senior users/suppliers</li>
<li>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</li>
<li>executive owns BC and has the final word on decisions</li>
<li>PB need to agree stage tolerances (WP tolerances may be set by TM)</li>
<li>PB is accountable for success/failure of the project and provides a unified direction to project and PM</li>
<li>business assurance vs. user assurance = value for money vs. product works as expected</li>
<li>PB provides resources and funds, supports the PM, ensures effective communication</li>
<li>PB may delegate responsibility to a Change Authority (person/group)</li>
<li>not necessarily approved by CPM</li>
</ul>
<h4>Project Manager / Team Manager</h4>
<ul>
<li>PM manages on day-to-day-basis and usually comes from the customer (preferred by PRINCE2)</li>
<li>needs to be proactive, may take roles Project Support, Team Manager and Change Authority</li>
<li>stakeholder management: identify and communicate effectively with people that have interest in project outcome</li>
<li>TM is optional, may be needed for geographical reasons or when the project is big or complex/highly specialized</li>
<li>PM may be supported by PMO/project support (administrative tasks, Configuration Management)</li>
</ul>
<h4>Communication Management Strategy</h4>
<ul>
<li>document describing how communication will be done (what, to whom, how often, internal/external)</li>
<li>essentially the <strong>rules of engagement</strong> of communication (flow of information)</li>
<li>responsibility of the PM during Initiating a Project</li>
<li>contains information on communication methods, tools/techniques, reporting, timing, roles & responsibilities, stakeholders, needed information</li>
</ul>
<h3>Quality</h3>
<ul>
<li>purpose: define and implement the means by which the project will create products that are fit for purpose</li>
<li>product needs to meet the expectations and can be used as intended, ensure that benefits of these expectations are realised and achieved</li>
<li>product descriptions must include quality criteria and tolerances (e.g. dishwasher-proof, keeps color for 20 years) to get some details</li>
<li>quality: total amount of features/characteristics of a product</li>
<li>provides a method to specify quality, carry out quality control, explain how to get quality approved and facilitates quality management during the project</li>
</ul>
<h4>Approach</h4>
<ul>
<li><strong>Quality Planning</strong></li>
<li><strong>Quality Control</strong>: implement and track quality methods</li>
<li><strong>Quality Assurance</strong>: focus on quality in the <strong>organization</strong>, independent review, complies to company standards, quality processes are in place</li>
<li><strong>Project Assurance</strong>: 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</li>
</ul>
<h4>Quality planning</h4>
<ul>
<li>identifying the products to control</li>
<li>writing a product description for them (product description containing composition, format, development skills, quality criteria/tolerances/methods/acceptance procedures/responsibilities)</li>
<li>agree on acceptance criteria with PB (quality is assured by PB)</li>
<li>communicate agreements to stakeholders, common understanding</li>
<li>establish how quality can be controlled (baseline and tolerances)</li>
</ul>
<h5>Customer quality expectations</h5>
<ul>
<li>get the quality expectations (e.g. from the client)</li>
<li>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</li>
</ul>
<h5>Acceptance critiera</h5>
<ul>
<li>customer and supplier agree on acceptance criteria that the product must satisfy when complete</li>
<li>can be a simple list with the criteria itself, its priorization (MoSCoW) and the current status (Yes/No)</li>
<li>responsibilities: PM collects inspection/survey and other documents, executive confi</li>
<li>project and manufacturing, Senior User is responsible for all other acceptance criteria</li>
</ul>
<h5>Quality Management Strategy document</h5>
<ul>
<li>defines quality requirements and control methods for all products in a project</li>
<li>defines how quality standards are applied ("how quality will be done")</li>
<li>typical topics: what system/standard, tools and techniques, who is responsible for documenting and approving/confirming, timing of activities</li>
</ul>
<h5>Project Product descriptions</h5>
<ul>
<li>created for all products as part of the planning activities (before PP is completed)</li>
<li>needs to contain quality criteria, acceptance methods and acceptance responsibilities</li>
<li>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</li>
<li><strong>PPD</strong> (one document) is the description of the main product and more like an overview and is created in the SU phase</li>
<li>what does the product need to deliver to get accepted (acceptance criteria)</li>
<li>identify roles and sources of information for project/product</li>
<li>usually 2-4 pages with a lot of quality-related information</li>
</ul>
<h5>Quality register</h5>
<ul>
<li>diary of quality events during the project</li>
<li>may be a spreadsheet with these columns: product id, name, producer, reviewer, approver, target/actual review date, target/actual approve date, result</li>
</ul>
<h4>Quality review (meeting)</h4>
<ul>
<li>four roles: chair (host), presenter (represents product producers), reviewer (reviews, asks, confirms), administrator (admin support for chair) or <strong>CRAP</strong></li>
<li>objectives: assess products against criteria, involve stakeholders, provide confirmation, sign off the product (create baseline, no more changes)</li>
<li>output: decision to quality-approve products or not (complete, conditionally complete or incomplete)</li>
<li>Quality Register gets updated with a summary and date of a follow-up meeting</li>
</ul>
<h3>Plans</h3>
<ul>
<li>purpose: facilitate communication and control by defining the means of delivering the products (Why, What, Who, When and How much)</li>
<li>plan always needs to show that targets are achievable</li>
<li>plan theme provides a framework to design, develop and maintain project plans</li>
<li>failing to plan is planning to fail</li>
</ul>
<h4>PP levels</h4>
<ul>
<li>three levels of planning to reflect different management level needs:</li>
<li><strong>PP</strong>: direction level (high-level), used by Project Board, shows major products, resources, activities, their cost and when they will be delivered, approved by executive</li>
<li>will be baselined for later reference</li>
<li><strong>Stage Plan</strong>: management level, created for each stage with more detail, used by PM day-to-day</li>
<li><strong>Team Plans</strong>: delivery level (team manager), plan the work in WPs</li>
<li>there may be <strong>Exception Plans</strong> (when out of tolerances, get project back on track, replaces project/stage plan, PM must inform PB) </li>
<li>there will be a <strong>Benefits Review Plan</strong> (part of BC)</li>
<li>typical contents of plan: prerequisites, assumptions, incorporated lessons, budget, monitoring and control information, tolerances, product descriptions</li>
<li>types of management products: baseline, records and reports</li>
</ul>
<h4>Product-based planning</h4>
<p>Products are identified first and then activities, dependencies and resources required to deliver these products</p>
<p>Tasks:</p>
<ol>
<li>write PPD (describe main product, SU phase, Senior User/Supplier provide information)</li>
<li>create product breakdown structure (hierarchical list all products, e.g. Mind Map, but no sequence)</li>
<li>write product descriptions (for required products)</li>
<li>create product flow diagram (product flows/interdependencies, sequence of creation of products, a bit like an IKEA assembly diagram)</li>
</ol>
<p>A product checklist lists all major products and delivery dates.</p>
<h4>Creation of plans</h4>
<ul>
<li>Initiation Stage Plan for the first stage is created by PM</li>
<li>Product-based plans are created by PM and/or TM, used in SU, IP and SB processes</li>
<li>Stage Plan is created by PM during SB process</li>
<li>Stage Plan gets updated as soon as actuals are received from a WP</li>
<li>project plan needs to be approved by PB, is also updated in SB process and at the end of project</li>
<li>team plans are optional, created by TM</li>
<li>Executive approves project plan</li>
</ul>
<h3>Risk</h3>
<ul>
<li>purpose: identify, assess and control uncertainty (improve ability of project to succeed)</li>
<li>risk = set of events which will have an effect on achieving the project objectives / improve the ability of project to succeed</li>
<li>all projects introduce something new and uncertainty is risk</li>
<li>risks are communicated in all major reports (also Lessons and End Project Reports)</li>
<li>risk may be either <strong>threat</strong> or <strong>opportunity</strong></li>
<li>risk management is one of the main tasks of the PM</li>
<li>three steps to Risk Management: identification (describe), assess (likelihood, impact) and control (respond)</li>
<li>risk appetite: how much risk is a company willing to accept</li>
<li>risk tolerance: acceptable/unacceptable deviations from what is expected</li>
<li>risk owner: responsible for managing, monitoring and control of risk aspects assigned to him</li>
<li>risk actionee: carries out risk response action</li>
</ul>
<h4>Risk Management Strategy</h4>
<ul>
<li>document that defines project procedures for Risk Management</li>
<li>how risks will be identified, assessed, controlled and communicated (techniques and standards to be applied)</li>
<li>template may already exist in the company/programme</li>
</ul>
<h4>Risk Register</h4>
<ul>
<li>captures and maintains information on all risks (threats/opportunities)</li>
<li>record of risks with their history</li>
<li>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</li>
</ul>
<h4>Risk Management procedure</h4>
<p>five steps:</p>
<ol>
<li>Identify (complete RMS document first, identify context, use checklists and lessons learned from other projects and brainstorm with specialists)</li>
<li>Assess (probability and impact)</li>
<li>Plan (steps for response)</li>
<li>Implement (carry out responses from step 3)</li>
<li>Communicate (stakeholders, use existing reports)</li>
</ol>
<p>or <strong>I</strong> <strong>A</strong>te <strong>P</strong>eaches <strong>I</strong>n <strong>C</strong>hina.</p>
<ul>
<li>risks are expressed in <strong>cause</strong> (Volcano eruption in Iceland) / <strong>event</strong> (wind brings ash into UK airspace) / <strong>effect</strong> (80% flights delayed/cancelled)</li>
<li>or: due to X, there is a risk of Y that could result in Z</li>
<li>estimating is about assessing the probability, impact and proximity for each risk (e.g. via Expected Value or Pareto)</li>
<li>evaluating is to group all risks and get a risk value for entire project</li>
<li>each thread/opportunity must be understood regarding probability, impact, proximity and how impact may change over time of project</li>
<li>existing reports are used for communication, e.g. Checkpoint/Highlight/End Stage/ End Project/Lessons reports</li>
</ul>
<h5>Responses to threads/opportunities</h5>
<ul>
<li>threats: avoid, reduce (probability or impact), fallback (contingency/plan of actions), transfer (to another party, e.g. insurance), share (common in customer/supplier), accept</li>
<li>opportunities: exploit (use it), enhance (improve likelihood), share, reject</li>
</ul>
<h4>Risk budget</h4>
<ul>
<li>money that is put aside to deal with threats/opportunities, fund responses</li>
<li>cannot be used for anything else</li>
</ul>
<h3>Change</h3>
<ul>
<li>purpose: identify, assess and control any potential changes in products that have been approved/baselined</li>
<li>handle change requests and issues that arise during the project (<strong>issue and change control</strong>)</li>
<li>don't prevent changes, but get them agreed and approved before executing them</li>
<li>issues should be prioritized following <strong>M</strong>o<strong>SC<strong>o</strong>W</strong></li>
</ul>
<h4>Types of issues</h4>
<ol>
<li><strong>Request for change</strong>: on a baselined product</li>
<li><strong>Off-specification</strong>: agreed to be done but not offered by supplier (missing product / product not meeting spec)</li>
<li><strong>Problem/Concern</strong>: anything that the PM needs to resolve or escalate, can be positive/negative</li>
</ol>
<h4>Management products</h4>
<ol>
<li><strong>Configuration Management Strategy</strong>: 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</li>
<li><strong>Configuration Items Records</strong>: 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</li>
<li><strong>Product Status Account</strong>: report on state of products (e.g. on stage level), checks the current version, picture of progress made against the baselined products (usually from Project Support)</li>
<li><strong>Daily Log</strong>: diary/notes for all informal information, useful to prepare Risk / Configuration Management Strategy</li>
<li><strong>Issue Register</strong>: document to capture and maintain issues (formal), contains reporter, raised (date), prio, severity</li>
<li><strong>Issue Reports</strong>: describes issue(s) in detail, lists related issues, recommendation, issue type, raised by, impact assessment, decision</li>
</ol>
<h4>Change budget</h4>
<ul>
<li>sum of money that customer/supplier agree to use to fund requests for change / change analysis</li>
<li>Change Authority (assigned by PB) manages this budget, review/approves RfC</li>
<li>PM can always refer to the change process (e.g. via form) for all change requests, never has to say "no"</li>
</ul>
<h4>Configuration Management activities</h4>
<p>Maintain and control changes for each product, two activities at project start:</p>
<ol>
<li>Planning: To what level will Change Management be done? Which documents/information do we need?</li>
<li>Identification: how to identify each product uniquely (file name, e.g. project-product-owner-version-date)</li>
</ol>
<p>three activities during project:</p>
<ol>
<li><strong>Control</strong>: Nothing moves and nothing changes without authorization (baselining, archiving, distribution copies, ...)</li>
<li><strong>Status Accounting</strong>: reporting current/historical data for each product in product Status Account format</li>
<li><strong>Verification & Audit</strong>: Are products in line with Configuration Items Records?</li>
</ol>
<h4>Issue and Change Control Procedure</h4>
<ul>
<li>Capture: determine issue type and if formal/informal</li>
<li>Examine: assess impact on project objectives</li>
<li>Propose: actions to take (identify options, evaluate, recommend)</li>
<li>Decide: someone approves/rejects the recommended solution</li>
<li>Implement: take corrective action</li>
</ul>
<p>or <strong>CEPDI</strong>.</p>
<ul>
<li>data can be stored in Daily Log, Issue Register and Issue Report</li>
<li>issues are always escalated to level above (e.g. PM > PB)</li>
</ul>
<h3>Progress</h3>
<ul>
<li>purpose: establish mechanisms to monitor/compare actual achievements against the planned ones, provide a forecast for project objectives, control unacceptable deviations</li>
<li>Exception: deviation beyond agreed tolerance levels</li>
<li>PM may set tolerance levels and manage minor deviations himself</li>
<li>there are <strong>Work Package</strong>, <strong>Stage-</strong> and <strong>Project</strong> tolerances</li>
</ul>
<h4>Progress approach</h4>
<ol>
<li>delegate authority from one level to the next</li>
<li>divide project into management stages, authorize only one stage at a time</li>
<li>time-driven and event-driven progress reports (e.g. Highlight Reports)</li>
<li>raising exceptions: alert above layer if big issue occurs</li>
</ol>
<p>Delegating authority:</p>
<p><strong>CPM</strong> >>> Project tolerances >>> <strong>PB</strong> >>> Stage tolerances >>> <strong>PM</strong> >>> WP tolerances >>> <strong>TM</strong></p>
<p><strong>TM</strong> >>> WP progress/issues >>> <strong>PM</strong> >>> Stage progress/exceptions >>> <strong>PB</strong> >>> Project progress/exceptions >>> <strong>CPM</strong></p>
<p>So PB gets (regular and Change/Exception) reports and authorizes Stages while PM get Checkpoint reports, reviews Progress and authorizes WPs.</p>
<h4>Management Stages</h4>
<ul>
<li>chance to check viability, review, authorize</li>
<li>equate to commitment of resources and authority to spend</li>
<li>decision points for PB between stages, never overlap</li>
<li>PM may manage on behalf of PB</li>
<li>at minimum are two stages in project (Initatiation, Delivery Stage)</li>
<li>number of stages depends on duration, key decision points, risk, amount of control by PB, confidence, product sensitivity to plan</li>
<li>stages should be short when there is a lot of risk/complexity</li>
</ul>
<h4>Technical Stages</h4>
<ul>
<li>how companies/teams work, usually linked to skills (e.g. design/build/implement/test)</li>
<li>grouping work together (by techniques or products)</li>
<li>may overlap each other and span a Management Stage Boundary</li>
</ul>
<h4>Event- and Time-driven Controls</h4>
<ul>
<li>event-driven controls take place when something happens (e.g. Exception Report)</li>
<li>time-driven controls take place at pre-defined intervals (e.g. Highlight Report every two weeks)</li>
</ul>
<h4>Progress Reports</h4>
<ul>
<li>Checkpoint Reports: TM reports to PM, progress compared to agreed team plan, status of WP, frequency is defined in the WP</li>
<li>Highlight Report: PM reports status of stage compared to Stage Plan (not much detail, 1-2 pages)</li>
<li>End Stage Report: PM creates at end of stage, PB decides whether to authorize, modify scope or stop the project</li>
<li>End Project Report: PM creates during Closing process and PB authorizes closure, provides overview what went well and what not, review of benefits</li>
</ul>
<p>Relevant documents for PM:</p>
<ul>
<li>PM checks progress via Checkpoint Reports (from TM) and </li>
<li>Quality Register (maybe also Lessons Log from previous projects)</li>
<li>PM keeps track of progress via Daily Log, Issue Register, Product Status Account, Quality Register and Risk Register</li>
</ul>
<h2>Processes</h2>
<p>Structured set of activities to accomplish a specific objective</p>
<ol>
<li>Starting Up (SU)</li>
<li>Initiating a project</li>
<li>Directing a project</li>
<li>Controlling a stage (CS)</li>
<li>Managing product delivery</li>
<li>Managing a Stage Boundary (SB)</li>
<li>Closing a project</li>
</ol>
<p>lifecycle for most important themes:</p>
<ul>
<li>BC: created in SU, completed/baselined in Initiation, updated in SB, final update in Closing</li>
<li>Plan: PPD in SU, plan created/baselined in Initiation, updated in SB, final update in Closing</li>
</ul>
<h3>Pre-project</h3>
<ul>
<li>before the actual project starts, contains Starting Up and Directing a project</li>
<li>first, create a project mandate document (trigger for SU, what is desired)</li>
<li>verify that project is worthwhile (prevent poor projects from starting)</li>
<li>PB reviews the <strong>Project Brief</strong> and decides to initiate the project </li>
</ul>
<h3>Initiation Stage</h3>
<ul>
<li>purpose: gives direction and scope of project, forms the "contract" between PB and PM</li>
<li>define product quality, project timeline, costs, risk analysis and commitment of resources</li>
<li>assemble PID, PID contains almost all project information to date (Project Plan, BC, Strategy documents, Risk Register, Team Plan)</li>
<li>create BC and Benefits Review Plan</li>
<li>create project and stage plan</li>
<li>project board gets the PID and authorizes the project</li>
</ul>
<h3>Delivery Stage</h3>
<ul>
<li>PM accepts products and gets approval for them</li>
<li>close the project by comparing project with the original plan, write End Project Report, plan post-project benefits reviews and deliver Lessons Learned report</li>
<li>PB revises data and authorizes closing</li>
</ul>
<h3>The seven processes</h3>
<h4>Starting Up a project</h4>
<ul>
<li>responsibility of PB and Executive, occurs before project starts, should be brief (avg. time could be one week depending on size and complexity)</li>
<li>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?)</li>
<li>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)</li>
<li>also the general project approach should be defined (update existing product / from scratch / off-the-shelf solution, internal / external)</li>
<li>project mandate will be expanded to Project Brief</li>
<li>Project Brief also contains scope, roles & responsibilities and performance targets</li>
</ul>
<h4>Directing a project</h4>
<ul>
<li>responsibility of PB, runs from start to end, starts on completing SU</li>
<li>PB authorizes stages and applies <strong>Management by Exception</strong></li>
<li>purpose: enable PB to be accountable for the project by making key decisions, have overall control and delegate day-to-day work to PM</li>
<li>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</li>
<li>decisions about tolerances for stage exceptions are made (PB)</li>
<li>main outputs are approvals (e.g. Stage Plan, Exception Plan, PID), authorizations and notifications</li>
</ul>
<h4>Initiating a project</h4>
<ul>
<li>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)</li>
<li>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</li>
<li>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)</li>
<li>begin with the strategy documents, complete BC after Project Plan (since PP contains time and cost information)</li>
<li>PB needs to "allow" the project to continue via signing off the PID</li>
</ul>
<h4>Controlling a stage</h4>
<ul>
<li>purpose: assign and monitor work, deal with issues, take corrective action, report progress to PB/stakeholders (communication)</li>
<li>objectives: focus on delivery, control risks and issues, keep BC under review, deliver products to agreed quality within cost and time and achieve benefits</li>
<li>main input documents are Stage Plan and PID</li>
<li>monitoring via Checkpoint Reports and Quality Register (and other registers)</li>
<li>report to PB via Highlight Report (PB authorizes/reviews)</li>
<li>PM also maintains logs, registers and Configuration Items Record document</li>
</ul>
<h4>Managing product delivery</h4>
<ul>
<li>purpose: manage and control work between PM and TM by placing formal requirements on accepting/executing/delivery of products</li>
<li>objectives: products are authorized and agreed, team is aware and understands expected effort, time and cost, deliverables are within tolerances, TM provides progress information</li>
<li>TM needs to demonstrate that products meet their quality criteria (e.g. via Quality Review Meeting) and work gets done</li>
<li>also covers acceptance and execution of project work by external suppliers</li>
<li>WPs have three activities: accept, do and deliver (update Quality Register)</li>
</ul>
<h4>Managing Stage Boundary process</h4>
<ul>
<li>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</li>
<li>objectives: products need to get approved, review documents (PID, BC, Project Plan, Risk Register, Lessons Log), request authorization to start next stage</li>
<li>End Stage report and next Stage Plan are submitted to PB, BC is updated</li>
<li>report the performance of the existing stage (PB evaluates against Stage Plan), products and benefits have been delivered (continued business justification)</li>
<li>for exceptions: prepare Exception Plan, seek approval and replace PP/Stage Plan with Exception Plan</li>
<li>record information/lessons for later projects</li>
</ul>
<h4>Closing a project</h4>
<ul>
<li>purpose: fixed point to check if the project reached its objectives and products were accepted</li>
<li>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</li>
<li>ownership of the project gets transferred to the customer (handover)</li>
<li>update Lessons Log, Configuration Items Records, Benefits Review Plan (evaluate the project)</li>
<li>prepare project for closure by creating End Project Report, Lessons Learned Report and Acceptance Record</li>
</ul>
<p>Sources: </p>
<ul>
<li><a href="http://www.mgmtplaza.com/elearn/dirBooks/P2FPM42.pdf">PRINCE2 foundation training manual by Management Plaza</a></li>
<li><a href="http://quizlet.com/9018193/prince2-foundation-flash-cards/">Flashcards</a></li>
<li>http://www.prince2primer.com/key-prince2-foundation-and-practitioner-exam-learning-points</li>
</ul>
</body>
</html>
<!-- This document was created with MarkdownPad, the Markdown editor for Windows (http://markdownpad.com) -->