Soop: Simon’s Observations On Projects

SOOP 131

My SOOP’s (Simon’s Observations On Projects) are inspired by the observation that gaining competence in managing change has parallels with making soup. See Soup.

This list of observations, hopefully includes a few worthy of being called aphorisms, but all should direct successful management of change whether in the private, public or not-for-profit sector.

#soop all come from our training courses at https://learn.logicalmodel.net/. Our ‘all-you-can-eat’ £5/month subscription includes all our courses from accidental project manager, intentional beginner to expert and PRINCE2 and PRINCE2agile exam preparation (exams extra!)

SOOP-1. A project is a decision making architecture whose purpose is to transform capital (Shared culture, Intellectual property. Plant and machinery etc) when acting or reacting to context change. [Foundations and Concept of all P3M-FC]

SOOP-2. Project management has grown-up on the supplier side of change initiatives. This has biased thinking to be overly focused on deliverables instead of benefits. The deeply rooted mind-set thus created has led to very difficult to see misconceptions about the nature of projects, (but which are mostly ‘obvious’ with hindsight). FC

SOOP-3. Projects are a means by which people create change to the status quo that enables some form of return on the effort expended. FC

SOOP-4. The idea that ‘project management’ is the discipline that matters is wrong to start with!

The fact is no one undertook a project for its own sake. A project is the transition of the portfolio of asset uses from current-state-business-as-usual to future-state-business-as-usual.

Project management is a collection of techniques. If we set the boundaries where ‘temporary project’ defines them we un-link the techniques and procedures from their driving force: the return of value (e.g. dividends and capital growth to equity holders, services or security to citizens).

Without the correct links, fault-lines such as distorted capabilities to handle risk attitude, arise in any initiative. A quick scan of reality shows that on average project management and managing of risk performs below desired levels of competency.

The whole or complete topic is the portfolio of asset uses. Investment management; Caring for Capital. Project management is just a subset. To get projects right we must discuss them alongside benefits management. For that we need roles such as the sponsor and mechanisms such as portfolio level decision making. FC

SOOP-5. Good guidance avoids unproductive bureaucracy – PRINCE2 is a good tool here but sadly that isn’t PRINCE2®‘s reputation! [PRINCE2]

SOOP-6. Projects (stages, sprints, phases, work-packages, tasks, jobs or any other form of activity) that don’t produce some change to the world are cost without value. FC

SOOP-7. Nothing happens in a project without people. People don’t need procedures to succeed, but, if done right, procedures improve the chances of success and possibly the speed of achievement and size of impact. FC

SOOP-8. Process without people (who understand and use it) is valueless. FC

SOOP-292. Inappropriate use of best practice when the context is not as defined by the best-practice is wrong and often very damaging. [FC and Quality-Q]

SOOP-9. BAU is the portfolio of on-going activities that uses equity and debt to return utility to stakeholders. FC

Utility might be physical safety, security and health or utility might be beauty and excellence or capital growth or utility might be revenue return to the capital’s owners or it might be interest to debt lenders. [ FC and Business Case-BC]

SOOP-10. Benefits Management is the parent of programs. Programs the parent of projects. Projects are (or better yet, ‘Management of Change’ is) just a phase in the investment life-cycle between equity injection and equity extraction. BC FC

SOOP-11. A project is: the collection of necessary, sufficient and interdependent activities that together are designed to achieve some controlled change to the current state of the world for which some, one or all of us have some degree of utility. FC

SOOP-12. Business-as-usual’s defining criteria are that, 1) during its normal existence its end point is not envisaged and 2) while often cyclic, it is in a stable equilibrium with its context. FC

SOOP-13. Projects are about change to business-as-usual. A project’s defining criteria are, 1) it takes us out of equilibrium even though its purpose is to create a future-equilibrium, and 2) its normal existence is wholly focused on reaching its terminating end-conditions. FC

SOOP-14. To succeed, projects must be flexible, responsive, reactive and back-cast from the target ‘future-state-business-as-usual’. Metrics for change, such as the contents of the A2-Business Case, are (should be) rooted in descriptions of the future as if they were history. [FC & Transformational Leadership-TL]

SOOP-15. Projects are SYSTEMS whose purpose is to adjust business-as-usual participants (agents) or boundaries or processes (rule-sets) or inputs or outputs or any or all of these. FC TL

SOOP-16. Projects are the collection of activities that drain resource, will and skills from the revenue or service generating business-as-usual. Programs add transition of the Portfolio to its new-stable-state-business-as-usual. Benefits Realisation-TL FC

SOOP-17. The use of resources is guaranteed: 100% probability. The delivery of a benefit to those who commission the project is less than 100%. Projects are an investment, an exercise in applied risk management. Those who are commissioned may be guaranteed a fee for involvement and, so for them, the project IS NOT a risk – i.e. there should be no possibility of extra gain (opportunity) as there is no possibility of loss (threat). The threats and rewards may be shared. How investment risk is shared is subject to contracts. [Risk-R]

SOOP-18. Organisations [ SHOULD ] use a kanban portfolio backlog of demands on resources (human capital, process capital, plant and money) that ensures an affordable mix of maintaining the status quo and transition to a future-state-business-as-usual. Transitions within the portfolio are projects. Pull based capacity management is essential in a VUCA world. FC-TL

SOOP-19. Portfolio Management means ‘managing how we use the total asset-base (portfolio of capital) available to us – i.e. Changing our actions when our context creates opportunity or threat and repeating how we previously, beneficially used our capital so long as our context remains constant’. FC-TL-BC

SOOP-20. Any project, indeed every project

• is commissioned to change the state of the world in some way
• is uncertain as to degree of success
• will create unintended consequences
• is ultimately a part of the pursuit of gain or to avoid loss, and so
• is incomplete on its own

A project is a sub-contract for deliverables within some wider initiative (a Program). If the supplier of development skills, and those who deliver the benefits after the project are different people, the project (the transition) is an inferior contract within one or more superior contracts that care for participant’s equity.  FC-TL-[Program Management-PgM]

SOOP-21. BAU requires supervision rather than management. Typically, business-as-usual has a staff contingent whose assignment is considered ‘permanent’, a funding mechanism that authorises expenditure on an annualised basis and a defined set of standard procedures that repeat in some predictable pattern largely driven by the sun and the moon – e.g. every day, every month, quarterly or annually. FC-TL

SOOP-22. There is no such role as project owner; the role is ‘investment owner’ and the span is from Capital Injection to Capital Extraction.

SOOP-23. If there is one crucial skill that differentiates a project manager from a business-as-usual-manger, it is fluency in tools and techniques for, ‘how to focus a disparate group of contributors on an emerging common goal’.

SOOP-24. Projects are inherently reactive. The legal profession handle this via contracts composed or terms (stuff we must do or must not do) and conditions (the trigger for the terms). Full, richly defined, risk (±) relevant project plans ARE contracts.

SOOP-25. Some citizens of the corporate world have been indoctrinated to believe reactive is bad. That is a simplistic view. Reactive is often the right approach in projects, less so in business-as-usual.

SOOP-26. Projects are temporary but investments are long-lived. It is the investment, not (just) the project, that needs management.

SOOP-27. There should not be a transfer of obligations to deliver value from the money and time invested in the project – the writings that say this have the wrong mind-set behind the pen.

SOOP-28. Notwithstanding, the boundary question harvesting’s initial focus is to settle changes delivered by enabling stages into being future-state-business-as-usual rather than business-as-unusual that most projects leave in their wake. The harvesting phase’s first stage is to settle the new into being the norm.

SOOP-29. The job of each management level receiving a work package (whether called task, programme, project, sprint or stage) is to design, aka plan,‘how’ to achieve what is being requested within constraint. Contradictions between constraints are relocated for resolution by the superior authority or expertise.

SOOP-30. The typically quoted triplet of time, cost, scope or ‘Faster, Better, Cheaper’, is only illustrative of success criteria, not exhaustive.

SOOP-31. Before planning is conducted, attempting to impose constraints on all project variables (all as in ‘to time, to cost and to quality’) is generally baseless wishful thinking. After planning, and before agreeing a baseline, there should be choices to optimise one of time, cost or scope/quality.

SOOP-32. Process adds extra cost that is only justified if it is more than paid for in effectiveness and reduced uncertainty.

SOOP-33. All constraints imposed by people are capable of being changed. Change the people or, change the people!

SOOP-34. Projects are conducted by people. Plans are predictions of people’s future actions that will create a new state of the world. Plans can never be followed blindly. For plans to be reliable requires consideration of many factors in their creation and use.

SOOP-35. A plan is a collection of elements that starts with the statement of objectives, the ‘WHAT’ that we want to have achieved when we have finished following the plan. After ‘what,’ everything else to do with plans is more speculative. In many circumstances the What is also unstable and or unclear. Stability and clarity are drivers of life-cycle choice – Pre-Dictive or Ad-aptive.

SOOP-36. The steps of Planning (Agreeing Target, Sharing Options, Agreeing Steps) are used when planning from scratch, AND when re-planning to affect day-to-day corrections needed to proceed under control, AND when conducting Impact Analysis for change management. The essence is true in iterative and sequential project models.

SOOP-37. Once a plan is created it is only of use if it is then referred to regularly; like a map, the journey covered so far must be ‘ticked-off’ and newly identified hazards navigated around. Routinely, ‘what is left to do?’ is re-assessed against CURRENT expectations. For example, incomplete tasks scheduled in the past and still relevant, must be rescheduled in the future and resource profiles recomputed.

SOOP-38. The steps of planning explore the collection of options available to the project management team for HOW to achieve the ‘what’. Then select amongst the options and agree the baseline, i.e. agree the ‘contracts’ that say, “We will achieve agreed success criteria within agree tolerances given agreed success factors.” – [Planning-P]

SOOP-39. A usable plan is a shared consciousness, however it is represented or arrived at. P

SOOP-40. If, during planning, we create understanding, then amending intention, schedules (and all other project elements), is comparatively easy and without it, may be impossible. P

SOOP-41. Creation of a usable plan must be (is best) done as a social activity. Planning is about understanding and buy-in, not schedules. Schedules change. P

SOOP-42. ‘Making a plan’ mostly involves selection between options whose merits we cannot distinguish during planning. Later, during execution, the shared consciousness from planning allows for swift and coordinated revision of the currently selected route to achieve the one certain part of the plan – the objective. P

SOOP-43. Useful plans are understood, agreed, committed to, achievable and subject to situational change; ultimately plans are a bunch of options and the mind-set to treat the options flexibly. P

SOOP-44. The project manager’s skill should be in focusing a group on an end point and creating a team whose shared contributions will achieve the results required. FC, P [Accidental Project Manager-APM]

SOOP-45. The project manager and exec should recognise the impact of project management control overheads. They are assessed during planning workshops when it is possible to gauge how much shared understanding and humour the product owners/senior user(s) constituents show, and how much solution specific domain knowledge (and humour) the scrum master’s senior supplier(s) staff possess. P

