In support of strategic colocation

one-bad-appleA recent Harvard Business Review article provided the analysis on a research study conducted by Jason Corsello and Dylan Minor into potential benefits of strategic colocation.

Managers usually collocate staff by role, by job level or by project team but rarely is individual capability factored into this decision making.

The authors’ research showed that pairing a fast worker with a slower one appeared to speed up the productivity of slow worker rather than slowing down the faster one. Similar pairing highly productive staff who did lower quality work with those that were slower but produced higher quality outcomes resulted in improvements in both the productivity of the slower workers and quality in the sloppier ones.

These performance gains only appeared to be achieved when the workers were sitting very close together and distances of 25 or 50 feet did not reveal the same improvements. Neighbors, it appears, really do make a difference!

On a more concerning note, the research supported the old adage of one bad apple spoiling the barrel. Close proximity to workers who exhibited toxic behaviors resulted in normal workers sitting with them picking up their bad habits.

This will come as no surprise to elementary school teachers who are used to reseating students based on classroom behavior or aptitude.

But how can this help improve our projects?

Project managers should look for signs of chronic toxic behavior and not procrastinate in addressing it. The longer they wait, the greater the likelihood that this behavior will infect other team members. In those extreme cases where a particular worker is critical to the success of the project but is consistently toxic, separating them from others on the team might be the best option.

Early in the life of a project expectations should also be set with team members that seating arrangements are fluid. This will reduce the likelihood that staff will complain about being relocated once a better understanding of their strengths and weaknesses has been gained.

Once a project manager has learned which of their team members are the most productive or produce the highest quality deliverables, they can then decide whether pairing them up with slower or lower quality team members might improve overall project performance.

Such decisions should never be made lightly as individual personality traits, existing relationships as well as organization and team culture could produce unintended consequences after making such changes, but with a bit of luck a rising tide might raise all ships!

Categories: Project Management | Tags: , , | Leave a comment

Focus on individual impacts when communicating risks!

less-is-more-8A recent article by Uzma Khan and Daniella Kupor in Harvard Business Review adds support to the argument for keeping things simple when it comes to communicating risks.

Through a series of experiments focused on positive and negative risks, the authors determined that there is a greater likelihood of individuals making an objective, logical decision when a single significant impact is presented as opposed to when that same impact is presented along with a number of other lower impact outcomes.

In their own words “Thus, adding prizes that make a sweepstakes objectively more valuable ends up decreasing the sweepstakes’ perceived value. Similarly, noting smaller side effects that make the drug objectively more dangerous can in fact make it appear less dangerous by making the larger side effect seem even less likely to happen. This biases us against taking positive risks and avoiding negative ones.”

How might this sort of bias be relevant to our understanding of project risk management?

Recognizing that risk owners are frequently reluctant to commit time or political influence to actively responding to a risk, we might be tempted to try to stack the deck in our favor by communicating multiple potential impacts which might result if the risk gets realized.

By doing this, we might actually diminish the perceived threat or opportunity presented by the risk resulting in risk owners responding in the exact opposite manner than what we had hoped for.

To avoid this, while it is a good idea to capture complete information in our risk registers, when presenting risks to stakeholders, focus on communicate the single impact which presents the greatest threat or opportunity. Then, if you don’t get the buy-in you were hoping for, add weight to your argument by sharing other potential impacts.

As the authors state “…when it comes to helping people evaluate risk, less is more.

Categories: Project Management | Tags: , , | Leave a comment

Five expectations for agile tools…

wrong-toolAgile delivery does not mandate the use of software tools, but when scaling agile within large organizations with  greater numbers of stakeholders, geographic distribution of pods, compliance requirements and similar enterprise challenges, tooling can improve efficiency and effectiveness.

There are a few basic expectations which should be met to ensure that your tooling isn’t consistently identified as a blocker during stand-ups and retrospectives.

Stability

Agile enables greater levels of transparency and objectivity than traditional delivery but if the underlying tools can’t be trusted to reliably and responsively capture and provide information then pods are likely to experience greater levels of interruptions and requests for status updates.

Interoperability

There is no right answer when it comes to the choice of purchasing an end-to-end tool suite from a single vendor or pursuing a best-of-breed point solution approach. But without seamless integration at the logical connecting points, the risk of data quality or redundant effort increases.

Context-based flexibility

While we encourage team self-organization, in larger environments there is the need to have some standards about where and how critical delivery information elements are captured. Without this, there is likely to be no consistency between product or project-based pods which will make it that much harder to enable a self-serve, lean governance and oversight model.

Usability

A good tool facilitates agility by adapting to the working style of the team member instead of requiring them to significantly modify their practices. The greater the delta between tool and team member practices, the greater the need for comprehensive training and for constant reinforcement of expected practices.

Scalable complexity

Minimally sufficient applies to documentation as well as tooling. Teams new to agile should be given a very basic set of features but have the ability to incrementally expand their usage as their maturity increases. However limiting which capabilities are visible to these teams should not prevent more capable pods from advanced usage.

I’m agnostic when it comes to software solutions as the best tool in the hands of a fool will just make them a more dangerous fool but tool capabilities should be commensurate with team needs.

Categories: Agile, Project Management | Tags: , | Leave a comment

Create a free website or blog at WordPress.com.

%d bloggers like this: