Your address will show here +12 34 56 78

What is PMO? 

A Project Management Office, also known as a PMO, has traditionally sat within technology departments. More recently we’ve seen a shift for PMO’s to be an enterprise function, as it’s projects that drive the delivery of business strategy Below is the simple explanation of ” What is PMO? ” the beginners guide.

The main role of a PMO is to provide governance, standards, reporting and process around project delivery. Its function is to maintain and define the standards as well as planning and prioritisation of the project pipeline.  

When a company gets to a level where they run multiple projects, this is where they will get value and traction by implementing a Project Management Office (PMO). A successful PMO consists of a few foundational elements including tools, processes, people, and strategyStandardising processes and improving efficiency will ultimately result in significant cost reductions and improve productivity across an organisation. With an increase in project volume and an increase in more complex projects, a Project Management Office becomes a vital part of any business.  What is PMO continued..


What is PMO and what does it do? 


A PMO is not defined by a tick box list it will vary from company to company but below are some of the possibilities: 


Promote communication in an 
organisation and information flow 

  • Train and coach stakeholders and project leaders 

  • Standardise methods and processes  

  • Plan resources 

  • Create a project portfolio  

  • Prioritise projects 

  • Create strategy 

  • Prepare resources for portfolio board 

  • Maintain Employee data: capacity, project allocation, and skills 

  • Optimize resources and solve conflicts  

  • Monitor projects and project portfolio tracking 

The technology industry is growing and so is Project Management Offices.
Find out what the future trends are of PMO over the next few weeks. See why you should outsource your PMO:

CO:PMO – Outsourced PMO



Wayne Kelly recently attended StarWest in Anaheim, LA – one of the longest running Software Testing and quality assurance conferences.   

First of all what a week I have had at a Software Testing conference in Los Angeles.  It’s been non-stop from 8.00am in the morning till later than 7.00pm some nights due to a full on schedule.  With over 100 opportunities to learn and network Wayne Kelly had exposure to everything from Testing in Dev Ops, Big Data, Analytics and AI/Machine learning for Testing.  I met some amazing people from all sorted of industries: Military (creating drones to shoot down other drones), financial, pet food, sporting ….the list goes on.

What I found particularly interesting:

The main message was all about Agile, shift left there still remained an old team structure with test Managers, Leads etc and still a demand for people at that level, something we seem to be moving away from in New Zealand.
Another interesting observation that I noticed from a show of hands in group question in answer was around automation. There seemed to be an absence of automation and teams still doing projects in a waterfall approach. 
The theme seemed to be companies are saying they are doing Agile but the people still felt very much a waterfall methodology was the order of the day.  Obviously, there were those companies, although the minority from what I observed that we well advanced in Agile, BDD, TDD etc and looking for the next steps.

Main key learnings part 1:

– Automate.  
There were some amazing tool demos.  Vendors have also identified this trend and most of the tools had a non-code ability, a lot more advanced than simple record and playback functions previously seen.
– Upskill. 
Its essential to remain relevant – a message driven home by almost all of the speakers.  But as one speaker pointed out, often it’s about learning to apply your skills in a different way, which required a different way of thinking.  An example being in the way tests are created using BDD.

Main key learnings part 2:

– Less is more.  One of the tutorials I attended was about Heuristic Test Strategy Models.  The speaker, first of all, managed to drive down a 25-page document to 5 pages. As a result of using mind maps to drive coverage and scope.  Another example of doing less with more was a move from detailed test cases to checklists.  Some rather powerful techniques.
– Collaboration.   Furthermore a big theme throughout the conference was collaboration and as a result, this tied in a no blame culture.

Wayne Kelly.


Ed Overy the CIO of KiwiRail talks about the completion of transformation of the ICT function and PMO ( Outsourced PMO ). Going from very traditional model to a partner led model for delivering ICT services to the business. He was given the challenge by the CEO of KiwiRail so approached LPS with a goal of reducing costs.

The two sets of services LPS provided were based around Outsourced PMO (Project Management Office) services:

Project delivery: Project Managers some business analysts and testers looking after the delivery of projects.
PMO: Portfolio of projects delivered rather then just delivery itself.

The benefits of Outsourced PMO that Ed Overy saw as a result of using LPS:

1. Cost was a main benefit delivering projects at a third of the cost as they were in the past.
2. Lift in consistency, quality and capability due to LPS. This can be due to personalities, capabilities and individuals. LPS was able to cope with these and deal with them quickly as you wouldn’t normally be able to do this in house.


Recently we have been working with four of our valued clients focused on re-imagining Testing Services for the New Zealand corporate marketplace. The initial phases of this work concentrated on where each of these clients are on their testing journey. With the relevent gains they are trying to realise and the pains they are trying to avert. 
This week we completed a joint “co-creation” workshop from which we are now developing the next version of our Testing Services Value Proposition. 

Value Proposition

Using Design Thinking principles in conjunction with the Value Proposition Design method we have taken a customer-centric approach to re-designing our testing services. Where you might have thought surely testing can’t be re-imagined, you may be surprised how a joint forum such as this surfaces unseen, and therefore unmet needs, as well as features that don’t hit the mark or features that are not required. 

