Episode 217 – Exploring HYPERID: A New Frontier in Hybrid Project Management

Original Air Date

Run Time

36 Minutes
Home Manage This Podcast Episode 217 – Exploring HYPERID: A New Frontier in Hybrid Project Management

About This Episode

Arash Parsania
Arash Parsania


We love bringing new ideas to our audience because staying informed of innovative approaches empowers project managers to tackle challenges, spark creativity, and stay ahead in a constantly evolving industry. In this episode, we explore the innovative world of HYPERID (Hyper Inter-Methodological Delivery), a flexible hybrid new methodology for project and product management created by Arash Parsania. Arash shares his journey in formalizing HYPERID, the innovative project estimation techniques it incorporates, and what sets it apart from other methodologies.

In agile teams, traditional estimation techniques like coffee cup or T-shirt sizes provide a relative sense of task complexity. In this episode Arash highlights his “person-day” estimation method and the balance between broad knowledge and specialized expertise in agile teams. Join us to hear about the core elements that make HYPERID a versatile tool and the key steps involved in transitioning to this innovative methodology.

Arash brings over 20 years of experience in project management, consulting, and digital business transformation. With expertise spanning industries like software engineering, retail, automotive, and telecommunications, he has advised organizations on process optimization, project portfolio management, and digital transformation. Arash has collaborated with global leaders to enhance project management quality.

Remember Richard Lawrence from episode 183?

InSite by Velociteach now offers his latest online course!
Are you ready to take control of your product backlog and make smarter, higher-impact decisions? Enroll now and start transforming your backlog today!

Preview this online course: 80/20 Product Backlog Refinement

Favorite Quotes from Episode

"…sometime later when I had the feeling that a set of processes, structures, methods, and best practices came together that were harmonized with each other and had been proven in practice and did not have the weaknesses of other methods like waterfall and scrum. This is how HYPERID saw the light of day. But long story short, I just had to get things done."

Arash Parsania

"…a methodology was needed that utilizes the strengths of both approaches, or many approaches like waterfall and scrum, and compensated for their shortcomings with new methods and approaches to better meet the needs of companies in terms of project and product delivery."

Arash Parsania

Staying updated on innovative methodologies empowers project managers to tackle challenges and spark creativity. In this episode, Arash Parsania introduces HYPERID, a flexible hybrid new methodology for project management and product development. Arash shares the innovative project estimation techniques HYPERID incorporates, what sets it apart from other methodologies, and his “person-day” estimation method. Take a look at a different approach to manage your projects.

Chapters

00:00 … Intro
02:37 … The Inspiration for HYPERID
07:14 … HYPERID vs Waterfall or Scrum
09:54 … Delivery Performance
10:37 … A Metaphorical Example
13:48 … Core Elements of HYPERID
21:00 … 80/20 Product Backlog Refinement
22:06 … Project Estimation Technique
25:57 … One Project Manager for One Project
29:13 … Generalized vs Specialized Knowledge
31:11 … The Transition to HYPERID
33:56 … Find out More
35:35 … Closing

Intro

WENDY GROUNDS:  Hello, and welcome to Manage This, the podcast by project managers for project managers.  We’re so glad you’ve joined us today.  I’m Wendy Grounds, and in the studio with me is Bill Yates.

If you’re enjoying the show, we’d love to hear from you.  If it’s on our website Velociteach.com, social media, or your favorite podcast app, your feedback helps us keep inspiring and supporting project managers just like you. 

We also want to mention that we are recording out of Summer Street Productions in Kennesaw, Georgia.  We’ve been recording here for a while, and we’re really happy.

BILL YATES:  It’s fantastic.

WENDY GROUNDS:  Yeah.

BILL YATES:  Great service.  High quality, and great people to work with.

WENDY GROUNDS:  Yes, we’re very happy with the studio.  They do podcasts, audio/video recording, all sorts of things.  Thanks to Tim and the team.  If you would like to find out more, just send me an email, or reach out to Summer Street Productions.

