No longer should we depend on out of the box Scrum, PRINCE2 or Waterfall Models. We don’t need models. We need flexibility, adaptability and creativity to successfully plan and manage today’s complex projects.
WHAT IS HYBRID PROJECT MANAGEMENT?
Organizations have spent years and lots of money designing project management models. Their inventories will include versions of the Waterfall Model along with one or more versions of Scrum, FDD, DSDM and perhaps other agile models. So, CMMI Maturity Level 2 seems well established but, according to Mulally, is seldom used. Assuming we have competent project managers, it is safe to assume they have found other alternatives than those provided by their organization and defined in the project management body of knowledge. Those alternatives are probably variations of what their organization has provided. These alternatives are not published but travel below the radar but it is safe to assume that these alternatives align with these three factors:
- the behavioral and physical characteristics of the project
- their cultural and organizational environment of projects
- the external supply/demand markets for the deliverables
All three of these are dynamic. They can change at any time and in unexpected ways. When any one of the factors change, the specific project management approach designed by the HPMgr might also need to change. The objective is to maintain the alignment of the project management approach to the project in order to achieve maximum business value and minimization of the risk of project failure. In other words, projects are unique and so should the best fit model for managing them also be unique. After all, project management is nothing more than organized common sense – isn’t it? That is the basic principle underlying a hybrid approach and sets the stage for defining HPMgt.
WHAT IS THE HYBRID PROJECT MANAGEMENT FRAMEWORK TRANSFORMATION?
In order to achieve and maintain that alignment a robust HPMgt Framework must be defined. At the highest level of abstraction, a robust framework will have 3 phases:
- Ideation Phase
- Set-up Phase
- Execution Phase
The dependency relationship among these three phases is shown in Figure 1.
Figure 1. The HPM Framework
In this phase a definition of what the project is all about is developed. It begins with some type of request or mandate from a sponsor. Alternative approaches to the project are suggested and prioritized and a Business Case is developed. A short summary of the project approach is developed (such as a Charter Statement) which is used to gain approval and support for the project.
In this phase a definition of how the project will be done is developed. It may include a specific project management model which may be an off-the-shelf, customized or unique model. In some cases, the vetted portfolio might be used to create the approach. The Set-up Phase will include a high-level plan with a budget, resource requirements and a schedule. That high-level plan might be subject to approval at an executive level.
This phase executes the project management model that was designed for the project. In the most complex cases the learning and discovery that resulted from a previous iteration may require a revision of the Set-up Phase.
The Execution Phase has a feedback loop to the Set-up Phase which is unique among project management methodologies and requires some explanation. During the Client Review Step it may be discovered that changes to the solution require a review of how best to continue the project into the next cycle. That is an activity best done in the Set-up Phase.
SCOPE OF THE HPMgt FRAMEWORK
The above robust definition allows for several solutions. In fact, since a project is unique, the solution (a project management model) will also be unique. To be a useful framework the HPMgt Framework must support any project – from the very small and simple to the very large and most complex. At the highest level the Framework is defined by the Ideation, Set-up and Execution Phases. That defines the “WHAT” that must be done for every project. Within that robust structure we can define the “HOW” to do it. In defining that “HOW” the basic assumption is that the HPMgr is in charge and will define the “HOW” utilizing the vetted portfolio of tools, templates and processes. In using that vetted portfolio, the HPMgr can select and adapt items from the vetted portfolio to create an approach that aligns with the three factors that profile the project.
The Project Support Office (PSO) for the HPMgr will be an adaptation of the typical Project Management Office (PMO). The PMO is usually seen as a standards and compliance organization. That won’t work in a HPMgt environment. The PSO is by definition a support organization. That support includes:
- a vetted portfolio of tools, templates and processes
- consultants to provide support at the request of the HPMgr.
This article has defined the starting point for HPMgt. Stay tuned for other articles to follow that will put some meat on the bones of the “HOW”.
[Mulally, 2017] Mulally, Mark, 2017. All is not the same in the World of Project Management, ProjectManagement.com, 3/27/17
[Robins, 2016] Robins, David, 2016. Introduction to Hybrid project management methodology, (HTTPS://WWW.BINFIRE.COM/AUTHOR/DAVID/)
[Wysocki, 2019] Wysocki, Robert K., 2019. Effective Project Management: Traditional, Agile, Extreme, Hybrid, 8th Edition (John Wiley & Sons Publishers, forthcoming)