f.art

Sam and Kris

image

Global distributed workforce collaboration issues

Advertisements
Standard
cognoise

How running your college workshop can fetch you a better job

You may have heard about graduates not being ready for industry, industry not having investments into finishing schools, about the rapid growth of disconnected/under-equipped/unregulated finishing schools throwing still unusable talent, industry accrediting academia with no standard method among other problems of disconnect between education system and industry.

In my opinion this is an issue at personal level that collective systems or their coordination cannot solve. In other words we are turning a universal problem into a global problem and throwing costly resources at it including student time, tax money to solve. Approach to such universal problem solving begins at student level.

Here is a back story of an unused workshop at IITM. It used to be a workshop heavily funded with staff supplies since inception, that was post second world war with developed countries funding or setting up labs in IITs (IITM has a lot of lab equipment from Germany, while Kgp most was from Russia, Kanpur was US equipment). I was probably one of the last set of students to touch an old German particle classifier that was almost defunct till we decided to do something with it. Actually number of students using the workshop steadily declined as industry needs, student interests, technology shifted over years, leading to under used infrastructure with no useful outcomes. Now one fine day (actually over a year) this workshop was converted to a student run lab, with much lesser resources than before but with complete freedom to do what interests students. Fast forward 2 years this lab establishes itself as national champion in robotics, new materials, among other accolades.

Now as a student it makes a perfect place to find your own version of ‘cool’,  follow on what’s interesting to the student, instead of working on lab experiments that industry does not need anyway.

If I were a recruiter and I get a student who can clearly explain his 2 failures while really doing something in such workshops, and not a shiny bright power point slide with all adjectives pre-loaded, he is on board…

Standard
cognoise

High Coordination Low Planning

It may sound contradictory but i believe that high coordination projects cannot have high planning. When means of coordinating is multiple and efficient and actors are many, trying to predict timing of outcomes in the face of high uncertainty is meaningless.

Imagine picking up someone from airport, there are many uncertainties starting from passenger actually boarding the flight, flight being on time both departure and arrival, weather, delays in airport among others. Now let me list a few coordination tools available
1. departure information from airlines and other providers like airports and third-party apps (both push and pull forms)
2. mobile phone messaging and status like it being switched off or very many styles of missed call messaging
Above 2 categories are asynchronous you can add a synchronous coordination modes of actually calling or chatting online

Now any amount of planning to pick the passenger from the airport is pointless without being aware of the current situation. as tools have become ubiquitous and varied, instead it is useful to focus on the information access and availability for accomplishing the task. Now this may be a very simple task with not much costs, but project planning still in many industries (including IT) is high investment low return activity, still more time is dedicated than any other preparatory activity. industry data supports this as most estimates on both timing and outcomes are error prone from biases, uncertainties and assumptions made.

Massive coordination today happen with tools that were not previously available ranging from github, wiki, Facebook and email calendars. Many start-ups have had significant success without long-range planning (anything beyond 6 months), here is an example on ‘planning is guessing‘  by David Hansson of 37 Signals.

My take is most plans and the associated effort should be considered non-value added activity and waste, instead efforts to remove information asymmetries could pay off better. These may include adoption of better tools to coordinate, designing low latency processes say agile, awareness of context and resources, even simple ground truth documents or guidelines for acting in uncertainties …just saying

Standard
cognoise

Collaboration delineated

‘Why’ is usually more important than the how. As knowledge managers do not usually have any say in ‘why collaborate’, they are stuck with the how. And then there is the constant tradeoff between why a business does something versus why for an altruistic purpose. Again, knowledge managers are comfortable with the altruistic purpose of a community, of innovation, of knowledge sharing, of wisdom in crowds or similar such purposes. That leads me to think the why part of the equation is a red sea muddled with points and counter points, but the how part of collaboration is open for intervention.

Collaborate with its original meaning, “to work with” has to be delineated further. “Work” today is non-linear than what it used to be (even 5 years back) and “with” is very disjointed as well.

