Thursday, March 26, 2015

Taking Advantage of Opportunities

Our Enterprise SWAT Team Lead has started an Innovation Forum within our division.

During one of the forums, our HR Client Partner at the time asked about ways we can create a training page for our Division.

This has been on my mind since the inception of Ecosystem 1.0.

Opportunity knocks....

As we discussed in the previous post, just because we are busy planning doesn't mean the world stands still.

The SWAT Team Lead, the HR Client Partner and I (with the blessing of the Deputy Muck)  spent a month putting together a training portal through our SharePoint site.

Beyond providing a page that combines all of the training resources available to our division, we are also using this as a prototype for a University-wide training portal.  This is also a way for us to rapidly prototype this idea within SharePoint.  See what works and what doesn't.

A few notes:
  • We opened this to view-only for the entire organization.
    • We will likely isolate some permissions for things that are Division-only, but this is a start 
  • Edit permissions are available to the Division.  We are going on the assumption of trust.
  • We are currently using documents and links to the documents as the structure for the curriculum.  Depending on how the interfaces with other groups go, this might change to the Wiki features or a SharePoint add-on
  • There is currently no tracking or reporting attached to any of this outside of whatever is native to SharePoint.  This means, no completion records.  Again, this might change if the organization determines that it is a requirement.  Right now, it's not on the priority list.  Specifically reportable items are accessed through the LMS.

The 7 minute video below provides a walkthrough of the portal.

Hope this helps. Comments welcome.


Tuesday, March 24, 2015

Principles of the Learning Ecosystem 2.0

Establishing the principles behind the ecosystem was the first step in developing Ecosystem 1.0.

Having these principles available lets me take advantage of opportunities while I attempt to organize everything into the new TOGAF-based architecture.

It's even more important when working in an organization that does not particularly value the act of planning.  You still need to show progress and activity.  Creating a Visio flowchart or a Requirements matrix doesn't really count.

I also need some critical success factors to measure against. 
The world won't stand still while I get my act together.

The principles I am moving forward with:
- As needed performance support
- Continuous professional development

Critical success factors:
- Visibility - can people find the training they need?
- Communication - do people know what they need?
- Tracking - do people know how they are doing?

The Ecosystem is at a point where I need to re-establish relationships with the stakeholder community (there have been a number of changes) and validate whether we want to maintain these particular principles and critical success factors.

Unfortunately, the primary stakeholders and supporters within my division have other priorities right now.  So I am going to move forward with this until the timing and environment improves.  At least this gives me a foundation to work with.

Thursday, March 19, 2015

The Hazards of Planning

- From the Happy Medic.

This is a lot more glamorous than preventing the fire in the first place.

Resistance.  I've seen this over too many years and too many organizations.

People nod their heads and go "Yes - planning is a great idea!  We should have a strategy!  This will help us make better decisions! We can save money! (etc)"

And then they do everything they can to prevent it from happening.

  • Lack of "flexibility" - they can't just up and do what they want once there is a plan in place. Not that this was ever true, but before they could feign ignorance if things don't work out.
  • The need to start saying "no" and set boundaries - a perceived political handicap for those whose entire career success is based on making people (especially higher-ups) "feel good".
  • The fear of uncovering something they don't want uncovered - ANY of these planning / organization / architecture projects run the risk of uncovering some skeletons.
    • Processes not "working" the way they are supposed to (and the resulting "surprise")
    • People using the lack of transparency to serve their own purposes
  • The assumption that "knowledge is power" without understanding that knowledge is more powerful when shared.
    • Even worse - when you are doing this within a culture that often actively punishes sharing.  Even if the touted "values" state otherwise.
  • The activities of planning don't look like actual work.
    • Or worse, too many instances of planning being done in replacement of actual work.  This happens enough times and any organization is going to get a bit cynical.
  • Prevention isn't nearly as glamorous-looking as fire-fighting
    • People love rescuers.  It just sucks when the problem could have been prevented in the first place.
    • It's hard to prove your worth by showing what DIDN'T happen and preventing problems.  It's much easier to show the problems (that manifested) that you DID solve.   Irregardless of whether it was a self-created or preventable problem.