SOOP-46. The Gantt chart is the wrong tool for creating plans. This is one of those ‘first principle’ rules you can break when you know the consequences. P

SOOP-47. Solitary planning of group activity is possible for well understood problems where buy-in is unimportant – a mistake the rest of the time. Solitary planning of group action is highly likely to end in failure, as is believing that software tools can plan – software tools only document what people have planned. P, APM

SOOP-48. To be accurate in the context of uncertainty requires specification of tolerances, i.e. ranges. If accuracy (veracity, truthfulness, reliability) is to be maintained in the context of uncertainty then precision reduces. P, APM [Estimating-E]

SOOP-49. Estimates differ from guesses because estimates INCLUDE an audit trail to justify their contents; both can be wrong but in an estimate you can spot it, tell why, and make corrections. E

SOOP-50. All planning must balance detail with time frame and expertise. The aim is always to be as precise as is useful, while still being accurate given what we currently know. The closer the match between our suggestion of causes and effects, then the greater the confidence we can place in the plan. P, E

SOOP-51. A way of expressing how far ahead we can plan is to say “simplicity means ‘cause and effect are known in both directions”; defined results and only those results from defined triggers. Defined triggers and only those triggers to generate defined results’. In the ‘simple (deterministic)’ case, we can plan to infinity with absolute confidence. As complexity rises so we suffer an increasing degree of failure in ability to state or link cause and effect and thus reduced capacity to plan into the future with precision that is still accurate. In this case backcasting from a goal is the preferred approach. P TL

SOOP-52. Risks are differentiated from issues, and problems, by the dimension of ‘uncertainty’. All concerns are either certain or not. Within ability of not, within authority or not. Those that are not certain (in cause and/or consequence) are risks. A problem is a concern for which I have Ability and Authority. If certain and either ability or authority is missing then its an issue. Issues are relocated R, [Project Controls-PC]

SOOP-53. A problem is an off-plan state within my/our skill AND authority to resolve, i.e. a problem is an inevitable and treatable concern. PC

SOOP-54. An issue is an off-baseline state outside my skills OR authority, i.e. an issue is a concern that is inevitable and untreatable by me. PC

SOOP-55. A project is an exercise in applied threat and opportunity management. R, PC

SOOP-56. The project manager’s planning mantra should be, “Faster, Better, Cheaper. Please pick two but understand that the third will be the consequence of thousands of decisions during planning and execution.” If you pick scope we’ll be waterfall, if you don’t pick scope we’ll be agile. APM, PC, [Development Lifecycle-DLC]

SOOP-57. As a golden and general rule when using any form of template or checklist, never omit something because there was no ‘official heading’, and never write crap to populate a heading where no value accrues. Just write, ‘no observation of valuable’ or similar. If you should be able to fill a heading in and can’t, then write, ‘being researched’ – and be sure it is! PC

SOOP-58. Writing reports (logs and registers) is valueless until they are read. PC, APM

SOOP-59. ‘Learning’ only occurs through application (experimentation) not through observation, although observation is a prerequisite. FC

SOOP-60. Delegation agrees responsibility for achievement of a target within constraints by someone. It MUST also pass enabling resources and level of authority. Delegation of responsibility CREATES accountability in the delegator. That is: obligation to resolve Vision versus Authority/Resource/Skill shortfalls. FC, TL, APM

SOOP-60. Delegation = agree responsibility for achieving a goal = pass Resources Authority + Constraints. Delegator CREATES own accountability (=Duty to fix issues of Vision vs. Power Resource Skill).

SOOP-61. For some senior managers it is an unwelcome surprise to realise they are accountable for project decisions that directly affect success, so must make timely response when called upon. The realisation of the transparency best-practice project control creates is one of the real reasons adoption of methods may be sabotaged. FC, TL, APM, PC, [PRINCE2-P2]

SOOP-62. In general projects should be, ‘by the business, for the business’ not ‘done too the business’. Thus the full-cycle investment manager should always be the sponsor! FC, BC, APM

SOOP-63. All the procedures in the world are of no use without people, while good people without procedures can succeed. The actions to appoint the team are 99% of the determinants of project outcome. FC, APM, TL

SOOP-64. Nothing happens in a project without people. FC, APM, TL

SOOP-65. Stakeholders are all those people with an interest in, or ability to exert an influence on, the project. Note interest does not have to be a vested interest nor does influence have to be a positive influence to count as a stakeholder.

SOOP-65a. Stakeholders are all those people with a sharp-stick within reach. FC, APM

SOOP-66. Stakeholder analysis starts on project day-one and is repeated to some degree every day. Characterising the attitude to risk can only be done with stakeholder involvement, knowing customer (quality) expectations and agreeing acceptance criteria without having a solid stakeholder analysis, are all mistakes that are normally project killers. Q

SOOP-67. The project manager should appreciate the question in hand at the start of planning, is ‘how to create a shared, agreed view of what we will have achieved when the project ends’. The tools are shared workspace (whiteboard?) and depending on the participant’s role either business-case, backlog or breakdown structure. The techniques are social sessions that ‘decompose’ mission to vision, vision to products and ‘back-cast’ products to activities. APM

My friend Bill Duncan says SOOP-67 implies planning happens once. So as clarification: Some basic elements

• Every-time you facilitate or participate in planning start with “Know the target”
• “A project needs continuous/ continual (re-) planning. At Day/ Sprint/ Team/ Weekly/ Work-Package/ Stage/ Phase/ Release/ Monthly/ Quarterly/ Project/ Business Case/ Program/ Annual/ Portfolio/ Strategic review level – the PMBoK-G and Agile both tell us about the norms at the shorter end of the scale eg under Business Case  (Remember Process Groups are not phases) 🙂
• PM duty to get planning discussions held
• Planning discussions held whenever clarification of what or how required – That’s particularly (only?) where coordination or rationing (or oversight) is required
• Planning discussions start with “where is the (currently) envisaged end point”  – Most planning discussions occur against the context of “whats the current plan and the most recent achievement/ activity versus current intention and expectation?”
• Planning session end with agreed and allocated/ scheduled/ resourced etc actions – including those that are purely contingent

SOOP-68. Ensuring a shared view of the end point (and escalating irresolvable contradictions to the exec and, perhaps, beyond) is achieved IS the project manager’s #1 concern. The biggest focus on this aspect is during definition of project (stage, Release, Sprint, A26-Work Package) end-point. Subsequently, focus is required during change control. Responsibility rests variously with Product Owner and scrum master or project manager depending on mindsets and methods FC, TL, APM, [Scope Management-SM], PC, Escalation-Esc]

SOOP-69. At the beginning of a project (release, stage, phase, sprint or work-package), everyone arrives with their own expectations. Expectations may be unspoken, immeasurable and contradictory. By the time we’ve finished defining scope, the hope is that all targets are agreed, aligned and explicit. ‘All’ is unlikely, people often keep personal desires unspoken, but ‘All’, including the personal, is the target. Esc, SM, APM, TL, FC

SOOP-70. If some stakeholder might kill a project, the best time is before much has been invested. Involving the negative stakeholders early (even if only to decide how to side-line them!) is always best. [Politics-Po] [Stakeholder Engagement-SE]

SOOP-71. I suggest the correct strategy is to agree whether politics will be handled by the sponsor or the project manager, or both. Politics should not be handled by the project manager without explicit recognition from the exec (and possibly a note in the project manager’s role description). Po, SE

SOOP-72. Lack of clarity about project objectives isn’t ‘wrong’, it is often reality, but it is more expensive. SM, DLC

SOOP-73. It is to be expected that when Stakeholder Expectations are extracted they are incomplete and contradictory. It is the Product Owner’s (or exec and senior user’s) roles to resolve contradictions or analyse how the project will be affected by politics and how plans will compensate for it. Po, SE, SM

SOOP-74. Since acceptance criteria drive tasks, and tasks drive costs, and costs drive the A2-Business Case, then the more complete and stable the AC, the more reliable is the cost side of the investment appraisal. [Cost Management-CM], FC

SOOP-75. The Product Owner(s) or Senior User(s) are accountable for the competent expression of complete and correct acceptance criteria (Definition of Done). The expression Caveat Emptor reflects the potential gap between Fitness for Purpose (FFP) and Conformance To Specification (C2S). Q, SM

SOOP-76. The senior supplier cannot guarantee Fitness for Purpose (FFP) only Conformance to Specification (C2S). Q, SM

SOOP-77. While scope is being defined, you must gauge how freely people share opinions and engage in good natured argument – there should be lots. There should be lots of smiling and joking. If not, then opinions are not being aired, options are not being explored or tested or well made. Bad ideas are not being challenged and replaced with good ones. Commitment is not being built. Decisions made are at risk of being unmade later. Po, SE, [Team Building-TB], APM, TL

SOOP-78. How much humour and cooperation is exhibited in defining ACs or how unclear and volatile the ACs are, will define how strong, competent and mutually supportive the project manager and sponsoring exec will have to be throughout the project. [Leadership-L], Po, SE, SM, PC

SOOP-79. A project goal statement is a short description that MUST state, ‘what the world will look like after we have finished’ (the investor’s target). A good one does it in binary, testable terms that define the delivery team’s means to show, ‘we are done’. Phrasing should avoid, ‘how we’ll get there’, unless delivery method is constrained.

SOOP-80. A business case, and all that flows from it, must always be current. ‘Current’ reflects evolution of the project and the wider context. No project should deliver to what was asked for on day-one unless the world is a very stable place or the project is only one day long. BC, Po

SOOP-81. Note a crucial distinction: the A2-Business Case IS NOT A JUSTIFICATION of the project. It is the DESCRIPTION of the project’s justification. BC

SOOP-82. As a general rule pet projects are safest when short. Get in, get it done, get out. Successful delivery of pet projects is often a route to promotion. APM, Po

SOOP-83. Best practice guidance says the A2-Business Case must be re-described periodically throughout the investment’s lifespan. It must be evaluated (overseen) at portfolio level rather than just through the project. BC, Care for Capital-C4C]

SOOP-84. Simple projects don’t need much senior management involvement, and complex ones do. Po, PC

SOOP-85. For many change initiatives, cost isn’t the selection criteria, it is the customer’s psychological will to accommodate change and the suppliers capacity to accommodate concurrent changes. TL, SE

SOOP-86. The most important criteria for project approval is to review ‘this project’ against ALL those currently active and also delivering into the same business-as-usual area of the enterprise. The portfolio authority must assess if the degree of ‘churn’ that will disrupt service provision and revenue generation in the target area of operations is below the threshold staff can tolerate. [Portfolio Management-PfM], BC, Po, APM

SOOP-87. Simon’s Project Index of Virtue (SPIV) calculates (Benefits Identified/Effort still to be exerted). The projects with the highest values at any time should be the ones being actively pursued. BC, PfM