Our guest today is Arash Parsania.  He’s not just any project management expert.  He’s the mind behind HYPERID.  It’s a cutting-edge hybrid methodology for project management and product development.  Arash has over two decades of experience.  He’s been a driving force in digital business transformation, process definition, and optimization for project and product development, as well as project portfolio management.  And we’re excited to talk to him about HYPERID and finding out a little bit more about that.

BILL YATES:  Yeah, Wendy.  When we connected with Arash, the idea of looking at a unique methodology for, you know, here’s a different approach to manage projects, that idea just jumped out to me.  I was keenly interested in having a conversation with him.  We’re always looking for new tools, new approaches, ideas to share with our listeners.  And this is something that can apply to all types of project management environments that you’re in.  We’ll get to hear from Arash as to why he evolved this and some of the pain points that led him to develop this methodology.  So, here’s our chance to share another approach with you.

WENDY GROUNDS:  Yes, I think you hit the nail on the head.  We do want to share new things with our audience.  I think we’re always thinking what would they want to hear about, what’s something new.  Either it’s a book we’ve read or a methodology just like this.  So, we hope everybody enjoys the show today.

Hi, Arash.  Welcome to Manage This.  Thank you so much for joining us today.

ARASH PARSANIA:  Very happy to be here.  And thank you, Wendy and Bill, for having me, and a big hello to all listeners of this great podcast.

WENDY GROUNDS:  Yeah, thank you.  We are very appreciative of our listeners.

The Inspiration for HYPERID

So, you have been teaching us a little bit about HYPERID, which is what we want to talk about today.  What was your experience in both IT projects and traditional project management models like waterfall and scrum, how did this all lead to the development of this methodology?

ARASH PARSANIA:  Interestingly, I’m often asked about this, and the answer is perhaps somewhat surprising.  There was never any intention of developing a new methodology, nor was it that I was so bored that I stayed up all night, as we say in Persian, chewing bones and inhaling the smoke of the oil lamp in order to put an inspiration on paper.  HYPERID was simply born out of practice.  I was like most other project managers, also one of those who was suddenly handed the project management role just because I happened to have done a decent job before without having any idea about project management. 

And unfortunately, we see this far too often in companies these days, too.  And in a situation like that, you don’t have the time or the nerve to say, wait for a while, I’ll do some project management training first.

BILL YATES:  Yeah.

ARASH PARSANIA:  Then I’ll deliver the project for you.  So that doesn’t work.  Unfortunately, when you get an assignment like that, you often have to start immediately because everyone is suddenly in a hurry.  So, I had no choice but to simply do what seems logical and right to me.  I simply had a job to do.  And of course, I also made mistakes; and I did good things in these projects, too.  And where I made mistakes, I tried to do things differently the next time in order to achieve better results.  This pattern was repeated several times until I was curious enough and able to take the time to engage with the theory and the teaching of project management.

And in terms of time, we are now around the early 2000s.  Back then, waterfall was a prominent process model.  And I found that many things in it were not suitable for the IT projects, especially when it came to things related to product development.  At some point I came across the agile models, which were still very unknown at that time.  And I found that my way of implementing projects was much more suited to the agile approach than the waterfall approach. 

And during my research in I think it was 2005, I came across a company that was one of a few that implemented its projects in an agile way, even fixed-time, fixed-price projects, and with a very high success rate.  It was therefore a logical decision for me to join this company and learn a lot, which I did.

But things were similar there, too.  So as soon as I started learning the theory, I was already expected to roll up my sleeves and implement projects in a hurry.  And I was delivering these projects one after the other, improving my approach over time, and always under the assumption that I was doing things exactly as this company intended.  Until the moment of the awakening, my awakening, and probably the awakening of all of us.

So, during an internal audit of a large program that I was in charge of, the auditor noticed that I was doing things somewhat differently than the company intended, which didn’t make him very happy.  And we discussed, and we got into an argument, and the program was taken away from me and handed over to another project manager.  But it was only two weeks until they all came back to me and asked me to reintroduce the methods and tools because they had realized that there was no other way to plan and implement such a large program like that.

