Please login or join to subscribe to this thread
David, I think the term "hybrid" and its very nature precludes it from having guidelines. I guess at a high level there could be some guidelines about inter-connectivity that ensures the essence of each framework remains true to it's principles.
The 'hybrid movement' seems to be a result of being more adaptive to the needs of the organization and/or the product. No longer is it driven by fitting the square peg in the round hole. It's gaining a better understanding of the unique needs of the project and applying the framework, practice, and method best suited - whatever that my look like.
Additionally, organizations may not be equipped for a 'transformation' to label themselves one or the other. Or potentially, its a process requiring proven success with varying approaches.
The first thing to understand is: "Something" project management does not exists. You will not find any reference about that inside the PMBOK. What exists is project management performed following a guide (PMBOK for example) into quit different environments where the environment is defined by a life cycle model, a life cycle process based on the model, a method based on the life cycle process and perhaps tools that support the method. For example, in my actual organization, people are assigned as project manager working at the same time with an initiative that is using adaptive/ iterative-incremental/ Scrum and others using predictive/waterfall/SDLC.
I think of hybrid as a mechanic solving a challenging mechanical issue. An expert project manager should be able to reach into their tool box and find a combination of tools to solve the problem and get the car back on the road.
If you are doing the same work to a different product you should have a standard process that is most effective most of the time i.e. Oil Can Henry's.
Project management includes many factors at the core is process driven and leadership driven. A good PM will determine rather the work requires more process or more leadership. A good rule of thumb the more unknowns the more leadership.
to avoid running afoul of posting guidelines, I've dumped the content of an article I wrote mid-last year on this very topic - hope it helps!
A question which I’m frequently asked by learners attending my agile foundations courses is “I’m quite comfortable with what’s required for a waterfall project and what’s required for an agile project, but how do I plan and manage one where some of the scope is going to be delivered in a waterfall manner and some will be delivered using an agile approach?”
I could plead the project management equivalent of the Fifth Amendment by answering “It depends!” which is a perfectly valid response given that the context of such hybrid projects varies widely.
In some projects, there is a very clear delineation between the type of deliverables being produced with each approach and there is limited direct integration between these deliverables. For example, technology deliverables might be completed in an agile manner whereas change management deliverables such as training collateral get produced in a traditional manner. In others, deliverables themselves are produced in a hybrid manner. For example, the web portion of a technology solution might be produced using agile methods, but the back end integration with a legacy system needs to be done in a traditional manner.
Another attribute which influences this is an understanding of who is delivering which work streams. Are they all being produced internally, or is a vendor responsible for either the agile or the traditional deliverables?
We also need to be conscious of the relative effort, complexity or scale of each work stream. A project where 95% of the deliverables are produced in a traditional manner will need to be planned and managed in a different fashion than one where the bulk of the scope will follow an agile delivery approach.
Things to consider when faced with such a hybrid project are:
Orchestrating delivery cadence from each work stream to ensure that consuming work streams are not incurring prolonged delays in receiving components from providing ones. This can be a challenge when an agile work stream has dependencies on a waterfall work stream. On the other hand, if an agile work stream is delivering components to a waterfall one, there is an increased potential of component inventory buildup which is wasteful and could increase the likelihood of rework.
Defining a common set of ground rules is important to avoid creating “us and them” rifts between the work stream teams. For example, if the agile work streams are able to use information radiators or other barely sufficient methods of communicating with stakeholders, figure out how the traditional work stream teams can do the same.
Make the life of your approvers and control partners easier by coming up with a common method of capturing key information which they will need in order to bless your project.
Requirements capture can be challenging in a hybrid situation as agile teams might prefer to use collaborative tooling such as Jira whereas traditional teams might want to use a business requirements document. Managing reviews and signoffs will be difficult, especially when the outcomes of each work stream are tightly integrated, if you don’t settle on a common approach.
Finally, agile mindset and behavior need to prevail across the entire team and not just the agile work streams.
Purists will be shuddering while reading this while pragmatic realists are likely nodding their heads in recognition of how often a hybrid scenario occurs, especially in large organizations where the large variety of contexts eliminates our ability to apply a single methodology to all projects.
When it comes to managing such projects a key lesson (plagiarizing Malcom X) is not to preach integration while practicing segregation!
I agree, we as a community need to recognize the change and should present a good approach to the idea/method of Hybrid. Do we stay true or try to spawn uniqueness? I think that each company, industry, and organization should take the best approach to be successful. It'll be interesting to see how Project Management will change to meet Hybrid needs.
I agree we'll (PM's) need to be able to use many different skills to make the Hybrid method work in our organizations.
Project Management means so many things in today's business environment. As you have pointed out, following a method and putting it into place is not limited to who, rather how, it can be done.
Project Management as a whole does exist as we have a community of professionals that strive to better their skills to increase the profession. Job titles aside, our community of practice is relative, adaptive, and in great demand. The relevance of Project Management is this reason I ask this question and appreciate your response.
In my experience, it seems as though organizations limit the type of tools allowed to be used. The hybrid methodology is a broad term and would suggest an unlimited range of fluidity. I agree that a good PM should be able to lead and use whatever means they see fit to make a project successful, however, there should be some structure on how that works.
Well written, I think that an Agile mindset is what most organizations will move to but haven't fully invested themselves to it yet if ever. This means all of the traditional roles will have to embrace this change and we (PMs) will see many different variations of this.
Flexibility will be the key to success and guidelines that help shape it will unique but will eventually spawn in our community of practice; I imagine a new manifesto.
Please login or join to reply