Happy to see that my white paper PRINCE2 and DevOps, a successful marriage or recipe for divorce? is now live on the AXELOS content hub.
More and more organizations are incorporating DevOps into their working practices to get more done. Many organizations will also use PRINCE2 to deliver projects. But can an organization really use these two approaches together? This paper will show that an organization does not need to pick and choose which approach it will take; PRINCE2 and DevOps can be used together and even share some similarities.
This paper will examine DevOps and the PRINCE2 governance structure separately and will compare a temporary PRINCE delivery team with a permanent DevOps team. I describe how a PRINCE2 project manager can cope with DevOps teams and how DevOps teams can cope with the PRINCE2 governance. The paper will combine both approaches to explore how they can be successfully implemented together.
I hope this white paper will be useful and feel free to give me your comments.
Yesterday, November 18th, there was a 3-hour virtual event to celebrate the launch of the 2020 Scrum Guide with nearly 20,000 registrants. I connected 15 minutes before the start but received a message that the limit of 1000 participants was reached, and I couldn’t participate. Luckily the event was streamed, and you can now watch it on demand (see below). Can you imagine It’s been 25 years since the launch of the first Scrum Guide?
The guide is now crisper, leaner (only 13 pages), more transparent and even less prescriptive. The concept of a separate development team within the team is now eliminated. Just the self-managing Scrum team with three sets of accountabilities (PO, SM, and Developers). Each of the three artifacts now contain ‘commitments’ to them. For the Product Backlog it is the Product Goal, the Sprint Backlog has the Sprint Goal to be defined during the Sprint Planning when discussing the “Why”, and the Increment has the Definition of Done. They exist to bring transparency and focus on the progress of each artifact.
A pity the guide only contains plain text. I think some pictures could add value too. On the other hand, other organizations, e.g., Scaled Agile could take an example to bring back the framework to being a minimally sufficient framework. With every new release of SAFe, the framework is growing without any removements, and as a consequence making it more complicated.
In the book Agile transformation – Structures, processes and mindsets for the digital age, the author Neil Perkin shows how to transform an organization to a new type of business for a new age and to become fit for purpose for both the present and the future.
To create the right agile transformation, you have to make sure you have the right balance between vision and iteration, you remove barriers to organizational change, and you follow a parallel, and not a linear approach. You have to be fluid, not fixed, open, not closed and put experience, over efficiency and use more leadership, and less management.
Above all, modern transformation programs need to be adaptive, responsive and build from continuous learning. You have to think big, start small, and scale fast.
Think big by creating the right vision (inspirational, distinctive, simple, challenging, directional and tangible), to use bold, disruptive thinking and context mapping and use the foundation enablers technology, data, culture and people. Start smallmeans you have to focus, to set the teams up for success and encourage the right mindset. Scale fast by means of using the right scaling agile structures and building momentum for change through strategy and execution, leadership mindset and adaptive strategy.
The book is built around the organizing principle think big, start small, and scale fast.
Conclusion. The book is not always easy to read but definitely a must read when you are at the start of your own transformation and to make sure you think big, start small and scale fast. It contains a lot of theory, insights, practical examples and case studies (Kodak, Fujifilm, DNVBs, music industry, ASOS, Amazon, Haier, Netflix, DBS, Lemonade Insurance, Stripe, Monzo, Vodafone, ING, ANZ) to give you a jump start in when transforming your own organization.
Being a Project Manager – A different Book on Project Management by Hamutal Weisz and Daniel Zitter focuses on the essentials and practice of project management.
I love the process of baking bread as a metaphor for project management and all those related colorful pictures throughout the book.
Project management is the ‘flour’, the base; its function is to create the path to the goal. Project control is the ‘yeast’; its function is to influence all the other ingredients and ensure that the project progresses according to plan as it moves towards its goals. Communication in the project is the ‘water’; its role is to unite the efforts of all those who are working on the project.
The back cover explains that this book is suitable for managing any project of any size, subject and control. And here, I have my doubts. Looking back at the metaphor, I think this only works for more traditional projects or waterfall projects. If I want to use a more agile approach, the metaphor and the book will be of no help. This book is very prescriptive and explains a very bureaucratic way of working.
But after narrowing the scope (only traditional waterfall projects) there is still a lot of value in the book. In line with the metaphor the book is divided into three sections project planning, project control and project communication. Every chapter ends with a conclusion and a summary of corresponding tasks for the project manager. Within every chapter one or more stories to explain the theory.
The first section – Planning the project – focusses on the preliminary planning and the detailed planning. It starts with the need, objectives and the stakeholder identification and involvement. Based on assumptions and constraints the project lifecycle is defined and a work breakdown structure and rough estimates are developed resulting in a preliminary work plan and risk identification (NB only threats no opportunities). Next, the project is broken down into tasks and dependencies between tasks are identified and task constraints are determined. Resources are identified and allocated to tasks. As a final step a risk management plan is developed, and the baseline plan is finalized.
To control the project you need ongoing, periodic and special controls. Ongoing controls are task controls based on the work plan, routine task, resource, deliverables and quality controls and permits, authorization and approval controls. Periodic controls on quality, schedule and critical path, budget, milestone, give & get, tasks, changes and risks. Goal and gate controls, evaluating priorities, issues, estimating project completion and lessons learned are special controls.
The last part – Communication in the project – focuses on formal and informal communication. In total twelve (!) different types of formal meetings are explained. Next the reasons behind and the participants of informal meetings are described as well as the development of informal communication channels and the execution of informal communication itself.
In the appendices a task checklist for the project manager, a glossary and an overview of excluded topics (NB to exclude financial topics, e.g. cashflow, life cycle costs, financial analysis and ROI and say that all financial matters that are essential to the project should be referred to the financial manager, is a little bit too easy. For me a project manager must be able to build and maintain a business case to substantiate continuous business justification).
Throughout the book you find many references to practical tools to be used in your own traditional project. On www.beingaprojectmanager.com (NB the link in the book isn’t working) you can download 23 Word, PowerPoint, Excel and MS-Project templates.
Someone noticed me of Agile 2. If you look at the corresponding website, Agile 2 is positioned as the next iteration of agile. It’s still works in progress of a group of 15 authors. You can find their case for Agile 2. Why they think agile is deeply broken and that they want to fix it. Among other things, in their opinion the Agile Manifesto says little pertaining leadership.
The core of their guidance is about leadership. “Leadership is the most important thing of all in an organization: with good leadership, the initial methodology will not matter in the long run because it will be adjusted as needed; conversely, with bad leadership, the best methodology in the world will fail”.
At this moment the author group already agreed on the values and principles of Agile 2.
The six values are:
Thoughtfulness and prescription
Outcomes and outputs
Individuals and teams
Business understanding and technical understanding
Individual empowerment and good leadership
Adaptability and planning
Besides the values they see 10 principle categories:
Planning, transition, and transformation
Product, portfolio, and stakeholders
Frameworks and methodologies
Technical dimension and technical fluency
Individual versus team
Team versus organization
As stated, these are principle categories. Each category has its own principles. In total there are 43 principles. For me a principle must be universal, self-validating and empowering. 43 principles are far too much. I would suggest focusing on agile leadership and stay away from the rest otherwise I think this scrub will never become a tree in my agile forest.
See their website for more information: agile2.net
In the whitepaper Project Optimism Bias in Capital Investment Decision Making, the author Milvio DiBartolomeo brings us in the world of biases.
The whitepaper is divided into four parts. It starts with a discussion about the need for realistic estimates and assumptions, and clear project plans for mitigating know risks to make the right decisions.
The next part is about project optimism bias and its effect to inaccurately estimate time and cost requirements. The third part put the spotlights on some APMG related guidance like better business cases, managing benefits and the Praxis framework. The last part discusses some techniques to adjust for optimism bias.
The author describes optimism bias as a cognitive bias that causes someone to believe that they themselves are less likely to experience a negative event despite previous experience and lessons captured resulting in overestimate benefits and underestimate total cost of ownership in terms of capital, maintenance, and support.
The following related concepts and biases are explained: planning fallacy, sunk cost fallacy, anchoring, and risk contingency.
To minimize optimism bias prior to full capital investment the following standalone or combined techniques can be used: reference class forecasting, data trust, data range (I assume 3-point estimating?), control points (gate way reviews, project validating reviews, pre-mortem, post-implementation review) and confidence level (cost accuracy: P50 or P80).
Conclusion.The whitepaper definitely helps to get a basic understanding of optimism bias and techniques to minimize it. The P50/P80 was new for me and a little bit difficult to understand. If I read the Defining P50 and P80 manual from the Australian Government Department of finance, it mentions “P80 is a cost that will not be exceeded 80% of the time”. And this is something I can understand but is in my opinion something different than the sentence in the whitepaper “P80 is an indicative total cost of ownership estimate that will not exceed 80% of the timescale for the project which is why having sufficient contingency in place is so important for the sponsoring organization”. But maybe I am wrong, I am not a native English speaker. Next I think in a whitepaper about optimism bias, some words about illusory superiority, the illusion of control and the impact of hindsight bias, self-serving bias and confirmation bias on optimism bias could make sense too.
Just published the New bird’s eye view on the agile forest (PMWJ) and I can already make an adjustment (will it ever stop?).
Designed for all levels of business (enterprise, team of teams and teams), Remote Agility Framework (remote:af) is an evolution to your ways of working to overcome the modern challenge of distributed teams.
Enterprise: Make strategy accessible to enable autonomous decision making with directional alignment.
Team of Teams: Align teams with data for effective planning, governance and delivery.
Teams: Design teams to evolve to fit the nature of the problem that they are solving (mission, product and operating teams).
remote:af is designed to enhance existing frameworks, enabling remote working while providing lightweight guidance for those new to agility.
It’s based on the following principles: enterprise principles (trust in people, strategy evolves, clarity is king, and remote but responsible), team of teams principles (all teams are equals, pass things gently, help each other, and measure what counts) and teams principles (respect circumstance, work smaller, further, but closer, and tool the F up).
In the framework we see enterprise-based events (strategy and scoring), team of teams-based events (all hands planning, review and retrospective) and team events (team planning, review and reflection).
Happy to see my A new bird’s eye view on the agile forest article in the October edition of the Project Management World Journal (PMWJ). It’s less than a year ago when the first edition of this article won an award. At that moment it contained 50 agile ways of working. In this new version I added 30 new ones which brings it to a total of 80 agile ways of working (including links to websites with more detailed information).
Portman, H. (2020). A new bird’s eye view on the agile forest; PM World Journal, Vol. IX, Issue X, October
The following article is a modified version of the published article on PM World Journal:
After nine years there is a new edition of the Managing Successful Programmes (MSP) guide. It’s a best practice so I assume the changes will be incremental and not a revolution.
Good to see that the guide is 80 pages less (now 224 pages) and I really like the four scenario’s which are used to show what specific topics mean for the different scenarios. The four used scenarios are the national rail network programme, the bank compliance and adaptability programme, the charity organizational realignment programme, and the utilities maintenance and improvement programme.
The first thing you see when opening the guide is a summary or quick reference card of MSP. Looks like they embraced my idea to add a quick reference card as I did when writing the official Directing Successful Projects with PRINCE2 guide.
To get a first understanding of the differences, I will look at principles, themes, processes, organization and products. It is just a first impression; I will not go into the details where you will probably find many more differences.
Programmes aligned with MSP are directed by principles which are universal, self-validating and empowering.
MSP 5th edition
MSP 2011 edition
Lead with purpose
Leading change Envisioning and communicating a better future
Collaborate across boundaries
Deal with ambiguity
Align with priorities
Remaining aligned with corporate strategy
Deploy diverse skills
Realize measurable benefits
Designing and delivering a coherent capability Focusing on the benefits and threats to them
Bring pace and value
Adding value (Learning from experience)
Still seven principles but slightly different. Some are more or less combined and two new principles: collaborate across boundaries (to facilitate effective cross-organizational governance where it does not already exist) and deal with ambiguity (to embrace the volatile, uncertain, complex, and ambiguous nature of programmes and focuses attention on the need to make ‘eyes-open’ choices). Learning from experience is now incorporated in the new knowledge theme.
Themes are essential aspects of governance required to ensure that the programme is aligned with the principles. Themes are collectively applied during the processes throughout the programme lifecycle.
MSP 5th edition
MSP 2011 edition
Programme organization Leadership and stakeholder engagement
Vision Benefits management Blueprint design and delivery
The business case
Planning and control Benefits management
Quality and assurance management –
Quality and assurance management
– Risk and issue management
The MSP 5th edition uses 7 themes and the old MSP 2011 edition uses 9 themes. As we can see, several old themes are combined, and some are divided across the new themes. Two themes are more or less new. The purpose of the knowledge theme is to acquire, curate, and use knowledge, to use knowledge and experience to learn lessons, and to build a culture and practice of continual improvement and to manage information to ensure its integrity, controlled access to the right versions, and data privacy (this last part was covered in the information management part of the quality and assurance theme).
The decisions as a separate theme is new. Of course, the old guide spoke about decisions too but now it get much more emphasis. The purpose of this theme is how programmes make decisions at various points across the programme lifecycle, whether those decisions be related to resolving issues, responding to risks, or any other choice requiring a considered and governed approach and it’s the prerequisites for effective decision-making within programmes. The CHAOS Report’ 2018 from the Standish Group sees decision latency as one of the key factors why so many projects fail. In other words, if you want to improve project success, you have to speed up your decision-making. So it makes sense to have a dedicated theme for decision making.
The lifecycle (in the previous edition this was called the transformational flow) of any programme is incremental. Programmes are designed to deliver benefits of value to stakeholders throughout the programme lifecycle. As new information becomes available, adjustments are made. Programme management requires a focus on learning, design, and redesign of the progression towards the desired future state.
MSP 5th edition
MSP 2011 edition
Identify the programme
Identifying a Programme
Design the outcomes
Defining a Programme Managing the Tranche
Plan progressive delivery
Managing the Tranche
Deliver the capabilities
Delivering the capabilities
Embed the outcomes
Realizing the benefits
Evaluate new information
Managing the Tranche
Close the programme
Closing a Programme
MSP 5th edition contains one additional process. The old process Managing the Trance is now divided across the processes design the outcomes, plan progressive delivery and evaluate new information.
No major changes to the structure and roles.
MSP 5th edition
MSP 2011 edition
Senior responsible owner (SRO)
Senior responsible owner (SRO)
Business Change Manager (BCM) (only one in the programme board)
Business Change Manager(s) (BCM’s)
The last part of the comparison are the products. There is no division in boundary, governance or management information baselines.
MSP 5th edition
MSP 2011 edition
Programme definition document
– Delivery plan
Programme plan Projects dossier Resource management plan Information management plan
– Benefits realization plan
Benefits realization plan
– Stakeholder engagement and communications plan
Programme communications plan
– Assurance plan
Quality and assurance plan
– Financial plan
Programme preparation plan
– Governance approach
– Stakeholder engagement and communications approach
Stakeholder engagement strategy
– Design approach
Benefits management strategy
– Funding approach
– Delivery approach
Monitoring and control strategy
– Resourcing approach
Resource management strategy
– Knowledge and learning approach
– Information approach
Information management strategy
– Assurance approach
Quality and assurance strategy
– Decision-making approach
– Issue resolution approach
Issue management strategy
– Risk response approach
Risk management strategy
Target operating model: processes, culture, organization, technology, infrastructure, information and data, knowledge and learning
Blueprint: processes, organization, technology, information and data (POTI)
In the MSP 5th edition we see the following new documents: decision register, decision-making approach, the knowledge and learning approach, financial plan and the funding approach. Some documents are omitted or aren’t formal documents anymore, e.g. programme definition document, programme preparation plan and stakeholder profiles. The old strategy documents are now integrated into the programme strategy document.
A pity the health checks are omitted in this new version.
Conclusion:We can conclude that the MSP 5th edition is not a revolution. The usage of the four scenario’s makes it much simpler to understand the different topics. The quick reference card at the beginning is definitely helpful. Changes in principles, themes and processes are in line with the current way of working and support a more agile mindset.
On the AXELOS website you can find my blog how the Directing Successful Projects with PRINCE2 guide can help you with decision latency.
‘The CHAOS Report’ 2018 from the Standish Group sees decision latency as one of the key factors why so many projects fail. In other words, if you want to improve project success, you have to speed up your decision-making. The Standish Group studied this decision latency for over a decade and stated that a project will create one decision for every $1,000 in project labour cost. If it takes hours to make a decision, you must find ways to reduce this interval by decentralizing the decision making and eliminating steps that take time but have no value, e.g. too many meetings. Simply reducing decision latency can improve your project performance by 25%.