SOOP-88. Best-practice in investment (project) approval should define accountability for benefits to rest, clearly with the single point of authority delegated by the organisation’s equity holders, i.e. through the main board’s governance duties, through the portfolio management function to a change’s sponsor. A ‘Management Handbook’ should be written during embedding that sets-out the mechanisms, rights and duties of those involved. [Governance-G], Po, PC, BC

SOOP-89. To be accountable for benefits requires control over the factors affecting benefits. That includes ultimate decision maker, especially with respect to threat and opportunity, and trade-offs between decisions that affect acquisition (project) costs and ownership costs (margin size and timing). BC, Po, PC, G, [Benefits Management-BM], R

SOOP-90. If a project manager wants to meet with their project board it is because a decision is required. The project board should turn up informed and without delay. G, PC

SOOP-91. Of all the strategies in which to secure project board involvement the most important is Risk Management. Definition of assessment scales and thresholds that match risk appetite is impossible without project stakeholder engagement. R, SE

SOOP-92. Development of the project’s goals MUST explore and develop the sponsors and stakeholder’s attitude to risk, must define the risk assessment scales, must establish who has passion for what aspects of the project’s uncertainties at the earliest possible opportunity and every subsequent opportunity. This is part of appreciating the ‘risk culture’. R, SE

SOOP-93. Risk is ‘a future condition or state with the possible cause(s) of that state and the consequence(s) that would affect the world in ways one or more of us cares about’. R

SOOP-94. Project management and risk management may be two labels for the same discipline. At the least, management of a project is an exercise in applying risk management. R

SOOP-95. A Project might be ‘the coordinated actions of an organisation seeking to change the current state of the world to a future-state-business-as-usual in a way that has utility for the (most powerful) stakeholders’. FC, TL, APM, G

SOOP-96. Every discussion of risk is a discussion of possible and intended actions. Intended actions are ‘a plan’, and plans stand or fall on their estimates. Estimates are uncertain predictions. There is a close relationship, if not just one topic in ‘benefits hoped for’, plans, estimates and risk. R, E, P, 

SOOP-97. As in all insurance equations (contracted risk arrangements), a small certainty (your wage received) is traded against a larger less probable value (corporate profit and loss). When the employee’s efforts don’t generate return to the shareholder, they still get their wage by eroding the shareholder’s equity. When the employee’s efforts generate a surplus, it goes to the shareholder as the equity participant’s reward for risk taking. That the shareholder underwrites the employees wage and deserves reward for it is frequently forgotten, particularly in the public sector. R, APM, TL

SOOP-98. The solid start point for ultimate ownership of risk is: who ever puts up the capital (shareholder’s and taxpayers money, participants blood, sweat and tears) and may lose it or gain from it, then they ‘Own the Risks’. R, SE

SOOP-99. Don’t split authority over establishing project controls from accountability for delivering benefits – psychology prevents it from working. R, SE, G, [Psychology-Psy]

SOOP-100. Generally opportunity is a weak force of attraction while threat is a strong force for repulsion. IE Pound for pound threat is more ‘serious’ than opportunity. Psy, R, BC, [Complex Adaptive Systems/ Leading Complex Projects-LCP]

SOOP-101. EMV says NOTHING useful about A RISK. It is the contribution each risk makes to a project’s aggregate exposure from a risk pool. EMV can only be calculated if reliable numeric probability and impact scores exist (rare). Safe use needs understanding (also rare). See soop 300. R

SOOP-102. Never quote a risk’s factored value (its EMV)– it is useless in isolation for any practical use. Only quote EMV of a pool of risks, and then only to people who understand probability density functions (z-tables). R

SOOP-103. Reserve should only allocatable by ‘the next higher level of management’ who may call it tolerance. R, PC, BC

SOOP-104. Good risk assessment scales are descriptive, in emotional, visceral language. Numeric scales do have a place but are more limited in applicability, less useful and often more expensive to use. R, PC, BC

SOOP-105. Risk scales position uncertain events against how much unallocated cost and unallocated time they will consume (and all the other dimensions of unallocated care that exists) to assess significance. R, PC

SOOP-106. If risk awareness isn’t in people thoughts and deeds having it in a document is scant use – reinforce the culture when appointing the team and in the workshop that defines the project’s goal and approach. The RMStrategy must integrate to operational risk procedures or programme risk procedures. It must match how the organisation handles corporate governance. It must reflect authorities and escalation routes. Esc, R, BC, G, PC, P

SOOP-107. The GOLDEN RULE in risk identification is “do not try to assess (yet)”. Any conversation about “That doesn’t matter…” or “that’s important…” should be immediately chocked off – focus on volume. Analysis is important, will come later but cannot be effective without a pile of risks to assess – create the pile! R, Running Workshops-RWS]

SOOP-108. All risk identification comes from the sub-conscious mind, good wording from the conscious mind. Its a 2 step process. R, RWS, Psy

SOOP-109. Golden Rule: Don’t put good risk definition before capture. When there is a ‘price’ to be paid IE some bureaucracy in the entry process people won’t raise risks. Psy, R, PC

SOOP-110. Risk Categories should be applied not to causes and consequences but to responses. Categorising responses is a useful way to group actions for assignment of response responsibilities and rationing limited budget. R, PC

SOOP-111. The GOLDEN RULE in the risk assessment process is “do not develop responses in this step”. It is OK to return to risk identification if needed. R, RWS

SOOP-112. The GOLDEN RULE for identify risk responses is “do not select responses (yet)”. It is ok to return to assess or even identify if that is useful. R, RWS

SOOP-113. All possible risk responses that are identified are recorded to the risk register with their actions, costs and timescales and the affect that they would have on all risk probabilities, impacts and proximities. Selected responses, whether to enhance, or avoid or contingent must be copied (transferred) to the resourced schedule for management of risks. Projects are run from backlogs and baselines not risk logs. R, PC, P, BC

SOOP-114. When considering the selection of responses to threat and opportunity the important insights is to benefit-cost-analyse all responses, whether response to cause or consequence, for the affect they have on all other risk’s causes and consequences and the A2-Business Case as a whole. R, PC, P, BC, G

SOOP-115. It is useful to group risks by the responses that would affect them. IE categorise the risks as changed for better or worse by the same response or response type. A wonderful response to risk one that makes risks 2 to 20 worse needs to be seen for its aggregate affect on the A2-Business Case. R, PC, P, BC, G, BR

SOOP-116. A risk that sits in a group that cannot be reduced below 100 items also needs to be seen for what it is: complex. R, BC, BR

SOOP-117. Good management of selected risk responses is simple (but seems rarer than it should be): take those responses that the team select to action and put them into backlogs and baselines (A26-Work Packages in the A16-Stage Plan perhaps). Then manage the project as normal to the sprint backlog or stage plan! P, PC

SOOP-118. Manage activity (whatever its deliverable) from the kanban board/ sprint-backlog or A16-Plan (Project) (Stage) (Team). P, PC

SOOP-119. A risk-response A26-Work Package’s deliverable is an altered risk profile. Key to Risk Management is monitor the A26-Work Package’s RESULTS back into the A25-Risk Register to chart the risk’s improving position: sweetening opportunity and receding threat. On the basis of the new, current status re-perform the prioritisation and response selection steps. Stop actions that have achieved the desired alterations, initiate alternate action where the response isn’t working satisfactorily. R, PC, BC

SOOP-120. A contingency is specifically allocated to a pre-defined uncertain state. It is a pre-authorised, auditable provision for a known unknown. Contingency comprises those resource elements (skill, will, time etc) set aside for known unknowns whether impacts are positive or negative. It isn’t just an unjustified and unauditable ‘bit of extra’. R, PC, G

SOOP-121. The size of all contingencies whether called tolerance or fall-back or something else must be auditably based on some estimating basis. Thus if a contingency/ tolerance is not used in the context of the event or estimate that it was linked to then its future expenditure on something else is unauthorised. R, PC, BC, G

SOOP-122. Project Configuration Management (CM) is record keeping. It applies to ALL products: physical and intellectual, project management or specialist. [Configuration Management-CfM]

SOOP-123. A configuration is a collection of “relevant stuff”. A project’s configuration is everything the project creates, acquires or amends. The whole Product Backlog or Breakdown Structure (PBS) of specialist and management products that together totally resolve the project’s objective within constraints and under control. The configuration includes all specialist results, all controls and all management products. CfM, PC, G, [Product Management-PdM], Q

SOOP-124. The step-by-step review of intermediary acceptance criteria are the foundations for explaining the glib statement of “quality is built in not bolted on”. Q, PdM, SM, [Quality Planning-QP]

SOOP-125. Remember: having a document is of no value till it is read, understood and followed. Nothing happens in a project without people knowing the content of documents. Psy, FC

SOOP-126. Ease of management of concerns (problems, issues, risks and changes), volume of concerns encountered, and adequacy of budget to run the procedures to manage concerns and address the concerns being managed is proportional to the effort spent in project (and stage/ release/ sprint) start-up. Psy, SE, PC, G

SOOP-127. The ‘management of concerns’ procedure must be implemented to be as fast as required by the most urgent concern (issue), and relaxed for less urgent concerns. NOT built for the norm and side-stepped for the urgent: in this case the project becomes literally out-of-control at the time it is handling an unusual situation and a second (fifth?) disruption at the same time is much more likely to be terminal. PC, Psy, G

SOOP-128. Two subject matter experts who don’t agree and work in a collaborative environments is safer, but slower. TB, Psy, SE

SOOP-129. Difficulty of resolution of project interests is inversely proportional to the number of participants and their good humour. Psy, TB

SOOP-130. Perhaps rather than Net Present Value and the implied dominance of financial assessment we should talk of Net Present Utility (per stakeholder!)? BC, BR, TL

SOOP-131. A project manager who works as technical expert on the critical path is a recipe for disaster: the first concern that needs managing creates a schedule impact. FC, APM, TL, PC, [Schedule Management-SM]

SOOP-132. Golden rule of Issue management: Create one very easy to enter process whose first step is capture in a publicly visible place. Then instigate widest possible sharing and invite impact commentary. [Change Management-ChM], CfM, PC, G, Psy

SOOP-133. Policy is the statement of values or aims that guides the creation of new procedures for contexts where procedures are absent or challenged. G, PC

SOOP-134. Definition of FfP and C2S are foundation stones upon which much (everything?) else in good project management stands.

FfP = Fitness for Purpose: reflection of scope’s “I need”. Ffp is “What” plus acceptance tests and Definition of Done. It is of the Product Backlog or Breakdown Structure (PBS) in the quality mirror . Conformance to Specification = C2S: quality mirror’s reflection of scope’s “How” and Work Breakdown Structure (WBS)/ Sprint backlog. Q, SM

SOOP-135. Quality planning, as in “select standards” is crucial to estimating. Estimate are only meaningful when how-the-work-will-be-carried-out is explicit. ‘How’ must match product quality targets.

