Getting 195 countries to agree on reducing carbon emission when a lot of them are reluctant, this in final round of negotiations of 2 weeks, is an achievements that leading management consultancy would be very proud of to say the least. The agreement has indeed been hailed as the world’s best diplomatic success. How was this achieved?
Quartz reports on the use of a negotiation technique called “Indaba” originating from South Africa which bring people together in face to face discussions with every party stating their red lines and ideas on how to move things forward.
This is however only part of the story. The French leadership, including the President, has been working for many years to prepare this event, they engaged directly with head of States and gave reluctant countries the facilitator’s role on the exact same topic where they were challenged.
The COP21 started with the head of States and not concluding with them? Why? This was a way of telling the negotiators, “You are here to get an agreement in the next 2 weeks”, something the french diplomats will use to remind negotiators their bosses wanted results.
Next key countries were particularly taken care of. For example, South Africa, leading the G77 + China group, was a critical member of this round, and choosing the “Indaba” terminology was a way to recognise the work done by South Africa in the Durban negotiation round.
Then, coalition between countries with conflicting interests but with some common grounds where built, leading to ambitious proposals as the Guardian reports.
Most importantly, the French leadership did listen to every body with respect and created an environment where negotiators could share their issues and concerns openly. Laurent Fabius even stated at the beginning to key negotiators “I will not hide anything to you and I expect the same from you”.
So what can we learn as managers from this? A few things:
- Listen and be open: listening, truly, every parties and allow everybody’s concerns to be expressed freely.
- Care pays: caring and show respect to everyone.
- Engage: don’t leave anyone without a role.
- Organisation pays: plan your negotiation, set objectives and get senior leadership involved.
- Skills pays: bring on people that can drive this process.
Apple streaming music service was announced at WWDC 2015, the service will be available for a paid monthly subscription. Apple also announced that the first three months of the service will be free.
Apple is usually pretty good at understanding its customers – one of their biggest stakeholders – and offering the service for free for 3 months sounds like a good way to get people started and try the service without commitment.
However, there is a group of stakeholders that Apple seems to have ignored on this occasion: the artists whose music will be streamed. Just under a week after the announcement, one of the most iconic member of this stakeholder group, Taylor Swift, wrote an open letter to Apple to complain about those 3 months “free” streaming because this would mean no revenues for artists:
We can speculate about how this all happened. It’s likely that Apple did not involve artists upfront because of the usual secrecy wrapped around any product launch and that artists discovered about the terms and conditions right after the service was announced. Or maybe majors were aware and did not or could not complain, possibly because of Apple’s bargaining power.
Beyond those speculations, Apple has been quick to respond to Taylor Swift open letter, and probably considered she is a good representation of this stakeholder group. Apple quickly changed stance and announced that artists will be paid even during the 3 months free trial. Eddie Cue announced it at the tail end of the week-end:
Please check Ars Technica for the full story.
This is stakeholder management at play. Apple probably tried to push the free trial on their own terms but when they understood that a large group of stakeholders of this new service was going to be very upset with this, and effectively pulling content from the streaming service, they quickly changed the terms so that key stakeholders of the service would have their requirements addressed without affecting the service delivered.
What are the lessons with can take away from this when managing projects and programmes?
- Make sure you identify all stakeholders for your projects and understand what they have to gain (or lose) from the project you are leading;
- Develop a strategy for each of the stakeholders and monitor how the implementation of this strategy is doing;
- Adjust as needed and always keep in mind the benefits you are seeking to get from the project.
Rewind a few years back.
I am preparing for the PMP exam and a significant part of the preparation is to understand in fine details the PMBOK, Project Management Body of Knowledge. This is a process based body of knowledge, containing over 40 processes linked to each others through artefacts and using tools and techniques. Learning processes goals is important, understanding the flow is also key: which processes use or update what artefact, what are the tools used?…at the time I felt that going through the book itself was limiting learning.
I put aside some time to create a tool that I think would have helped me to learn the PMBOK faster by easily navigate through processes, inputs and outputs and tools and techniques, and understand how they relate to each others. The tool is here www.bokmap.com and I hope you will find it useful.
The growth of scaled agile is breaking up the project manager role and the parts are being distributed between other roles, essentially driving out the need for a project manager on most projects.
Have a look at Enterprise SAFE’s glossary, there is no mention of the “Project” word, “Program” is however largely represented. SAFE talks portfolios, programs and teams but not projects.
Why is that?
A project is a temporary endeavour to produce a product or service, in scaled agile (or agile really) there is no such thing, the driving principle is the continuous delivery of value and the responsibility for this is up to agile teams and portfolio management.
The closest role to a project manager role in SAFE is the Release Train Engineer. Even this is more like a programme manager type of role because there is more sense of continuity in a program manager role than in a project manager role.
More of a leader than a manager.
Agile implies self organising team, self-managed at scrum level with the scrum master orchestrating the team. Scaling up and delivery of value often means co-ordinating delivery from several scrums, this is where Release Train Engineers or Agile Program Managers are operating but not in a management role but more in a leadership role because management is done at scrum level.
They are here to coach and help rather than drive the work being performed, they are more focused on the outcomes and on the yearly plan for the program that in individual deliverables.
For project managers of this world this can be very unsettling because they have to learn to outsource direct control on what is being delivered and use more of their soft skills rather than the hard project management skills that they have learned through the years and through traditional project management methodologies or body of knowledges.
Project management body of knowledge describe the project processes that project managers should be using for their work.
Product processes are about how the team goes about creating the project outcome – the craftsmanship of the product or service. In software development – this will include things like how are requirements engineered, how is the design done, the development and testing performed – this is the area of software development methodologies.
There are obviously some overlap and both set of processes show overlaps. The most glaring example is usually around “scope”, in PMBOK version 5, the “Collect Requirements” process outputs the “Requirements documentation”, which is an area where product development methodologies would usually be very prescriptive.
Similarly, the Praxis Framework has a “Define Scope” process that covers requirements but acknowledging that it is vastly influences by the delivery mechanism.
With regards to the delivery work, the creation of the product, neither PMBOK or Praxis are descriptive and that’s a good thing. Praxis identify this “doing work” as the “Development Process” which is piloted by the Delivery Process yet not part of the framework itself.
In practice, what matters is that:
- There are processes in place to develop the scope,
- There are processes in place to develop the product,
- There are overarching processes to define, monitor and control the work being done.
- Roles and responsibilities are defined so that there is no ambiguity about who is running which process.
In medium to large organisations the pipeline for new projects is often wide and business owners battle amongst themselves to grab budget and ensure priority calls go their way. Resources are finite. Budgets are not unlimited and resources cannot always be scaled up to accelerate work products creation (in software development projects at least – so even if a project has its budget secured, the next hurdle is securing resources to deliver the objectives at a suitable time (i.e., very soon).
IT departments often are confronted with many part of the business pushing for their work to be done first. You would think that IT would be courted by business owners for favours but that’s actually often more blame and escalate game.
Part of the problem is expectations management. Projects begin as ideas and they mature the cost to deliver and timescale start to materialise in the owner’s mind and often this is crystallised and assumed as reality. When IT end up being fully engaged and discover more of the requirements then the picture drawn up is often different that the crystallised picture. Disappointment occur.
The other problem is managing resources constraints, even if a project is funded there are other projects running already and the newly approved project might face resources shortfall. Again a source of disappointment.
First build visibility very early of capacity and potential bottleneck. Capacity should never come as a surprise to anybody in the organisation.
Second, manage expectations. Often project spend a lot of time at business case and requirements level, if delays occur there then resources might have gone (taken by another project) and timescale won’t look good by the double effect of late requirements and less resources available. So capacity updates should be regular once the project has started.
This is the usual symptom of a “Push” mode, where projects are pushed towards delivery. The alternative is a “Pull” mode where the delivery teams pull work when they have capacity to deliver. That’s when the business as a whole decides which project comes next for delivery.