Continuity typically is on a work item (e.g. system requirement or issue). To achieve continuity within groups there has to be an overlap of function (e.g. development), identity, effort (e.g. of coding), space (a physical space, a code base). Work in Progress items are more suited for continuity, e.g. developers working together on a release (10.3.4 or R14) or version, talk abstracted or abbreviated language among them that lends continuity. End-products are not given much prominence for example the specification itself or any of the process documentation created during the process.

Coordination is for actions done by individuals in a specific time and space (e.g. check *.ini before service start up, capture log immediately after error, build after check in from all developers is complete). Within groups most understand the rules or rituals and follow them, usually there is not much to intervene here. If the number of people that need to be coordinating increases then a linear sequence with fall backs and alternate paths are developed usually by managers. That flowchart is presented in review meetings with no relevance to actual developers. I find Paul Graham’s maker manager distinction very relevant here.

Communication is often a channel decision, and people choose channels that they are most comfortable.

As in managers email, developers list, clients chat or instant message, friends SMS, and family calls

Channel is a tough choice to make specifically because

· enterprise software are aged and fragmented,

· email inbox more and more looks like somebody else’s to do list,

· managers cannot control requirement change over chat messages,

· and documents never are updated

Rule of thumb that has worked for me is take work to a channel where all the parties are already present. If there is no channel, create one and allow free access.

Metrics around velocity or work, closeness of drop dead date, progress on work items, my items (both in and out), are all derivable from most systems. This I feel one of the basic reasons why basecamp succeeds.

Coherence

· is meaning derived from the work,

· is making sense of where we are, and knowing where the effort is going,

· is relating to the bigger picture

This never comes from status meetings with a formatted ppt, most developers consider that meeting as a break and try to speak as less as possible and take back no action forget about coordinated actions. A concept map on the other hand provides a better way to look at things zoomed out or zoomed in, more clearly with relationships and dependencies.

Knowledge manager’s job gets interesting if more than one of these dimensions is handled. Just saying

Standard
cognoise

Project Artifact as Boundary Object

A project can be visualized as a opportunity for interfusion of multiple different identities of people. These identities stem from role performed in the project, technology specialization/association of the project team member, affiliation with customer through proximity on location/role/relations, among many other identities.

A general agreement to collaborate across these different roles is realized as a need in most cases and there are contractual tie ups (could be a real agreement, or defined by role and individual responsibilities) between several pairs of parties, customer-service provider, manager-resource, practice-resource, onsite-offshore. Real progress on work usually involves actions by project team members across different identities.

When identities fuse across, there is a need for objects that are “Common Point of Reference that can have different meanings attached to it, while can act as a means for coordination, alignment and translation, while catering to different concerns simultaneously” 

That was a definition of Boundary Object, all emphasis indicate the key characteristics.

Within Knowledge Management there are real good examples of boundary objects, below are some

  1. wiki page on wikipedia
  2. Knowledge Map of a project/community
  3. a story/anecdote

 If you are on a project it is likely that your deliverable, usually an artifact is also being used as a boundary object. But no one thought about it that way yet…and you compromised, some symptoms below

  1. Have you ever noticed the indifference with which core process groups fill out or create templates, while the end users of the templates find it hard to use it for any real purpose
  2. Even when you send a status report that goes through the hierarchy will the “head” be able to make sense of the original concern that you wanted to be acted on or was it all lost in translation
  3. Dev team seems to be at ease with the seemingly random project wiki, while the business team finds it real hard to get anything out or the other way around, is the wiki really that pliable
  4. The tester does not seem to be all concerned with the reds in the project plan, while the PM is unable to catch the significance of a red flag in a key test case

Mark Weiser spent the best part of his life working on Ubiquitous computing. He has another noted work as well in which he indicates all social and knowledge work is all about reducing the problem to reach an agreement , where he explains reality distortion with the classic archetype the Dilbert. And there are measures that you can use, to reduce Reality Distortion and for those academically oriented there are complex equation to represent them, but I like the cartoons better.

 The real issue I think is, can we design boundary objects and reduce the reality distortion differences over a period of time?

Standard