Adventures in home working

(updated with a link to Michael’s post that works!)

Michael argues that we hide behind the need for culture change on many collaboration projects, his key point is illustrated by this example:

if a team can run a project in email then they can run one in a collaboration tool. They don’t need a change in “culture” to make the transition, they need a change in “work practice”.

Whilst it’s difficult to disagree with the point that to switch from using email to using a collaborative workspace space requires a change in working practice, I don’t agree that it doesn’t sometimes also require a change in culture.  To cite a few examples of my own: 

1. creating a shared knowledge base requires people to share expertise that they might traditionally have thought of as essential to their long term employment and to reduce the visibility of their individual contribution to maximize that of the team.  Changing this attitude requires some culture change away from individual performance and “knowledge is power” and more towards “team results matter”.
2. creating a blog that narrates your work requires significant investment of time and energy and opens up immature ideas to public scrutiny.  This requires a culture change away from “immediate results” towards “investment in the future”, “spin off innovation” and “improved quality through greater participation”.  It requires managers to encourage people to be open and take risks without fearing that this will reflect badly on them.

In my personal experience I have seen a lot of culture related issues that have stalled changes in working practice designed to improve collaboration, for example:

1. People not being comfortable with letting other team members get access to their work in progress files,  preferring instead to only provide access to published/polished information
2. People not being comfortable with producing weekly highlight reports because it exposes the peaks and troughs in the output as if it were peaks and troughs in their input,  ie some weeks they might not have any highlights at all, maybe only low lights but have been working very hard
3. People being very concerned about publishing their ideas and thought processes in discussion areas because they believe that sharing incomplete work potentially damages their reputation and that the reviewers might take control of the conversation
4. People not investing the time and energy required to submit assets to a corporate knowledge base, because the people who benefited were too far removed from the contributor and therefore there was no benefit to her

I think all of these concerns were pretty valid ones,  working through them requires the working practice change to be supported by a culture that recognize and rewards the change in working practice.  Often the cultural change that’s required isn’t immediately obvious and that in itself is a cultural issue.  A willingness to take a risk – knowing that your peers and managers are will be there to support you and not stab you in the back. 

Right now as we move to a new world of work with less job security, and a lot more external competition from free agents and BPO providers it’s not difficult for me to see why some people look for evidence of culture change BEFORE they are comfortable with working practice change.

I blogged a little about the steps I see a person going through on their journey to collaborative behavior here and the factors affecting success here.

A long time ago now I read the Mythical Man Month,  and I remember two things from it:

1. On a large activity conceptual integrity is really difficult to achieve and maintain
2. In the sixties IBM seemed to do a better job at managing large development programmes than we do now with all of our computer assistance

I’m often reminded of these two points,  almost every day I see the evidence of an activity that has no conceptual integrity and even when it started with it, most programmes I deal with have lost it completely by the time they have finished.  Joel illustrates the point nicely with this story:

In one of Gerald Weinberg’s books, probably The Secrets of Consulting, there’s the apocryphal story of the giant multinational hamburger chain where some bright MBA figured out that eliminating just three sesame seeds from a sesame-seed bun would be completely unnoticeable by anyone yet would save the company $126,000 per year. So they do it, and time passes, and another bushy-tailed MBA comes along, and does another study, and concludes that removing another five sesame seeds wouldn’t hurt either, and would save even more money, and so on and so forth, every year or two, the new management trainee looking for ways to save money proposes removing a sesame seed or two, until eventually, they’re shipping hamburger buns with exactly three sesame seeds artfully arranged in a triangle, and nobody buys their hamburgers any more.

and goes on to describe how he has been victim of this conceptual integrity drift himself,  although it’s impressive that he realized that it had happened and stopped it,  if this had been an activity run by a project manager and not an owner I bet it would never have been stopped!

This is sort of what happened with our new web design. We’ve been tweaking it and polishing it and changing things carefully, and the firm we hired to design it has been taking us step-by-step through information architecture, site maps, wireframes, initial designs, and several rounds of design. All with a carefully-designed process to get our buy-in at every step along the way. And so far every step I thought the design was converging and we’d get a nice web design out of it.

And then I came back after a week on the road, took one look at it, and thought, oh crap. We can’t go public with that.

So as I was saying – I’m also often reminded about the fact that we seem to have forgotten how to run programmes (and maybe projects as well),  I partly blame computers – today’s projects seem to be way too much about sitting in from of a laptop producing plans, estimates, registers, and deliverables and not enough about objectives, people, progress, discussion, review and quality. 

Joel has written a great book,  that has some useful insights into these and many other issues.

