A Social Endeavour

October 15, 2012 by
Filed under: People, Quality, Teamwork 

A friend of mine has gone back to school to do some research into cognitive biases and how to mitigate them in the context of technology projects. As part of his research, he is reproducing an experiment that looks at the drivers surrounding particular tasks in projects – in this case, estimation. While the results are not yet comprehensive enough to satisfy the statistical gods, there is a trend coming out of the data that is interesting to ponder.

As it turns out, one of the primary drivers for why we do what we do when we think we are estimating has little to do with ‘getting the right answer’ or ‘being able to predict when the task will be done’, but has a lot to do with maintaining our status in the social hierarchy of the project environment. That is, regardless of the particular technique we use, our response is motivated by what we think will be a satisfactory response for the person asking us for an estimate.

I’m going to go out on a limb in two directions.

First, I think that once there is significant data, the results aren’t going to change all that much. In my experience, the need to be ‘a team player’ and to ‘give the answer that you think the person wants to hear’ are critical elements of the practice of estimation. Most people have an idea of the time constraints from the project, and there is an overwhelming need to try to fit the estimates to these constraints. If we are told the project has to be done in 6 months, all the known work to be done somehow magically fits within 6 months.

Way too often, that response magically becomes exactly the constraint, far too often for it to be a coincidence, and I know that most constraints, in reality, are far too constraining for these estimates to be reasonable. We’re not estimating at all, we are hoping, we are praying, we are saying what we need to so the conversation ends as quickly as possible so that we can get busy with all the work we need to get done to meet our crazy promises.

Second, I think this discovery isn’t strictly limited to what we do when we are ‘estimating’. Almost everything we do on projects is part of a deep, complex social interaction of a group of people trying to get something done.

Sometimes, but not always, the group has taken the time to gain a shared understanding of what that something really is, and what done really means.

Sometimes, but not always, the group takes the time to understand how to work effectively with one another, given the many dimensions of diversity that any group will naturally have.

Either way, being part of a project team is part and parcel with the building of a product, and being part of a team means that we have a number of social connections with the others in the team. If we want to build a great product, it is in our best interests to:

  • have a consistent understanding of where we are headed – what we are trying to accomplish, from a number of perspectives,
  • be able to smoothly interact with one another – to collaborate openly and constructively,
  • stay consistent with one another, which implies that we need to interact frequently throughout the project.

One of the operative words in that list is ‘constructively’. We need a great deal of interactions to get through any project, and these interactions need to be constructive toward our accomplishing our shared goals. If we are estimating (or testing, or documenting, or…) with the intent of merely maintaining our social standing (or in other words, of not getting in trouble), we’re missing the point. We should always be interacting with the intent of bring us closer to our project goals.

Of course, this can only be done if we do have those shared goals, and if we have built a culture where we can safely challenge one another to strive toward those shared goals. If we are busy defending our status, if we are struggling to get things done quickly to avoid the limelight, we will complete our tasks, but the project results won’t be what they could be.

The quality and quantity of our interactions within teams need to be carefully fostered – in most teams that means both need to go up. We need to work together to clearly agree on goals, we can work together to better understand and appreciate one another’s different perspectives, or we can work independently.

In either case, we will finish the project at some point, but the results will vary dramatically. – JB

If you enjoyed this post, make sure you subscribe to my RSS feed!

Comments

One Response to “A Social Endeavour”

  1. Richard O'Rourke on October 16th, 2012 3:09 pm

    Well, you have two arms (last time I saw you anyway…)

    “I’m going to go out on a limb in two directions.”

Feel free to leave a comment...





  • Search by Topic

  • What’s Happening

    September, 2017 – A workshop series to help you develop resilience in the workplace and in your life!

    Next open enrolment sessions start soon – contact us to get involved!

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.


    Contact Jim if you would like to connect around any of the upcoming dates:

    • September 19-21, 2017 – Winnipeg, MB
    • October 4-5, 2017 – Regina, SK
    • October 21-22, 2017 – Winnipeg, MB
    • November 1-2, 2017 – Saskatoon, SK
    • November 27-28, 2017 – Edmonton, AB
    • February 10-11, 2018 – Edmonton, AB
  • What People are Saying

    Jim Brosseau’s understanding of the true dynamics of the IT workplace shows through in Software Teamwork. For those on the IT solution delivery front lines, and for those who manage them, his insights and wisdom will lead to not only better projects, but a better work life as well.

    — Bruce A. Stewart, Chief Executive Officer, Accendor Research, Inc.