Client driven services
A further question might be, why would clients give up their time to help us design our services? Also why would they share their needs, pains and gains with other organisations? The answer is simple. If you can design what is offered in the marketplace, you are more likely to find what you are looking for. You also find that you have the time to stop and think about your role, what testing means to your organisation and where it should be heading. Sharing that with others you get immediate takeaways and, an added bonus, establishing deeper connections within NZ Inc.
So, what did we discover? Do customers just want their testing done cheaper? In fact, no, although cost is always a consideration, it is not the focus – value, relationships, trust and quality outcomes rank much higher. As you would expect a testing services offer needs to offer testing services, with quality outcomes, using best practices and the best people. But it was the unseen and unexpected that will make the difference in our new proposition and we’ll reveal that at a later date.
Mark Norwood

On Monday evening, I attended an ITP presentation given by Colin Ellis. The presentation was entitled “The Project Rots from the Head” and provided his perspective on project failures and how to prevent them. 
Colin’s key proposition was that project failure is a direct result of leadership failures. Either by the Project Sponsor, the Project Manager or them collectively. This arises due to them not being effective in their respective roles.
The role of the Project Manager was to:
  • Build the Team; 
  • Build the Plan; and 
  • Deliver the Project 
Colin stressed the importance of doing these items in this order – building the capability, defining the approach and doing the work to realise the outcome.


Personal Reflection on Projects

In reflecting on this proposition and assessing them against the projects I’m currently involved with – both client-facing, internal to LPS and those outside of work. They ring true for us achieving our goals. 
For me these are:
  • LPS – the current client needs – building the capability to deliver; 
  • outside of work – my leadership of a School Board and mentoring a Principal with the SpringBoard Trust; or 
  • personal – getting rid of a few kilos as we head towards Spring/Summer (with the help of the “Biggest Loser” competition at SKYCITY) 
Each of these activities has the need to manage challenges across my work with others, to proactively collaborate and in being true to myself.

LPS Context

It is these softer skills that are a common challenge for us all – in building and contributing to effective team cultures, positively delivering for our client organisations and maintaining a commitment to our values.
As we look at the growth LPS is seeing across our clients and our market, it is important that we continue to focus on the right people doing the right things to get the right results. 
Next week we will celebrate an important milestone in LPS’ history. There are now 200 people in our collective team. I look forward to celebrating this with you and continuing our plan towards our next milestone. In conclusion we will contunue to enable quality project outcomes for our clients.
Kevin Maloney

LPS, Testing, Thought Leadership

TestI’ve been fortunate enough over the past few months to be involved in a number of high-level Test Maturity reviews for several organisations, and found myself asking the question “why do we test?”.

A very simple answer may look like “We test to ensure that the application under test works as expected”. So often we fail to define exactly what “expected” looks like and we don’t come to a common understanding of what we are producing and what we should be testing.

One of the reasons, I have seen many times, is that we don’t come to a common understanding of what is expected because we “don’t have time”. We have all seen what happens next; the project is de-railed by applications that, all too late, don’t meet expectations – which of course were never understood – with deadlines missed, budgets blown, customers disappointed.

If we were to pause for a moment and define these “expected” outcomes, what could the final outcome possibly look like?

  • Shared understanding of expected result

  • Clarity on what is or isn’t a defect

  • Defects and changes caught earlier

  • Re-work reduced and ultimately,

  • Projects delivered on or close to Go Live dates

I’m not suggesting a ‘plan everything upfront before being built’ waterfall approach, but more of a collaborative approach between those members of the team that need to be involved. Something similar to the concept of the 3 Amigo’s; where BA’s, Developers and Testers work together to gain a shared understanding and agree on how they know when something has been done correctly.

I’ve worked on many projects where a solution is developed by a 3rd party. The developer produces code based on their understanding, the code is unit tested by the developer and then tested again by the vendor’s test team. Each pass with flying colours, only to be delivered to the client to fail dismally.

You ask yourself the question “Why?”. You jump to the conclusion that ‘they’ didn’t test it properly. But more often than not, it comes down to a misunderstanding of what was actually required. Taking the time up front to communicate amongst the team, the BAs, Developers, Testers and the Business would have given a much better chance of common understanding leading to a better view of what is to be delivered and when.

The cost associated with these misunderstandings is evident in Boehm’s Law, illustrated below.

There isn’t a “one size fits all” model but perhaps a clearly defined set of principles we adopt may help us along our journey. So, next time you find yourself testing in a world where project members are clearly not communicating to get to a common understanding and where there is not enough time to elaborate the requirements, consider promoting a collaborative requirements gathering, involving all the team and a JBGE (Just Barely Good Enough) approach.

This isn’t an excuse for doing a poor-quality job because quality is in the eye of the beholder: the audience for an artifact determines if it is sufficient, not the creator of it. If your stakeholders require an excellent, detailed artifact then it is JBGE when it reaches that point of being excellent and detailed.

Given the promise of Agile, can we adopt similar agile-like practices into waterfall or hybrid projects, what do you think?

In the meantime, when you are faced with a project that hasn’t got the time (or other excuses) for requirements gathering, ask yourself in the words of Dirty Harry “Do I feel lucky?” (Well do ya….?). Because you’re going to need luck to get this one done on time.

Contributor: Wayne Kelly