And at that moment I realized that this topic around how to plan and implement a project had developed a momentum of its own on my end, which was not necessarily 100% wrong.  And for many years after that, as an auditor and coach myself, I realized that challenges in projects are often the same, and so are the solutions to them.  This way, HYPERID has always evolved without it existing as a standalone methodology under the name HYPERID, or me thinking about creating a central methodology out of these approaches, until I was repeatedly asked whether I would like to put things on paper so that the wider range of people can benefit from them.

And that’s what I actually did sometime later when I had the feeling that a set of processes, structures, methods, and best practices came together that were harmonized with each other and had been proven in practice and did not have the weaknesses of other methods like waterfall and scrum.  This is how HYPERID saw the light of day.  But long story short, I just had to get things done.

HYPERID vs Waterfall or Scrum

BILL YATES:  Yeah, I love that practical approach.  And it speaks volumes that, okay, this worked for you, and then people saw it, and they wanted to be able to follow it, too.  So, then you had to write it down.  You had to figure out, how do I share this and make a cohesive model?

One thing I want to point out, just so our listeners know, we’re saying “HYPERID” with a P, like P as in piano, and not “hybrid” with a B, like Bill.  So, this is different.  This is HYPERID.  This is the approach that you’ve created.  Now, help us understand, differentiate for us, scrum and waterfall.  What are the differences in HYPERID, your methodology, as compared to waterfall or as compared to scrum?

ARASH PARSANIA:  To answer the question regarding these differences, I need to briefly explain why scrum and waterfall don’t work these days, in my opinion.  In the end, HYPERID was developed in such a way that I always had to find solutions for difficult situations, as I just explained.  And I have two explanations for each, one factual answer for project managers, and one metaphorical answer for project managers and non-project managers.

First, the factual one.  We see that the success rate of projects has been declining since around 2015.  And there are very good reasons for it.  Agile methods, and in particular scrum, improved project delivery significantly, especially in the 2000s, since they made the complex scope change management processes of waterfall models much easier and placed appreciation of changes at the core of the methodology.  So, this way they increased the focus on value creation.  And that’s why scrum worked well in projects for some years, until their shortcomings become obvious, which in my opinion is the reason for the decline of the project success rates. 

In short, both linear approaches, known as waterfall and agile methods, don’t fully meet the needs of today’s companies when it comes to tech projects or IT projects, each in their own way.  And I explain now what I mean with that.

Scrum, for example, struggles with planning and providing reliable information on when something will be delivered, what it will cost, and what resources will be required.  This is core information that companies need these days and can’t live without.  As a result, scrum can’t deliver on time and on budget because it doesn’t address these questions upfront. 

Waterfall, on the other hand, struggles with quickly finishing specifications and planning or responding to changes during the implementation in a simple and straightforward way.  Both approaches currently show mediocre delivery performance values.  And delivery performance directly impacts project success, which is actually why I introduced this KPI with HYPERID.

Delivery Performance

To explain it for your listeners, delivery performance, very simply put, is the mathematical product of effectiveness and efficiency.  And waterfall struggles with effectiveness because they don’t have this outcome orientation, while scrum struggles with efficiency, leading to mediocre delivery performance values for both.

Long story short, a methodology was needed that utilizes the strengths of both approaches, or many approaches like waterfall and scrum, and compensated for their shortcomings with new methods and approaches to better meet the needs of companies in terms of project and product delivery.  So, this is why hybrid methods have been sought after for some time.  And this is the gap that HYPERID with a P is filling.

A Metaphorical Example

So, the metaphorical answer to this question how HYPERID is different is, let’s imagine I have to get from Munich to Berlin in five hours to fly on from there.  And then if you consider this as a simple project or as the simplest project, the analogy to the waterfall approach would be that I have to use an old paper map. 

