Month: March 2019

Risks? What risks?

Development management professionals looked in wonder at the U.S. Supreme Court case against IFC. In brief, America’s top justices handed down a landmark ruling in favor of a group of Indian villagers looking to sue the International Finance Corp. — the private sector arm of the World Bank — for its support for the coal-fired Tata Mundra Power Plant. The villagers said the project contaminated groundwater, killed marine life, and ejected coal ash into the air. IFC did not contest that the damage occurred, but argued it is immune from liability under U.S. law. Tata Mundra – named “India’s first ultra-mega power project” – gave already in 2015 some indications of headaches to come, if you read The Guardian article at that time. The World Bank projects go through internal assessments of impact and risks. The Guardian’s investigations seem to suggest that the standard assessments of social and environment impacts have been carried out.  Those affected had used the available remedy of applying to the Compliance Ombudsman who also looked into the matter (http://www.cao-ombudsman.org/cases/document-links/documents/IFCresponsetoCAOAudit-CoastalGujaratPowerLimited.pdf). If you are interested, there are further details on the case https://www.devex.com/news/calls-for-stronger-accountability-after-ifc-supreme-court-ruling-94387

This post is not about the legal implications of the ruling on whether it will open or not the floodgates of litigation against International Organisations. Reading the above analysis reminded me of the importance of accountability and the related risk management in project design and implementation.

With due consideration paid to the accountability framework of the organization/client, a project manager works for, the risks assessments are an inherent part of the latter’s job. While project managers are not (always) magicians with abilities to foresee the future, taking time to do a proper risk assessment from smallest internal projects to largest (infrastructure) projects is worth every second of it.

It is not unheard of to tick the boxes and fill in the risk logs (or risk registers) with standard information at the projects design phase. How much time and thought is dedicated to risks assessments and diligently answering to the question “what could go wrong” depends on a number of factors, including the risk threshold of those who design the project and the context of the project. Not taking time to do a proper risks assessment results in project delays or even damages. And no project manager wants to have to recover a troubled project or the client/organization to pay for that.

Risk logs are live documents. They are like growing children: need to constantly keep an eye on them throughout the entire project management lifecycle.

Do:

  • identify risks as early as possible in projects;
  • consult stakeholders on the risk assessment and risk management plan;
  • apply rigor to risks assessments and risk management plans;
  • complement qualitative methodologies with data-driven approaches to risk assessments (see OECD (2019) Analytics for Integrity http://www.oecd.org/gov/ethics/analytics-for-integrity.pdf);
  • avoid ‘blind spots” and biases by means of third party monitoring and evaluation, if/when possible;
  • be mindful of and monitor eventual third party risks, which could impact the project; take legal/administrative steps to reflect them in the agreement with the third party;
  • constantly monitor risks and apply remedies.

There are a variety of project risk management tools available on the internet. I found this risk log of practical use in some projects. Feel free to download it. Template_Risk Management Plan_EN

Job descriptions and roles in projects

“What roles?! There are only three roles in this project: project manager, assistant and financial officer!” This was a response from a participant in a “Giving positive feedback training for managers” at the point we were discussing how to get the best from team members to achieve success. And that answer made me sad.

“She should resign from this position. She is more of the creative type”, I heard one day in respect of a team member of a diplomatic mission.

What the two above have in common? The missed opportunity to look beyond and to put to use the best of everyone for the project.

Job descriptions are necessary. No doubt. They offer clarity and a certain protection to staff. As it was the case of a driver in a project team who was asked by a consultant to deal with his expired driving license. “Sorry, Mark, it is not his job. If you need help, we can talk about it outside working hours and see if I have private connections to guide you through the right procedures”, was my response back then. It protected my colleague and offered clarity on roles in the project.

Back to roles and missed opportunities. People are different and this makes their skills and competencies complementary in a project/team. It is the project manager’s job to ensure this complementarity. To do that, he/she needs to learn what each member of the team is best at, ideally before the start of the project.

There are a variety of ways to do that. I remember a team building retreat we had at the World Bank, when each was asked to describe the skills he/she brings to the team. Through a skillful moderator we realised how many various skills we bring individually to the team and how, as a result, we make the team collectively strong and unique.

The holy trinity of projects

Every project has a

  • Scope,
  • Budget and
  • Timeline.

This is what differentiates them from routine/regular business. Project management literature calls this trinity ‘the triple constraints”.

This trio also serves as a success measure. Truly successful projects deliver what is required, within the budget and on time.

I also believe the Trinity is in good company when Quality and Integrity butt in.

Some trade-offs might be necessary between the scope, budget and time. If the sponsor or client want a closer launch date of the product/service, additional resources and reduced scope might be necessary.

Sometimes, the project manager will have to have the courage to say No to trade offs. Saying No at the right time to anything which risks creating a scope creep is a project’s manager duty. It can be No during the design phase, before the commitment. It can be No during the implementation phase, when the client’s appetite increases. This requires some business acumen.

In the business world, some use the “law of two-thirds” to decide the trade-offs. It offers criteria for decisions about what will define a product or organization (inspired by Tyler Kleeberger, A Technique for Deciding When to Say No, Medium, published on Medium, January 2019). Essentially, you can’t do everything so what should you do?  It will not surprise you that the three criteria are (again):

  • Quality
  • Speed
  • Price

You must consider all three, but you can only choose two. For example, a manufacturer wants to deliver quality and wants to be fast? Then the products are likely going to be more expensive. A business desires to offer its services at low prices, but also wants to maintain quality? Then, it is likely that the speed is going to be reduced. Those who want something that is fast and cheap will have to compromise on quality.

It will be important to keep an eye on the perspective and the short, medium and long-term benefits, along with a good risks management strategy. I would never compromise on integrity though.

It takes humility, strength, and fortitude to acknowledge your project’s, your team’s and your own limits. It also takes visions and leadership to choose and to focus on priorities. It is not unusual for me to ask my colleagues and my client: “So what are the 3 big things this project shall deliver?”.

IMG_1374image credit StamfordGlobal, 2008.

 

 

Re-post: Beyond Best Practices: How to Use Design Thinking in Rule of Law Promotion

This article “Beyond Best Practices: How to Use Design Thinking in Rule of Law Promotion”, by Siddharth Peter de Souza for PeaceLab touches upon the How and Why of the design thinking in rule of law projects (and not only, I would say):

– listen to what users’ say,

– observe what they do and 

– strive to meet their needs.

These ideas are central in both human – centered development management theory and practice.

Link to article: https://peacelab.blog/2019/03/beyond-best-practices-how-to-use-design-thinking

Stakeholders analysis or who else is in the sandbox?

Projects are not stand-alone “enterprises”. They usually need to co-exist and be implanted in already “populated” areas by those who have /can have a stake in a project.

A project’s needs assessment or design phase shall include the stakeholders analysis. I am sometimes asked “Why do a stakeholders analysis?” This analysis enables an up-to-date picture of stakeholders’ roles and interests in the project. These can range from ministries, parliaments, local authorities, institutions and organisations, both public and private, professional and non-professional groups, to people and groups of people.

I sometimes, make an analogy with the sandbox and start my analysis by looking around who else is in the “sandbox” and what they do. Who builds a castle (ambitious ones), who destroys it (opposition), who digs ditches (planners), who is well equipped with buckets and shovels (the doers), who sits on the edges (the expectants) …Sandbox-Pic

In development management projects, I find the following classification of stakeholders useful for the analysis of their impact/potential impact on the project:

  1. Resource Providers: those who provide funds.
  2. Target Group: are directly affected by the project and directly benefiting from the work of the project
  3. Beneficiaries: those who directly/indirectly benefit, in the longer term, from the improved capacity (skills, knowledge, etc.) and quality of services and products of the target groups
  4. Project partners/supporters: provide support for the implementation of the project. Although not in B and C categories above, their co-operation is vital for the successful implementation of the project (e.g. ministries, other governmental agencies, NGOs)
  5. Potentially affected/threatened: are/could be adversely affected by the implementation of the project
  6. Opposers: are/could be opposed to the implementation of the project
  7. Undecided: stakeholders with unclear role.

These categories are not static and stakeholders might switch roles throughout project implementation. It is thus important to regularly monitor their roles and stance.

Feel free to download and use this template PROJECTS STAKEHOLDERS ANALYSIS TEMPLATE_web

 

Thought of the week: context matters

-Thank you and your team for the flexibility.

– Oh, no. We are not flexible. We understand context.

-Thank you even more.

The above was a dialogue I had some time ago. All good project managers know that context is important – he/she will not rely on a “one-size–fits-all” approach.

I am personally allergic to copy-paste, in projects and beyond. It makes me want to cry when I see the name of the country changed through “find and replace” in development project documents.

Do yourself and your client a favour – research the context, do a proper needs assessment and/or diagnosis and bring what’s needed in that context.

origami by Sofia, 2017