I have been worrying for a long time about how to improve the benefits delivery from investments in desktop, office and collaborative systems and it’s always bothered me how little attention Microsoft has invested in the problem until now!  They have come up with a tool called the Enterprise Learning Framework, which follows the lifecycle shown on the right.

It’s a simple idea – basically it exposes a whole load of existing material on the Microsoft web site through a simple interface that allows a communications team to identify appropriate content for different audiences at different phases of a project.

The sample below shows a few of the topics that are recommended for “influential knowledge workers” to review 1 month prior to deployment.  It’s a great idea much more approachable than previous attempts.  However as I reviewed the content I couldn’t help but feel that it talked as much about potential issues as it did about business benefits.  That may be commendable (Microsoft being honest) but it’s a bit of a worry! 

By way of contrast I watched this demo of Zoho Notebook and was blown away by the capabilities of this free of charge and legacy free product!

I just read a great post that describes some of the challenges that face project managers.  The basic premise is that it’s almost impossible to control a project because there are just too many people making too many decisions, but don’t give up hope the article provides a coping strategy. 

The analogy used is trying to pull a stage coach with chickens – really great.  Here’s an extract, but please read the whole thing!

The reason project managers can’t manage projects is because projects are unmanageable. The project manager’s responsibilities, as written, describe a fool’s mission. Provably unachievable.
The few who succeed resolve this eternal dilemma by more fully acknowledging it. They accept that, while their project is unmanageable, it might be capable of controlling itself. Not, however, by management command and pseudo control, but through conversation. I believe that most every project is capable of learning how to control itself, and that every element, every contributor, has something to provide to that conversation. Even, especially, the chickens.

The project managers who can’t create successful results don’t acknowledge that their projects are unmanageable. This acknowledgement could take them out of the driver’s seat and open the possibility for surprising, even delightful results. The alternative seems to be a stagecoach that eternally intends to, but rarely actually does, arrive on time, on budget, and on spec.

I have just discovered the chief happiness officer blog, which focused on happiness at work and I think it’s great.  Just this morning I was talking to Graham on the phone while out walking (I had nothing better to do, Graham was late for a meeting!) and I was saying how I dislike it when a company says it is in business to make a profit.  I much prefer to think of a company seeing its role as:

Providing fulfilling employment to it’s employees and providing great services to it’s customers whilst making a profit.

Framed like this the company can rethink it’s objectives and derive shareholder value as a side effect of having happy employees and satisfied customers, which I think (maybe unrealistically) is a much healthier way to run a company.

Anyway back to the blog,  the author is in the process of writing a book and is blogging ideas along the way, which seems a great process and one that’s increasingly popular.  As a taster here are some of the recent posts, followed by my comments:

Dealing with uncertainty at work, very important and useful advise in today’s climate.  As a team leader I have been in this situation several times and this is good advise.

Ask a co-worker for advice, a few years I did some research into who people like to ask for advise and way out in front was co-workers.  This was in an IT environment and it’s interesting that help desks were way down on the list.  We formalized this by creating a well supported super user role and it worked very well.

Why job descriptions are useless, very perceptive – when was the last time you looked at yours, the post doesn’t just trash job descriptions through, it describes some good alternatives.

Secret salaries vs. open, most people seem to prefer secret salaries, I worked in a department once with voluntary open salaries – almost everyone decided to declare them and we found it worked very well.

For more on my own thoughts on happiness check out this list of posts

The Creating passionate users blog has a great post on the need to challenge assumptions, so many times I come across assumptions that everyone knows are invalid, but are used because people assume they isolate a project from risk.  Of course all they really do is defer the risk.  Personally I think many assumptions should really be restarted as either issues or risks, that way they are constantly being reviewed by the project team.

Collaboration is a key competency for today’s enterprises and yet despite the fact that the Internet is awash with a myriad of different collaboration solutions many teams still struggle to be effective and most projects continue to fail by at least one metric.  

 Many people assume that collaboration comes naturally – provide people with a tool and off they go, unfortunately it’s rarely that easy. Despite the fact that hundreds of books have been written about how to help teams collaborate and how to successfully manage projects, many team leaders lack a simple framework to help them assess the scale and nature of the collaboration challenges that their teams face. Once the challenge is understood teams need practical guidance on where to focus appropriate process and technology improvements.

One approach is to look inwards at the team and the complexity of the task to assess the level of challenge according to four categories (see fig 1).  The first and probably the most important, is the degree of – common ground – shared by team members, teams with a lot of common ground collaborate more naturally together and common ground becomes increasingly important as complexity increases. 

Where you set the dials for complexity and common ground will dictate the relative importance of technology and process readiness. Understanding nature of complexity and the areas where common ground is lacking (the focus of this article) will help you to home-in on the types of technology and process tools that you need to make your team a success (a future article).