First, I would have to see where to go, and I would probably draw the route on the map, which would be similar to planning a project in the waterfall approach.  On the way I would face traffic jams, accidents, roadblocks, and so on.  And I would have to plan the road manually every time, and I would always face new surprises.  So, I lose a lot of time due to time-consuming planning and due to the fact that it’s difficult to deal with changes on the way.  It’s this way in the waterfall projects, too.  So, you have to deal with a long planning and difficult handling of change requirements.

The analogy to scrum is that I don’t use a paper map.  I just use a compass.  And by the way, as you know, the compass is even used in the agile terminology.  I start immediately because I don’t plan the route, but I only have direction information from the compass.  And I am not traveling on water or in the space, so there is no straight track.  I have to drive along roads and streets.  And from crossroad to crossroads or district to district, which can be an analogy to sprints, I have to get the compass out repeatedly and correct my direction.  And if there are any problems on the way, like accidents or traffic jams, I have to use the compass and find my new way again.

So, if you drive like that, you may arrive, but you don’t know when you will arrive.  And it’s very likely that you will arrive too late because, even though you knew the direction all the time, you probably didn’t take the optimal route because you didn’t know about the roadblocks, one-way streets, et cetera.

And that’s how it is in scrum.  So, you start immediately with the compass.  You don’t know which is the best way and often arrive too late and then at higher cost.  So, what we actually need is the well-known navigation system.  Sounds easy, but probably it’s not that easy in project management.  In other words, we need a fast calculation of the route, which would be the planning part, the most accurate prediction of when we will arrive, and in the event of challenges in between like traffic jams, roadblocks, accidents, et cetera, a quick recalculation of the route with a new forecast on the arrival time.

And HYPERID has been developed in such a way that it has the character of a navigation system.  So, it’s able to quickly provide information on delivery times and costs.  At the same time, it ensures a high degree of agility and allows you to make changes at any time when you’re already on the road, so to say.  And you can adapt the route to reach your destination in the best possible way. 

And this is the reason why a new methodology is needed, in my view, because neither a paper map nor a compass are sufficient these days to complete journeys that may involve certain costs, have a long duration, and companies can be successful today only on the basis of reliable project delivery because this way and only this way they can reliably put their objectives and their strategy into practice.

Core Elements of HYPERID

WENDY GROUNDS:  Why don’t you describe to us some of the core elements, the core design that makes up HYPERID?

ARASH PARSANIA:  In HYPERID, there are three main phases at the top level.  First one is Define Scope.  Second phase is ADP, that stands for Analyze Design Plan.  And the third is Deliver Value.  The first phase, Design Scope, is largely similar to other approaches, maybe a bit more structured and adapted to the following phase in HYPERID, the ADP phase.  But the second phase, the ADP, again, it stands for Analyze Design Plan, is a special one.  It ensures that binding statements on the delivery date, resource requirements, and costs can be made in a very short time.  And this ADP phase is also where most of the measures are taken to ensure that HYPERID is suitable for every type of project, from the construction of skyscrapers to the development of AI-powered software.

One of the first activities in the ADP phase is about the creation of a so-called “core design.”  And by core design, maybe I need to explain this topic.  So, in waterfall, a full design is normally created, a complete specification.  The disadvantage for tech projects is that the full design takes a very long time.  Sometimes the time required is so long that the project is even canceled, or large part of the specification becomes obsolete after some time because a lot has changed until then.  And this produces a lot of waste. 

With scrum, we see the exact opposite, a no-design approach.  Teams just start developing something. The downside is the following. They may have initial success with the POC or with an MVP.  But as soon as they try to make the next step and bring the solution to the whole organization, they find out that they haven’t considered necessary things like modularity, performance, multi-tenancy, multi-language capabilities, scalability, et cetera.  And this often leads to huge project delays, project restarts, and even project cancellations.

So HYPERID takes the middle path here and creates a core design that meets certain criteria.  One is it has to ensure that end-to-end consideration of the solution implementation is given.  It needs to include as few details as possible and as many as necessary.  And it has to be described so clearly that details of the work can be unambiguously derived from it.  And the recommendation is to define about 20% of the full design and define the remaining 80% as work packages that will be specified later during the implementation as needed.  This compensates for the drawbacks of both waterfall and scrum.

