A lot of learning in 2 1/2 hours! – a simulation game experience

Published on Wednesday 25 May 2016 by in News with no comments


westergaard

 

 

 

An incredible amount of learning and actionable takeaways in just a few hours’!

As part of their annual conference Westergaard offered a mini game based learning seminar in which delegates could participate in either the Grab@PizzaBusiness & IT-Alignment simulation or the Challenge of EgyptProject management simulation.

This article reveals the results and findings from the Project management simulation.

Simulation Scenario:  We are in ancient Egypt. The Pharaoh (Played by the facilitator) asked the high priest to create a project to build a Pyramid to secure the Pharaoh’s journey to the afterworld. The priest assigns a Project Leader and a project team to execute the project. The team has to identify requirements, and then plan and execute the project. Events and set-backs occur and must be dealt with to keep the project within Scope, Quality, Budget and Time. This requires managing work packages, managing risks, managing tolerances and all those other best practice project management processes and procedures. But be prepared. The Pharaoh comes with other issues and has other ideas which may impact the project.

The simulation game: Project preparation

The team was tasked with managing the requirements and producing a high level plan for the Pharaoh to sign-off on.

What happened? Incomplete requirements, took too long, ineffective use of resources, too much work at certain roles, people were sitting back waiting to be informed, there were many assumptions about who does what and what information will be provided, no engagement with users or sponsor, quality and risk managers were not involved early enough, lack of pro-active ‘ownership’ for role…..as can be seen many of the behaviors we explored in advance were displayed!

WE reflected and then asked the team. If we were to do this again  ‘What would you do differently’? (in fact what will you do differently if this was now a real project start up in YOUR organization)

  • Define, agree and communicate roles and responsibilities (including steering group, sponsor, users. quality and risk management).
  • Requirements management: scoping-in and scoping-out, understand business case, what are the ‘must have’ outcomes vs product delivery.
  • Risk management: delegates risk management to all in project to identify risks and countermeasure proposals.
  • Ensure risks also cover countermeasures relating to processes and procedures (e.g. RFC , procedure for inevitable scope changes).
  • Ensure the requirements are translated into a quality and acceptance plan.
  • Agree communication and reporting responsibilities (e.g. ask ‘what do you need to do your job’)?
  • Review role of ‘suppliers’ in proactive risk management.

The supplier provided cold beers to the Pharaoh hoping to be seen as a value added ‘partner’, as opposed to a ‘supplier’ who declared during preparation ‘not my problem’!

Project start up
Assuming you had now done all those improvements, what would they now include in a Project kick-off (once the plan has been approved and the project is a ‘GO’?

  • Communicate the plan to all stakeholders, including the budget, quality plan, risk plan and countermeasures.
  • Communicate roles and responsibilities within the project.
  • Ensure all know the ‘business case’. Not just the product deliverables but the ‘outcomes’ to be achieved.
  • Ensure all know the procedures for logging issues and escalation to relevant authority for decision making.
  • Ensure RFC procedure known to ALL, including users and sponsor for scope changes.
  • Ensure test, validate and accept responsibilities and schedule known and agreed (including users and business –right person, right skills, right authority)!
  • Ensure appropriate business roles are involved in the kick-off.

Project execution

We then executed the first 3 months of the business simulation. Stones were mined, shipped and constructed. Events occurred, the Pharaoh insisted on reports. The Pyramid was built facing the wrong direction!….we explored success and fail factors in Project execution:

  • Risk management is ongoing and it is everybody’s responsibility for recording issues and looking for risk countermeasures, including supplier! – the need for a ‘risk culture’.
  • PM needs to delegate more to PMO. PMO needs to become the co-pilot for the project manager. PM was operationally engaged in making spreadsheets and reports when PMO already had most of the information or knew where to get it.
  • PMO was delegated the issue log. PMO can become a strategic capability, supporting the project team, the risk manager AND the project manager.
  • Quality management needs to schedule acceptance planning, not just at end of project but at moments when ‘minimum viable product’ has been delivered or core functionality needs acceptance. Entrance to pyramid in wrong place, required a lot of rework.
  • People need to know the tolerances, there are always set-backs in a project.

These were just some of the types of discoveries that can be made using a simulation.

The team also started using visual management tools during project execution. Adding newly identified risks and counter measures to their risk board based on the issue log, and moving some of the risks to High(likelihood of happening) and high (impact on the business case).

 

And finally, a critical aspect for ALL projects should be ‘Project closure’ – capturing lessons learned. We asked delegates ‘What did you learn? What will you take away and do differently or raise as an issue in your own organization’?

  • The need to improve communication between teams (expectations, what you need to do your job, who is responsible for what, what the procedures are, responsibilities for risk, outcomes to be realized).
  • Clarify roles and responsibilities to prevent the PM being bombarded with all operational issues and questions and to clarify decision making, escalation).
  • Clarify expectations with customer, include risks, quality, budget, scope and outcomes, learn to ‘scope-out’ and embed new requirements in RFC – requires rapid insight into plan, cost, risk, quality.
  • Review supplier vs partner and agree appropriate risk/reward mechanisms and align project governance mechanisms
  • Review risk management, capturing issues, capturing at project closure, embedding risk into culture and behavior of all – as it related to ‘business outcomes’.
  • Revisit our kick-off meetings to address items we discovered today
  • Ensure a quality and acceptance plan with users (what, when and WHO)
  • Surprising amount of learning in 2 1/2 hours!! With concrete takeaways not just theory.

 

 

Share this article

Leave a Reply

Your email address will not be published.