Product quality targets (Acceptance Criteria) determine useful Process standards. Process standards are central to estimating. Estimates are predictions that define baseline. Baseline is the reference point required to be able to track progress versus expectation and control future project conduct. Q, E, PC

SOOP-136. Estimates are not numbers. An estimate is a heuristic to (re-) determine the range of values expected as of today’s understanding.

SOOP-137. Quality control is the use during product realisation of the process standards selected in quality planning by the technical and management team members. Q, PC, Earned Value-EV]

SOOP-138. No one should have a job title of ‘project quality control’. If they have then quality hasn’t been understood! Q

SOOP-139. Quality control is done by the person doing the job such as brick-laying, writing software or running a risk identification workshop. Quality control is only present in the project if it is in every action they take.

IE the people assigned the responsibility for producing (acquiring) some project product whether A3-Checkpoint Report or Astronaut’s Gloves. Q, TB, [Roles and Responsibilities-R&R],G, Q

SOOP-140. If the team do not, prior to the project, know with ‘unconscious competence’ the contents of standards and method statements then progress is very likely to be slow and rework high. Q, TB, E

SOOP-141. To be competent at project assurance requires understanding of ‘Quality’ as a topic AND being either skilled in the underlying discipline or being able to ‘play the dumb-laddie’ IE question even the ‘obvious’, and preferably both. Q, G, PC

SOOP-142. It is often said that communications are the most significant factor in project success. That is wrong. The most important factor is decision making. Good decision making is only possible with communications. Thus communication is vital but is not of itself of any use at all. FC,

SOOP-142a. It is often said that a project manager’s job is 90% communications. That is very misleading. It implies the PM must communicate 90% of the time and that is wrong. 90% of the pre-requisites to project success are the right people communicate the right content at the right time. The PMs role is to ensure the communications is happening not to participate in all of it. FC, [Project Communications Management-PCM], PC, G

SOOP-143. ‘Control’ is a process. Controls compare current status versus planned intention and re-use planning to develop appropriate adjustments to future intended activity. The process keeps the project focused on the target where-ever it is today. The movement of the target and the performance variance against current-plan are the inputs to decision making. PC, G

SOOP-144. Controls must cause mostly correct decisions within a timeframe that is adequate to take action. Controls must match the project’s context of significance (scale), risk (uncertainty), complexity (traceability of cause and effect), politics (decision making), management tone and stakeholder power. Controls are the mechanisms for, frequency of, content of, parties involved in and results from project communications. PCM, SE, P, PC

SOOP-145. The minimum needs for competent project control is shared consciousness about the purpose of the journey and agreement on how to steer. BC, PC, G

SOOP-146. The mechanics for controls operate across boundaries between timeframes and between delegated authority limits. Authority and timeframe boundaries span the investment’s existence. A ‘project’ is part of  an ‘investment’. Control that is limited to just the project and isolated from wider consideration of rationing of resources (capital) is disconnected from reality and invites failure. PfM, BC, BR, G

SOOP-147. Responding to project variances that are ‘better than expected’ is what delivers future-state-business-as-usual faster, better and cheaper than current project norms are targeting. Projects would be habitually early and under budget if people paid attention to the gains. PC, Psy, TB

SOOP-148. Generally in delegating some result I want the escalation of options back that confirm no wastage: IE “if you really want this scope in this schedule then I need these resources… or if scope and resource are fixed then…” PC, Psy, Esc, TB

SOOP-149. The operation of the controls demands two communication flows: One is “here are the target and resources and constraints” – often called delegation. The other is “here are the contradictions over which achieving targets is dependant on you making decisions”. Often called escalation. Esc, TB, PC, G

SOOP-150. Project assurance have an obligation to judge if adequate allowance is included in project member’s schedules for the technical activity AND its control overhead. PC, G

SOOP-151. Sales and winning business come mostly before planning determines calculated deadlines and resource allocations. The reality upon which deadlines are set is different in the market-place to the technician’s workshop. Neither is right or wrong. The Project manager’s job is to establish the ‘can’t be changed’ at each end of the spectrum and reflect the contradictions to those authorised to make decisions. ‘Downward’ for technical, tactical trade-offs and ‘upwards’ for strategic, often financial rationing trade-offs.

SOOP-152. Commercial pressures are to win business, IE make commitments before the facts are fully known. Committing on partial knowledge is the commercial risk the equity holders take. Where negotiable interim payments ease cash-flows. Customers always want to see evidence against which to make part-payments. In this reality are payment-milestones created and delivery dates decided: engineers are quiet correct when they observe dates were not calculated from their rationality. They are wrong when they complain about the dates – it illustrates their limited perspective. What was rational was provision to fund the pay-roll!

SOOP-153. For successful project delivery the current option-set embodied in the current plan must be regarded as disposable as soon as circumstances suggest a better selection of options.

SOOP-154. A plan is a shared consciousness that predicts: what outputs are to be produced and what resource will be consumed by what activities and when to deliver the outputs.

SOOP-155. A baseline plan is an agreed plan. An agreed plan is a contract that transfers control authority over resources, within limits in exchange for the deliver of a future-state-business-as-usual.

SOOP-156. When scoping the project with the first social group decomposition of the trigger or goal of any contract continues for as long as the customer wishes to attach acceptance criteria to the project’s results. For the team member/ managers (second social group) the initial decomposition ends when they no longer need to ask questions to clarify material choices about customer preferences. Strategic risks should also be captured at this time.

SOOP-157. For the team product based decomposition stops at the point at which something no longer has decomposition. It is atomic: at ‘this’ level it has only a life-cycle. Atomicity may be due to the laws of nature or a chosen perspective EG something is acquired as a complete CI. For the project manager each A26-Work Package should result in product(s) that are NOT decomposed in the A16-Project Plan but ARE decomposed in the A16-Team Plan. Whether they are decomposed in the A16-Stage Plan is a tone, style, level of control decision.

SOOP-158. When decomposition reaches the ‘atomic’ level then further analysis will have to shift from identifying component parts (‘Contains’ no longer works). Now we must look at life-span of phases in the (sub-) product’s life-span and the acceptance criteria between each life-cycle phase in the life-span.

SOOP-159. A product’s life-cycle steps will be the task in the Work Breakdown Structure (WBS) and must link to standard method statements in the Quality Management System (QMS). The linkages GoalàProductàLife-Cycle-Step (Method Statement) are fundamental to both estimating (A2-Business Case construction) and progress tracking (Ongoing review of A2-Business Case).

SOOP-160. To start planning with a phased or product development life-cycle view is possible when the customer is clear on what they want and the team knows how to deliver it. IE starting with a phased view is possible when everyone is highly experienced. In this case it is quicker and cheaper. It is not however likely to succeed when either customer or supplier is unsure of elements of ‘what’ and ‘how’. Many project stresses are rooted in an inappropriate start point during planning: cut corners when you know the consequences not otherwise.

SOOP-161. Never estimate duration. Only ever calculate them. Durations depend on effort divided by resource availability and productivity.

SOOP-162. Software is no substitute for a white-board and marker pen to generate a shared consciousness and commitment. Software is optional, people are not.

SOOP-163. A backward pass critical path calculation is useful to priorities speed-up operations. Commonly project manager’s of urgent or slipping projects attempt to speed every task and waste resource speeding tasks with float.

SOOP-164. Resourcing projects is a responsibility best carried out at portfolio level, if only for those rare resources that are the bottleneck in the organisation’s change initiatives.

SOOP-165. The sooner you mange projects in terms of money the faster you get promoted

SOOP-166. Estimates are created during planning, but their most important use is during execution to support reliable tracking of achievement and thus continuous appraisal of future actions that will deliver the project (and the biggest return on investment).

SOOP-167. Uncertainty in an estimating context might alternatively be expressed as varying confidence based on the observation that confidence of project delivery grows as budget and schedule allowed increases while that growth probably erodes the A2-Business Case.

SOOP-168. Both an estimate and a guess can be wrong but with an estimate when I discover the value is wrong I can tell why, if only partially and correct the basis to generate a better value.

SOOP-169. In most requests for an estimate the requester is asking for a “won’t be exceeded” value. Here be many dragons.

SOOP-170. Use of a range allows us to trade precision against confidence of correctness. Typical project estimates are highly precise and wrong IE inaccurate. A useful project estimate is first correct, IE accurate, and then as precise as needed (and no more). To create a correct estimate from sparse information generally forces a reduction in precision.

SOOP-171. Understanding the trade-off between experience, background information, time to estimate and precision while remaining accurate is a mark of estimating maturity.

SOOP-172. Always calculate cost and duration from work and resources. Calculate work from the result required. Quantities estimated should be restricted to the dimensions of the result required by the sponsor as defined by the senior user(s). From these resources and tasks IE work (effort) involved are derived.

SOOP-173. Where duration and cost are estimated as the raw quantities then audit trail, transparency, much of the ability to manage and all of the ability to track and forecast during execution of technical work is lost. A huge price to pay for no gain.

SOOP-174. By definition reserves (response to unknown unknowns) cannot be assessed other than by guess or analogy while a project’s total contingencies (responses to known unknowns) should only be assessed parametrically using the cumulative confidence ‘S’ curve.

SOOP-175. Filling in timesheets without solid understanding of what marks ACHIEVEMENT in terms used to define the estimates is UTTERLY USELESS for determining project status. It might just help finance plot outward cash-flow as seen via the payroll but nothing more.

SOOP-176. The records within an estimating history must match the content of estimates. IE the values recorded are only meaningful in the context of assumptions and observed factors affecting the result.

SOOP-177. After planning and before initiating change is a very good point at which to stop a marginal idea. IE an idea with merit but whose returns have a lower benefit to cost ratio, lower Internal Rate of Return, lower Net Present Value, lower strategic significance or lower gut passion than other claims on resources.

SOOP-178. By sealing the stage (and project) ‘contract’ between project manager and all higher level links in the chain-of-command we are declaring that the technical and project management tasks and agreed resource assignments match the costs and delivery dates for the outputs agreed to be in scope at the level of quality required and risk accepted (±). It is from this point only that “to time and cost and scope/ quality” has meaning and not before.

SOOP-179. Never agree a commercial contract where there is no transparency of supplier progress! If they have a legitimate argument for not sharing details of the schedule, task-measures and reimbursable costs then insist on the use of Earned Value for the reporting regimen and a penalty clause in the contract for dishonest (and just inaccurate) reporting.

SOOP-180. The crucial factor in delegation of work is not size of work but that the criteria by which obligation is met are clearly agreed by both parties.

SOOP-181. It is the team member/ manager’s job to say how to meet each output’s specification –IE to define the resorce and effort portion of estimates; the project manager’s to collate what is known and unknown into budget and scheduling options with allowance for uncertainty and the exec’s (sponsors) job to decide affordability, acceptance of uncertainties and whether politics overrides ‘engineering and rational calculation’.