By developing 20% of the full design, the design is completed quickly; and since the rest is specified later, it’s not a big deal if things become obsolete and change because no effort was spent.  So, in this case, one design work package is simply replaced by another.  And by considering the solution end-to-end, you avoid the scrum trap of realizing too late that the architecture is wrong because things like modularity, multi-language support, et cetera were forgotten.  So, you consider them in your core design.

And this 20% rule that I mentioned is not rigid.  So, if only a few changes are expected in a project, it can be increased to 70%, 80%, or even 100%.  Maybe in the case of a skyscraper, if too many changes are expected, you can reduce the core design to 10%.   So, this core design is a key contribution to addressing all project types. 

The second key contribution is also in this ADP phase, specifically in its P that stands for Planning.  Planning is done in HYPERID in three approximations.  The first ADP approximation is called High-Level Approximation.  And the outcome of this approximation is the so-called High-Level Scope Delivery Plan.  This is primarily for high-level phase and milestone planning, as well as scope adjustments and fine-tunings.

The second ADP approximation is called Mid-Level Approximation, with the outcome that is called a High-Level Delivery Plan.  This plan allocates work packages to iterations.  So, the planning granularity is on an iteration level. 

And the third ADP approximation is the so-called Final Approximation.  The outcome of this approximation is the so-called Delivery Plan.  And this is the ultimate plan, allocates work packages on a weekly basis considering their dependencies.  So, this plan is suitable for every type of project or product.

So, the general recommendation is to fully complete all three approximations during the ADP phase.  Under certain circumstances, for example, in highly evolutionary or outcome-based initiatives, the ADP phase can be left earlier.  Also, there are sometimes time constraints.  So, like when you’re participating in a tender and then don’t have time to complete all three approximations, an early exit is possible and allowed.  HYPERID provides multiple mechanisms, including a highly structured risk management to compensate for inaccuracies and ultimately to create a reliable plan.

And the third phase from these three main phases, the Deliver Value phase, is actually very similar to the scrum approach. However, there are a few differences here that are essential because this is the only way to ensure truly reliable delivery and reliability towards stakeholders of your project or product development.  A key feature here is the so-called SGRP, Scope Grooming and Rapid Planning, which recreates the plan forward after each iteration, like the mentioned example with the route recalculation of the navigation system.

And another key feature is the daily management of progress.  In my opinion, the kanban and scrum boards that are used today make a huge contribution to projects not being delivered properly and are a crime against the humanity of the projects.  So therefore, there is also a major difference between HYPERID and the way projects are implemented today with kanban and others when it comes to progress management.

BILL YATES:  When you describe the core design phase, I appreciate the balance that you’re looking for between waterfall, which is too heavy, takes too long, and scrum or agile, which sometimes doesn’t take that end-to-end perspective.  I really like your point.  I picked up on that, too, made a note of it.  The end-to-end consideration of the solution implementation is important.  I like also, though, to counter that, I like the agile perspective of, hey, as few details as possible, as much as necessary, so we don’t get bogged down in trying to document too much.  That’s definitely an agile tenet.

And your recommendation for, okay, look, in this core design phase, roughly 20%.  That’s helpful for practitioners to know, okay, how much time should I be spending in this phase of my project?  This core design phase should take, you know, again, give or take 20%.  That’s super helpful.

80/20 Product Backlog Refinement

WENDY GROUNDS: Here’s a quick message for project managers! Velociteach has fantastic learning opportunities, and InSite—our award-winning platform—offers over 70 online, self-paced courses aligned with the PMI Talent Triangle. It’s a great way to earn PDUs and maintain your certifications. We’re also excited to announce our newest course, “80/20 Product Backlog Refinement.”

Some of you might remember our guests from episode 183: Richard Lawrence and Peter Green, co-founders of the Humanizing Work Company. We discussed the role of project managers in agile, self-organizing teams where decision-making is empowered at the team level. Their insights were so engaging that we’ve teamed up with Richard to bring this course to InSite. 80/20 Product Backlog Refinement is designed for Product Owners, Managers, and anyone steering the direction of a product.

