Recently, in our webinar, “The 7 Deadly Sins of Project Management” we learned from Justin Rowe, Practice Director at our consulting partner, Lewis Fowler. In the presentation, Justin discussed the sins of project management as well as how to recognize and correct them. This resulted in mass attendee participation in questions, many of them very informative and relevant. Here are the answers to the top ones that came in.
- Do you see PPM groups emphasizing the importance of leveraging existing domain patterns and structures for enterprise use and re-use?
[Justin] I believe this is something that should always be encouraged from both a project and portfolio management perspective. Throughout the project lifecycle, a culture of continuous learning and discovery must be emphasized as team members with different amounts of tenure can apply their domain knowledge to projects as they are executed. Applying lessons learned in this situation again is critical to capture changes and fluctuations in the business, especially at the business unit level. As project demands are continuously captured and prioritized, embedding domain knowledge and the structure of what is to be the end product or solution of the project is valuable information that should be included within the project decision making process.
From the perspective of managing the portfolio of projects, this also depends on the direction the portfolio is going with regards to the strategy of the organization and the stakeholders with which the projects are serving. Domain expertise must be gathered, communicated and utilized at the strategic level of the organization, applying a balanced approach of portfolio governance while accelerating the project and portfolio team the ability to perform at a highly effective and efficient manner. As I mentioned during the webinar, allowing the PPM team to embed themselves with their customer base, as well as stakeholder areas can increase domain expertise to ensure they are focused on driving the expected project outcomes while managing all areas of the project (scope, schedule, budget, risk, etc.) This way, the PPM team has additional insight and situational awareness on the status of their project while capturing more data quantitatively within their utilized PPM tool.
- Where does a program management office fall into the hierarchy of portfolio/ project management office? My organization is looking to standardize departmental PMOs, set policies, governance, etc.
From my experience, establishing a Program Management Office will depend on a few circumstances, but will always fall upon the situation(s) itself. First off, the designation to create a formal Program Management Office has to do with multiple, more strategic factors to include size and complexity of projects within the portfolio, the governance structure required to enable it and how it aligns under the organization financially. Increased complexity of the number of projects and how it affects the company’s fiscal planning and execution can be used as input to determining whether a program should be established with a Program Management Office. As projects are being executed, individual budgets within each project is managed where the total dollar amount could be in the hundreds of thousands, for example, as where with a program with multiple projects that a strategically connected and aligned to the development of a larger product, the amount could be in the hundreds of millions. Also, if there is an increased requirement for structure and governance within the project portfolio, this could also be utilized as input into the potential of a Program Management Office. There are many other situational events that would have to take place to determine the true “need vs. want” around a Program Management Office. But here are a few questions to think about…
- Are there multiple projects that are not necessarily similar in scope, but support the development of an overall product or solution?
- Are there multiple projects with budgets that are fiscally connected that lead to the development of the same product or solution?
- Is there a requirement for the management of multiple projects closely tied together with related benefits that align to a strategic level goal and/or objective?
- Is there a requirement for strategic-level governance of multiple projects where resources, dependencies and other project related variables are closely aligned?
Answering some of these questions could provide some initial direction on the potential need to establish programs as well as a Program Management Office. Also, PMI’s Standard For Program Management, Third Edition is a great reference point that can provide some insight to your question as well.
- Do you see PMOs using Kanban scheduling tools for handling development work (iterations and Scrums, for example)?
As development projects are performed, assuming this question is targeted towards software development, the use of Kanban is excellent for visualizing progress as well as seeing where problems could be. Through the continuous agility that is engrained within this methodology, the use of Kanban can also be applied towards PMOs, whether or not they support an IT function or not related to IT at all. The focus here with Kanban is understanding and visualizing workflow, the velocity at which tasks are being performed and the ability to identify problems where solutions are immediately discovered to support continuous learning. In addition, the team can apply Work In Progress limits to which the capacity of tasks someone can perform is capped to ensure the continuous delivery of software is enabled.
With regards to scheduling, applying lessons learned from capacity limitations of previous projects or iterations within the current project will support the ability for the scheduling to remain agile, but not impede with project progress. Applying Scrum methods such as sprints (fixed periods of time, 2 weeks for example) with Kanban can also be utilized to define metrics around performance and velocity, but cycle times within specific tasks that have defined inputs-to-outputs. Flexibility and the utilization of both methods should be defined, dependent on the development environment and the situation that best fits the ability for the development team to effectively perform.
