Warning - this is a long post. What follows are images of the slides and our speaker notes from our presentation titled, “Enterprise 2.0 and Observable Work” from the Catalyst 2010 Conference in San Diego. This earlier post also contains a link to the SlideShare presentation.Brian presented the opening through slide 18. Joe took over and presented the case study of the QAD implementation in Suzhou, accentuating the gains realized from reducing project status meetings. Brian closed the presentation with slides 24-27. We did not present the appendix but encouraged the attendees to download the presentation and take a look at the additional information.
The general concept of observable work seemed to resonate with the audience – although we were challenged to apply the concept to highly regulated industries such as finance or healthcare.
The time savings associated with meeting elimination was a hot topic during the Q&A and on Twitter with the #Owork tag. I think it deserves some clarification. Trust me when I say that there is nothing my colleagues hate more than status meetings with their managers.
Joe is talking about 100 hours per week savings – not 100 hours total over the life of the project. If you don’t believe us, ask Joe for clarification on his calculation. This was like a pickup of 2 full time resources through reduction of lengthy status meetings.
This starts with the title slide and notes, where applicable, appear under each slide. We did not read these notes during the big show but they should give you a pretty good idea of what we discussed.
There were no animations or audio/video. Maybe in the next version…
Today we are going to demonstrate the concept of Observable Work, and how we have implemented it within our team at Alcoa Fastening Systems.
So, why are we here, and why should you listen to what we have to say?
After a short background on us and our company, we will begin the discussion of "Observable Work". This is a term that has been around for a few years, and we found that it describes very well how we strive to work.
It has helped to crystallize our thinking on what we are trying to do with collaboration practices and 2.0 technologies.
Instead of trying to define Observable Work, we will list some core principles to show what it is. And I cannot promise that I will not use images of monkeys to do it.
We have one slide on enabling technologies showing some familiar "2.0" technical themes.
Finally, we hope to spend much of our time on real world examples. Joe will present a case study of how we applied these principles and technology to implement an ERP system in Suzhou, China.
We will be happy to take your questions at the end of the talk.
Our primary mission at Alcoa Fastening Systems Information Services is the delivery, operation, and enhancement of enterprise software and related services for thousands of internal customers.
My role is Director of Information Services. Joe manages our North America Aerospace Project Management Office, where he oversees and manages major system implementations and integration efforts across multiple locations.
We have about 80 IS colleagues at 20 operating locations, worldwide, and we also work hand in hand with our Corporate IS organization. It is a large, virtual team
We have the perhaps not unique situation of working for a company that grew by acquisition, leading to a complex hairball of legacy business processes and accompanying IT platforms. We work in a highly matrixed environment.
Most of us have at least two bosses; some of us more - although I don't think any of us have 8 bosses like Peter Gibbons in Office Space. We are a public company, so we have Sarbanes-Oxley to worry about.
On our team, we have a charter to deliver common IT-enabled solutions across dozens of locations, each of which is evaluated by a stand-alone P&L. The people we work for are highly focused on manufacturing and engineering, rather than the black box of IT.
We are always looking for ways to improve ourselves and our team’s performance. We cannot change the world, but there are some things squarely within our control.
We don’t like silos. They prevent work from getting done.
We must be aligned in our matrixed environment, and multiple locations. We cannot accomplish our business objectives if we are not aligned.
Almost nothing is set in stone. We plan, and re-plan, all of the time. Battle plans rarely survive first contact with the enemy.
These guys must really trust each other. In using the term silos I am thinking at all levels of organization - roles within a department, across departments, locations, business units, between companies. As much as I would like to, I don't want to seem naive and say that silos are 'bad' and that they must be smashed. I think that we can try to make them permeable. In fact, I believe that managers have a responsibility to make their own silo as permeable as possible.
The real underpinning of the first four principles is trust. No one is going to feel comfortable working across silos, outside of their normal chain of command and comfort zone, without it. I don't have a formula for that, but it takes time, and you can lose it in an instant.
We are social where required, but it's not something that we dwell on.
The social aspect deserves a little more discussion. A pure focus on Information and Process Flows tends to ignore the social dimension of how we live and work as human beings. Our ability to be effective will suffer greatly if we neglect this.
Being IT guys, and introverts at heart, remembering this is not always easy - but we try to get a little better at it every day – although I don’t think that we will ever groom each other like the chimps in that slide.
We seek simple solutions to business problems, fighting a tendency to over engineer just because it is possible.
What we do and how we work is highly interdependent with the rest of our organization. Finding and leveraging these links adds value and relevance. Surfacing these links and finding the relevancy of each individual action makes work more rewarding for everyone involved.
The last slide about status is subtle, but important. We believe that working this way can reduce overhead and administration, allowing everyone to focus on doing work, not reporting on it. Joe will touch on that in his case study.
The underlying technologies of Enterprise 2.0 are key to implementing observable work practices.
Hypertext, a solid security model, advanced search, linking, aggregation, activity streams, classic wiki/blogging features are all important and we use them heavily.
Legacy productivity tools are an important part of any successful productivity/collaboration platform - we are thinking particularly about email as a universal notification and editing tool because 100% of our users are comfortable with it.
I would like to transition into some real world examples, and show you what this looks like in practice. My company is very safety conscious. I hope that our safety managers will appreciate the fact that this kid is wearing all of his personal protective equipment.
This example is a test scenario for a customer return process, part of a major system upgrade. The business analyst who created this article had some simple goals.
- describe the business process that needs to be tested within the software
- get feedback and approval from colleagues in Customer Service, Quality, and Finance
Notice the paragraph-level comments by Customer Service and Quality - there is a threaded discussion in the middle of this test scenario.
At the bottom of the article, there are "I approve" comments from everyone time and date stamped, with links back to their profiles.
A key takeaway is that we invent lightweight processes as required using text, tags, and comments.
We did not trade emails to collaborate and we did not use a structured workflow or business process management system to accomplish the approvals.
We strive to create and share all of our work products just like this – for projects, strategy, compliance, documentation, budget, etc.
Approximately 30,000 of my colleagues can read that hypertext article if they need to see it, and 2,500 can comment on it. If we need to show them, or pull them in for collaboration, we can.
Over to Joe.
(Joe Crumpler presented his case study on Suzhou. It went very well – here are his notes)
I’m a project manager. I’ve done it most my professional life. As a project manager, I’ve been on a continual quest for tools. I’ve used almost everything imaginable, and with varying degrees of success. A few years ago I started thinking about how to use a wiki to manage some of the complex communication processes common to technical projects. We use TeamPage. I’ve used it on a few other projects, but for the project in China, I pushed our use forward in an effort to drive more direct benefits to the project.
We did a midmarket ERP implementation of QAD to replace a failed implementation of another ERP product from a few years in the past. From experience, we knew about the language barrier. We knew about the cultural barriers, we knew about the lack of a systems culture, and most importantly, we knew the turnover rate was astoundingly high. 30% of the people we train today will be working for another company in six months.
Because we knew what to expect, we were prepared. We pushed most of the knowledge to the wiki, but we also pushed the project structure and planning process to the wiki. I used MS Project and Traction TeamPage, and it was a marriage of two diametrically opposed tools, but it worked fine.
The key concept in my effort was “build structure.”
Everything that was in my head became an article. We held nothing back. Simple things like job descriptions, roles, work schedules, travel requirements, all found a home as an article. The more complex stuff, due diligence audits, planning, scope, and the project plan… all of it became content. Each member of the team read and re-read every article. Comment threads started and grew. We linked it all together in too many ways to count. New team members came up to speed in a few hours. Learning what the project was became second nature.
Then we broke the project plan down into milestones and deliverables. Each milestone was described in detail with up and downstream dependencies, responsible parties, due dates, and a definition of what “done” was. This too was linked into the project wiki at every conceivable level. Then we translated it into Mandarin. Well, more accurately, we built it all and translated it all at the same time. It simply grew up around a core concept of building structure and defining everything.
Why do we do this? We build fasteners at AFS, waste is known by the Japanese term muda. On projects, meetings are muda. Meetings suck the life out of your team and bring progress to a halt. The more I define a project in a wiki, the less I time I consume in a meeting. We did not have project status meetings. All that meeting content was in our wiki.
Instead of project status meetings, project resources updated status on wiki articles. As the project manager, I monitored status. My time commitment did not shrink, I still worked a long hard week, but my team spent almost no time in meetings. My obligation was to keep up with the flood of information and provide direction. A daily checkpoint meeting, lasting no more than half an hour, replaced a three times a week four hour (or more) status meeting. The simple act of updating status via comments freed us from the need to meet for status. I picked up at least 80 hours of productive labor each week because of this. It resulted in a 30% labor pickup overall. I’ll never go back to the old way.
Peer pressure is a great motivator. On a project team, fear of exposing yourself to the ridicule and ribbing of your teammates keeps people focused on updating their activities. Small frequent updates telegraph problems. Everyone knows what is going on. Everyone has access to the latest files, information, and planning. The PM does not need to babysit. The PM can focus on removing the obstacles that would prevent the team from achieving its goals.
What was our goal? We went from request to live in seven months. A team of techs from the US supported a travel team of analysts. We accomplished a task that normally requires at least 2x the time and many more resources. We did it on time and under budget. The stars lined up for us on this project, but our map was in Traction.
People ask me, “What did you do differently?”When I start to tell them about our wiki, they lose interest. They want to know what it was I actually did. They want to know my secret. I tell them about our daily status meetings. We talked each day at 8:30 China time, which was the end of the day in California. I ran a tight meeting. Open issues from previous day’s articles were reviews for open items. Open items were tagged with as “to do”. Open unresolved issues were updated in the meeting if needed. A new article was created and linked to the previous day’s article. New issues were captured. Someone was assigned an action item. Things got done. Rinse and repeat.
I was afraid of losing control, but found the articles a perfect way to catch the incidentals.
The key take away from this was that the, this process cut the team free to work. They saw me from half an hour each day (if you don’t count the bus ride to work). It felt like I lived in their heads because I read every word they wrote. I worked the issues. My team worked without interruption for 8 to 10 hours a day. I had more control, more visibility, and after the project was over, an audit record without precedent. I can’t wait for our internal auditors to take a look at the project.
My customers used the wiki too. All of their training material was linked in. Each article was translated by a stateside team. There was a day or two lag in some cases, but nobody complained. My customers contributed to our discussions, learned about the project, and helped us document our process by approving key milestones and deliverables as comments to articles. My overhead went down, my productivity when up. Like I said in the beginning, I’m a tool user. We’re using this tool in the PMO now and slowing building it up to manage our portfolio of projects. I’m optimistic about the possibilities.
What we tried to demonstrate today was the concept of Observable Work and how we have implemented it on our team. I hope that we have succeeded in that. It is definitely a journey, not a destination.
We do not want to leave you with the impression that we have found the holy grail of productivity and collaboration and the application of social software to work. We have a set of principles and underlying technical solutions that work for us.
Going forward, we want to continue to learn first, and teach second. We are not sure that this approach will scale, but it works ok for us.
As this technology space evolves, it will have implications for us. We can only hope that the principles we have identified can be implemented in any platform, regardless of vendor or underlying technology. Otherwise, we are too busy getting work done to worry too much about it
These are some of the many wonderful thinkers and practitioners out there that helped us directly and indirectly, and whose ideas we have used and remixed.
In particular, I would like to thank Greg Lloyd of Traction Software for introducing me to the concept of Observable Work. I would also like to thank Jim McGee and Rick Ladd for reviewing and commenting on this presentation. Rick is responsible for the monkeys.
Please see Jon Udell's article. As best I can tell, he invented the term Observable Work. There's lots of good stuff here.
From time to time, Joe and I will continue this discussion online in our blog, where we talk about productivity, collaboration, and project management. We would love to see your feedback there.
Thank you for your time. Thanks to my colleagues as well. All of the examples you saw here are just their "Observable Work" in action.
You can connect with us on Twitter or LinkedIn.
You should get a copy of this presentation through participation in the conference. There are a few slides in the appendix with more examples as well as some statistics about our platform and other technical details.