Thursday, April 28, 2016

Breaking Down Themes - Mapping to Business Benefits

To help us decide what to tackle first, we took a look at the potential business benefits of improved communications.

  • Reduced "Time to Market"
  • Reduced response time to clients and each other
  • Consistent messaging across the division
  • Increased awareness of our services

The next question we asked - what activities would help us achieve these benefits?

Our brainstorms went all over the place.
Everything was written down.
We then measured those ideas against whether that idea would get us closer to those business benefits.

Ultimately, we wound up focusing on Business Writing for our first cycle.

1) Business writing feels more "tangible".  Since our audience is mostly made up of engineers and technical folks - we felt that it would be easier for them to see progress.

2) We felt (right or wrong) that business writing allowed for a level of "detachment" in this early going that "verbal" and "non-verbal" communication wouldn't.  Changing "behavior" can be a charged subject - especially when the person isn't necessarily doing anything "wrong".  Writing, at least, has a visible product.  Our engineers like having something to show for their efforts.

3) We also felt that a focus on business writing would move us more quickly towards the benefits of consistent messaging and increased awareness.

4) Finally, the hope was to take some of the pressure off of our communications specialist - who has been doing the job of 2 people for too long.

In the next post - I'll talk about what we actually did....


Tuesday, April 26, 2016

Breaking Down Themes - What Does Success Look Like?

The next meeting - the group stared at the themes we chose:
  • Communications
  • Collaboration
  • Consultancy
  • Consumerization / Brokerage
  • Accountability
  • Adaptability / Agility
  • Technical
Ultimately, we decided to tackle Communications first.
To us, Communications (and effective communications skills) is the core that drives the other themes we identified.

--------------------------------
To help us decide what we wanted to DO about Communications - we first asked ourselves what the Business Benefits of better communications would be.

We came up with
  • Reduced "Time to Market"
  • Reduced response time to clients and each other
  • Consistent messaging across the division
  • Increased awareness of our services
  • Improved identification of "the real issue" - needs clarification

This gave us both an argument, and potential metrics to measure our programs against.
By the way, you noticed that "Improved identification of 'the real issue' " has Needs Clarification next to it.  That's because we weren't able to figure out how we could identify that behavior or whether we were actually improving identification of 'the real issue'.  We may circle back to that later....
----------------------
Next, we asked what observable behaviors we expected to see as a result of "improved communications"

We came up with
  • Are the right people involved?
    • Know a clear objective
    • Know their clear role
  • Roadblock identification
  • Are you doing what you agreed to do when you agreed to do it?
  • Do we know where to find information?
    • What is coming?
    • Impact on us and our team?

We decided these observable behaviors worked for both Communications AND Collaboration.
----------------------

The answers to both of these questions serve as our guides for measuring success.
Don't worry - I'll talk about how effective (or not) we have been in a future post.

Thursday, April 21, 2016

The Fractal Gets Tested

Among other activities this past year, I have found myself leading a training subcommittee.

Typically, employee professional development has been the responsibility of the individual managers.
With the push for us to spend our money smarter, the division decided to try a more coordinated approach.

Rather than treating this as a typical training subcommittee, where we sit and debate on what courses belong in the curriculum for the department, we decided to as some harder questions.

  • What needs to happen to make the department more responsive to change?
  • What behaviors do we want to see (and not see) in our environment?
  • What topics do we want to pursue as areas of emphasis and why?
  • What environmental supports need to be available for any training intervention we decide to pursue?
  • How will we know whether anything we do is working?  

I've been very fortunate that with this committee, I found 4 people willing to run with me.
-------------------
Day 1 - we decided to tackle the direction we wanted to march in.