This on-demand course is your key to mastering essential skills that will maximize impact, minimize risk, and propel your product and team to new heights.

Project Estimation Technique

One other really helpful thing that I wanted to talk to you about and have you share with the listeners is this idea that you share regarding project estimation.  I thought it was super helpful.  I mean, you know, especially for agile teams that we talk about using coffee cup sizes or T-shirt sizes to make estimations. 

And again, that sounds good until you start actually doing that.  Okay, now I have a sense of how these tasks or these features, how they kind of stack up against each other.  But I still don’t really have a sense for how long they’re going to take.  Share with us the idea where you implement this along with this concept of a person day.  Just talk us through that estimation technique.

ARASH PARSANIA:  Very good and important that you’re talking about this topic.  There may be misunderstandings around this statement since I advised against complexity estimates earlier.  So, to inform all listeners correctly, effort estimation in HYPERID does not take place in T-shirt sizes in general; but there are two values, minimum effort and RDE, which stands for risk-driven effort.  Only at one point, namely in the first ADP approximation, T-shirt size estimates are used. 

And there is a very good reason for that because, as mentioned, the first version of a plan rarely meets the expectations of the stakeholders.  So, a T-shirt size estimate is recommended so that the scope and the outcomes can be quickly aligned with the available time, budget, and capacity to avoid having to repeat the actual planning.  So, the inaccuracies are not a problem here at this point in the first ADP approximation, as more precise planning will take place later.

But there are also some very important measures here that help avoid the typical problems with T-shirt sizes that you mentioned.  You have already mentioned the first one, so estimate of the effort in person days and not in complexity.  So, we must stop lying to ourselves and distracting from the actual need with false reasons.  And the actual need is to estimate efforts in person days.  People think and act in years, in months, weeks, hours, et cetera.  Therefore, a higher accuracy is achieved always when estimating in these units.  Of course, you can make any translation ratios and even estimate in kilograms of rice or numbers of dogs, but it doesn’t make sense.

And if we are all honest, as soon as someone makes a complexity estimate, the first thought that runs through their mind is how many days or hours would it take?  And then the other important point is to clearly define what range of person days the respective T-shirt sizes should cover.

BILL YATES:  Right.

ARASH PARSANIA:  And an important mistake to avoid by all means would be not to leave the largest T-shirt size when it’s XXL open at the end.  So, for example, 100 to an infinite number of person days, or a number that is too high, like hundred to thousand person days.  So, the upper limit should be about twice the size of the lower limit, so for example, 100 to 200 person days for the biggest size.  If the end is left open, the work packages tend to be few but bigger. 

By defining everything as XXL, which will happen, you are taking very big risk because you don’t know whether it’s about 150 days or 1,500 days or something else.  If you set the upper limit at, for example, 200 person days, you can avoid making incorrect and inaccurate statements about the time and cost required or the expected outcomes.  The scope can then be adjusted again so that the actual effort estimation and project planning takes place in the second and third ADP approximation.

One Project Manager for One Project

WENDY GROUNDS:  Arash, talking about accountability for project managers, why is it important to just have one project manager on one project?

ARASH PARSANIA:  Oh, yes, this is a topic that is subject of endless debate.  The best way to explain it is to use the definition of tasks, which goes hand in hand with the question, who does what by when.  So, a task needs an outcome, a due date, and an owner, one owner.  And project management is a task. 

Now a few additional explanations to that.  A lot of decisions have to be made in a project.  As soon as there is more than one project manager, disagreements start.  Lots of debates and discussions that waste time and money and often ruin the success of the project.  As soon as there is more than one project manager, you have to define their roles and responsibilities.  You need to put that down in a RACI matrix.  This alone is a challenge, but the bigger challenge is actually sticking to those rules and regulations.  This doesn’t happen, as far as I saw it.

