Chapter News

Chapter Communications Blog

How to rescue a troubled project

Author: Carmello Dimotta, PMP

CarmeloDimotta

Tuesday, 21st of March, 2017, 18:30

Location: PwC Zurich, Birchstrasse 160, 8050 Zurich

Interesting topic, that raised my interest already when I came to know about this event. And Marc Lahmann, director of the Transformation Assurance Division, and Manuel Probst, senior project manager at PwC Switzerland, have definitely met my expectations. You find so many whitepapers and articles about problem solving. The PMI also teaches various techniques to analyze and resolve problems. But I was happy to have the opportunity to attend this event and enrich my project management tool set.

That many projects - or even most of them - face a failure during their lifecycle, is well known. Project failure can happen and it does especially nowadays, that the definition of success has changed. The standard project management triangle of scope, time and cost is not enough to define key performance indicators. The so-called "added value" and "stakeholders expectations management" have become even of more importance. The overall project context has become more complex and, with this, also the ways to handle difficult situations.

In the today's environment, the project can be in one of the following stages:
- challenged, normal project management zone. Each project, per definition, can be considered a challenge
- struggling, when the project shows first signals of deviation from baselines
- troubled, it's clear that the project shows signals that something can go wrong
- critical, the project is close to fail
- failure, no options or ways to bring the project back to normal.

The bad news is that projects can quickly go from challenged to troubled. The good news is that troubled projects can be rescued. Key is to have a clear strategy, a structured way to assess the situation and apply the recovery process. A process that, basically, consists of four steps:
1. Direct report of the emergency, answering the what, when, where questions and informing the stakeholders about the issue
2. Anamnese, initial high-level pre-assessment, that helps to bring the project back to trackable
3. Diagnosis, going deeper to the fundamental layer to identify the root cause and plan the recovery
4. Therapy, inform the stakeholders about the recovery and execute it.

After the interactive presentation, at the apero, I could also share my experience with my colleagues and learn from theirs. We were discussing on how to practice the learnings and I had the feeling that we all were looking for ways to develop new issue management techniques. Risk management can be used as mitigation and reduce the likelihood that project issues can arise. However, it's quite normal to face troubled situations in a project and each project manager should have a clear strategy to bring the project back on track. Many thanks to Mr. Lahmann and Mr. Probst for sharing a solid technique to keep available and use when necessary.

Kind regards,
Carmelo Dimotta

Event Report - Managing Stress and Emotions @ Work

Author: David Fowler, PMP

David Fowler

Event Report - Managing Stress and Emotions @ Work: Concrete Tools

Tuesday 4th April

"We are going to explore our minds, let go, be cool !"

Anyone who thought they were going to just sit back and listen to Frédéric Kerautret talking about stress management was in for a surprise: “Everybody stand up for our first exercise”. And there we were, staring into the eyes of our neighbour for an uncomfortably long period of time.

It was an excellent icebreaker and introduction to a highly interactive event. The key message was that we connect with many different groups of people in our daily work. How do we cooperate and behave with these people? In order to understand each other better, we must first work on ourselves.

 Frederic 1

 

Frédéric guided the audience through tools and techniques to manage emotions, increase self-awareness and improve behaviour towards others.  Several  excercises kept the audience fully focused, concluding with a “Lion” and “Tiger” workout to shake off the stress of the day and prepare for the apéro.  

Whilst not all the answers could be provided in a short presentation, there were plenty of topics to whet the appetite and leave the audience eager for more.

 Frederic 2

 

Event Report: Learn from the best – the way to Project Excellence

Author: Carlos Martinez, PMP

Carlos Martinez Arteaga 100x100

On the 1st of December, Mr.Jürgen Ekert presented at the Hotel Victoria (Basel) the event "Learn from the best, the way to Project Excellence."

The room was full for the event, and few of the attendants knew that it was going to be a very interactive presentation.

Initially the attendants were asked to "Break the Ice" by meeting with another and sharing with them an experience they considered as a good achievement. This direct communication aims at bringing people together, to loosen up the atmosphere.

This can also be blended with a session of Lessons Learned fom previous projects, which will help the project with the learnings captured in other projects by different teams.

Continuing, Mr. Ekert explained how generations differ in the learning process, which is important as training has to be adapted to the different processes, and for this, the department he manages, Project Office, has created several training processes.

2

As a recommended practice, trainings should not be series of PowerPoint slides, but rather as interactive as possible, for this flipcharts are ideal, together with forming working groups so that they can apply the training with their day to day. The flipcharts can be prepared upfront with prints that can help the development of the workshops.

When starting the training workshop it is necessary that the goals are laid out, for this all trainess should indicate what do they want to do different? The so called"Future Perfect".

One interesting learning from Mr. Ekert's trainings is that he has realised that in most cases teams actually know how to solve a problem issue, but they still need someone from outside to guide them, someone who is neutral and can challenge the team, someone who knows how and when to ask the right questions and that at the same time facilitates the workshop.People need time for reflection which will even be deeper if different questions are asked. With this the participants find much better Solutions.

