Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Nov 05, 2019 7:24 AM
Replying to Scott Ambler
...
A few thoughts:
1. The pit crew team trains tirelessly (punny) and focuses on experimenting with new ways of working (WoW) in order to shave milliseconds off of very repetitive tasks. The learning from that is that its important to invest in enabling teams to experiment with improving their WoW. Pit crews also stay together for years, they're typically not organized as a short-term project team for the Indy 500.
2. Navy seal teams take the best of the best from the rest of the US military. They then train relentlessly for the occasional high-pressure engagement. They also cross train and are generalizing specialists. Everyone has one or more specialities and is competent at other aspects of the job, and they're always trying to get better. So the US Navy makes a huge investment in these people over the long term, and they keep these teams together for a long time.
3. It's interesting that the examples of "project teams" that you bring up are actually long-standing teams in practice, not short-term project teams.
4. We could argue that projects (hunt down this bad guy, win this car race) are being brought to these long-standing teams. This is a very common pattern that I see a lot of in organizations that are well down the agile transformation path.
Dear Scott
Very interesting these thoughts of yours
Thanks for sharing
Do we agree that high performance is achieved through training and continuous improvement and is it a medium to long term process?
How can we achieve this (high performances) from outsourced teams and project managers? Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Nov 05, 2019 7:28 AM
Replying to Scott Ambler
...
Yes, I agree with Kiron. Knowledge workers are most effective when they're led, not managed. This has very interesting implications for managers of such people: They need to move away from command-and-control strategies (which work poorly with skilled workers in general, BTW) towards leadership strategies such as motivation and enablement.
Dear Scott:
The three of us agree that "Knowledge workers are most effective when they are led, not managed"
How to implement "leadership strategies such as motivation and enablement" in outsourced teams and, of course, going through the stages identified by Tuckman and in return getting high performances? Saving Changes...
Scott AmblerConsulting Methodologist| Ambysoft Inc.Toronto, Ontario, Canada
Nov 05, 2019 7:10 AM
Replying to Scott Ambler
...
Luis, good point. It takes time for a team to learn how to trust each other and work together well. One of the drawbacks of the strategy of forming a team for a project then disbanding it once the project is complete is that you lose the benefits to be derived from a gelled team.
Worse yet, you motivate people to not invest time in building relationships with their co-workers. This reduces the overall effectiveness of the team. Yesterday at PMO Symposium I was in a discussion with a few PMO leaders and we were discussing various issues they are facing back at work. A couple of people talked about how their organizations treated contractor PMs very differently than their full time employees (FTEs). They made it pretty clear that the contractors weren't being included in strategy discussions, the sharings of learnings within the PMO, and other important things. I was shocked that they weren't treating the contractors as full team members.
When entire teams are outsourced, including the manager/leader, then you need to rely on that team to be effective. That navy seal team is no longer yours, they're simply a team of mercenaries whom you are hiring to do a job. So whatever organization is offering those mercenaries to you is responsible for helping them to become effective. The onus is on you to be sufficiently competent to hire, direct, and monitor that team. And part of their overhead, which you pay for, is the other organization will find ways to enable the team to learn and improve over time. Maybe that team has been assigned to your organization to learn a new set of skills as they get the job done for you. That expertise that you're hiring them for? Someone else paid for them to gain that expertise. The expertise that the next organization is going to pay them for having? You'll pay for that on their current gig with you. The implication is that even though you'll pay for it, you'll only benefit from that team's improvements for as long as you outsource to them. The minute you let them move on you lose that expertise, and you'll likely have paid a premium for it because of the outsourcing relationship.
Short-term strategies, such as outsourcing to another organization for their "gig team" or contracting people to work as "gig workers" is a short-term strategy that provides you with short-term benefits. This is fine as it gets the immediate job done and doesn't leave you with FTEs that you are then responsible for. BUT, any improvements or learnings that those people accrued while working for you go out the door when they do.
Implications:
1. If you want to gain the long-term benefits of investing in people's learnings then you need to keep those people around long term. The "gig mindset" pretty much prevents that if the people leave after a gig is done.
2. If you want to gain the long-term benefits of a team's learnings then you need to keep that team together long term. The "classic project mindset" where a team disbands at the end of a project pretty much prevents that.
3. If you decide to keep a gig worker or a gig team on for the next gig, then the next gig, then the next gig,... you've effectively hired very expensive people full time. This isn't this cost effective. Furthermore, in some countries, such as the US, it's not really a viable options as there are time limits on how long you can keep contractors on.
...
2 replies by Luis Branco and Thomas Walenta
Nov 06, 2019 8:57 AM
Thomas Walenta
...
Scott, agree there are different scenarios to use gig workers.
I have seen projects include activities and even phases (as part of their planned scope) to transfer knowledge as part of the project. This is building the benefit of preserving the gained knowledge for the organization.
Also there are one-off project you probably only need once and it would be waste to build that capabilities inhouse, so you use specialists.
Sometimes these specialist are so rare on the market that you have no choice.
And some organizations choose to outsource capabilities just because of lower costs, this is the business case for outsourcing. It is when the capabilities are in abundance on the market.
This all is good old project management: build your project method according to the specific needs of the challenge. PMBoK.
Nov 07, 2019 5:55 AM
Luis Branco
...
Dear Scott
Excellent framing of the issue and thorough analysis
Thanks for sharing your opinion
Saving Changes...
Scott AmblerConsulting Methodologist| Ambysoft Inc.Toronto, Ontario, Canada
Nov 05, 2019 7:24 AM
Replying to Scott Ambler
...
A few thoughts:
1. The pit crew team trains tirelessly (punny) and focuses on experimenting with new ways of working (WoW) in order to shave milliseconds off of very repetitive tasks. The learning from that is that its important to invest in enabling teams to experiment with improving their WoW. Pit crews also stay together for years, they're typically not organized as a short-term project team for the Indy 500.
2. Navy seal teams take the best of the best from the rest of the US military. They then train relentlessly for the occasional high-pressure engagement. They also cross train and are generalizing specialists. Everyone has one or more specialities and is competent at other aspects of the job, and they're always trying to get better. So the US Navy makes a huge investment in these people over the long term, and they keep these teams together for a long time.
3. It's interesting that the examples of "project teams" that you bring up are actually long-standing teams in practice, not short-term project teams.
4. We could argue that projects (hunt down this bad guy, win this car race) are being brought to these long-standing teams. This is a very common pattern that I see a lot of in organizations that are well down the agile transformation path.
There are several ways to achieve team performance, and certainly training and continuous improvement are two of them.
You can achieve this in outsourced teams, or with contractors, using similar strategies. If you bring these gig workers into your org and take responsibility for them during the period they work for you, then you can choose to include them in any skills improvement efforts. Of course you're limited to what is allowed within the countries you operate in. Many countries have employment laws that force you to treat contractors/gig workers differently than FTEs and this often hampers your ability to support their learning efforts.
A common strategy is to put into the contract mechanisms to invest in these sorts of people. For example, if you want to provide training for a team that is composed partly of contract/outsource people and partly of FTEs, then the contracting companies may need to pay for their share of the training budget or not charge you for their people's time while on training.
...
1 reply by Luis Branco
Nov 07, 2019 5:58 AM
Luis Branco
...
Dear Scott
This is a big question:
Who will bear the costs of training and continuous improvement?
Saving Changes...
Scott AmblerConsulting Methodologist| Ambysoft Inc.Toronto, Ontario, Canada
Nov 05, 2019 7:28 AM
Replying to Scott Ambler
...
Yes, I agree with Kiron. Knowledge workers are most effective when they're led, not managed. This has very interesting implications for managers of such people: They need to move away from command-and-control strategies (which work poorly with skilled workers in general, BTW) towards leadership strategies such as motivation and enablement.
In outsourced/contractor situations the people effectively have two potential masters now, you and whatever company they are contracting through. So if you want to gain the benefits of learning and improvement you need to work with that organization to ensure that they happen. Are you vendor management people capable of writing and then governing such a strategy? Saving Changes...
Scott AmblerConsulting Methodologist| Ambysoft Inc.Toronto, Ontario, Canada
Nov 05, 2019 5:49 AM
Replying to Senthil S
...
It is best to conduct a daily standup or huddle and to ensure you have a scrum of scrum and make sure necessary and sufficient training is provided for all team members to ensure they are at the same level. Also conduct periodic performance reviews to ensure they are on track and committed to achieve the common goal.
Yes, a team huddle (daily or not) was a common practice long before Scrum popularized it within the agile community.
Holding some form of reflection/retrospective session was also an important practice long before agilists stumbled into it. But few teams execute them well unfortunately. I've written about this, and how to actually execute well, in Guided Continuous Improvement (GCI) at https://disciplinedagiledelivery.com/gci/.
...
2 replies by Luis Branco and Thomas Walenta
Nov 06, 2019 12:05 PM
Thomas Walenta
...
To widen the view about standups: I saw my 1st in 1997 when we hired a gig PM to save a project (I was leading the PMO then). His leadership style was command/control and coercive. And adaptive. Highly successful. He forced the core team to be in the office every morning 7am. 15 minutes standup and you better be prepared.
Nov 07, 2019 9:51 AM
Luis Branco
...
Dear Scott
Excellent question yours
Thanks for sharing it.
What characteristics, in your opinion, should an organization with a body shopping business have?
Saving Changes...
Scott AmblerConsulting Methodologist| Ambysoft Inc.Toronto, Ontario, Canada
Nov 06, 2019 12:54 AM
Replying to Anton Oosthuizen
...
The improvement quotes in your F1 example is due to advances in technology and process. Standards are very important when you want to improve to a consistent level i.e. multiple teams with access to the same standards could function at the same level of efficiency. But even the best standards and procedures cannot overcome a lack of aptitude, training, and knowledge. Going back to your F1 example, the improvements would never be possible of you replaced the team with 7-year-olds or white-collar office workers.
Anton, I mostly agree. The improvements came from a combination of technology improvement, process improvement, and team training. The people on an F1 pit crew team train over and over again. If you want a video of them you'll see that they are all standing in a specific spot, in a specific pose, the car comes in and stops in a specific spot, they react and they smoothly do their individual task. They would have trained over and over again to learn that muscle memory. They would have also reflected after practice sessions to identify potential ways to do it better.
Could you train 7 year olds to do it just as well? Probably not given the strength requirements to operate the equipment. Could you do it with office workers? I bet you could get them to a respectable response time in a few days (could even be a one-day team building exercise, hmmm....) and given time to learn the skills and gain the experience turn them into a real pit crew if you wanted to.
...
1 reply by Anton Oosthuizen
Nov 06, 2019 11:27 PM
Anton Oosthuizen
...
Scott the issue with training office workers is to illustrate that it is not only about process, training, and technology. You need some sort of aptitude in order to do perform certain tasks well. Let's call it technical inclination in our F1 example. Maybe you can teach somebody to do something like a parrot without them understanding what and why they are doing it. You have a fair chance of getting fair performance but the second something deviates, which in life and in our example it does, you go from hero to zero.
I can teach anybody how to write hello world code in Java and do it well but when I request that they save hello world to a file instead of displaying it on the screen.....BOOM.
Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Nov 06, 2019 5:16 AM
Replying to Scott Ambler
...
When entire teams are outsourced, including the manager/leader, then you need to rely on that team to be effective. That navy seal team is no longer yours, they're simply a team of mercenaries whom you are hiring to do a job. So whatever organization is offering those mercenaries to you is responsible for helping them to become effective. The onus is on you to be sufficiently competent to hire, direct, and monitor that team. And part of their overhead, which you pay for, is the other organization will find ways to enable the team to learn and improve over time. Maybe that team has been assigned to your organization to learn a new set of skills as they get the job done for you. That expertise that you're hiring them for? Someone else paid for them to gain that expertise. The expertise that the next organization is going to pay them for having? You'll pay for that on their current gig with you. The implication is that even though you'll pay for it, you'll only benefit from that team's improvements for as long as you outsource to them. The minute you let them move on you lose that expertise, and you'll likely have paid a premium for it because of the outsourcing relationship.
Short-term strategies, such as outsourcing to another organization for their "gig team" or contracting people to work as "gig workers" is a short-term strategy that provides you with short-term benefits. This is fine as it gets the immediate job done and doesn't leave you with FTEs that you are then responsible for. BUT, any improvements or learnings that those people accrued while working for you go out the door when they do.
Implications:
1. If you want to gain the long-term benefits of investing in people's learnings then you need to keep those people around long term. The "gig mindset" pretty much prevents that if the people leave after a gig is done.
2. If you want to gain the long-term benefits of a team's learnings then you need to keep that team together long term. The "classic project mindset" where a team disbands at the end of a project pretty much prevents that.
3. If you decide to keep a gig worker or a gig team on for the next gig, then the next gig, then the next gig,... you've effectively hired very expensive people full time. This isn't this cost effective. Furthermore, in some countries, such as the US, it's not really a viable options as there are time limits on how long you can keep contractors on.
Scott, agree there are different scenarios to use gig workers.
I have seen projects include activities and even phases (as part of their planned scope) to transfer knowledge as part of the project. This is building the benefit of preserving the gained knowledge for the organization.
Also there are one-off project you probably only need once and it would be waste to build that capabilities inhouse, so you use specialists.
Sometimes these specialist are so rare on the market that you have no choice.
And some organizations choose to outsource capabilities just because of lower costs, this is the business case for outsourcing. It is when the capabilities are in abundance on the market.
This all is good old project management: build your project method according to the specific needs of the challenge. PMBoK.
...
2 replies by Luis Branco and Scott Ambler
Nov 06, 2019 9:28 AM
Scott Ambler
...
A few thoughts:
1. Transferring knowledge as part of a hand off to others is better than not doing so I suppose, but is often less effective than we hope. The problem is that tacit knowledge takes a lot of time to learn, and that's what's often required for effectiveness. I've seen a lot of projects where they've attempted this sort of thing, and it's definitely helped, but when I would visit the team that the work was handed off to a few months later they were still investing time to learn from scratch what that had supposedly picked up during the transfer. We need to look at the overall lifecycle, not just the project portion that we're involved with.
2. One-off projects are definitely good candidates for outsourcing. Until you discover that it's not a one-off, or that you need to maintain and evolve the output of the project. Then you start wishing you'd done it yourself, sometimes as you're redoing it again.
3. Hiring contractors for the specialties is definitely a good idea. A much better idea is to also include in the contract that they coach and teach their skills to your people AND you then ensure that your people step up and do so. Sadly I hear a lot of talk from organizations about this strategy but don't see as much execution of it. I've seen a lot of high-priced specialists who were supposed to be shadowed but then weren't because the FTEs couldn't be freed up.
4. Outsourcing for cost savings rarely seems to work out in practice. I hear about the cost savings of outsourcing all the time, and then when I look at the "business cases" justifying these outsourcing efforts they almost always end up being wishful works of fiction at best. To do it right you need to consider the total cost of ownership (TCO) as well as the total benefit of ownership (TBO), and both of these figures require a systems mindset to actually calculate. How much work needs to occur on the customer end to specify, manage, govern, and validate the outsourcing work? That adds up quickly, and it's important to recognize that outsourcing efforts typically require significantly more of these activities than insourced work does. What is the cost of contract management, in particular change management when you want to evolve the requirements of the work? From an operational point of view, what inefficiencies are being introduced within the customer organization to work with the outsource company. For example, a few months ago I was working with an organization that walked me through the cost savings they'd achieved through outsourcing their help desk. They honestly believed they were getting a great deal because they only looked at the costs of the help desk operation, which in fact were lower than when it was insourced. So we then worked through the overall process from the point of view of the people being served by the outsourced help desk. Wait time had skyrocketed. They effectively had expensive people wasting time waiting to be served by inexpensive people. So I suggested we take those costs into account. They were uncomfortable with that idea. Then we discovered that the problems weren't being solved as often as before, requiring new tickets to be submitted and more waiting to occur. So I suggested we take those costs into account, and they were also uncomfortable with that suggestion. Bottom line was that when we calculated the total value of ownership (TVO), TBO-TCO, we discovered that it was negative. Their great deal was actually an incredibly bad deal in practice. Worse yet, when we started working through potential scenarios to fix the help desk process we couldn't see any way to make it cost effective and still involve the outsourcing company. And I've lost track of the number of times I've run into situations like this.
Nov 08, 2019 2:15 AM
Luis Branco
...
Dear Thomas
I read your response to Scott carefully.
Thank you for your input.
You suggest: "build your project method according to the specific needs of the challenge. PMBOK"
This topic is designed to reflect on the performance of project teams.
What would you do and how would you do to get outsourced teams (it seems fashionable) to perform high?
Saving Changes...
Scott AmblerConsulting Methodologist| Ambysoft Inc.Toronto, Ontario, Canada
Nov 06, 2019 8:57 AM
Replying to Thomas Walenta
...
Scott, agree there are different scenarios to use gig workers.
I have seen projects include activities and even phases (as part of their planned scope) to transfer knowledge as part of the project. This is building the benefit of preserving the gained knowledge for the organization.
Also there are one-off project you probably only need once and it would be waste to build that capabilities inhouse, so you use specialists.
Sometimes these specialist are so rare on the market that you have no choice.
And some organizations choose to outsource capabilities just because of lower costs, this is the business case for outsourcing. It is when the capabilities are in abundance on the market.
This all is good old project management: build your project method according to the specific needs of the challenge. PMBoK.
A few thoughts:
1. Transferring knowledge as part of a hand off to others is better than not doing so I suppose, but is often less effective than we hope. The problem is that tacit knowledge takes a lot of time to learn, and that's what's often required for effectiveness. I've seen a lot of projects where they've attempted this sort of thing, and it's definitely helped, but when I would visit the team that the work was handed off to a few months later they were still investing time to learn from scratch what that had supposedly picked up during the transfer. We need to look at the overall lifecycle, not just the project portion that we're involved with.
2. One-off projects are definitely good candidates for outsourcing. Until you discover that it's not a one-off, or that you need to maintain and evolve the output of the project. Then you start wishing you'd done it yourself, sometimes as you're redoing it again.
3. Hiring contractors for the specialties is definitely a good idea. A much better idea is to also include in the contract that they coach and teach their skills to your people AND you then ensure that your people step up and do so. Sadly I hear a lot of talk from organizations about this strategy but don't see as much execution of it. I've seen a lot of high-priced specialists who were supposed to be shadowed but then weren't because the FTEs couldn't be freed up.
4. Outsourcing for cost savings rarely seems to work out in practice. I hear about the cost savings of outsourcing all the time, and then when I look at the "business cases" justifying these outsourcing efforts they almost always end up being wishful works of fiction at best. To do it right you need to consider the total cost of ownership (TCO) as well as the total benefit of ownership (TBO), and both of these figures require a systems mindset to actually calculate. How much work needs to occur on the customer end to specify, manage, govern, and validate the outsourcing work? That adds up quickly, and it's important to recognize that outsourcing efforts typically require significantly more of these activities than insourced work does. What is the cost of contract management, in particular change management when you want to evolve the requirements of the work? From an operational point of view, what inefficiencies are being introduced within the customer organization to work with the outsource company. For example, a few months ago I was working with an organization that walked me through the cost savings they'd achieved through outsourcing their help desk. They honestly believed they were getting a great deal because they only looked at the costs of the help desk operation, which in fact were lower than when it was insourced. So we then worked through the overall process from the point of view of the people being served by the outsourced help desk. Wait time had skyrocketed. They effectively had expensive people wasting time waiting to be served by inexpensive people. So I suggested we take those costs into account. They were uncomfortable with that idea. Then we discovered that the problems weren't being solved as often as before, requiring new tickets to be submitted and more waiting to occur. So I suggested we take those costs into account, and they were also uncomfortable with that suggestion. Bottom line was that when we calculated the total value of ownership (TVO), TBO-TCO, we discovered that it was negative. Their great deal was actually an incredibly bad deal in practice. Worse yet, when we started working through potential scenarios to fix the help desk process we couldn't see any way to make it cost effective and still involve the outsourcing company. And I've lost track of the number of times I've run into situations like this.
...
2 replies by Luis Branco and Thomas Walenta
Nov 06, 2019 12:11 PM
Thomas Walenta
...
Outsourcing can be successful for both parties.
I worked in and sold outsourcing for datacenters, help desk, application maintenance, cloud, BPO since 1995. You just need to target win-win and have a good retained organization.
And yes, there are players that can do it (and benefit from sustainable profits) and some who do not.
Nov 08, 2019 2:23 AM
Luis Branco
...
Dear Scott
I can only thank you for this reflection for our exchange of views.
Very interesting
Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Nov 06, 2019 5:50 AM
Replying to Scott Ambler
...
Yes, a team huddle (daily or not) was a common practice long before Scrum popularized it within the agile community.
Holding some form of reflection/retrospective session was also an important practice long before agilists stumbled into it. But few teams execute them well unfortunately. I've written about this, and how to actually execute well, in Guided Continuous Improvement (GCI) at https://disciplinedagiledelivery.com/gci/.
To widen the view about standups: I saw my 1st in 1997 when we hired a gig PM to save a project (I was leading the PMO then). His leadership style was command/control and coercive. And adaptive. Highly successful. He forced the core team to be in the office every morning 7am. 15 minutes standup and you better be prepared.
...
1 reply by Luis Branco
Nov 08, 2019 2:33 AM
Luis Branco
...
Dear Thomas
It's just the daily meeting proposed in some agile frameworks.
I know some organizations that use early day briefing and late day debriefing
When team and individual goals are not aligned with the organization's goals, weekly coaching sessions so that the team performs high
Does this method allow for medium and long term results?