And please don’t get me wrong.  There are also projects with two project managers that work well.  I’ve seen some of them myself and have also been part of such structures.  However, projects with two project managers are only successful if one of them is the ultimate decision maker, and the other is subordinate in this respect. 

And company leaders often make such decisions because they are either fear-driven or risk-averse, or because they already know that they don’t have the right people to do the job.  But their conclusion to staff this with two PMs is not necessarily right.

So, if the company leaders, insist on more than one project manager, then I recommend staffing three instead of two.  So, this leads to better decisions and less time and money wasted because with three people you always have a majority and can avoid endless debates.

BILL YATES:  Okay, yeah.  You have a tiebreaker.  That’s so interesting.  When I was reading through the book, that was something that was really intriguing to me because I think for some sponsors or executives, it’s almost like a little bit of a compromise they make where they may say, okay, I really should have somebody from IT heading up this project, but there’s a business need that’s being addressed. 

So, I really need to have the business owner represented as the project manager, too, or someone that reports up to her.  Then you end up with two leaders.  That just creates more complexity, more confusion as to who’s ultimately accountable.  I like your idea of either insist on one or go with three.  That way you have a decision.  That’s good.

ARASH PARSANIA:  Yeah, this is exactly right.  And then actually this shows this old way of thinking from the waterfall times because business has created requirements, and then it was handed over to the IT to create specifications and develop it.  So, this mindset is still there, and that leads to the fact that people say, “Okay, we need one business project manager and one IT project manager.” 

So rather you need a good project manager, a project lead who can make decisions; and you have a good architect, a lead architect, something like that, who can manage the technology aspects of the project.  But it doesn’t need to be necessarily an IT project manager.

Generalized vs Specialized Knowledge

BILL YATES:  One of the things I wanted to ask you about, Arash, is some comments you have in the book about there’s the idea with scrum in agile practices of having generalizing specialists.  And I get it.  I completely get it.  With every team, whether it’s an operations team or a project team, it’s great to have redundancy.  It’s great to have cross-training and all that.  I totally get it.

 But I think you kind of raise the flag of, okay, let’s be reasonable here when you talk about estimating and getting into, okay, on a team, who should be estimating what?  Should we expect everyone to have enough knowledge where they should speak with the same voice, versus those who really have specialized knowledge?  So, there’s your soapbox.  I invite you to stand up and preach on that a little bit.

ARASH PARSANIA:  Thank you.  This is also one of the problem areas that we see again and again with scrum.  So, scrum is very effective because of its outcome orientation.  But unfortunately, scrum is inefficient, as explained before.  So, to distract from this weakness, the scrum dogmatists say that, in scrum, all team members must be able to do everything.  Everyone should estimate all efforts and do all the work.  In other words, a designer should also develop software, and a software developer should also create designs, so if you take it seriously.  And that this is not only unrealistic, this is ludicrous.

So, it may work mediocre in an amateur or semi-amateur environment, but it doesn’t work in a professional context.  Here you need the best designer, the best developer, the best data scientist, et cetera.  So, this is unrealistic.  These so-called high-performing teams do not exist, and I haven’t seen that.  And if they do exist, they are extremely rare.  I don’t know.  So, we should rather accept our reality and act in a way that fits this reality.  That would be my answer to this.

BILL YATES:  That’s great.  That was perfect.  Oh, yeah.

The Transition to HYPERID

WENDY GROUNDS:  So, if a company is currently using a waterfall or a scrum project management methodology, is it easy to transition to HYPERID?  What does that process look like if they wanted to move over?

ARASH PARSANIA:  Yes, of course.  And probably I need to say it as the creator of HYPERID.  But it should be indeed relatively easy to do that because HYPERID with P is a hybrid methodology.  Therefore, part of the methodology is familiar to them anyway.  So, one way or the other.  Those who use the waterfall model would have to add a few things from the agile aspects of HYPERID.  Those who use scrum would mainly have to take on the planning aspects in addition and adapt their way of execution to some extent to increase efficiency. 

