Why should we discuss that?

“Why would we discuss that, it will never happen? I have more important things to do now, that are actually happening…”

This was the phrase I heard in a meeting I created to start the risk management process. We were supporting a growing company to implement their Project Management Framework and PMO.

We have gone through all Project Management Knowledge Areas, and understood which good practices were fit to their size and culture. We knew at that time they were not mature enough in project management at that time to embrace all desired tools and techniques, and their business model also wouldn’t allow them to do so.

One of the biggest challenges we faced was around Risk Management. This is a tricky area, because on one hand it is easy to understand that something will go wrong, no matter how hard you try to avoid it. On the other hand, it is hard to turn that abstract concept into tangible issues and action plans.

We really looked at Risk Management with care. We created templates to help with risk identification, response plans and even contingency plans, and risk management meetings that were supposed to take place weekly, and they did for a while. After some weeks, we realized that these meetings were getting empty because there were no more risks to be identified, they said, and the evolution of those identified earlier was very uncertain.

Even though we were not the project execution team, we attended some of their meetings as support. On doing that we realized something remarkably interesting. They were discussing risks at their weekly status meetings. The real problem here was they were discussing risks, but not treating them as such.

After this finding, we suggested adding risk as a mandatory subject in the agenda of the execution status meetings. This way, risk tools, such as the risk identification sheet, or the risk response forms were brought as an asset to the meetings.

This approach streamlined their process, as there was no longer the need to transfer the notes from the minutes to another document. They were now bringing the appropriate template to help them make the right questions around the issues, or risks, they were foreseeing.

In the end, those intangible ideas were related to what was happening in the project. The perspective change helped them answer that question they asked in the beginning: “Why should we spend time on something that may not even happen?” because now they could correlate that to the real world.

You can hear this post here

Why am I training experts?

On the last few months I have been into a very special challenge. I have been given the task to train experts around their own work.

This is strange, as soon as they are the experts, and even if I know the subject in depth, they know it better, because they are the ones who really perform the work.

Around 5 years ago this company came to us with the task to understand what were the best practices around their global operations, in this case, project management. Their objective was to standardize their processes globally based on them.

They had an enormous quantity of projects being planned and implemented, but each region had a different standard to be followed, and the documents provided, even though fulfilling the requirements to go through their tollgate process, were not standardized. Basically, each project was presented in a different way.

This allowed huge quality variation among the information delivered, therefore, it was getting harder to streamline the decision making around which project of the portfolio was more fit to the company strategy.

At that point, I was invited to support an initiative that would gather all those project documents which were successful, and presented good quality throughout all company’s regions.

With good communication and stakeholder engagement plans, we were able to understand what they had in common, and create a list of what should be the minimal information to be supplied, and how was the better way to present it according to the company’s values, culture and expectations.

After getting this done, we were able to define templates and guidance documents to create a standard to be followed globally.

As it’s been done for more than five years now, even if the main objective remained, the scope of work for each phase of this initiative changed. Here is a summary of what was done so far:

  • Formed a team able to gather the information needed
  • Select best practices and understand what added value or not
  • Create templates based on used and successful documents
  • Validate and deploy template and guidance documents, providing examples
  • Determine and structure a centralized repository of knowledge, methodology, information and documents
  • Engage teams on using the new framework

This incredible transformation process has been implemented using several good practices around business analysis, project management, requirements elicitation, stakeholders engagement, change and knowledge management. There are many other side initiatives and next steps to this new environment that were created.

Now, the challenge is to keep the teams engaged and adherent to the new procedures implemented. Even if they are the experts and they know it better. I am happy to being able to explain the reasons they are using the tools provided, how they would be better used and how they relate to the current company’s policies.

Something new happened! Old news…

I am happy to announce that I have a blog! It is brand new, just three months old!

When I wrote that first paragraph, I saw the word “old” there, and it made me think about the process of starting it an how it is deeply related to transformation.

This blog is not old, nor it is new anymore, as there are some posts before this one.

When new ideas come, we make tryouts, prototypes, we discuss it, create expectations alone or in small groups. That’s what I did here, and all this effort is not seen as change yet, as nothing is different from before.

We understand all of this as “change” after it is announced and involve more people because then it becomes tangible, there is a pressure to have it solved, at this point, it doesn’t matter if the change will take place or not, it has to become the new status quo or to be terminated.

That’s how changes happen, they are never brand new. They are always there, under the surface, growing quietly as whispers. We can sense them, but they are not clear yet.

They need to become a change when they already have momentum, a starting force that provides inertia to be resilient against all the opposing forces that will try to stop them.

In Project Management we use the kick-off meeting, where a lot of effort has taken place and its time to announce to all the team and the stakeholders it is an actual project.

In my case, I am creating a posting routine, maintaining it for some months before announcing it, so here it goes…

I started my brand new, three months old, blog!