According to the CEO Magazine (June 18th, 2015), agile companies’ revenue grow 37% faster than their competitors, generate 30% higher profits and outperform their peers on every efficiency, customer, and employer measure. Multiple new players such as Uber, Airbnb, and Amazon have changed the landscape here in Australia and new companies emerging weekly potentially disrupting the market.
An agile PMO can greatly drive the organisation, guiding and supporting them to achieve their goals faster, more cost effective and of better quality.
So how can a traditional PMO move to an agile PMO?
Change won’t happen overnight. It takes time, money and effort to get there. When moving an organisation to an agile approach, People, Projects and Processes need to be reviewed and transformed. This won’t happen in weeks, rather than months.
Project teams and Management require training, coaching and support. Existing behaviours will be challenged and need to be changed. An agile approach for project delivery needs to be established. New practices will be learned and adapted (Stand Ups, Retrospective, Showcases, Pair Programming, Automated testing, Refactoring…) and metrics will be established and collected. Core teams need to be formed and established and Community of Practises will need to be setup to support teams and groups.
There is also the focus on reducing reporting, meetings, emails, sign-offs and governance in order to speed up the delivery.
Some of the key differentiators between a traditional and an agile PMO are outlined below:
Traditional PMO / Organisation
Agile PMO / Organisation
|Annual funding will be released for project work once a year. These funds needs to be spend by the end of the financial year, otherwise the funds will be ‘lost’. This might drive the wrong behaviour. Funds might be spend on activities, which might not bring the desired return, impacting the organisational goals and targets.||Incremental funding is based on the number of resources. These funds will be released throughout the year per planning cycle (e.g. quarterly). Since teams are stable, hardly any additional project resources are required. Therefore the funding amount will be in most cases consistent.|
|Centralised Annual Planning is performed yearly and only adjusted when major incidence happen.||In an agile organisation the strategy, goals and targets are set. However, the roadmap on how to get there will be adjusted during the year. Planning will be done on a regular basis (e.g. monthly) and the current situation and market will be analysed. Corrective actions will be taken accordingly (rolling wave planning). Decision making is distributed and not centralised anymore, which requires a high level of communication, trust and accountability.|
|Governance is performed through project status reporting (e.g, milestones). Information is aggregated and might be delayed, depending on the reporting cycle (e.g. fortnightly).||Governance performed through daily stand-ups, Scrum of Scrums, ‘Project walls’ and Leadership Boards. Information is available ‘real-time’.|
|Traditional Project Management focuses on artefacts and plans. The Project Manager uses the Work Breakdown Structure as a tool to adhere to it. Change Management is used for corrective actions. Focus is adherence to plan and to produce the desired end-product.||Agile Project Management focuses on collaboration, customer interactions and customer satisfaction. Through agile sprints and planning features will be completed. Focus is value-driven.|
|Examples: PMBOK, Prince2, V-Model, ISO 21500||Examples: Agile Project Management, DSDM, Scrum, Kanban, Lean, SAFe|
|Organisations struggle with having too many projects underway and not having enough resources to do the actual work. An individual resource can be assigned to multiple projects at the same time. This often results in productive loss of individuals, delay of project outcomes and therefore delay in business benefit realisation (http://www.apa.org/research/action/multitask.aspx).||The work is based on the number of resources available not on the number of projects. The emphasis here is that the team is pulling the work and not overloading its team members (Kanban method). There is no individual work assignment. This has the effect that more work will be done as the teams are working more efficient and effective.|
|Measurements are an afterthought. Many organisations are claiming to perform business benefits realisation but when drilling down, hardly any metrics, measurements or baselines are included. Reporting and tracking of outcomes once the project has been deployed is hardly done.||Focus on Measurements and Benefits. Organisations, which follow an agile approach tent to focus on benefits and measurements from the beginning. They typically use a lean or business model canvas, form hypothesis to benefit to results (http://blogs.atlassian.com/2013/10/fight-the-dark-side-of-lean-ux-with-the-experience-canvas/).|
|Detailed Plans / Business Cases: Traditionally, plans will be developed and created in form of documentation as a means of governance and justification e.g. the person who wrote the document thought of all the requirements. Documentation is required as Sponsor and Business Owner will be less engaged in the project - compared with an agile approach (e.g. possibly only at a monthly steering committee meeting).||Lightweight Business Case: The Business Case will be developed with the extended team (including development team and management), therefore only light weight documentation is required. Since the Sponsors and Product Owners belong to the team and meet on a regular basis (in some cases daily), corrective actions can be performed when required (via Executive daily scrums). Documentation is reflected in light weight notations like mock up screens, stories and done criteria’s not necessary a word document.|
|Project Teams exists: Organisations tent to scale their project resources (e.g contractors / partners) based on existing or upcoming project work. Individual resources will be assigned to project work. Time and effort is spent on onboarding new resources. New teams have to go through the team formation process. After the project has been deployed, teams will dissolve and knowledge will be lost.||Stable teams exist: Organisations will use existing resources to form stable teams to undertake the project work. The team will stay together and will pick up the next available work request. The teams forming process will only occur once and knowledge stays within the teams. No individual resource assignment.|
|Single projects are performing their deployments throughout the year. In the classical sense projects are releasing milestones. Coordination’s between project deployments are complex due to the numbers of projects, interdependencies and release windows.||Release Trains performing regular deployments throughout the year. Release trains will deliver features. Any features can be easily and in a timely manner released. This can drastically shorten the time to market.|
Depending on the size of the organisation and the size of the software development teams this transformation might not come cheap.
However, the questions might be better: Can an organisation afford not to change?