APM BoK 7 consultation: your views shared
The APM Body of Knowledge benefits hugely from the input of the profession and we are pleased that the APM Body of Knowledge consultation process has been conducted professionally and fairly and that we have heard from a wide group of interested parties, not just those who have a passion about a specific aspect of the profession. The diversity of views and input received helps us improve what is produced.
The seventh edition proposes to continue in the spirit of previous editions, collaborating with the project community to create a foundation for the successful delivery of projects, programmes and portfolios. To provide access to everyone and ensure a broad range of views fairly, APM ran an eight-week online consultation, from 26 February to 20 April. Participants were invited to rate the proposed structure, as well as make suggestions on the range of topics covered. Over 400 people took part, sharing more than 1,500 comments and providing numerous supplementary documents.
As we move forward to commence writing, we will look at the detail from all these submissions, and we will also consider the partially completed submissions recognising that they may not fully reflect individuals’ views. Thankfully, none of the findings and suggestions that we have read so far come as a surprise to us. There are a few areas where what is being asked for by you is what we intended and already have in mind. For example, engaging and influencing stakeholders not just analysing them; dealing with the interpersonal skills required by project professionals and an appropriate focus on benefits (identification through to realisation).
By far, the most problematic aspect of APM Body of Knowledge 7th edition will be how we resolve the ‘agile’ matter. We are adamant that any binary ‘waterfall vs agile’ language is counter-productive and we need to find alternative ways talk about agile in project management.
It is good that the inclusion of this language around agile in the proposed structure consultation has brought forward creative ideas from the profession. We have received many balanced views about how to achieve the benefits of an iterative approach where scope and quality is the variable, without denouncing approaches that prioritise trading time and cost to complete scope to the right quality. We already have some ideas how to move forward and we have selected practitioners who use agile approaches in their work to be part of our writing team.
We have selected a writing team that covers the breadth of the profession and whose experience broadens our personal specialisms: namely, my doctoral research and experience in organisational change, risk and decision-making experience, and recent practitioner experience as director, change portfolio for Associated British Ports, and advisor Professor Darren Dalcher’s academic credentials and successful track record in practitioner development. This team, as well as the editorial team, will be announced to you shortly.
In summary, we have good insight from the consultation and nothing we have seen so far gives us major cause for concern, although we will be paying close attention to how we might improve the structure and address any concerns raised during the consultation. We have a writing schedule that provides opportunities for early engagement and feedback and we are confident that if we hold the process and provided that no major issues emerge from the detailed feedback, then we will be able to deliver a high-quality APM Body of Knowledge 7th edition by spring 2019.
4 comments
Log in to post a comment, or create an account if you don't have one already.
Thank you for reporting back on the consultation Ruth. You highlight the difficult issue of integrating "Agile" and so-called "Waterfall" methods. I suggest we move from looking at this as an either/or discussion, to one of both/and. I am aware of several projects that have successfully combined agile with sequential dependency networks ("waterfall" is only really used in one field of PM (IT), and as such I find it unhelpful to add it to the generic BOK without a footnote like this ;-)). I think there is significant scope for fusion where we use dependency networks for high-level project planning, agreeing reliable project-level commitments, and then select from a range of other techniques that help control and accelerate execution at the work package level, or during specific stages. This latter including Agile, but also other visual project methods, Kanban boards, LastPlanner (used in construction) and even a lower-level independent Gantt schedule. The approach has been called two-tier planning. Tier 1 is the project-level plan with say 15-200 logically-linked tasks/work packages. Tier one is used for resource allocation and synchronisation, setting overall targets, and portfolio management, and Tier 2 is the detail within these packages, and which is controlled locally, using a range of methods, and whose detail often emerges as the project develops ("rolling wave"). You can add more levels if needed, but the key difference between current planning levels and this "two-tier" approach is that the lowest-level of detail tasks are NOT logically linked to other project tasks. The dependency network is established at the lowest-level-minus-one, and then the task owner manages the flow within the work package. So for example the T1 plan might have 4 sequential sprints in it, but the detailed work within each sprint (T2) is managed using whatever method is appropriate - and if we are talking an IT software development, this will probably be agile. There are several benefits of this. It will introduce ideas like agile to sectors that have traditionally put far too much detail into logically-linked plans. It also minimises the need to keep updating the project schedule as detail emerges, and in line with actual progress. These in turn help give clearer priority signals to team members about what to work on next. I known many planning tools have already developed this kind of functionality, both traditional critical-path, and critical-chain. And it is consistent with the idea of rolling-wave planning. Some of Agile's higher level approaches, such as progressing the projects in small batches (sprints) are not unique to agile and the BOK should generalise these for all project to use. Others that spring to mind are limiting work-in-progress and minimising inefficient task switching and multi-tasking by team members, the idea of having a prioritised scope buffer including some "nice to haves" (I think agile talks about "MoSCoW"?), cross-functional teams, rapid prototyping, etc. Many of these are known good-practices used on many flow-based processes from projects to manufacturing and distribution. The presentation of a range of Tier 2 methods will also ease updating and discussion of emerging innovations in the BOK, such as moving from the small-batch approach of an agile sprint to continuous flow methods developed for IT projects (the Reliable/Ultimate Scrum method developed Wolfram Mueller), and the variations on the theme - such as scope-boxed sprints rather than time-boxed. Because I feel the ideas of agile/scrum/sprints have potential on other fields outside IT, we should also generalise terms like "story-points", which don't really mean much to someone designing part of a steel structure.
Thank you for your comment, Ian. The writing team take a similar view; presenting ‘agile’ and ‘waterfall’ as a binary choice is misleading. This came out strongly in the comments we received during the consultation, the view that the two are alternatives is not only misleading, but also unhelpful. To reinforce this, it was a similar message that came from APM’s Agile Summit, held last year. We also see that the language we use is very important – practitioners frequently refer to ‘Agile’ as a methodology, which is often confused with a more universal idea of working with agility. A similar argument can be taken with the idea that ‘waterfall’ is singular way of managing projects. In response, we intend to have topics which focus on ‘iterative’, ‘linear’ and ‘hybrid’ lifecycles, as options which will happen very early in the project’s conception. Through this, we hope to illustrate the range of options available to project professionals when delivering their projects.
BoK 7 Have we got the balance right? I have just submitted my detailed comments (writen in haste last night as away for next three weeks!) on the latest stage of the emerging BoK 7. A lot of excellent material; however, my impression, when reviewing the content in the light of the challenge of providing effective P3 understanding and management guidance, is that when compared with BoK 6, there is an increasingly significant imbalance between the HR and Finance Content and giving guidance on understanding, managing and containing the challenges of physical resource management, such as logistics and supply chain management related issues in the P3 environment. It is almost as if there will be no logistic or supply chain related problems because these will be covered by the carefully thought out and drafted contracts. And if there are problems, it is for the suppliers to sort out regardless of how good or bad are our internal P3 physical resource management strategies, plans and processes and the information flows between us and the supply chains! From my several years of experience, the best P3 managers are those who have taken the trouble to include an understanding of the basics of logistics in their toolkit. As I often remind colleagues, brilliant logistics and supply chain management will never guarantee a successful project; however, poor logistics and an absence of robust supply chain management processes will almost certainly result in failure! David Powell Princes Risborough
Stress Testing BoK 7 May I add another comment/suggestion, and I apologise if this has been addressed elsewhere? Has there been any thought given to stess testing the new BoK and its content against real world P3 challenges? What I envisage is taking some P3 failures (and we are spoilt for choice, especially in the mega project/programme arena!) and running these against the BoK. What were identified as the critical areas which P3 management got wrong and at what level (business case, scoping, planning, resourcing, delivering, commisioning etc.) and would following the proposed BoK 7 guidance: a) covered that critical area in a resainable level of detail, and b) if the propsed APM BoK guidance had been adopted/followed then would it have made a difference/turned failure into success? Just an idea, but I thought it was worth sharing. David Powell Princes Risborough