In the end, it certainly makes sense to start with the general training to get to know the process, the specifics, and then the terms used in HYPERID.  For example, an iteration is called “delivery cycle.”

And I always recommend starting with medium-sized and low-risk projects.  This allows organizations to gain initial experience and plan the roll-out in the organization.  And there are also tools that are already available for free with the book so that planning can be done according to HYPERID and based on the HYPERID terminology. 

And by the way, one important thing for me at least, a tool manufacturer for a very modern and AI-driven project management software and I are currently looking for companies that would like to run a POC.  In this case, the software and HYPERID consulting would be free of charge for the company concerned.  The reason is that we want to see what additions are necessary for a HYPERID edition of the tool, and how the tool works with the process so that a specific HYPERID edition of this tool set can be provided.

And we also offer this POC free of charge.  So, this is also a good opportunity for an interested company to get to know HYPERID and then the PM tool also at no extra cost.  However, we cannot do this with many companies in the same time, at the same time, due to capacity constraints.  So first come, first serve.

BILL YATES: That’s fair enough. Yeah, very good.

ARASH PARSANIA: As mentioned, HYPERID has evolved over time, over the years until it reached its current state.  And I think HYPERID is currently in a stable and solid state that will meet many future challenges, too.  One of the reasons for this is that it was developed in such a way that it can support different types of projects.

 The HYPERID methodology can look a bit different in 10 years’ time than it does now, but it should and will ensure the success of projects.  That’s my commitment.

Find out More

WENDY GROUNDS:  Very good.  I think it’s always exciting that we get the opportunity to talk to someone who’s wanting to try something new.  And so, if there’s anybody in our audience listening to this who has tried HYPERID or, you know, has put this into practice, we’d love to hear from you, and we’d love to hear how it’s working.  And if our audience would like to find out more about HYPERID or get in touch with you, can you tell them where they should go?

ARASH PARSANIA:  Best way is via the website, www.hyperid-methodology.com.  There’s already a lot of information about HYPERID available on the website, and there are different ways to contact us.  Please use this opportunity to share your experience, wishes, and feedback with us.  Indeed, we would love to hear how it works for you.  Or contact us if you need help, for example, for the introduction of HYPERID in the organization.  People can also contact me directly, for example, on LinkedIn.  I always look forward to meeting new people and talking about interesting topics.

BILL YATES:  Excellent.  Well, thank you so much for sharing the reason behind HYPERID.  That’s always helpful, and I can relate to that.  It’s like, okay, I have to find a better approach, something that works for me.  So, this is born out of practical experience on your part and observing other teams.  And from that, you created this new approach and this new way to tackle projects.  So, thank you for letting us share that.  Thank you for all you’re doing.

ARASH PARSANIA:  And thank you.  Thank you so much for having me and giving me the stage and the opportunity to bring HYPERID to your wonderful audience.  It was a great experience and great pleasure.  And I hope that your listeners could take away one or the other impulse to make their projects more successful.  Thank you very much.

Closing

WENDY GROUNDS: That’s it for us here on Manage This.  Thank you for joining us.  You can visit us at Velociteach.com, where you can subscribe to this podcast and see a complete transcript of the show.

Now for our chance to give back.  You’ve earned your free PDUs by listening to this podcast.  To claim them, go to Velociteach.com.  Choose Manage This Podcast from the top of the page.  Click the button that says Claim PDUs and click through the steps.

Until next time, stay curious, stay inspired, and keep tuning in to Manage This.

Comments



Leave a Reply

Your email address will not be published. Required fields are marked *

PDUs:

0.5 Ways of Working

Podcast PDUs – FREE

PMP Certified? Follow our step-by-step guide to claim your FREE PDU credit with PMI for listening to Manage This podcast.

Subscribe to Podcast

Stay connected and get notified of every new episode.

Listen on Apple Podcasts
Listen on Spotify
Listen on Amazon Music
Listen on Youtube

Subscribe to Email

Join our PM community and select the types of updates you’d like to receive.

Recent Episodes