Thursday, June 25, 2015

Requirements from Scratch Step One - Write It All Down

I tackled the survey requirements first by brainstorming what I think I want.

I then did a Google Search - Survey Tools Review

Found a couple of baseline requirements lists and added stuff that we needed to consider that I missed.

I then dumped the initial list into a requirements template I created under "Scenarios". 
Honestly, I'm not sure I'm going to keep this template, but it is a start.
I'll clean it up later.

Video is about 5 minutes long.  This is pass 1. Enjoy.


Tuesday, June 23, 2015

Requirements Sample - Survey Tools

I have been working with our lead architect on a couple of survey projects.
  • The first project captured self-reported application development skills.  We've had a couple of projects this year where our in-house staff didn't have the skills needed for the new application. No one's fault - it happens when you replace a major piece of your enterprise system after using the same thing for 10+ years. The architects and management wanted to get a better feel for what skills our developers possess and, when we go into another one of these projects, what we need to account for if we go a different direction from our current systems. For me, this project was a lesson in why skills databases are so expensive.

  • Another project captured feedback for in-house, vendor supplied and commonly available training materials and events. This includes webinars, week-long classroom "bootcamps", online tutorials, YouTube videos, knowledge bases, books, anything someone grabs to learn how to do something.  What are people accessing if they need to learn something? What are the pros and cons of what they used? Is this worthy of further investigation and investment? Is there a particular direction we should take when we spend training money?  More online support? More boot-camps?   Ultimately, management wants to see where the best return on investment lies.
It has been a good opportunity to see what we have lying around the office and how the survey tools we have available work.

Unfortunately, I have not been entirely happy with the survey tools I've used so far
I want to figure out why I'm not happy with what we have + see whether there is something within our existing tool set that I may have missed.

The exercise also provides evidence that what we currently have doesn't meet our needs (if that is truly the case - I think part of the issue is my inexperience).
So how do survey tools fit in to the Learning Architecture?
1) You know those smile sheets? Type of survey.
2) Want to do more robust Kilpatrick evaluations? Survey.
3) Quizzes? The way most are written (multiple choice / true-false) - Survey.

Most of the LMS and Talent Management systems I've encountered have built in assessment / survey tools.

And the nice thing about putting together requirements on our side - it helps other groups outside of "training".  Many groups within an organization, at some point, want to run a survey to figure out
  • Whether their service meets their customer's needs
  • Where there may be opportunities to improve
  • If a program is working (at least by perception, reality may need further validation)

Over the next few posts - I'm going to show you my process for capturing requirements from scratch.

Thursday, June 18, 2015

Requirements Management in the Ecosystem

- Gaping Void of course.
I could leave well enough alone, couldn't I?
TOGAF encourages the use of a requirements repository.

We don't have one. So I need to build one. Somehow.

The initial reaction the business analysts had when I asked what format they use for requirements and told them of my plans to consolidate them into a searchable library was....

"Why would you do that?"

  • Our functional needs haven't changed for decades.
  • The general functionality of the tools we use haven't changed since the advent of the internet.
  • I don't feel like re-creating the wheel with each upgrade or re-evaluation of the toolkit
  • Requirements for some of these tools can help other groups since, if we think about it, the tools we use for "learning" perform many of the same functions as the tools we use for "working."
 Below is the way we are (still) thinking about the ecosystem.

No matter what happens - people still need to access stuff, people need stuff to access and people will want proof that they completed the stuff.

So what are the requirements we need to collect?

Well - what do you have lying around the office?

Chances are, you (as a Learning and Development team) have the following:
  • LMS requirements (example from University of Central Florida)
  • Webinar tool requirements (Top Ten Reviews - scroll down to see the requirements list and comparisons)
  • Classroom technology requirements 
  • "I need an online tutorial covering X topic" requirements 
    • Find the Needs Assessment / Intake of all of your old projects that required an online tutorial.  
    • Don't have online tutorials in your environment and need to start from scratch?  Look at the Needs Assessment / Intake of all of your old Instructional Design projects.....
  • Development tool requirements (Upside Learning has a nice tool comparison discussion and grid)
I'm sure you have more.

Don't have these lying around at all?

The next few posts, I'll show you my process for documenting this stuff.

Meanwhile - enjoy your scavenger hunt.

Tuesday, June 16, 2015

TOGAF - Requirement Types

To do this requires a system.
Your system should be built based on requirements.

Image from  National Association of Women in Construction.

Karl E. Wiegers, in his book Software Requirements (2nd ed, 2003), identified the following requirement types.

I'm breaking them out further (with thanks to Steve Corlew, the TOGAF certification trainer I worked with) into 2 sections...General Requirements and IT Requirements.

