Traditional forms of\u202fenterprise project management\u202fare constantly evolving as the field matures and expands. Although these ways of thinking have been successful in the past, changes to the ways we work, lightning-fast globalization, and the increased use of Agile across industries require a new way of working.<\/p>\n
As a result, structuring an Agile\u202fProject Management Office (PMO)\u202fis the next logical step. But what is an Agile PMO?<\/p>\n
Agile\u202fPMO\u202fis a modern take on\u202fProject Management techniques. Its purpose is to adapt quickly to our changing needs and world in ways a regular PMO simply cannot. Although many of the goals are the same, an Agile PMO makes projects more flexible than traditional methods.<\/p>\n
A system of workflow checks and balances that streamlines forward movement<\/p>\n
Comparison between Agile and Traditional PMO:<\/strong><\/p>\n Top of Form Bottom of Form<\/strong><\/p>\n What are the features of an Agile PMO?<\/strong><\/p>\n A great Agile PMO looks a lot like a\u202ftraditional PMO\u202fwith a few key exceptions based on the philosophies of\u202fAgile methodology.<\/p>\n Project\u202franking:<\/strong> Agile PMOs keep a catalog of enterprise projects that are ranked according to the order of importance by predetermined criteria.<\/p>\n Grooming:<\/strong> Backlog grooming\u202fin Agile means project organizing and tracking. Among its many benefits, an Agile PMO makes it easy to keep track of all upcoming and active projects in one place (Book of Work).<\/p>\n Team empowerment:<\/strong> Team empowerment\u202fmeans allowing teams to be self-reliant, make their own informed decisions, and remove otherwise time-consuming approval processes. When each team member has complete visibility into project plans and data, they can all take ownership of the project so that there is no need for reporting to a manager each step along the way.<\/p>\n Project filtering:<\/strong> In a traditional PMO, most projects begin without a clear approvals system beyond a simple sign-off. In an Agile PMO, there is a standard qualification filter that puts every new idea through initiation and an approval stage before it gets added to the backlog.<\/p>\n Team communication:<\/strong> In an Agile PMO, teams aren\u2019t determined by the projects. Instead of ending and starting a new group for every new assignment, cross-departmental teams stick together. This may require some additional support from members from time to time, but it\u2019s ultimately more productive than starting from scratch each round.<\/p>\n Measure team velocity:<\/strong> Regular PMOs count hours, while Agile PMOs measure team capacity and what they can complete in each sprint. Not only is it a better estimation of how long certain tasks will take, but it also promotes a more productive way of doing things.<\/p>\n The Organizational Structure of an Agile PMO<\/strong><\/p>\n Traditional PMOs rely on a top-down approach to their leadership and team organization. The organizational structure of an Agile PMO, on the other hand, is far more circular. At the top of a traditional PMO chain of command are business owners and PMOs. Agile PMOs also place business users at the top, but that\u2019s where the similarities end.<\/p>\n From there, the flow moves to the project team, which includes the\u202fproduct owner,\u202fScrum master, developmental resources,\u202fquality\u202fassurance resources, and miscellaneous resources. The PMO offers project support and guidance to the\u202fScrum\u202fMaster, who provides progress updates to the PMO throughout the project lifecycle. Each resource category is owned and managed by the appropriate manager, i.e., the developmental manager oversees developmental resources and so on.<\/p>\n In the organizational structure of an Agile PMO, the PMO plays the role of a consultant and not a manager. This frees the PMO to focus on making each team as efficient as possible. Instead of keeping tabs on basic project characteristics such as budget and time, they can instead focus on offering their insight into creating better systems while teams self-organize.<\/p>\n Because the Agile PMO is no longer the middleman, it\u2019s more important than ever to hire and train collaborative teams. One may even find that a hybrid approach is best for a particular group as the organization makes the transition.<\/p>\n How to Build an Agile PMO<\/strong><\/p>\n Common Challenges for Agile PMOs<\/strong><\/p>\n Inexperienced teams, micromanagement, and adoption struggles are three of the most common challenges for Agile PMOs. Here\u2019s what they are, how to spot them, and what anyone can do to overcome each one.<\/p>\n Inexperienced teams<\/strong><\/p>\n There are two reasons why that usually happens. First, they could feel that the company culture makes it difficult or even impossible for them to have their voice heard. Second, until a group of people find their rhythm together, it can be a challenge to negotiate the social and professional aspects of the project (both of which are very important in an Agile PMO).<\/p>\n How to overcome it:<\/strong> Set new standards for hiring individuals who are experienced with collaboration. Then, consider the personalities of everyone before grouping them. And finally, work to create a consistently high-quality environment for everyone, especially those who may be part of a marginalized group.<\/p>\n Micromanagement<\/strong><\/p>\n Traditional PMOs often play the role of both manager and administrator as they assist teams. Micromanaging can look like taking over the duties of a team leader. It can also look like failing to delegate questions or tasks to the team members or not having clear-cut boundaries for one\u2019s role. Contrary to popular belief, micromanaging in\u202fproject management\u202fhas less to do with any perceived personality deficiency and more to do with establishing formal lines of leadership and clearly defining project responsibilities from the very beginning.<\/p>\n How to overcome it:<\/strong> An Agile PMO must transition out of the mindset of being a hands-on participant and into being an expert Process Consultant. Teams can and should support in doing so. Make new procedures and chains of command clear at the beginning of every project.<\/p>\n Adoption<\/strong><\/p>\n It\u2019s no secret that\u202fadopting Agile processes\u202fcan be challenging, especially when teams are used to functioning in a certain way over many years. But for an Agile PMO to be effective, everyone must get on the same page sooner rather than later. If they don\u2019t, it could lead to communication breakdowns that keep Agile PMOs from performing their highest ROI duties and delay progress as teams struggle to work autonomously.<\/p>\n How to overcome it:<\/strong> The right project management tool makes it easy to visualize and understand processes, tasks, and approvals, even for teams with zero experience with Agile.<\/p>\n Conclusion:<\/strong><\/p>\n In a nutshell, an Agile Project Management Office is a modern take on project management techniques. Its purpose is to adapt quickly to our changing needs and world in ways a regular PMO simply cannot. Although many of the goals are the same, an Agile PMO makes projects more flexible than traditional methods. With the experience of implementing the same with our clients, we can reap the benefits such as the enablement of real-time visibility across the organization, improved communication and accountability, aligning projects with business objectives, business decision-making, and improved effective resource utilization.<\/p>\n At Cigniti, we have a full-bodied PMO whose focus is on faster project turnaround time. They are observant of the specific needs of customers and manage active projects and products needing immediate attention. Cigniti has a very organized Process Asset Library (PAL) that has robust PMO processes, guidelines, and templates, which are utilized extensively in managing the Agile PMO.<\/p>\n\n\n
\n Parameters\u202f<\/strong><\/td>\n Agile Project Management<\/strong><\/td>\n Traditional Project Management<\/strong><\/td>\n<\/tr>\n \n Flexibility and Adaptability<\/td>\n Emphasizes flexibility and adaptability<\/td>\n Emphasizes planning and predictability<\/td>\n<\/tr>\n \n Project requirements<\/td>\n Prioritizes customer satisfaction and working software<\/td>\n Prioritizes following a strict plan and meeting project requirements<\/td>\n<\/tr>\n \n Communication<\/td>\n Encourages face-to-face communication and collaboration<\/td>\n Rely on written documentation. Formal communication<\/td>\n<\/tr>\n \n Project phases and planning<\/td>\n Uses short sprints for planning and delivery. Allows for changes and adjustments throughout the project<\/td>\n Uses longer project phases for planning and delivery. Has a rigid plan that is difficult to change<\/td>\n<\/tr>\n \n Team Functionality<\/td>\n Cross-functional teams<\/td>\n Functionally divided teams<\/td>\n<\/tr>\n \n Organization<\/td>\n Self-organizing teams<\/td>\n Hierarchically organized teams<\/td>\n<\/tr>\n \n Organizational Structure<\/td>\n Linear<\/td>\n Iterative<\/td>\n<\/tr>\n \n Project Scale<\/td>\n Large-scale<\/td>\n Small and Medium scale<\/td>\n<\/tr>\n \n Development Model<\/td>\n Life cycle model<\/td>\n Evolutionary delivery model<\/td>\n<\/tr>\n \n User Requirement<\/td>\n Clearly defined before coding or implementation<\/td>\n Interactive inputs<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \n