Tag Archives: Work Out Loud

Working Out Loud: The Use Cases

Posted on by

I’ve decided to dig back into my roots of IT Requirements Management practices to contribute to the public conversation and understanding of the concept of Working Out Loud. For more on my personal history contributing to this idea, read here: Working Out Loud: What Happened to Then? We’re at Now, Now!

The below is a flow of an idea of something I’d like to get rolling on, with some help. Certainly not a finished product. And the target benefactor is an individual worker…or someone coaching individual workers about adopting “working out loud” work behaviors into their daily practices.

The Idea:

Capture the “behaviors” of someone that is effective at Working Out Loud into a modular use case format, organized around typical work behaviors and how each of those can be shifted to the “new way” of working instead of how most people in today’s work environment might go about that activity. And organize those use cases / behaviors / activities using John Stepper’s Five Elements of Working Out Loud.

  • Organize it and build it in a process similar to how I used to capture and organize IT system requirements packages.
  • Work Out Loud while defining Working Out Loud 🙂 So what does that really mean? A few things that will be critical to this working:
      1. It’s an ongoing work in progress, not a finished product. But I’m publishing it in progress, not waiting until it’s done.
      2. It’s public. You know I actually started this as in internal blog post for my company only? Bad Bryce, Bad! (Sorry. We have a new puppy in the house…habit.)
      3. Many Will Contribute. That way, it will get better as it goes and hopefully people much smarter than me will contribute to it! As a result, this post will be a living and crowdsourced table of contents that gets updated to reference new use cases / behaviors / activities are developed and shared by myself or others. As a result it must be…
      4. Modular. This is the parent post that will define the patterns and then link to the real meat of the topic. Whether those are blog posts I write for a given use case, or one that someone else decides to contribute within their own respective blog (or elsewhere).
      5. Open to Suggestions. These rules. The structure of the use cases. The use cases listed below. They are all open to improvement and change. Let me have it. Let’s make it better together.
      6. This Should be a Wiki. I know. I know. But I didn’t have a good one set up in the public domain to start from. And I didn’t want to lose the concept before my son’s basketball game today 🙂 I can see this evolving and moving to something more like a wiki format that takes me out of the role of “curator”. Once I get more time I’ll shift it to some place where we can all work on it in that form or fashion.

Writing a Use Case:

Each detailed use case should contain the following:

  • Work Activity Description
  • The typical / default behavior of today’s worker
  • The “Working Out Loud” behavior of tomorrow’s worker
  • Benefits of shifting the behavior
  • Risk Considerations / Mitigation
  • Real Life Stories / Examples of this “new” behavior in action. What was the outcome?

Use this definition created by John Stepper and captured on the Working Out Loud wikipedia page as a guide to brainstorming the application of the behavior to daily work activities:

“Working Out Loud is working in an open, generous, connected way so you can build a purposeful network, become more effective, and access more opportunities.”

The Use Cases:

Each use case is meant to represent a typical daily work activity.

If you have some that you think I’ve missed that you’d like added, please comment or contact me directly and I can get them added. This is a work in progress and merely a suggested starting point, including the topic groupings. As we identify and write new use cases, we can regroup and come back here and link to each individual one. Or eventually move this structure into a more wiki like structure in the not too distant future:

  1. Making Your Work Visible (Observable Work / In The Flow)
    1. Seeking an answer to a question / problem
    2. Answering a question directed to you about your area of expertise
    3. Answering a question directed to you unrelated to your area of expertise
    4. Creating a presentation for a team / committee / department / town hall
    5. Collecting team input prior to starting a work deliverable
    6. Creating content for a work deliverable (WIP)
    7. Collecting feedback on an in-progress work deliverable
    8. Creating content for a work deliverable (Finished Product)
  2. Making Your Work Visible (Narrating Your Work / Above The Flow)
    1. Writing your objectives
    2. Writing a project status update to management / customers
    3. Taking meeting notes
    4. Capturing brainstormed ideas about a project / process / opportunity
    5. Sharing progress / status on an assigned task
  3. Making Work Better / Creating Shared Value by Default / Leading With Generosity
    1. Achieving awareness of work outside your direct responsibilities
    2. Coaching people outside of your team / department
    3. Discovering external resources about your role / area of expertise
    4. Leading / Participating in corporate responsibility projects
    5. Contributing to the Corporate Conversation (Engagement, Activities, Facilities, Corporate Policies, etc.)
  4. Building a Social Network / Making It All Purposeful
    1. Forming and collecting a community of experts on a topic
    2. Connecting with fellow employees on personal interests