When asking questions, the facilitator has to make team face the hot topics, also recall the achievements done by the team.

4

After that the targets for improvement have to be identified, for this the project team vote the points they think would improve most the results.

Now that the team has a clearer understanding on how to achieve the "Future Perfect", it is recommended to re-visit how they foresee this and give a clear definition to what this would look like and the requirements for such. First steps / action items need to be defined.

Finally, the training workshop does not end here, but should be reassesed at some point in the near future, indicating what will be the team's next steps, who will take care of what and when in time will the team reasses how far have they progressed towards the "Future Perfect".

5

To ensure that each team member "takes something home", there are 2 questions that will help them to understand better how they have progressed during the workshop. "What will be different after the workshop?" and "What else?" with this second quesiton, the team is challenged further, helping them to deeper understand their progress and how to achieve it. The second question can be repeated multiple times.

Another question that helps people is "How would they recognize that a problem has been solved?" and "How would a colleague recognize this?"

My personal big thank you to Mr. Jürgen Ekert for sharing his experience both professional and personnal and for organizing it. Looking forward to participating at the next PMI event, I wish all the readers a happy and successful 2017.

Kind regards,

Carlos

 

Event Report - 12th of May - Successful Agile Integration into Existing Methodologies

Author: Arbin Bhaghat

 

Agile implementation was started for small projects. Does it work also for big projects and structured large companies?

If yes, how can we integrate successfully Agile into existing methodologies and processes? Is it worth trying it?

These are the questions that Sascha Wyss, PMP, PMI-ACP, answered at the conference in Basel.

Sascha started with an example, based on his own experience.

A CRM solution implemented for a big concern over multiple countries in Asia. The project was rolled out in Agile and it worked! A tangible proof that Agile can work also in big companies.

Sascha examined then differences with traditional methodology - in particular Waterfall - and Agile, and key topics about implementing Agile successfully, including documentation, regulatory requirements and management approval.

Agile is a group of software development methods based on iterative and incremental development. In a company with traditional development methods,typically these problems occur:

  • Comparison with Existing methods, e.g. Waterfall, with defined milestones and deliverables
  • Depending processes, which stakeholders want to keep as they are
  • Wrong perception, when you think Agile as a method with no control, no budget, no documentation
  • External regulations, e.g. SOX
  • Hesitant management

When implementing Agile here, one has to consider that important milestones are at the starting and closing phases of the project lifecycle and that during these phases deliverables and documentation remain the same, regardless of the methodology.

Agile comes into plan during the Define/Plan phase and Executing. Inputs to the Define/Plan phase is the Requirement Specifications Document which is translated in user stories stored and elaborated in the so called Product Backlog.

How about documentation? Agile is considered often a methodology without enough documentation.

Sascha identified three categories of documents in Agile, when comparing it with Waterfall:

  • Untouched documents, delivered in the initiating and closing phase of the project: Project Charter, Lessons Learned, Closing Documents and so on
  • Open documents, created and delivered during the planning and executing phases. Those documents are taken one-to-one from the Waterfall method and applied to Agile, adapting them accordingly (Release Plan, Test Plan, User Acceptance Testing Plan, Defects Log, etc.)
  • New Documents, Agile typical documents that help the iterative implementation (Product Backlog, Sprint Backlog, Burndown chart)

In most of the cases, there are no documents that you would use in Waterfall and not in Agile. Sometimes Agile amount of documentation exceeds the Waterfall based.

Differences are also in roles: n Agile you might have more roles than in Waterfall. For example in Scrum, an Agile methodology, the Product Owner has the vision of what he or she wants to build and the Scrum Master ensures that the team applies Scrum properly. Where is the figure of the Project Manager? Does the team really need a Project Manager? The answer is yes, especially in big companies. PM's responsibilities would be communication with Senior Management, working with finance and reporting to the PMO, talk to the HR department for resources and so on.

How about regulatory requirements? Can Agile work with those? No doubts for Sascha, who suggested also two approaches. In the Agile's iterative process you can:

  • Perform validation at the end of each release, that means more work but possibility to deliver the product increment at each release
  • Perform a retrospective validation at the end of the development phase, with the big disadvantage that you are not allowed to deliver until the product is completely implemented and validated

Last, but not least, management buy-in is key in the introduction or integration of Agile in big companies. Sascha suggested organized workshops or conferences led by well prepared and experienced mentors. Important is not to use any pilot: they are easy to be failing, and if this happens, Agile is out.

In conclusion, Sascha presented ways how to integrate successfully Agile in traditional methodologies and how to overcome obstacles:

  • Preparation is required
  • Mutual trust and team spirit
  • Collocation, e.g. in Scrum at least the team and the Scrum Master must be located in the same room
  • You need management buy-in.

I am thankful to him for this interesting and valuable conference and to Arcondis for sponsoring the event.