The application of this approach is best illustrated by an example; in this case a typical corporate strategy team which is undertaking a regular yearly review cycle. Their review is not particularly urgent, but is complex (see fig 2) because of the interdependence of different tasks, the need to innovate to stay competitive, the number of decisions still to be taken and the need for different stakeholders to negotiate.

The team lacks common ground (see fig 3) in quite a few areas but the fact that they don’t all know each other, will be working virtually across multiple time zones and will need to work both on and offline will be a particular challenge to them given the complexity of their objective.

Initially the team should focus on building the relationship and trust between team members, probably push for a kick off using a professional video conferencing session and concentrate on well facilitated audio conferences while the team members get to know each other. Common access to information will be very important, so the team need to ensure they use an information sharing/discussion system that is available to everyone, is asynchronous and works well off-line, these characteristics are essential and can be achieved even with disciplined use of email and conference calls.

If the team wants to push the boundaries they should consider a web hosted team room with off-line support and also routinely recording their meetings; this will make it easier to create focus, manage information, engage new team members and involve specialist contributors.

Longer term the team members should consider Instant Messaging and Blogs, as these will allow members of the team to get to know each other much better, help them understand each other’s challenges and perspectives and extend the strategy review process throughout the year. 

A refinement to this simple framework is to consider how the needs of the team will evolve over a projects lifecycle, teams need different processes and tools during the storming and forming phase than during the performing stage for example.

I have long held the belief that successful collaboration is not so much about getting fancy technology and much more about process, culture and careful deployment and use of the technologies you do have.  I was therefore pleased to see the results of a survey on collaboration that S. Ann Earon reported on Collaboration Loop, the questions related to audio conferencing, web conferencing and video conferencing.  What’s interesting is that she reports:

While their responses sound logical and intuitive, when further study was done to determine how well their recommendations were put into practice, it was sad to note that many forget the obvious.

This my experience as well,  unfortunately its all too common for project success criteria to focus mainly on successful deployment of technologies and not on successful adoption of those technologies in the medium to long term, this tends to drive a lot of poor decisions which are definitely not the fault of the project team,  but need to be layed at the door of those who design the projects in the first place.  It’s useful to look at the responses in more detail:

Audioconferencing
•    Make it easy to use
•    Quantify cost savings
•    Better describe internal PBX capabilities
•    Provide training & case study experiences
•    Purchase good quality equipment
•    Trial usage, create awareness
•    Adopt self service reservationless model
•    Promote, promote, promote
Webconferencing
•    Do a business case and promote it
•    Use it and see how it works
•    Remember that not everyone is web friendly
•    Provide training & case study experiences
•    Advertise and don’t restrict use
•    Explore all products & standardize on one
•    Make it easy to use
Videoconferencing
•    Make it easy to use
•    Provide open house demonstrations
•    Quantify cost savings
•    Provide training
•    Provide a user competency test
•    Pick up charges under general overhead to promote usage
•    Get senior management endorsement
•    Make it part of the corporate culture that everyone be trained & required to use the technology
•    Promote, promote, promote
•    Hire a consultant

Rod Boothby has an interesting article describing some the the real business applications of blogs.  He chose managing projects in this example and I am a big supporter of this.  I have spent a lot of time observing projects and programmes failing and think that blogs can play a really important role in fixing these broken programmes.  I wrote about my ideas on how blogs would help a couple of years ago – so long ago that the term blog was hardly known.  The essential insight is that project management is more about the people than it is about the process, and blogs are a great way to facilitate the necessary team dynamics and cross team dynamics that’s so essential to success.

We can sometimes get carried away by the idea that the solution to all of our problems is team work, we draw ever more people onto our conference calls, send our emails to bigger circulation lists and try an enlist a diverse group of people on every project to increase innovation.  Stop a minute does this always make sense, sometimes we just need to get the job done!

Taking a lesson from sport, there are “track and field teams” and their are “basketball teams”.  Sometimes we should think more like track and field.  There is a great article on this over on Ezine which is worth checking out, but here are some of the examples that I recall when I needed to step back and ask myself what sort of team I wanted:

• The really complex problem;  to solve this I needed to put two people together in a room, and provide them all the support they needed, but otherwise just keep everyone out of their way.  For this problem focus was key
• Get a fairly simple project delivered to time and budget;  get a team together who had done it before, who new each other well and manage them lightly.  For this problem innovation was not a priority, so it was better to have a small team, who new their stuff and worked easily together.  There was no productive friction to create innovation, but also no friction to slow them down
• Get a very complex project concept clear; to solve this I needed one person to get their head around the concept, and describe it, to help them they needed plenty of opportunity for discussion and review,  but it was their concept in the end and so it had integrity