Focus On the Interfaces

October 7, 2007 by
Filed under: Project management, Teamwork 

Recall a while back where I wrote about a couple of training sessions in one company where there was a simulation involved, the teams building a device after spending some time working out the network of activities required to get the job done. Back then, one class managed to develop a well-conceived network but failed to accomplish the construction task, while the other managed to build the device, despite not having an end-to-end schedule.

I ran another class from the same company through the training last week, and as they say, the plot thickens. A blend of the previous two results, and a little more insight into where to focus.

As always, the first two attempts go as expected. Horrible failure the first time around, and enticingly close to success next time around. The groups in this class then put together a couple of network diagrams that looked quite similar to the previous ones, identifying many of the same optimizations that are necessary to refine the overall time for construction (the device lends itself – guided somewhat by the instructions – to being built in one reasonable manner).

In the final attempt at construction, the class did quite admirably, and was very close to completion (and within a few seconds of the time predicted by all of the schedules that had been developed in the past) when the wheels essentially fell off. For want of a couple of connections between some of the component parts, the group would have set a new record. Instead, they fumbled about with these very few problems and blew out their overall time by more than 50%.
Watching from the outside (one of the best parts of being an instructor), they fell into the same trap that I have seen with a lot of software teams over the years.

Each individual task was pretty well thought out, with a good understanding of who was going to do what, and when. The challenges came in the handoffs, the interfaces between the components.

When we have something to do, it is usually pretty clear to ourselves how we are going to go about doing it and what completion looks like, even if that understanding evolves along the way. At any point in time, our single viewpoint is self-consistent, almost by definition. If there are uncertainties, even those are consistent (if not, then we have additional challenges). At the end, then, completion of the task is as expected at that time. We rarely disappoint ourselves at the finish line, because we have successfully tempered our own expectations throughout the activity.

Trouble is, though, that in large projects with a lot of interdependent tasks, something that we finish is going to be used by someone else. Even if we have a perfect common understanding with the recipient of our product initially, expectations will diverge as we build our product if they are not in lock step with us. That common understanding is never perfect, though, and any gaps can potentially widen considerably over time.

What we see as completion for our activities is not nearly as important as what the recipient sees. Only the recipient is qualified to assess the ‘doneness’ of our tasks (if you have a spouse, you have likely learned this for yourself). Any imperfections in that common understanding up front means we need to stay in lock-step with the recipient throughout the process to prevent any divergence. This is true with the end customer, of course, but it is the little misunderstandings along the way that build up to the large customer disappointments.

The handoffs are where things go wrong. Most relay races are fumbled at the exchange of the baton, and even with this simple, clear exchange there is a lot of effort in practicing a successful handoff. In software, the handoffs are far more complex, are ill-defined up front, and if you look back, are the source of many of the problems we face on our projects.

It is easy to construct a complex schedule of interrelated tasks that appears to show a path to completion on a project. Even if we have all the right tasks, it is those deceptively thin lines between the boxes on a Gantt that are the source of grief. If we recognize that we need to stay synchronized with the recipient of our activities (internal or external), we are less likely to disappoint. – JB

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

Comments

One Response to “Focus On the Interfaces”

  1. Expertise vs. Teamwork | Clarrus on September 22nd, 2010 7:20 am

    […] were working through a project management workshop that I have blogged about in the past, where we have a fun blend of theory and practice centred around a brief construction project. With […]

Feel free to leave a comment...





  • Search by Topic

  • What’s Happening

    September 15, 2016: Thanks to the Vancouver chapter of the IIBA for inviting me to present a talk about Real Analysis agility - the bottom line is thoughtful application of effective analysis over Cargo Cult application of the latest fashionable approach! - fabulous interaction, great feedback!
    November, 2016 - 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:

    • March 1-3, 2017 - Winnipeg, MB
    • March 6-8, 2017 - Edmonton, AB
    • March 15-17, 2017 - Victoria, BC
  • What People are Saying

    I learned a lot from Jim, and will always be grateful to have had him as instructor and client. Jim’s class lectures reflect how knowledgeable and well rounded he is – as a person, software developer, and project manager. As a client, Jim is great because he understands the issues that obscure most projects. He made sure we both achieved our goals. It will always be a pleasure working with him.

    — Donabel Santos