Armed with the University's and Division's Strategic Plans (which hadn't been published quite yet), 2 whiteboards and some pens, we did a bit of brain dumping and surfaced the following environmental trends:
  • Globalization 
    • There is a push at the University to expand its international presence.  The school I work at is also known for its International Affairs program, so there's that.
  • Nomadic Workforce
    • There was a telework initiative a few years ago that moved a number of us to remote worker status for at least a couple of days a week.  Got the staff off of the expensive real-estate and allowed the University to reduce its leased footprint in the city.
    • We are on two campuses - and many of us travel regularly between the two campuses.  So even those who argue against telework have difficulty arguing for everything being "in person" these days. There is usually at least 1 person either working remotely or on the other campus.  Everyone is too mobile.  Come to think of it - the ONLY meetings I have been in during the past year where everyone was physically in the same location has been staff meetings - called by my boss way in advance OR when we all happen to be in the same place at the same time.
  • Engagement through technology
    • Um...we're the IT Department.  Of COURSE there will be technology.
 From here, we then defined some themes that supported these trends.

After much scribbling and conversation - the team came up with the following list.
  • Communications
  • Collaboration
  • Consultancy
  • Consumerization / Brokerage
  • Accountability
  • Adaptability / Agility
  • Technical
Notice how the vast majority of the themes are soft-skills heavy.

Our ability to keep up with the technical skills we needed wasn't questioned.  Looking at the training plans for the division, most teams focused on technical expertise.  However, the team felt that soft-skills will be the differentiator in how effective we can be as the environment evolves - for the Division, as well as for individuals.

And as I do my own research and observation among my friends in the wider world - I am seeing dramatic changes that necessitate being much more "people-friendly".  Organizations are looking for people they want to work with, not just people with the requisite technical chops.  The least I can do is help my colleagues be better prepared for this "brave new world."

Tuesday, April 19, 2016

Phase G - Executing Your Evil Plan





During the Implementation / Execution phase of your architecture, you need to keep track of two things:
  • The projects you started to execute your architecture.
  • The OTHER projects that will impact your architecture.
----------------------------
Tracking the projects you started is the easier part.  At least - I hope it is.
And that you have systems in place to track those projects as they move through the project lifecycle.

The harder part is figuring out what OTHER projects you need to keep track of that might impact your architecture.

Then - getting access to that information so you can, actually, keep track.
Particularly if you are not involved in that project in any substantive way.

This is where being either IN the IT department, or at least really tight with them helps.

Barring that - see whether you can get the IT project report every month and/or access to the  client portal for your IT department's project management system (if one exists).
--------------------------
Types of projects to look for:

Video Conferencing Systems -  Recent updates provide for integrating whatever web meeting tool you are using with the video conferencing system.

Phones -  Why the phones?  Because many of these projects often have VoIP soft phone clients or Unified Communications functionality.  ie - people will have phones on their computers and you can use them as a tool to deliver training.

These clients also have video functionality in the phones.  The phones themselves do too. 
That video functionality opens up lots of instructional design possibilities.

Phone system projects also have the potential for impacting your conference bridges - so if your team is highly reliant on conference bridges, you will want to keep an eye on that. 

You may want to seriously consider better leveraging the (often) free Voice over IP functionality within your webmeeting tool anyway.  How many teleconferences have you been in where the person on the phone says something like "now, for those of you on the phone, if you could see the screen...."
I'm on a personal quest to eliminate that experience in my world.

Identity Management or Access Management - Not all of these projects require a lot of attention.  What you are looking for are projects that change how people are grouped. Are they adding a group type (such as people who have access to x system?)  Are they re-defining job categories? Is there a change to how they update people? Those groups will impact how you can assign people to courses.

You also want to keep an eye out for any Single Sign-on project or update.  These projects potentially break access to your LMS and other systems if you have any form of automated access and user creation on your solution. 

Related - keep an eye on the HRIS (Human Resources Information System) space as well, if you are not already part of the HR Department or the area within which this function is housed.  These are the folks who can mess with how people are defined and have a huge impact on your assignment groups. 

Your learning ecosystem is (hopefully) well integrated into that space anyway. 

Mobile Device Management - If your organization does a lot of work with mobile apps (create their own, leverage apps from vendors), keep an eye on any Mobile Device Management projects.  Especially if you have a program where your users are accessing your materials or learning systems using company-provided (or approved, for organizations with BYOD policies).  Implementations or updates to Mobile Device Management programs could potentially keep your users from accessing your stuff.

Document / File / Multimedia Content Management - Implementations and updates to this area impact where you stash your stuff, how much stuff you can stash, what type of stuff you can stash and people's ability to access your stuff.

Related - you will also want to keep an eye on any Data Security Policy changes. Both from the IT department and from your Compliance / Legal departments.  Any changes here may force re-writes / updates to your existing materials OR change where you are hosting and/or accessing those materials.

Web Services - If your team leverages your organizations web tools, you should keep an eye on updates in this space. You are likely keeping an eye on whatever is happening with browsers anyway if your organization is highly reliant on eLearning for delivery.  The systems I'm considering here are enterprise level web content management systems and changes to those systems (or even wholesale replacements).  The team will likely perform outreach if you have one of their web services as a central part of your ecosystem. 

---------------------
As you get more familiar with the activities of your IT Department and how your ecosystem fits into the greater enterprise ecosystem, you may find yourself keeping an eye on other areas - such as Business Intelligence.

The key here is to look for anything that could potentially impact your systems and plans.
 

Thursday, April 14, 2016

Prioritizing Sleep


I write this at 2:30am.

My friends and co-workers know that I am an unapologetic morning person.
The running joke is "Wendy turns into a pumpkin as soon as the sun sets".
My friends (and boss - who seems to get the brunt of my crazy early morning emails) are very understanding.
 ---------------------------
Morning insomnia has been an issue for most of my adult life. 
The past 5 years, it's gotten better.
I'm down to only a couple of mornings per week where I'm waking at ungodly hours and not getting at least 6 hours per night.

I've learned that I don't function terribly well with less than 6 hours a night. 
I'm OK in the morning (to me, others may argue with that assessment), but by 1pm - the brain decides it doesn't want to work anymore, I get even crankier, and I want sugar (preferably in licorice, mint, gummy bear or ice cream form).

A helpful pattern I picked up during the Masters Thesis push is "sleep when you are stuck."

Tough to do at work (most workplaces frown on napping) - but when I am in the throes of learning something really mentally intensive, I find myself sleeping a lot more.

Knowing these patterns, I went into the PMP boot camp week with the plan to prioritize sleep during the week. Above all else.

The plan:
  • Schedule the test for your strongest time of day.  Since mine is early morning - I scheduled the 7:30am exam. 
    • Last year, I took the TOGAF in the afternoon on a work day 3 days after the class. Taking a test is stressful enough without walking in already frazzled from work and tired because you are trying to do this when the circadian rhythms want you to take a nap. I had zero intention of repeating that experience.
  • Go to bed as close to my normal time as possible.  
    • I knew my brain was going to be completely fried by the end of each day, and I don't work so well in the evening. I figured much more studying after class was likely going to be a case of diminishing returns.
  • Get to the hotel ballroom early. Leaving before 6am helped me beat DC traffic. That gave me time to do my homework while the brain was still fresh.  And the behavior was closer to what I was actually going to do on test day.
  • Don't sweat if you don't get your homework "done."  Thankfully, I found the extra time in the hotel ballroom in the morning was enough time to get the homework complete.
I was pleased to find that my plan worked brilliantly. Less stress, better rested, felt sharper than I had expected.
------------------
Meanwhile, I was amazed at the number of my classmates who prided themselves on not sleeping.
"I was up until 3am studying!"
"Yeah - well I was up until 4am, then came here at 6!"
"So Wendy, what did you do?"
Uh...went to bed at my normal time and came here early this morning.

They would usually go back to one-upping each other on their lack of sleep and busyness and how "hard" they were studying.  Much like work.

There is so much research on how lack of sleep impacts brain function.
And from experience, I knew that if I slept - it would allow me to process the information in a way that I could more easily retrieve it when I needed it.

Why are we still in the cult of sleeplessness and busy and "hard"?
How well is that really working? 

I would posit "not well"- if finding the director of a Fortune 500 company crying in the bathroom on day 3 - sleep deprived, frustrated, and scared that she wasn't going to pass the certification exam because she could not see ANY improvement in her practice tests - is any indication.
----------------------
I've been there.
Sleepless, busy and working "hard" (vs smart) doesn't work for me.
As much as my partner loves to point out my love of "the struggle".

My lack of sleep is not by choice and not a point of pride.
Yes, I get a lot of work done early in the morning.
Yes, I occasionally send emails at ungodly hours.

But for me, this is making the best of an unfortunate situation.

My current boss is smart enough to chide me for it (vs reward me for it).

I'm getting better.
It is a work in progress.
I'm going back to bed.

Tuesday, April 12, 2016

Phase F - Creating the Final Plan

It's been awhile since we talked about TOGAF and learning architecture.
----------------------------
All that project management talk recently had a purpose.  
Phase F - Migration Planning in TOGAF is when you finalize your plans.

All of that preliminary planning - the calculation of risk, the cost estimates for various options, and time estimates go into the decisions around your final architecture and migration plans.

Don't forget the environment.  Even if all of the risk, cost and time estimates argue for one direction - you may still be forced to go in an alternate direction because....emotions. Mostly fear. Especially when you are arguing to consolidate and get rid of things.  Because - without those things...what are they going to do? Have you inadvertently diminished that stakeholder's importance?  Reduced his/her power?  Scary stuff.

At the end of all of this will be a final target architecture for your Learning Ecosystem. We hope.
----------------------
Phase F has a few steps.
  • Making sure your plans align with any management frameworks within the organization.
    • Are you (still) aligned with your organization's business strategy and desired outcomes?  This should be a consideration throughout ALL of these processes.  More easily said than done at times - especially when there is misalignment between what the organization says it wants and what is actually happening.
    • Are you aligned with the Enterprise Architecture for your organization?  Real important if you are expecting IT support. No alignment = no help when you get into trouble.
    • Are you aligned with the Portfolio, Program and Project Management frameworks? This will help you get this stuff done.
    • Are you aligned with Operations?  This will help you run the thing when it is finished.
    • I am also going to add - are you aligned with DevOps (development to operations, or the bridge between when something completes as a project and when it becomes something you operate)?  If your organization HAS DevOps.  
      • I have found over the years that most implementations struggle and/or fail because project teams are so focused on finishing the product that they neglect to consider pesky things like training and support until the last minute (usually after they have pushed training off and they are 1 week out from go-live and realize that real people actually have to use the thing.  Then the support teams find out about it after the first angry end user calls....)
  • Assign a business value to each work package.
    • I'll go into business value in a later post, but fundamentally you are looking at:
      • Performance evaluation criteria (ie - what are the uptime / downtime expectations, speed between screens, etc)
      • Return on investment criteria (you should have some of this from your cost numbers crunching)
      • Business value
      • Critical success factors (this should have been defined in your Architecture Vision)
      • Measure of effectiveness (is it doing what you think it should do?)
      • Strategic fit (with the greater business and with the target architecture)
  • Refine your estimates for resource requirements, project timing and delivery vehicles
    • This is essentially the planning estimates for each project you will need to perform as you move from your baseline to your target architecture.
    • As you initiate each project, these planning estimates go into the Initiating and Planning process for that project.
  • Confirm your architecture roadmap and update your architecture definition document
    • Include any transition architecture and how long you anticipate that transition architecture to be in place.
  • Generate the implementation and migration plan.
    • Include the following:
      • All projects, activities and dependencies - internal and external to your architecture.  Basically - anything that might impact your learning environment.
      • The impact of the change. Make sure you address any potential negative impacts to areas outside of your learning architecture. 
      • The timing of any resource availability needs.  I would also make sure to include any necessary skills required here. This should allow some time for any necessary upskilling OR external sourcing.
  • Complete and finalize your architecture documents (or the ADM) and document lessons learned from this cycle.
    • Make sure you get any necessary formal signatures and approvals.  Especially important in more formalized or politicized organizational cultures.
-------------------------
At the end of all of this, you should have:
  • An implementation and migration plan
  • A project and portfolio breakdown of the implementation
  • Project Charters - to launch the projects 
  • Finalized architecture documents - including
    • The Architecture Definition document
    • Architecture Roadmap
    • Transition and Final Target architectures
    • Architecture Requirements Specification
    • Reuseable architecture building blocks
  • Any implementation governance models - especially for formal cultures
  • Change requests for the architecture capability as a result of the lessons learned. 
There might be a request for a completely new iteration of the whole cycle and a redo of the architecture work. 

Technologies change, business needs change, environments change.  Often faster than you can implement your first target and faster than you can go through this cycle the first time.

Be prepared. 

As you have seen over the past year or so from my postings (and the fact that I have written a lot of this out of order) - this often isn't a tidy process.

Thursday, April 07, 2016

The Importance of Accountability Partners

I've learned over the years that any major change is more likely to stick when you have accountability partners.

Those really important friends who touch base and ask "So.....how's that THING going?"  With the tone that says "You're doing what you SAID you were gonna do.....right?"

I've been very blessed to have a number of these accountability partners over the years.
The friends who care enough to check.
The friends who call out my excuses when I fail to practice the behavior I said I was going to change.
The friends who remind me that I am making the change because the old way doesn't work.
For me OR for them.

I value my friends. Deeply.
Their (occasionally constant) reminders that something just doesn't work eventually gets me to practice the hard emotional work of change.
And since many of them are educators, they will tend to dig a little deeper.
Mostly asking what caused me to regress.  Forcing me to reflect.
Then asking me to try again.

For which I am eternally grateful.
------------------
One of the members of the Up2Us community expanded this idea to our community.  This individual and another member of the community have been my accountability partners over the past year as I've tried to make some of my own changes (personal and not naming names - they know who they are and I am eternally grateful for their check ins and lengthy talks).

Each Monday - he goes into our Slack channel and asks "So what are you going to do this week?"

And the wider community responds with the activities they want to be held accountable for.

On Friday - he returns.  "How did it go?"    And everybody shares their successes and failures and what they thought went right and wrong.

I am finding that this exercise helps to expand the trust and connection we have built in the live events.  And for those who weren't able to make that year's event - it helps to maintain engagement in the community. Also to let them know that there is a corner of the world they can go to with cheerleaders as they walk through their own journey.

Two simple questions.
So what are you going to do?
How did it go?
So powerful.