*Initial groupings could change or break apart. This is just a first shot at it. And we may find some use cases fit within multiple top-level categories.

I’ve spent as much time as I can spare on this this morning…but as I promised…this is a work in progress. And I was hoping to have completed at least one real use case example. But that will have to come in another day or two.

More to come! Comments for improvement welcome. And a format / structure more suitable to content crowdsourcing as well.

Working Out Loud: What Happened to Then? We’re at Now, Now!

Posted on by

What Happened to Then? There’s a story about how I ended up in my enterprise role of change agent for Enterprise 2.0 / Social Business / Social Collaboration…whatever you want to call it.

For the first 10 years of my career at Lilly, I worked on various IT projects within the Regulatory department. And the role I typically performed best was known as “Business Integrator” or “Business Consultant.” And the biggest responsibility of that role for each and every project was to collect, synthesize and document the requirements of the ultimate business customers. We wrote these for four primary purposes:

        1. To reflect back to the business representatives that you understood what they were telling you…and had captured it completely and accurately.
        2. Requirements were the “contract” for defining how the ultimate capabilities would perform once delivered.
        3. They were intended to be THE source for the IT implementation team to scope, design, develop and test the deliverables against business expectations. Or locate and evaluate a third-party software vendor solution to get as close to the requirements as possible.
        4. And they were continually updated as a work in progress representation of the software development process as experimentation and iteration influenced changes to those requirements.

Over the years of doing this over and over, I developed my own art to being a “requirements manager,” particularly for fairly large IT systems, and eventually for projects that were evaluating and implementing third-party software packages. My “go to” method of organizing requirements into manageable chunks was using use cases.

To make a short story long, my methods began to draw some attention across other departments within the IT organization. People from other programs were wanting to my ideas and mentoring to replicate what we had done for their large scale IT programs. They wanted their people to learn what I was doing and how I was doing it. I was swamped.

We Just Passed Then! This was taking place in about 2007 / 2008, coinciding nicely with the time that our IT organization had just implemented a new “large scale enterprise collaboration suite.” As I explored what the new collaboration suite could do, I saw something that could help me better scale my knowledge sharing. Profiles, blogs and wiki libraries…oh my! It just clicked…

So I started blogging as I worked on projects. My thought processes, my tips and tricks, sources that I used for inspiration. I started using wiki pages to capture and get feedback on requirements instead of monolithic Word files. And occasionally instead of replying to an email request for someone, I would write a blog post and reply to that person with a link to my new blog post. And I set the security on all of that to be wide open across the entire company so others could see it and learn from it. I helped organize a “community” of business consultants that met once a month, brought in teams to share their stories and regularly presented to the members myself. But I also taught them how to follow along with and interact with my blog to keep the learning going between the meetings.

Then more and more requests for my time started coming in. New opportunities to consult for and lead larger IT-wide initiatives. Getting to present in front of the entire IT org at town halls or in senior leader committee meetings about updating our long standing software development lifecycle standards and implementing new requirements management training programs. Phone calls and e-mails and blog comments from people I’d never met asking me for help or thanking me for what I had shared. People asking me how to set up their blogs and wikis to look and operate like what I had done with mine.

I realized that there was a new way to work…and my mission was no longer to help my IT peers with requirements management. It was to be a Change Agent that would help all of my Lilly peers learn how to Work Out Loud on any topic of expertise. It had amplified my own reach and productivity, why couldn’t it do that for everyone?

When Will Then Be Now? By the middle of 2009, I had accepted a new role to take availability and adoption of our enterprise social capabilities to another level and begin teaching people all over the company the behaviors of “social collaboration”, aka Working Out Loud. And it’s about that time the practice starting becoming clearer to me and led to blog posts such as this one: When Will We Work Out Loud? Soon! 

Soon! I’m writing this story because this morning I had an idea. I’m going back to my requirements management roots (use cases) to help further the understanding and practice of Work Out Loud behaviors, in concert with and to complement the amazing work that John Stepper has shared of late: The 5 Elements of Working Out Loud.

I’m going to dig deep into my old methods of requirements use case modularization and topic hierarchy to capture the key behaviors of someone that works out loud effectively, including what one would need to shift from traditional behaviors to these new behaviors. And I’m going to build it in the true nature of Working Out Loud.

We’re At Now, Now! Click here to see my next blog post putting that idea into action…and to contribute and participate if you wish!