SOOP-182. Each management level delegates objective and constraints, listens to reflection of costs and timescales and agrees to allow the lower-level to proceed or changes the project’s context in some manner and requests re-planning. The cycle repeats until an acceptable balance is reached.

SOOP-183. The crucial factor in establishing A26-Work Package controls should not be consideration in terms based on the duration of the task, but in terms of impact of error or opportunity and time to remedy or capitalise.

SOOP-184. Tracking progress by ‘percent complete’ is only safe in physical and incremental tasks which includes brick-laying but eliminates all intellectual work such as ‘design’ and especially software.

SOOP-185. Where work delivers an intellectual results or is of an ‘only usable when the last item arrives’ type then the only safe, if harsh assessment is ‘Finished’: milestone achieved.

SOOP-186. Earned Value percentage-complete values for each inch-pebble on the way to a milestone should be agreed on verifiable grounds linked to the contents of the estimating package for the work.

SOOP-187. The three questions of ‘missing, wrong, extra’ are crucial at every hand-over. If asked and answered at every in-project handover then projects will eliminate creep and be in control of faster-better-cheaper trade-offs. Note ‘Scope-Creep’ is only one form creep.

SOOP-188. Creep caused by a failure to record, re-plan and re-price work arising from customer requests is either a failure of competent change control or the cost of politics.

SOOP-189. Politics may override rationality, price may be flexible but true cost of scope divided by resources must still be in the baselines.

SOOP-190. Project managers assemble details of costs, even under conditions of uncertainty but price is determined by emotion, politics and psychological.

SOOP-191. Control of unused budget linked to products frozen for review may reduce scope-creep by removing creep’s illicit funding.

SOOP-192. Generally reviews are reliable if performed by skilled people who are willing to constructively debate their opinions.

SOOP-193. Use of walk-through aims to spread ‘best-practices’ amongst the team. The return on investment is normally huge – I recommend there use!

SOOP-194. Projects are hard to run from one schedule of resourced tasks and impossible to run from more than one. Actions required by project management team members whether ‘Plan-A’, ‘Plan-B’ risk responses, authorised changes or any other source of work must be in the current A16-Stage Plan baseline that balances effort required for scope desired, resources assigned, acceptable durations and acceptable costs.

SOOP-195. Analysis of project status covers re-performing as much of the planning activities as are required to ratify ‘yesterdays’ plan as relevant to today and replacing/ supplementing those parts that are no longer the best of our options.

SOOP-196. Time spent (by senior management) on planning is repaid in swift situational decision making later.

SOOP-197. Formal reports should never be the first time any management level encounters bad-news. The formal report should only ever be a record of what was already communicated.

SOOP-198. Reserve the details of activities to the A3-Checkpoint Reports and A16-Stage Plan. This reduces project board meddling when of the 30 ways to achieve something the project team has selected one that the project board member would not have and now feels compelled to issue a random and unhelpful instruction about.

SOOP-199. Insisting that concerns are well defined at the start will discourage people from raising them. Capture in any form, THEN bring-up to quality needed to develop potential responses.

SOOP-200. At the identification stage for a concern to be ‘Well described’ means the positive and negative affects on the investment, on the product acceptance criteria, project success criteria, and success factor(s) are all expressed in terms of the untreated impact of the concern.

SOOP-201. Untreatable Risk: “a future conditional state, (together with the potential causes and consequences that will have an affect on something that someone powerful enough to matter, cares about and) about which we cannot ourselves decide the actions to take”.

SOOP-202. The key consideration in handling a concern is how much authority is needed to decide the responses to apply. The decision will be based on what magnitude are the inherent impacts and the affects of responses. How the authorised decision makers decide will include assessment of how probable the cause and consequences are (including when certain) combined with available resources, seriousness and urgency.

SOOP-203. Recommendations are in essence unauthorised decisions.

SOOP-204. Projects are successful when they deliver what the customer wants at the end (which is often not what the customer asked for at the beginning).

SOOP-205. [ Classically the call is for the project to close when it has achieved what was planned at the beginning: common sense and reality dictate projects should close when what is wanted at the end is completed. There may be contract issues to resolve if these two views diverge in ways that have not been subject to adequate change control. ]

SOOP-206. It is appropriate for the project management team to ask “how well are we matching our success criteria?” If we are to achieve some learning from our experience then the question should be asked in each team checkpoint, in each review of current status and in each planning session. Holding these discussions when closing a project is mostly a waste of time.

SOOP-207. Projects are a means by which people create change to the status quo that enables some form of return on the effort expended.

SOOP-208. Projects (stages, sprints, phases, work-packages, tasks, jobs or any other form of activity) that don’t produce some change to the world are cost without value.

SOOP-209. Projects ARE activity but activity is never their purpose.

SOOP-210. A key question is “is the Enabling / Harvesting boundary at ‘handover’ or full acceptance?” Reality is that outside of volume manufacturing it is MUCH MORE cost effective to target a good result and also provide a warranty to fix problems than to guarantee perfection.

SOOP-211. Project managers should understand that often a list of milestone dates is arrived at during pre-project commercial discussion for political, seasonal cash-flow or other reasons not based on technician’s assessment of scope-of-work to deliver the customer’s scope-of-products: These are constraints passed to the planning team, input to the planning process and will be part of the ‘faster-better-cheaper’ trade-offs proposed during planning or perhaps escalated as contradictory constraints after planning and before baselining

SOOP-212. Ultimately the supplier charges their customers for all threat carried on the customer’s behalf and may keep or share opportunities dependant on contract structure.

SOOP-213. Assumptions are assertions we hold to be true, real or certain. Foundations upon which our plans stand without evidence to support the assertions.

SOOP-214. Typically for the senior supplier(s) when responding to RFCs the ‘open market’ competitive considerations of winning business are different: now. RFCs may be the chance to increase margin and remedy contracts ‘sold as a loss leader or to unachievable deadlines’– this applies in-house as well as for ‘bought-in-under-contract’ arrangements.

SOOP-215. The supplier view of quality is “Conformance to the Specification (C2S): we built what was asked for (we can not read minds. Even if we could we are probably constrained by a contract – but at least that could be amended if the disconnect is spotted). We can only create what you say you want”.

SOOP-216. The sponsor’s contract is dissolved when benefits are delivered, not when the outputs arrive in business-as-usual. The project board’s, project manager’s and senior supplier(s) obligations may be dissolved when the outputs are delivered to business-as-usual but a better terminal condition is when the outputs are operating in a new ‘business-as-usual’ mode. The senior user(s)’ obligations end at the same time as those of sponsor or those of the project board.

SOOP-217. The recipient’s concern is to decide if the estimate’s precision is ‘good enough’ for their decision making needs at their level of willingness to tolerate uncertainty.

SOOP-218. “What can I do to help you achieve targets?” recognises that accountability cannot be delegated. It is the accountable person’s duty and self-interest to enable success by those responsible for a task. Exec’s and sponsors need to realise this too: telling them may require tact.

“Right first time” is miss-named. It is a mantra that only works in highly repetitive environments or hugely expensive ones (like nuclear power stations). Playing to people’s strengths means exploiting ‘step-wise refinement’ when-ever we can.

It is the duty of everyone who comes into contact with an assumption to confirm or contradict it if they have the evidence to do so. EG every recipient of a document that expresses an assumption owns the assumptions within it whether they shirked reading the document or read it assiduously: assumptions are ‘owned’ by everyone who ever became aware of them or had a duty to have been aware of them.

The fact is no one undertook a project for its own sake. A project is the transition from current-state-business-as-usual to future-state-business-as-usual.

Project management is a collection of techniques. If we set the boundaries where ‘temporary project’ defines them we un-link the techniques and procedures from their driving force: the return of value (EG dividends and capital growth to equity holders, services or security to citizens).

Without the correct links fault-lines such as distorted capabilities to handle risk attitude arise in any initiative. A quick scan of reality shows that on average project management and managing of risk performs below desired levels of competency.

The whole or complete topic is investment management. Project management is just a subset. To get projects right we must discuss them alongside benefits management. For that we need roles such as the sponsor and mechanisms such as portfolio level decision making.

SOOP-219. Good guidance avoids unproductive bureaucracy – but sadly that isn’t PRINCE2®‘s reputation!

SOOP-220. BAU is the portfolio of on-going activities that uses equity and debt to return utility to stakeholders.

Utility might be physical safety, security and health or utility might be beauty and excellence or capital growth or utility might be revenue return to the capital’s owners.

The correct place to end is also business-as-usual.

SOOP-221. The required concept is: Benefits Management is the discipline and projects are (or better yet “Management of Change” is) just a phase in the investment life-cycle between equity injection and equity extraction.

• • is commissioned to change the state of the world in some way,
  • is uncertain as to degree of success,
  • will create unintended consequences,
  • is ultimately a part of the pursuit of gain or to avoid loss and so
  • is incomplete on its own.

A project is a sub-contract for deliverables within some wider initiative. If the supplier of development skills and those who deliver the benefits after the project are different people the project (the transition) is an inferior contract within one or more superior contracts that care for participant’s equity.

SOOP-222. The care and attention of the investor aligns to the whole investment life-cycle. The sponsor may be the investor or may operate on the investors behalf for the time-frame from business-as-usual to (new) business-as-usual.

The sponsor may choose to delegate care of the enabling element (aka ‘the project’) to a role that we might name as “Project Executive”. The business aspects of the investor’s, the sponsor’s (and the exec’s) duties must be defined and executed by someone across the entire investment life-cycle.

SOOP-223. Those triggered into action by arrival of an idea that grows into the A20-Project Initiation Document [ Investment Definition ] and then leave when the money is spent fail to see a project for what it is to the customer.

‘The project’ is a phase with-in management of change and realisation of benefits. A project is just the development or enabling phase in any investment.

SOOP-224. It is only for suppliers that seeing projects as finite is significant: projects are finite investments are not.

SOOP-225. An issue is an inevitable decision-making need in the hands of someone who lacks either the authority or the knowledge to resolve it. A Problem is a decision making need in the hands of someone who has both the knowledge (skill) and authority to resolve it.

SOOP-226. Success criteria are narrow, inward facing, supplier oriented measures of the project. Probably defined towards the start of project definition and mostly applied at project, stage or work-package end to measure the project team performance versus the base-line agreed AFTER planning.

SOOP-227. Efficiency incentives promote sabotage of change. To achieve change first replace efficiency based incentives with measures of ‘difference’ EG number of initiatives started and sustainable.

Later replace ‘difference’ incentives with ‘percentage of the initiatives that are delivering improvements’ (to ensure step one only has initiatives of merit and isn’t bulked-out just for bonus generation) and then reinstate efficiency incentives some time later.

Tolerance is the allowable variation between actual status (or forecast status) and agreed base-line. Tolerance is a key concept for the governance of any hierarchical organisation structure based on delegated authorities: including projects.