As expected, as soon as real activity towards an architecture started happening, we started seeing resistance.
Right now, the only mitigation strategy I have is to couch my activities in terms of "personal organization."  Small scale, low profile, low resource need. As long as I don't neglect my current primary responsibilities and don't ask for much, I should be OK.  

Worst case scenario - I've learned something as a result of these efforts and have made some valuable changes to my portfolio that I can leverage in the future.

Tuesday, March 17, 2015

TOGAF - The Preliminary Stage in practice

This is the official description of how the Preliminary Stage works.

This is what this phase feels like.....

In my spare time (around projects and the job I am supposed to be doing), I am gathering all the things.

  • The tools and applications we have lying around the shop - both stuff we currently use and stuff that may prove useful later
  • Requirements and stories from 7 years at this organization
  • Outside stories from my peers I may find useful (otherwise known as "best practices")
  • Old project notes
  • Documentation
  • Models
  • Templates
  • Organizational processes we need to work within
    • For service delivery - we use ITIL to organize ourselves
    • For project management - we use PMBOK
    • Contracts processes
    • Procurement processes
    • Intake processes
    • Document it even if you think you won't need it.  Chances are, it will pop up later when you actually threaten to do something.
  • Stakeholders - including how supportive they are and how much they can hurt you.
    • This, you might want to keep very separate from the other documentation.
  • Organizational and environmental drivers
  • Any sacred cows - you DEFINITELY want to identify these. A lot of resistance will pop up from here.
Below is a 3 minute video containing a brief demonstration of how we are starting to organize stuff.
We're using SharePoint.


Thursday, March 12, 2015

TOGAF - The Stages

In TOGAF (The Open Group Architecture Forum) terms - this is the Architectural Development Model (ADM).  Because acronyms are awesome.

Please go to Introduction to the ADM and scroll down to section 5.2.2 for the official explanation and definitions.

These are mine (with apologies to the Open Group)

Preliminary - "What do I have lying around?"  Our organization is here.

Requirements - "What do people want this thing to do".  Lots and lots of levels to this.  I'm in the process of gathering 7 years worth of stories and figuring out how to build a requirements library.

A - Architecture Vision - "What is the high-level architecture and, roughly, how do we want this to evolve?"  Don't worry - the next few phases will nail this down.

B - Business Architecture - Nailing down processes and workflows.  What people actually do.  "How do we want to improve the process?"  Note: This piece SHOULD guide the other architectures.  However, B, C and D are often developed in parallel in practice.

C - Information Systems Architecture - This is all of the tools that you use to perform your processes. 

The model breaks it down even further into Application architecture and Data Architecture.
  • Application architecture focuses on what tools you use. 
  • The Data architecture focuses on what information goes in and out of the applications and where it goes.  Don't neglect the Data architecture. We will need this for reporting later.  You are doing reporting, aren't you?
D - Technology Architecture - This is the servers and network etc. Making friends with your IT department will be key.  You case they move a server your LMS is housed into the cloud.  Because there are other, non-technological ramifications to this action. Like having your user interfaces change on you without warning.  Or if they are having a maintenance outage that suddenly prohibits access to your webinar tool on the day you are presenting to 100 people. So it is good to have at least a rough idea of the technology architecture of your applications.

E - Opportunities and Solutions - This is where we nail down where we want to go.  What we want our future state to look like.

F - Migration Planning - This is where we plan how we are going to get there.  Which projects, what order, who we need to help us, that sort of thing.

G - Implementation Governance - "Git'r Done". Making real.

H - Architecture Change Management - Did we actually get there?  What worked? What didn't? What needs to change in the architecture plan? Where do we want to go next?  For those of us versed in ADDIE - this is the "Evaluation" piece.

As we were warned in our certification training - the first go-around through the cycle is the toughest.  Because all of the stuff is spread out and disorganized and housed in people's heads.

Our organization is using the Learning Ecosystem as a smaller scale way to start hashing through this cycle.  Mostly because I am motivated to actually use this thing I learned - at least for my own needs, even if few other people find it useful. And I think it is "low profile" enough to allow the SWAT team and I to experiment with some things around how this might operate on a larger scale.

Tuesday, March 10, 2015