We are going to use purchasing a new presentation development tool as an example.
Because everyone hates PowerPoint (apparently).

Examples (or the types of things you are likely to hear) are in italics.  

General Requirements - these will be guided by the Architecture Principles
  • Business Requirements - what the business is trying to achieve
    • "The business needs new presentation software that allows us to reduce presentation development time and automates presentation hosting to our website"
  • User Requirements - what the users need to be able to do
    • Example: "Users need to be able to edit a presentation built in the solution"
  • Functional Requirements - what the solution (software / hardware / network / other) needs to be able to do to allow the users to do what they need to do (User Requirements) and help the business achieve it's goals (Business Requirement). 
    • The details of what the solution needs to do.
      • Example: "Upon publication, the presentation will automatically upload to our web server."
    • Functional requirements for a system are often broken down into the different components of that system.
      • Example: if the system to automate presentation hosting to the website includes the presentation tool, a tool allowing upload to the web server, and the web server...the Functional Requirements will contain 3 different sections. One for the Presentation tool, one for the upload tool, and one for the web server
    • The sections separating out the different components will then be further broken down into Features - or the collection of  "logically-related" functional requirements that provides a capability so the user can do what he/she needs to do and to help satisfy a business objective.
      • Example: Submission of Presentation to Web (incomplete, but you get the gist...)
        • Requirement 1: The tool will allow the user to save a presentation without submitting it for approval.
        • Requirement 2: The tool will provide the ability to notify a designated "approver" that a presentation is ready to publish to the web site
        • Requirement 3: The tool will allow the approver to click a button and post the presentation to a designated location in the web site
  • System Requirements - the top-level requirements of the entire system.  When everything is put together, what does the system do?
    • "But,Wendy - we just want new presentation software! I'm not worried about a system!"  As soon as you are interfacing with anything else - you have a system.
      • Are you trying to display the presentation on your device onto a screen in a conference room? You are working with a system that includes 
        • the actual presentation software you selected
        • the device you are using (Mac, PC, iPad, Kindle, Smartphone whatever)
        • the projector in the room you want to use and any cableing
        • any application you are using so that your device can broadcast to the projector (if it is not already built into the operating system)
        • any
      • System requirement = Users can show the presentation through a projector onto a wall. 
        • Sounds simple, but how many times have you found yourself scrambling for converters (Mac or alternate device users who don't have built-in VGA ports) or fought with the wi-fi/bluetooth settings on either your laptop or the projector. Or is that just me....
 IT Requirements - what your IT developers need to help build the system of your dreams
  • Business Rules - corporate policies, government regulations, industry standards, definitions of particular terms (eg. a "student" is an individual who is registered for at least one University course offered through the Registrar's office.).
    • A good resource for helping you determine what business rules you need to collect will be the Business Analysts housed in the IT Department.  
    • The more refined you are able to make the business rules, the more the IT folks can help you.
    • "Who will have access to the presentation tool?" Business rules will help define the access.
  • Quality Attributes - these attributes are essentially further detail for each of the Functional Requirements. Acceptable time between screen refreshes, readability of buttons, that sort of thing.  
    • The questions your IT developers will ask during the course of the project as they build out the solution will likely be about quality attributes.
    • "How quickly do you need the presentation to show up on the website? Does it have to be immediately or can it be the next morning?"
  • External Interfaces - the interface between this system and other systems. 
    • "How does the presentation I developed using the Presentation software show up on Slideshare?"  Slideshare is the external interface.
  • Constraints - what in the existing system can't be changed. 
    • "Everyone we work with still uses PowerPoint.  Therefore, the Presentation application we choose has to be editable in PowerPoint." Unless you can somehow get everyone you share presentations with EVER to switch to your tool - this is likely a constraint.
I know this seems like a lot...but the time spent fleshing out requirements helps make sure you are actually building a solution that solves your problem and gives you a better shot of selecting pieces that fit your needs (vs fitting your needs to the pieces).

Even better, when we are ready to re-evaluate parts of our Ecosystem, we already have a baseline to start with!

Thursday, June 11, 2015

TOGAF - The Relationship Between Principles, Requirements and Matrices

Notice that big circle in the middle?


EVERYTHING in the ecosystem SHOULD map to requirements.

You may have noticed that the Capability Matrices in the previous posts sorta-kinda did.

In an ideal world (which I don't happen to live in right now), the order in which things would go would be:
- Problem definition
- Requirements collection
- Solution design and development based on requirements and guided by architectural principles
- Did it solve the problem yes/no?

The capability matrix for the resulting solution set would be based on the requirements collected.

The next series of posts will demonstrate how to create a capability matrix in my personal utopian fantasyland. And talk about requirements and requirements collection.
In TOGAF, when they talk about requirements, they are talking about the requirements for the entire architecture.

These requirements are shaped / guided by the principles underlying your architecture.

As more requirements surface, the principles of the architecture may shift.

For the time being, the 2 principles we are using to guide our Learning Architecture still work.
- As needed performance support
- Continuous professional development

When we put together our requirements for any solution in the Learning Ecosystem, we will be keeping those 2 principles in mind.

Side note: Some other organizations use the requirements they have collected over the years to help define their Architecture Principles.  That works too.  Requirements collection in our organization is still very immature.

Tuesday, May 26, 2015

Capability Matrices: Functionality Replacement

The second way I have used a capability matrix is to make decisions regarding application replacement.

In this instance, management was investigating getting rid of our staff LMS.
By itself, I don't have a problem with that.
However, they were looking to do it in a very tight timeframe - as in, not renewing the contract that expires in less than a year.

I used this particular capability matrix to show the following:
  • What we have and what each application does (most of them are content libraries containing pre-built tutorials)
  • What functionality we currently lose if we just stopped using that application.
  • Our current options (ie - what we have in-house that doesn't require us to purchase anything) for replacement
    • Including who "owns" that option
This matrix quickly showed management the amount of work that would be required to make the transition.

Our current Compliance program is very dependent upon our LMS.

We can later use this same matrix to help guide purchasing future content libraries and LMSs.
So Wendy, why did you put the content libraries and the LMS together?  They are different things!

Not to management.  They just see "learning".

Showing these things together helps show them the difference between the types of systems.


Rows - The content library / CMS / LMS currently in our environment
  • Again - this is the stuff we are absolutely certain about.  
  • There are many other LMSs and content libraries in our environment through individual schools and departments.  These change frequently and I'm currently not in a position to do an inventory.  Remember, I am doing most of this in addition to my current job.  And we are starting to hit the busy season for higher ed IT.
Columns - Requirements
  •  For this one, I pulled the requirements we used for the LMS portion of the Talent Management source selection.  I then took them to a higher-level since management doesn't need to see the technical details.
  • I also added some newer requirements - for when we decide to actually replace the LMS functionality.  Especially since there are new standards in our world (xAPI and CMI-5) that we will need to accommodate in the next iteration of our ecosystem.
  • Finally - since our solutions tend to have content attached to them, I wanted to outline what content was in the libraries.  


Thursday, May 21, 2015

Capability Matrixes: Where do I stash my files?

The first example I want to flesh out is the capability matrix I am using for determining where to host my training materials.

Doesn't your organization have a content strategy?

Thankfully, we are starting these discussions again - since the applications we are using for hosting have changed and multiplied.

2 years ago - it was pretty straightforward. 
  • Any training content that needed tracking went into the LMS/CMS
  • Anything that needed to be external facing to our audience and didn't require tracking went to our web site
  • Working files, base files, anything that needed sharing among the project team etc went to a shared drive

Now - we have:
  • The LMS (for stuff that needs tracking)
  • The web site (internal - mostly a server we upload files to)
  • Google Apps (currently replacing our shared drive)
  • A document management system (secure)
  • SharePoint
  • External-facing web site CMS
  • A Knowledge Management system
  • A Project Management system with document-hosting capabilities (that is also currently being switched out)
  • some point...a Digital Asset Management system
I still have projects where I need to have my materials tracked (occasionally) and visible (often).
Plus - I still need to be able to find my own stuff.

So in this example - I am using the capability matrix to help make decisions regarding where to host content.

Rough setup:

Rows: each of the applications I have access to where I can store content.
  • At some point, I will flesh this out to other applications that are in the environment.  Right now, I am more concerned about what I can do TODAY.

Columns: The "requirements"
  • Section 1: What file types each application can handle.
    • eLearning has some file types and packaging that are not used by the rest of the organization.  I have also discovered the hard way that some applications handle these packages a LOT more gracefully than others.
    • Some applications also handle certain file types "awkwardly" (please see Google Apps and MS Office)
  • Section 2: Other desireable features
    • I am using wiki, blog and real-time collaboration
  • Section 3: Who has approvals over content
    • When I make a decision over where I want to host my stuff - the less approval overhead the better.  
    • If I need to go through layers of approval - I always warn the project team that they will need to tack weeks onto a project and to not expect that materials will be updated quickly.  
      • Since many of the projects I have been on recently have been Agile (though I haven't been on an implementation project in my entire career that hasn't had development occurring in parallel with training) - approval processes get very unwieldy very quickly.  
Below is a brief demo video below of my current capability matrix for content hosting.