Tolerance is discretion for decision making. Being actually or predictably ‘out of tolerance’ means breaching some constraint and by definition being ‘in exception’.

SOOP-228. Tolerance is another name for the imprecision in both our ‘estimating ability’ and ‘status tracking ability’. Tolerance as an allowance is the degree of acceptable, natural or un-assignable variance in the system.

Tolerance as a threshold marks the point at which some concern changes from problem to issue treatable to untreatable on the basis of authority. Escalation is the mechanism by which some untreatable-uncertainty (aka ‘Ultra vires risk’?) or issue (untreatable-certainty) is returned to problem treatable status by being placed in the hands of a suitably authorised person or body.

SOOP-229. Initial setting of constraints is often of the ‘faster and better and cheaper pre-planning wishful thinking’ variety. In fact constraints should trigger “They want WHAT!, by WHEN!!” by the technical community.

It is planning’s job to respond with trade-off options that establish the cost implications of scope or the scope implication of deadlines etc. It is the project manager’s duty to escalate the contradictions between faster, better, cheaper aspirations and the project board’s duty to select between them or escalate to the sponsor or portfolio management board.

The current plan is the currently selected set of options.

SOOP-230. [ A concern is anything outside of current plans raised at any time by anyone for any purpose.

‘Concern’ covers the need to consider any aspect of the initiative of which the project is a part: whether current or future, with any degree of (un-) certainty, whether responses is mandatory or discretionary, major or minor, in tolerances or not, intolerable or not, desirable or not, possible or not and no matter who is affected or who funds or who decides its treatment. ]

SOOP-231. An untreatable concern is any actual or imaginable off-baseline that we are not authorised OR not knowledgeable/ skilled enough to deal with. The concern becomes treatable by presenting it to someone with (access to) sufficient knowledge and skill to understand the options AND authority to make a decision. There are risks and issues that are untreatable with the resources of the enterprise (or planet).

SOOP-232. ALL concerns must be logged to the publicly visible register.

Those that are trivial will be dealt with easily and where ever it is logged the effort needed should be the same: it does not cost more to log it properly).

SOOP-233. Whether a task is in the project’s scope because it delivers outputs, contributes to controls, undoes a mistake or promotes an opportunity it will draw funding from the same budget base-line, need authorisation from the same chain of command and be scheduling against the same resource-constrains.

The correct handling is for the first action of every concern to be capture to a single Register of Concerns

SOOP-234. Never attach a cost to raising concerns. Never provide disincentives, never make raising concerns difficult (EG by saying “Don’t bring me problems I want solutions” or “you cant log that it is incomplete” or “Its not well worded”).

Make logging concerns ‘free’ or better yet always ‘pay’ people for then with thanks and recognition. If there is any sort of cost people will avoid the process but the concern will still exist as a lost opportunity or a ticking time-bomb.

Without a single, cheap to use inventory we are exposed to the worst of dangers: that back-door routes to the introduction or avoidance of change spring-up. Being recorded does not make an inviolate commitment to further action: that is assessment based, but not being recorded guarantees the concern is outside controls (eg resource allocations) and so risks miss-handling.

SOOP-235. During SU the A19-Project Brief { Project definition { Project objectives, Desired outcome, … }, … A21-Project Product Description, … } is defined. Capture is senior stakeholder intensive.

If you do not capture strategic risks and risk appetite during the definition activities then every aspect of the project’s planning and control is unnecessarily and quiet avoidably weakened right from its start.

SOOP-236. If a project record is not used for a decision then question if it is really required.

Note some records are used day-to-day while some are only required when a problem is discovered and needs diagnosis and some are only use after-the-fact for audit or to learn lessons.

SOOP-237. To define the project target means define the criteria under which the supplier’s obligations are ended – the acceptance criteria. Acceptance criteria come from discussion with the project’s stakeholders.

SOOP-238. I use ‘responsible’ to refer to the duties of those who combine their skills and the resources provided to them to achieve the targets set for them within the constraints imposed on them.

Responsible = Does the work, a task may have many responsible contributors.

Where constraint, resources and targets are contradictory the responsible person(s) escalate(s) to the accountable person (singular) for resolution.

SOOP-239. I use ‘accountable’ to refer to the duties of those people who set targets for and provide resources to those who are responsible

Accountable = has the power to impose and relax constraints. Any delegated commission has a Single Point of Accountability.

SOOP-240. ‘Authority’ is the right, duty (and perhaps ability) to make decisions. The project management team should consider that decisions of direction and the rationing of limited resources are ‘delegated upwards’ and technical expertise decisions are ‘escalated downwards’ to greater knowledge based authorities.

IE Delegation and escalation are identical in intent – the project manager is (relocating an issue by) placing a duty to respond on someone with either financial or technical ability and rights IE ‘authority’ to resolve what to them is a only problem.

SOOP-241. Each phase in a product’s life-span must have acceptance criteria that define how to recognise when a phase or step is over IE the responsible person’s obligations have been fulfilled and the accountable must reward them.

A26-Work Package wise these are the conditions for handovers from team to team. Project wise these criteria aggregate up to equal the project’s overall closure criteria. IE the point at which product development in the senior supplier(s)’ hands becomes benefits development in the senior user(s)’ hands.

Expand every project product’s life-span where it overlaps the period of the sponsor’s investment and return on investment (a through life view).

SOOP-242. Reality will be somewhere between the extremes of jumbled expectation and 100% measurable, prioritised criteria.

Throughout the project the project manager and exec must be gauging how complete, certain, stable and agreed the description of the end point currently is. Just because the end point was clear in yesterday’s context does not mean it is still clear against today’s context. Project context changes when powerful stakeholders or share-price or thousands of other factors change.

SOOP-243. For project scoping workshops insist the exec (sponsor?) and powerful stakeholders attend scene setting and recommendations portions of the agenda: set a short time-frame for both and a break after both. Invite the significant stakeholders to the debating steps and don’t expect attendance.

The exec may wish to reserve decision making to themselves or a select group. Breaks may be 15 minutes or weeks (or more): either way the breaks are to allow for “corridor chats” and ensure no discussion allows ‘group think’ to move straight from debate into decision made.

SOOP-244. Uncertainty related to ‘What’ can be labelled strategic risk. It concerns choice of one goal over others. The care-for, the costs of and all the positive and negative impacts from strategic risks rest with the investor.

SOOP-245. Uncertainty from ‘How’ might be labelled tactical risk. It concerns “HOW we achieve the WHAT”. Care for tactical uncertainty lives with the supplier although costs and impacts are often split by contract between investor and supplier. Decisions may be made by the supplier but always under the investor’s veto.

SOOP-246. Another definition of project could run something like “those actions taken in an attempt to create a future state with utility to some (sufficiently powerful) stakeholders”. See the definition of risk XREF risk definition.

SOOP-247. [ The wise project manager (exec or sponsor) asks the finance director to appoint someone to the project team to drive the financial calculations. Presentation to a funding body is soooo much less challenged by the finance director when finance staff are the authors and manipulators of the numbers! ].

SOOP-248. A split of accountability for the realisation of the benefits from the authority to direct action to meet those accountabilities most commonly generates politics, recriminations and blame.

With control over only some factors unintended consequences are inevitable. People subvert what they can control to compensate for what they can’t.

SOOP-249. We must be clear that when the sponsor delegates care of the project to a “project exec” whose role matches a project’s temporary nature then guidance for the long-lived role is also required in order to set-out the sponsor’s accountabilities. [Remember the Sponsor’s Glossary entry p313: “PRINCE2® does not define a role for the sponsor” ]

SOOP-250. Project success results from agile decision making which results from commitment and understanding which results from involvement.

The probability of success is enhanced if the project board is involved in creating the control strategies. The level of control required is a cost benefit trade-off that expresses the managements ‘tone’ or ‘culture’ of trust and confidence. What is ‘adequate’ *is* the expression of this project’s participant’s joint appetite for risk and quality.

SOOP-251. If a project record is not used for a decision then question if it is really required.

Note some records are used day-to-day while some are only required when a problem is discovered and needs diagnosis and some are only use after-the-fact for audit or to learn lessons.

SOOP-252. When the exec’s focus on accountability is for a ‘safe project’ and safety is split from the accountability for return on investment then balance is lost. Simple psychology invariably means the exec’s authority is wielded with a risk averse focus.

One-eye is always then on a future potential need to demonstrate “Not my fault. I did my bit OK”. If the other eye is not on “won the prize” then the exec’s self-preservation-interest over-takes the project and stifles the potential for ROI – Realistically you must keep cost, risk and benefit accountability (and benefits participation via a bonus?) in one head.

With no pull towards benefits there is no balance against the desire to divert resources into protection from everything. Public services, newspapers and Health and Safety ‘culture’ are a demonstration of the vicious circle that results : there never can be enough resources to remove all threats and when threats loom who cares about opportunity!?

SOOP-253. Risks (individually) DO NOT HAVE AN OWNER, they have many owners reporting to the project manager and sponsor, while RISK (singular topic) does have one owner – the sponsor.

SOOP-254. Discussion of change, investment, benefits and A2-Business Cases must include uncertainty and its allocation across agreements via contracts if it is to be manageable.

Contract assigns roles that take specified actions under known and pre-authorised conditions.

SOOP-255. Project reality is an individual future state has multiple consequences and often multiple triggering causes.

In full what we need in the definitions of uncertainty are the observations that:

• Ø many triggers may each cause a new state, some in combination, some in series and some as alternatives,
• Ø the new state has many outcomes
• Ø some, one or none of which are positive and
• Ø concurrently some, one or none of which are negative
• Ø and possibly only in my eyes, perhaps only in your eyes or even in our eyes,
• Ø and every outcome is potentially a new trigger.

Risks exist in cascading networks of cause and effect.

SOOP-256. If you don’t express scales as emotional sentences, then, despite best efforts, it is typically in risk workshops that people will try to answer the, ‘How should we rate this?’ question by calling out ranges on a ten point scale. They will rank things as, “about a 6 or 7” or “that’s at least an 8.” It will take a while for them to ‘calibrate themselves’.

When they have calibrated their ‘feelings’, it will be typical that, ‘less than three’ will be low, ‘less than 7’ medium and ‘above 6’ high with three shades of high!

The shared emotional charge of the session that equated some level of delay to some level of cost impacts, will be lost and reinvented inconsistently in future workshops. Defining the scales is always best.

SOOP-257. Note, that typically, one layer of the organisation develops the risk responses and asks their superior layer to decide the balance of probability, active cost and benefit, reactive costs and benefit and inactive costs and benefits.

When we ‘know how they will choose’ then we have their ‘risk appetite’ defined: I suggest that is essentially never.

Unused tolerance/contingency doesn’t belong to the project manager or the project board – it belongs to the equity holders and must be given back to whoever allocated it or reallocated it via change control.

SOOP-258. It is neither possible nor sensible to declare a limit to concerns that can be raised – It just goes underground and out-of-control.