TOGAF - Defining where the Learning Ecosystem fits in

Please note that this overview is absolutely NOT a replacement for reading the materials or taking a certification course.

Open Group - TOGAF documentation and white papers
An Introduction to TOGAF 9.1 - free pdf

Any comments about TOGAF in this blog are my personal opinion, understanding and application.
I will be linking to appropriate pictures so you can see the source material.
One of the things I like about TOGAF is that it deals in layers - from general to specific.
Here is the general picture of the framework.

Our definitions:

Enterprise Strategic Architecture - all of the IT systems in our organization, including contracted cloud solutions.  Our learning ecosystem is meant to mesh in with this greater Enterprise layer as much as possible. 

From the beginning, one of the key tenants of the ecosystem was to integrate and mesh with the greater environment as much as possible.  Because this is where people spend most of their time working.  At least in my world.  And I'm in higher ed.  My audience doesn't do their day-to-day work in the LMS. At least last I checked.

It is also (in my mind) a win-win for both the educators and IT.  We get the tools we need to do our business quickly, the enterprise maximizes their IT investment, and it is much easier for the IT group to support us.

Segment Architecture (we are here) - for the purpose of the Learning Ecosystem, we are dividing this segment based on function. "Is it used for executing 'learning' stuff?" This level will help define the interconnections between the various applications and tools we use in practice. In this layer, we are looking at start-to-finish workflows, the tools we use to execute those workflows, and how everything inter-relates.  It's the "Program Management" layer - with "Learning Technologies" as the program.

When we are talking about start-to-finish workflows, we are not only talking about the technologies.  We are talking about what people are doing. Handoffs.  Choices and exceptions.  How people actually do their work.  In any of these methodologies driven by technologists, despite the best of intentions by the designers....application tends to be technology focused.  Less messy.  I'm trying not to fall into that trap.

Capability Layer - for the purpose of the Learning Ecosystem, this is the individual piece. For instance, SkillPort LMS would be a Capability layer.  All of the information about SkillPort (direct connections in and out, contracts, workflows, etc) would be within that specific capability.  Another capability layer would be set up for WebEx.  Another for the training portal we are developing using SharePoint.  Another for classroom registration. Another for instructional design....

The capability layers should NOT be limited to technology and the technologies we use.  We're trying to get a clear picture of all of our activities so we can plan a strategy and make decisions. 

The first challenge, for me, is going to be making sure I have all of the capabilities defined in a way that captures everything that should be in the Learning Ecosystem and that makes sense to people.

I'll be sharing these as I get these layers more tightly defined.

Thursday, March 05, 2015

Bringing Structure to the Learning Ecosystem

Over the past year, we've implemented some new technologies that will help bring the Learning Ecosystem to life.

It also expands the number of applications and technologies that are now available to us.
Tools and toys we can use to help create an environment that supports people.

Because of the huge increase in complexity, I figured it was time to find a model that could help organize this and bring some structure to what I was trying to do.

I've been playing with the SWAT team over the past year or so, in between work on a major Unified Communications implementation.

The SWAT team is trying to bring Enterprise Architecture into our organization.  Planning. Configuration Management. Some knowledge around what we actually have and how we can use it. This has become more important as our organization finds itself tightening its belt.

The old "Shiny thing, must buy" approach is (finally) being questioned.
The SWAT team boss, invited me to join his team for TOGAF 9 certification.

TOGAF is an open source enterprise architecture methodology and framework that seems to be increasingly popular.

Some things I liked about this model:
  • The emphasis on the business process
  • It has a well-defined series of steps / phases
  • The open source community has already developed templates and models we can use in each step
  • It accommodates project management and service delivery models in a really tidy way (vs just focusing on one aspect of work life)
  • A number of IT departments are using as educators, we are beginning to speak the same "language" as our IT folks.
  • It is built to solve the problem I have - accommodating a mess of stuff into one organized architecture that I can plan against.
So with shiny new cert in hand (yay me!), I am in the process of restructuring the ecosystem to fit this new model.

Around the regular parts of my job, of course.....
And with the usual limited resources + healthy skepticism of a large portion of my org.
Guerrilla change management...again.