An appropriate response to ‘over active’ change is to ask the exec and the senior user(s) how much project staff-time they are prepared to divert from ‘progress’ to impact analysis each period.

Then perform an initial ‘cost of analysis’ assessment on each received concern. Give the senior user(s) and exec (or change authority) the responsibility to prioritise between concerns against this budget before impact analysis is authorised. In a scrum project, this is basically the product backlog owner selecting stories for development sprint-kickoff meeting

SOOP-259. The customers view of quality is, “What ever is delivered should do what I want whether that is what I said or not.” Fitness for purpose (FFP) is customer friendly, investment centric, post project oriented and results based, hence PRINCE2®’s strength from being ‘product’ centric.

The customer’s desire is to be excited and delighted by what they receive. Customer satisfaction is rarely created by meeting project constraints of ‘to time and cost and scope’ but is always dented by missing time or cost or quality or scope or any other expectation.

‘Built what was asked for’ discharges the supplier’s obligation under the contract (legal or morale). The supplier’s desire is to be paid and to be gone [or to string the job out as long as there is money available, but that is another topic].

Knowing the contents of standards to the level that the technicians can apply them with full appreciation at the beginning of the consequence on steps at the end is ‘skill’ or dexterity or gracefulness.

The ratio of progress between skilled (unconsciously competent) and unskilled (consciously competent) is in the order of 10:1 or 100:1 (unconsciously incompetent).

To have control thus means we have to plan continually and we have to track actual status continually and we have to make decisions about what to do from ‘here’ onwards.

• The handing down of targets and constraints which must always be accompanied by resources and some degree of authority
• The reporting up of status and contradictory constraints (one source of ‘issues’).0.

SOOP-260. Planning is the process of sharing understanding of a trigger to act or a goal to achieve amongst those who combine the drive resources and skills to make it happen. Planning must be a social activity because projects are people intensive and change based: these two don’t mix well so require special attention to promote the chances of success.

Collaborative endeavours succeed when people are able to communicate disbelief, fears and doubts. Properly handled the debate leads to aspirations, ideas, and contributions then to commitment.

The results of competent planning are first a team, second some options, third a currently selected option-set and most importantly the context by which to make coordinated, situational changes as circumstances demand during project execution.

SOOP-261. Well defined activity scope is a key technique for the project manager for two reasons: 1) its definition builds the team and with a well formed team will build the products, 2) the only bits of a project that can be managed are the people carrying out activities!

SOOP-262. The tool of choice for creating a view of scheduling options is the Activity on the Node or AON network diagram. The technique of choice is a social session using sticky-notes and a wall. It is the people aspect that dictates that a good target size for a WBS / AON network is 35-50 items.

Group dependency planning (first with ‘customers’, second within technical team leads and third within teams) engenders involvement and hence buy-in. The other results of the session are shared appreciation of who depends on who, the options available and currently selected which will facilitate agility during execution when things are not to plan or the plan is not the best current option.

SOOP-264. Estimates are only needed as inputs that inform decision making.

SOOP-265. All estimating decisions are about one of only two needs:

1. rationing limited resources (deciding ‘affordability’)

(What is perceived as unlimited doesn’t enter human perception as needing to be estimated or even perception of being estimable)

1. coordination, integration and interfacing of parallel, separate things/ states/ conditions/ activities.0.

SOOP-266. An estimate is a presentation or package of elements that is used to (re-) generate an assessment of some future quantity or quality. Each estimate contains and combines evolving historical observations and as much relevant data as is currently available.

Estimates are applied where measurement would be used if we had the thing/ state/ condition/ activity to measure and the means to measure it. Where either ‘thing’ or ‘means’ is missing then either estimating or guessing is required.

SOOP-267. The producer’s duty is to be 100% reliable IE accurate and to provide the estimate as quickly and as cheaply as required. The variable is thus degree of precision achievable.

SOOP-268. An estimate is ‘good enough’ when ‘precise enough’ and ‘reliable’

• ‘Precise enough’ means the range between minimum and maximum matches the decision maker’s tolerance of uncertainty.
• Reliable means where the eventual actual value falls between the estimate’s minimum and maximum value or the estimate’s recipient is indifferent to results associated with errors.

Reliability is first accurate but second allows for ‘tolerably inaccurate’ in the eyes of the decision maker.0.

IE ‘Good enough’ = the degree of precision is acceptable and the eventual actual value reveals the estimate to have had a degree of accuracy that does not create an issue.

SOOP-269. An estimate contains {

• Ø The basis of assessment

The basis has to be an analogy, IE comparisons with previous experiences. The basis may be codified into formulae that are driven by parameters.

• Ø One or more scales in ‘trade terms’ – the inputs
• Ø One or more scales in project terms – outputs of effort and or cost and or duration and or scope and or probability and or any other quantity of interest,
• Ø Two or more places on each of the scales with an indication of how confidence varies over the range. How close together the two places are is the measure of the estimate’s degree of precision.

At a minimum an estimate must contain an assessment of the highest and lowest possible scale values and the reasons or circumstances that apply to realise the highest and lowest values.

By preference an estimate contains:

• a statistically significant number of values between highest and lowest
• a transparent audit trail of the causes of variation that support…
• …an expression of variation in confidence across the range.

Normally an estimate has only three values:

• the position on the scale(s) whose individual probability is highest, the ‘most probable’ aka ‘most likely’ aka ‘most frequently occurring’ result,
• the highest possible value with an auditable explanation of the cause of variation between most probable and the largest (but improbable) value.
• the lowest(also improbable) value and the audit trail to explain variation from the most likely.

Three values give a basis to express both our confidence across the range and the reliability of the confidence calculations – as described below.

• Ø Assumptions

Material facts whose contents are currently unknown. Assumptions are owned by everyone who has ever had sight of them. Assumptions are replaced by facts as soon as anyone who has had sight of them is able to bring knowledge to bear.

}

SOOP-270. Different estimating practices have different costs and yield results of varying quality: assessment of all project quantities should start with cheap crude (accurate low precision) estimates. Accurate high precision (expensive) estimating should be reserved for those project quantities where decision makers are willing to pay for them (again it is a sponsor’s choice). EG the factors affecting task durations where uncertainty exceeds float.

It is not until scope, schedule and budget are taking shape that we can judge where increased precision is worth the cost and effort of determination.

It is the project board’s appetite for uncertainty (risk) that dictates the degree of precision required.

SOOP-271. The more that scope links to documented estimating histories from previous similar work the cheaper and more reliable the estimates will be. Good estimating has a return on investment in its own right.

SOOP-272. A cost or duration in isolation of the work’s method statement and worker’s skill level is totally meaningless.

Trouble starts with the mindset that “some number is the estimate”. Resolution includes understanding that “an estimate is a package of assumptions, comparisons, methods and driving values that each time it is examined yields a range of values matched to confidence levels”.

SOOP-273. The Rolling-Wave-planning principle plans at two levels within the project:

For the ‘product oriented, whole of Project Plan’ the constant factor is its scope ‘up to the future-state-business-as-usual’. The variable factor is level of detail.

For the task oriented ‘up to-next-investment-checkpoint’ Stage Plans the guiding and constant principle is “at the level of control needed for day to day control”. The variable is how far into the future our clear vision extends. Higher technical skills, more and cooperative senior management involvement, clarity of end-point all determine how far that is. (The Stage plan may be an aggregate or team plans.)

SOOP-274. Projects succeed when the organisation understands how to plan them. Planning first creates a shared consciousness of the goals and constraints, and second of the options for distilling customer quality expectations to acceptance criteria.

During the Initiation Stage the project board should be constantly involved so that the plans created embody the options. A set of options is selected and the team can swap options during execution as unexpected or expected uncertain events unfold.

The project manager’s job is to advise the project board of options and the exec’s is to advise the portfolio management board of options. They may advise the shareholders.

SOOP-275. Two or perhaps three decisions are needed to move into benefits enabling:

• Ø will the portfolio management board authorise the investment as described by the Investment Management Plan,
• Ø will the exec confirm the contents of the Investment Management Plan gives them confidence that they can deliver the outputs; IE the project board [13.4.2 Authorise the project] and
• Ø will the project manager confirm the A16-Stage Plan gives them confidence that they can deliver the stage’s results: IE the project board [13.4.3 Authorise a Stage or Exception Plan]

SOOP-276. If the approval authorities are minded to continue then when they [13.4.2 Authorise the project] they seal a contract between them-selves and the chain-of-command below them down to the technical delivery staff for delivery of outputs in exchange for provision of resources and meaningful support.

SOOP-277. The project manager is expected to give support or take action on the contents of chats with any stakeholder: the written version of any report should serve as ‘confirmation’ and audit trail not trigger.

The principle of ‘discuss and act, written is for the record’ applies at every level of interface between management levels in any size project. ‘Chats’ are likewise significant with the team manager on behalf of their team members or exec on behalf of the project manager. Timeframes will vary based on topic and where in the project we are: daily may be too frequent once a stage is planned and before it is ready to deliver. At hand-overs daily is often too infrequent.

SOOP-278. Tracking progress is often poorly done; it doesn’t have to be. Reliable tracking starts with good estimates (package not number), uses a number of techniques to ensure reliable assessment of status and depends totally on honesty and transparency in reporting.

Reliable status tracking results when leadership establishes a culture of tracking what has ACTUALLY happened and of diagnosing the reasons for variances.

Any project that shoots the messenger or searches for blame over reason-for-variance guarantees results recorded from then on will match the baseline not the reality. Eventually the build-up of hidden tensions will cause an earthquake.

SOOP-279. Only ever calculate percent-complete from observation of results provably completed versus original allowances.

NEVER accept an assessment of percent complete without an audit trail traceable to the contents of the estimates used to construct the baseline budget and schedule.

SOOP-280. It amazes me how many projects equate budget spent (EG in staff hours and materials consumed) to progress. PROGRESS is NOT linked to hours booked to a cost-code. Timesheets are utterly useless for gauging progress – although they normally translate fairly faithfully into cost incurred.

SOOP-281. Corruption of honest data can happen at any level. Any and all corruption of status data at lower levels destroys the ability of higher levels to manage.

Most corruption of data is incentivised by inappropriate estimating behaviours and conducting blame-storms rather than sessions directed towards Learning-from-Experience.

SOOP-282. The majority of scope creep is caused by a well motivated specialist team. Great teams attempt to do the best job possible. As a result they expand their outputs and thus the amount of work required from all A26-Work Packages after them up-to delivery.

SOOP-283. The time and resources to create scope creep come from inappropriate estimating behaviours

Failure to detect scope-growth as it happens comes from not tracking progress via or back to the estimates.

Failure to detect scope-growth after it has happened is failure of quality review at hand-overs.

SOOP-284. previous step’s outputs who have self-interest that their inputs are of appropriate quality and match the start-point of their estimates.

Teams should be explicitly tasked to compare the A26-Work Package under review’s outputs (which are their inputs) with driving factors in their own estimates. Elimination of extras is pivotal to success. It needs understanding of how to estimate [ See 15.2.3 Estimating page: – 419 – ] combined with the SIPOC (Supplier, Input, Process, Output, Customer) tool plus AON networks [ See 15.2.2.4.4 Critical Path Analysis and Dependency Networks page: – 395 – ] and RACI charts [ See 15.2.2.4.3.4 The RAM or RACI page: – 393 – ]. In combination these facilitate management of creep effectively.

Ensuring correct and adequate content of each CI on the way to the final integrated output is pivotal to successful acceptance of the project’s final results.

SOOP-285. Quality (or Gate) reviews are frequently seen as “have we done everything we said we would?” This is the wrong question.

There are two correct questions for a review 1) “Is it safe to move on?” and 2) “Have we done what we would say today is required?”

SOOP-286. Often if the answer to a Quality Review is 90% “yes” then moving on is justified. It is the answer to the next question that is important: “does the 10% that is missing/ wrong/ extra matter?” Often the answer is “yes but fixing, 9% of each is good enough, a third of the price of 10% and no reason to halt moving on”.

Thus for every review aim for 100% and settle for 90% plus action to resolve the next 9% as soon as is cost-effective. The 9% MUST be in the re-balanced A16-Stage Plan that is followed from today onwards.

Then make appropriate record of the 1% but otherwise forget it. Of course this advise is NOT OK in an operating theatre or if building a nuclear reactor but is probably OK if building a canteen or scripting telephone greetings.

SOOP-287. Progress monitoring should gather details of the steps, effort, resources and materials still needed, and amend any factor or formulae in the estimate in light of ‘what we know and can see today’. Re-estimating will then recalculate the cost and duration remaining.

There will be cases early on in using this approach where despite spending time and effort on a task it is getting bigger as shown by the estimates not smaller. At least you are well informed! – Politics may dictate a non-mathematical basis for reporting.

SOOP-288. Never be so stupid as to say “Don’t bring me problems, bring me solutions”. Paraphrased that adds up to “hide problems until you’ve solved them”! Always a bad idea. The principle should be “NEVER delay raising a concern, I have access to more resources and possibly more experience than you”.

The tone you set in the project should be “As soon as you spot or suspect a trigger for action that is outside your knowledge OR your experience OR authority to deal with, then tell me. If you can suggest a solution too then that is a bonus! If it is within your knowledge AND experience AND authority then get on with it (and feel free to ask if you want a second opinion or a confidence boost)”.

There are a lot of commonly repeated, WRONG, damaging ideas in ‘popular’ project management guidance. Some even sits behind exams so absorption of the errors is mandated but not highlighted – For example that a project has a clear start and end – Maybe sometimes for the supplier but almost never for the investor. Thus PRINCE2 and PMBoK-G exams cause people to be taught mindsets that reality requires you un-learn or never attempt to apply. We DO teach the exam prep but we also call out the errors and we provide LOTS and LOTS of non-exam guidance, its ALL in a single £5/mth bundle >>>See Here<<< and quiet a lot including the full exam prep training is for free!

SOOP-289. Qn: Why do projects habitually run late?

Ans: because we don’t encourage reporting of under-runs or even know how to store up under-runs, while nature stores up the overruns without management action.

SOOP-290. Recording concerns is actually of little value on its own and not the true aim: it is communicating that is of value.

Ensure that all concerns are shared with all stakeholders when the concern is registered. ‘Shared’ must ensure that all stakeholders are actively informed of new and changed concerns. A positive “thanks not relevant to my stakeholding” or “thanks, yes, relevant to our WIIFM” should be demanded.

SOOP-291. ‘Reality’ in planning terms is when the plan’s total set of uncertainties match each other. EG Not sure what you want = not sure when you get it or how much it costs.

SOOP-292. Processes exist in nature. Procedures exist in books. A procedure is te human description of a process. Often procedures contain fashion or preference (and often for no beneficial reason).

SOOP-293. Accountable means sets the direction, provides the resources, delegates responsibility and receives the results whether good or bad. Responsible means combines Will, Skill, Time, Received resources and achieves the target set by the accountable person. Generally speaking the responsible person is guaranteed a reward for applying their will skill time. There risk is zero. The accountable person’s benefit from investment is at risk and so their less certain reward is generally bigger than the responsible person’s assured reward.

SOOP-294. Precision is lack of variation; Accuracy is correlation to the truth. Good estimates are accurate and as precise as needed. Useless estimates are inaccurate. Most people produce inaccurate precises estimates when imprecise and thus accurate would be so much more valuable. It is the recipient of an estimate’s duty to assess if precision is sufficient for the purpose at hand and pay extra if extra precision is warranted.

SOOP-295. Cost is what we put into an endeavour. Benefits are what we get out. Value is when the benefits are larger than the cost. V = B – C All, some or none of the quantities can be money. Every observer assesses the B and the C differently. A factor that is a B in one observer’s eye can be a C for another observer.

SOOP-296.  Always be clear about accountability because when everybody knows anybody can do it then everyone thinks someone will do it and so it will end-up that nothing got done about anything when something could be done by everybody but it has not been assigned to someone explicitly

SOOP-297. PBS and WBS – A rose by any other name…some texts want to call our initial model a WBS or Work Breakdown Structure. A shame. We lose clarity of concept. PBS – Product Breakdown is a clear name for what a WBS is – A noun driven (verb prohibited) decomposition.

Clear concept is, ‘First nouns (DELIVERABLE) then verb-noun or gerund-noun pairs to express product life-cycle stages or transitions’. E.g Man to moon = ‘Rocket’ then ‘Build Rocket’, ‘Launch Rocket’ Second; add verbs to express the noun’s life-cycle’.

NB. Deliverable = any service, product, result desired whether physical or not.

SOOP-298. An ESSENTIAL risk-oriented difference between #Agile and #Predictive (#Waterfall) is, one starts with the output’s definition, the other starts with inputs provided. The ends are the other way around. Dependant cost or dependant benefits.; both are #RiskManagement or #InvestmentManagement approaches to #estimating and allocating.

In a predictive or waterfall project, the dialogue between the investor and developer is as follows [with unspoken thoughts in brackets], “I’ve defined a business case based on project outputs I want you to deliver. [I’ve included stuff I won’t actually need and omitted stuff I will discover a need for later]. I’d like a commitment to cost and timescale now.” The response is then, “[Since I’m commissioned to deliver to an estimate created while I know the least, then its range will have to be wide. Since we agree a figure, not a range, I’ll only quote the top of the range. Also I can’t recognise and remove what you’ve over specified but]. OK I’ll re-quote when you add.”

Both sides know and, may even explore, “So the final date and cost are dependant on many factors but ultimately what is needed to start the return on investment phase may happen before the investor gives up.” – note this biased interpretation is mostly accurate but definitely not complete and mostly reflects situations misapplication to circumstances where clarity of goal and delivery process maturity are low.

In agile approaches, the same dialogue is, “Please spend the allocated resources in priority order across this inaccurate list of solution components.” The reply is, “OK, and since we are both growing our understanding at the start, we’ll refine as we go. Let’s periodically [iteratively] rank and re-rank requirements by Must – Should – Could – Won’t categories, refine our estimates based on recent achievements. and would you like me to deliver what we create as we go [i.e be incremental]?“

Does agile feel more or less ‘risky’? – It certainly has less false illusion of certainty that is unfounded BUT, be aware, development risk has partially been transferred to be benefits risk. Never forget Value = Benefit_Received  – Cost_to_Acquire

SOOP-299. E = MC^2 says matter and energy are interlinked such that the sum of all matter and all energy is constant; likewise with Risk and Reward. High certainty links to low reward while High reward is linked to low certainty. Projects, Contracts, Employment, Life in general, are all Risk Reward mechanisms.

SOOP-300. ONLY EMV is retired if a cause doesn’t happen, and **only when it’s statistically-significant-pool of companion causes are also past**. BUT the entire exposure is covered when any cause occurs (*IF* we got the p% right at the start!).

https://learn.logicalmodel.net/p/risk-masterclass Enrol (Free) and search “retiring”

SOOP-301.

If you’ve heard or repeated, ‘The PM’s role is 90% about communications’, and you believe that means you must constantly communicate with all sort of people, then you didn’t understand what you were told.

The PM’s role in comms is to ensure that all the right people are communicating about the right stuff at the right time – VERY DIFFERENT to being in all the comms! AND MOSTLY, best done by keeping the PM OUT of many comms flows.

After all, if the PM once understood the technology, do they still? If they understand the electrical engineering, do they understand the sociology and marketing or vice-versa? Probably not, nor should they dabble outside of their expertise. Equally, is it the software specialist or the purchasing person’s role to facilitate swift and smooth information exchange? Nope, they have a different day-job.

PMO and Project comms is EASY to get right but only after you understand the Why and How. Sadly, what you need isn’t the content that is most commonly repeated, but it is what is in our comms class. 

Watch out for my project comms short-course later this year.

SOOP-302. Common, but wrong: Dev-Team, “Our solution is slipping, we’ll stick with it and not deliver the business case targets.” Rare and correct, “Our solution is slipping, we need to find a new one that meets business targets.” It’s a mindset thing and it’s a contracts thing.

SOOP-303. Emotion makes the decisions but arithmetic justifies the choices.

SOOP-304. Vision is the expression of BENEFIT.
A Business Case sets out the calculation of VALUE.

Value = (ΣBenefit – ΣCost) in all axis of interest to all stakeholders
Benefit targets match to Value_Drivers, Benefit_Entry_Tests and behaviour enabled Benefit_Tipping_Points
Cost’s description is the discounted cash-flow traced from the development baseline’s resource consumption (Waterfall or Agile)

SOOP-305. PRINCE2’s power is its generalism. A minimal framework of distilled common sense that works everywhere, anywhere for anything that need leadership to make decisions

SOOP-306. If you are in a PMO then embrace PRINCE2; cheapest, quickest way to cover all bases – Stealth mode (w/out the name) to reduce pushback . It’s the Decision Making Architecture that glues projects to technical activity AND governance’s decision making

https://learn.logicalmodel.net/p/p2-2017-f-exam-booking/

SOOP-307. New p3m tools & methods COST extra time & REDUCE (short-term) ability to deliver. Teams may benefit in Sprint/ Release/ Stage/ Phase 2 or 3. Enterprise returns MAYBE in yr 2 or 3

Our £5/mth bundle is full of candidate ideas

SOOP-308. PMO note: best procedures are commonly known folk lore. Restrict doc. to memory needed to transcend generations across tribes (silos)

From our new Retrospectives eLearning – Free to 1st 100 sign-ups. After that £39, (or in £5/mth bundle)

https://learn.logicalmodel.net/p/retros-for-pmos/?product_id=1303581&coupon_code=RETROS

SOOP-309.

x

SOOP-310.