It’s a new year and it is time to start working on those resolutions. I am terrible about completing mine, I start off great but by mid-February they sort of drop off the radar; unless, I have a plan. The Division’s Applied Research and Technical Services group has been working closely with several clients in developing their Disaster Recovery (DR) plan and site. If one of your organization’s New Year’s resolutions is to establish a DR site, here is information about developing your DR plan and how to get started with building a DR site.


What is a Disaster Recovery site?

Disaster Recovery is the policies and procedures that enable recovery or continuation of vital technology infrastructures and systems following a disaster and where and how those vital systems and data are maintained. DR is basically an insurance policy based on the probability a disaster will occur.

A DR site is the physical location of the data, systems, etc., your organization needs to be functional.


How do I get started?

Many of the decisions you will need to make when developing a DR plan and setting up a DR site begin with answering the following questions:

  • What data/systems are essential to your organization?
  • What can your organization live without? (data? applications? both?)
  • If a disaster were to occur, how long after will the organization need to be up and running?
  • How many users will need access? How will they access the DR site?

Here are a few questions to help your organization get started in determining your DR needs:

  • What constitutes a “disaster” (power outage, building unavailable, natural disaster)? Decide what is important in your business scenario to back up to a DR site?
  • What type of site do you need (hot – available within minutes of a disaster, warm – available within hours of a disaster, cold – available within a few hours but may require updated data or applications)?
  • How often will the DR site be backed up?
  • Where will the DR site be located/hosted?
  • Who will be responsible for updating and maintaining the DR site (in-house or contractor)?
  • When will testing take place to make sure the DR site can be functional and all data/applications will run correctly if/when you need them?
  • What is your budget for DR site development and maintenance?

Once these topics have been thoroughly explored you can begin outlining your technical specifications, which include:

  • How many servers will be used?
  • What type of servers will be used?
  • How often will data replication take place?

As you become more involved with the DR process you will develop more questions specific to your organization. There is no right or wrong answer, only what is needed by your organization to recover from a disaster. The key is to start the conversation and begin determining your DR needs so you can develop your DR plan, site, and maintenance strategy. Hopefully before New Years 2016!



The Race to the Top (RTTT) grant has come to an end (see CAIRE and the Race to the Top and Evaluating the Implementation and Utilization of the Race to the Top Projects). This project has been a part of the Center for Application and Innovation Research in Education (CAIRE) for the past four years. As with any project that we spend a long time on, we are sad to see it go, but are very proud of the work accomplished. RTTT provided the CAIRE team with many opportunities to use our skill sets, both individually and collectively.


Over the last several months the CAIRE team evaluated the impact and utilization of several individual RTTT projects. Surveys were a large part of the data gathering process. Each project had its own unique survey, and our team took much time and skill in creating surveys that would yield the data necessary to provide information to contribute to the decision making process.


Throughout the entire RTTT project, CAIRE evaluators used personal interviews to gather information that can only be conveyed through direct contact with those people “in the trenches”. Talking directly to both Maryland State Department of Education (MSDE) employees and local education agencies (LEA) employees, yielded useful impressions and a deeper insight into the success of a project that cannot be conveyed through surveys or test results.


Data Analysis
After obtaining survey results and interview results, the CAIRE evaluators carefully analyzed those data sets quantitatively and qualitatively. Researchers compiled the data, developed themes, and presented the data that indicated trends and direction.


By using our skills to develop insightful and meaning surveys, conducting thorough interviews and analyzing copious amounts of data, the CAIRE team presented our findings and recommendations to MSDE as they move to the 21st century with the Maryland Career and College Readiness standards.



If your organization has ever embarked on an IT project, you may have heard a lot of buzzwords when it came down to the documentation needed. System Requirements (one of my favorite), Communication Plan, Work Breakdown Structure, Test Plan, are just a few of the types of documents that may have been thrown around as potential documentation needed for the project in order to help secure its success. But what are the documents and do you need all of them for every project?

The table below provides a very high level explanation on some common IT project documents. It is ultimately up to the project manager and stakeholders as to which documents are truly necessary. Having all the documents does not guarantee a successful project; however, having the truly important and useful documents can specific to the project help with its success, no matter if it is large or small.

Document Name What is it? When do you need it?
Concept Proposal Explains the “need” for the project and to gain a project sponsor. This document is used when it is necessary to explain “Why” strategic goals are not being met or where mission performance needs to be improved.
Project Charter Explains the scope, objectives and roles and authority with regard to the project. This is created by a project sponsor. This document is usually needed if a project has an in depth approval process.
Project Scope Statement Explains the intended results of the project and outlines the specific team being pulled together for the project. This document is always needed because it lays out the foundation of the project.
Project Management Plan Documents the planning assumptions and decisions, facilitate communication among stakeholders, document approved scope, cost, and schedule baselines. Most projects should have a project plan; however, depending on the project it can be very detailed or it can be very simple or any degree between. Project Managers want to create this document as there “blueprint” for the project.
Work Breakdown Structure Decomposes a project into individual activities. All projects should have a WBS that outlines each activity, resource assigned and time frame to complete.
Risk Management Plan Foresees risks, estimate impacts and define responses to issues. This document is recommended for most high dollar, detailed projects in order to help mitigate issues before they arise. This document can be included in the Project Management Plan.
Change Management Plan Documents the formal process for any changes to a project’s scope that may or may not impact the schedule. This is recommended for all projects to ensure that all stakeholders understand the process if a change is necessary in order for the project to be successful. This also helps to alleviate scope creep. This document can be included in the Project Management Plan.
Communications Management Plan Outlines types of communication (email, cell phone etc.) and who needs to be contacted and when he/she should be contacted. Most projects should include this information; however, this does not need to be very complex and can be included in the Project Management Plan.
Human Resources (Staffing) Management Plan Outlines the roles and can include specific personnel needed to successfully complete the project. Most projects should include this information; however, this does not need to be very complex and can be included in the Project Management Plan.
Quality Assurance (QA) Plan Outlines how the final product has been vetted and tested before delivery to ensure it meets the project requirements and/or customer’s expectation. Recommended for most projects; however the detail can be adjusted to match the project. This can be included in the Project Management Plan.
Cost Management Plan Provides detailed cost information in managing the budget and costs of a project. Most projects should include this information; however, this does not need to be very complex and can be included in the Project Management Plan.
Procurement Management Plan Shows how items necessary for the project (hardware/software etc.) will be purchased, by whom and when. This plan can also outline the procurement process. This document is only needed for more complex projects where multiple items are purchased and there is a need to track those purchase. This does not need to be very complex and can be included in the Project Management Plan.
Business Process Document Details the business process flow associated with the project. This document can be the basis for a scope of work, included as requirements, and can even be the basis for training materials. It is up to the Project Manager and stakeholders to determine if it is needed.
System Requirements Document (SRD) Lists in detail all the requirements needed for the developers to deliver a system that meets the customer’s needs. This document is always needed for IT projects. (See: Are Requirements Necessary When Purchasing IT Products?, What Does Your System Require? and Knowledge Center
Requirements Traceability Matrix (RTM) Conveys how a requirement is being tested. This ensures that all requirements have properly been tested. This document is needed whenever a System Requirements Document and a Test Plan are developed.
Test Master Plan (TMP) Details how procedure used to test the final product and record results. (See Going from Requirements to Test Plan) This is always needed in order to test the final product.



It’s a huge undertaking to develop a website. And, it’s not something you should venture into lightly. Before you get started and throughout the development stages, it’s important to consider these things…

Set Goals

Do you want to gain more visitors, create more interaction with your visitors, have higher search engine ranking, utilize a blog, integrate more videos and images? Whatever your goals may be, document them in writing before you get started and reflect back to them throughout the development.

Prioritize Usability

No one will visit or stay on your website if it does not work. It’s important to think through your website’s navigation in advance. You can come up with a solid plan around your navigation by considering your audience, developing personas, performing a card sort, and defining the information architecture. Also, consider the integration of a search tool to benefit your users. Have you ever considered how visually impaired website users will encounter your website? This is a good time to reflect on ways you can provide a positive experience with your website. Lastly, be sure that all images and links are working and that page load time is quick.

Consistent Design

It can’t be stressed enough… use a consistent design throughout your website. Visitors should feel like they are having the same experience from page to page. To aid in this, re-use elements from page to page. Also, consider using colors that associate with your brand, but also create strong contrast to help with readability. Use legible fonts, but try to stick to a limited number of fonts to help with the consistency theme you are trying to achieve. You can use varying sizes and weights of fonts to assist with creating visual hierarchy. Finally, in your design, try to use beautiful imagery that does not look too much like stock photography.

Craft Content

Like they say…content is king. Develop clear messaging on each page that is developed for your audience. Select strong keywords throughout your site and always use page titles and headings. Thoughtful effort at this stage will help engage your audience as well as help with your search engine optimization. Make contact information readily available in locations like the footer or a contact page and try to integrate call to action elements on each page. Lastly, establish a plan for maintaining content. You may want to consider a implementing a blog to assist with this, but whatever you decide, a plan will assist in meeting goals related to your content development plan.



If you have been following along with some of my blogs, you will notice a recurring topic: REQUIREMENTS (Are Requirements Necessary When Purchasing IT Products , What Does Your System Require?).  I know I have written this before, but having good requirements is the foundation of any successful system. If you write really good requirements at the beginning of a project, you will have useful Test Plan by the end of it.


Requirements Development and Testing
In the System Development Life Cycle (SDLC), there are two areas that tend to be short changed, in both the time needed and details required:  requirements development and testing. These are the same two areas that cause the greatest issues if there is no commitment. If well written and easily understandable requirements are created at the beginning of the project, then the developers can build a system that meets those requirements and then those same requirements can become a clear and concise Test Plan. This will result in a Test Plan that thoroughly evaluates the requirements, thereby providing the client with a fully tested system that meets their needs.


Systems Development Life Cycle - Image Credit - Netlocity

Systems Development Life Cycle – Image Credit – Netlocity

Elements of a Test Plan
A Test Plan, in its simplest form, is a chart. Applied Research and Technical Services (ARTS) uses an Excel spreadsheet that includes the requirements, arranged in numerical order, and incorporates columns that let the Tester denote whether or not the system performed correctly.  For example, the requirement may be, “The System shall include a log in screen that contains both ’Username’ and ’Password’ fields.” If during testing, you go to log into the System and either the “Username” or “Password” field is missing, the requirement was not met and the failure will be indicated on the Test Plan.


Testing is an important part of any system development process; however, even with the best Test Plan and the most conscientious Testers, there is almost always some bug that no one anticipated.  That’s ok! Between the unit testing (testing done by the developers during development), using the Test Plan that is based on the requirements,  and the testing being completed by the client (User Acceptance Testing – UAT), most major issues should be discovered and corrected prior to the system “going live.”



A while back I wrote a blog about writing a Request for Proposal or RFP (“How do you write a RFP?”).  That blog discussed the overall RFP creation process. Now, it is time to look at one very specific but important element of the document, Vendor’s Minimum Qualifications.


What are Minimum Qualifications?
A simple answer is the lowest required level of knowledge and abilities that a company as a whole or any proposed individual must possess to be considered for award of the RFP. Carefully crafted minimum qualifications allow the organization issuing the RFP to provide potential vendors with a checklist of a vendor’s “must haves.” The tricky part comes in writing clear and understandable minimum qualifications.


How do you write GOOD Minimum Qualifications?     
Ahh, here’s the rub.  What may be clear to you and your organization may not be clear to a potential vendor. For example, it may be important to your organization that the vendor possesses five years development experience. Writing a minimum qualification as, “Vendor shall have five years IT development experience” leaves the interpretation of the minimum qualification wide open. A better way to write the minimum qualification is, “Vendor shall have a five consecutive years developing inventory tracking programs.” Even though your RFP may be requesting an inventory tracking program, being specific when developing minimum qualifications helps to “weed out” those vendors that do not possess the skills and experience that you require. Minimum qualifications should encompass specific skills and abilities that your organization feels are “non-negotiable” and required in order to complete the project on time and on budget.


This also extends to specific personnel that you want to be a part of the project.  To request that a “Vendor shall provide a project manager with telephony experience” is not a good minimum qualification.  In order for the vendor to propose a project manager that will truly meet your needs, it would be better to write the minimum qualification as “Vendor shall provide a project manager with a minimum of seven years’ experience managing telephony projects for at least 200 users. ”  A vendor, when preparing its response to the RFP may have a great Project Manager in mind; however if that person has never handled a project on the size and scope that matches your RFP, then you will not receive the skill set needed to complete the project. A good minimum qualification will help them align their proposed solution with your true need.


What if there are qualifications that would be beneficial, but aren’t required? 
In addition to minimum qualifications, another level that can be included is the “Additional Qualifications.” These qualifications, for example, may be specific certifications, such as a Project Management Program certification or PMP or Cisco Certification. “Additional Qualifications” are just that, extra qualifications. If a qualification for either the vendor or its proposed personnel is absolutely required then it is a minimum qualification and needs to be portrayed as such in your RFP.



One of the Division of Innovation and Applied Research’s strengths is its highly skilled staff. Another strength is its ability to call upon Towson University’s multitude of talented and knowledgeable faculty. Our latest project involved working with the Maryland State Department of Education’s Division of Early Childhood Development (DECD) and Dr. Nhung T. Nguyen, an Associate Professor in the College of Business and Economics.


DECD contacted the Division of Innovation and Applied Research with regard to a compensation and classification project. Bill Hansman took on the role of both analyst and project manager, and then reached out to the University for a subject matter expert to be part of the project team. Dr. Nguyen, who earned her PhD in Management from the Virginia Commonwealth University, was a perfect fit since compensation management is one of her areas of expertise.


The team decided to use in-person interviews, and surveys, to meet the projects goal of analyzing the job duties at DECD. The team accomplished this by:

  • Analyzing current job descriptions, which included reviewing the State’s MS-22 language and comparing that language with information that was received from the interviews and surveys.
  • Comparing each employee’s resume with the knowledge and skills needed for his/her current position, and determining if the resume indicated if he/she was over or under qualified for that position.
  • Reviewing the internal job structure from the data received, which allowed the team to make recommendations about the DECD positions as they currently exist, and to revise current position descriptions to reflect the work actually being done, as well as to draft new position descriptions. These actions are needed to fill current vacancies within DECD.

Bill and Dr. Nguyen accomplished the project’s goal of analyzing the job duties in terms of scope of responsibility and its distribution across the DECD’s organization units. All of the work the team performed lead to recommending areas for possible changes that would optimize DEDC’s efficiency and effectiveness.


This was a rewarding project for the Division and client and also a great opportunity to develop a new collaborative relationship with one of Towson University’s expert faculty members.



So you don’t think you need requirements when buying a new IT product? If you are buying something for home use, chances are you don’t.  But if you are talking about business use – that can be an entirely different story.


In most professional environments there is more than one user, or more than one person that needs results based on the product.  With several people needing the product to perform in a certain way, it is better to find out how it will be used up front.  (See “What do you require?”).  It takes careful planning and requirements gathering to purchase, install, and customize a  product that meets a specific business need. So what happens if you don’t gather requirements before making a purchase?


Time and money are two words bantered around a lot. So if creating requirements costs time and money, how can it save both?

  1. If you know what your requirements are before you go looking for the software, you will save time when searching for the right product.
  2. If a commercial off-the-shelf ( COTS) product meets all major needs with only minor tweaking, and you already know which requirements are “must haves” and which ones are “nice to have,” you save money!  If the COTS product you find does not meet your needs then you will need to either change your expectations, or spend additional money retrofitting it.
  3. If you spend more time upfront determining all requirements, including requirements on where the product will be housed and who will need access, less time and money will be spent on implementation.
  4. If you spend the time and money on the requirements up front, you can then use the information in a Request for Proposal, ensuring contractors understand what is needed, so they can provide an accurate cost estimate, once again saving time and money.

So what is the “worst case scenario” if you don’t obtain your requirements upfront?



  1. Purchase a product that doesn’t meet your needs and you do not use it.
  2. Spend time (in some cases years) trying to make or modify the product to work.
  3. Lose institutional information, which is never documented and cannot be retrieved if one person holds all the knowledge.

Requirements gathering can be onerous, but if done correctly they can be worth their weight in time and money!



Last week I attended a Return on Investment (ROI) workshop by the ROI Institute, hosted by the International Society for Performance Improvement, Potomac Chapter.  Based on my professional background, the lens I used to understand the content and discussions, was training.  As I reflected afterwards, I was left thinking that we, as trainers and developers, really could do a better job demonstrating the value of what we do.  Often times when determining if a training has been a success or not, the only data we draw from is class evaluations, and while evaluations can shed light on trainee reaction and learning, it doesn’t measure success.  I think we can do better.  As trainers, we need to start asking the bigger questions:  Are trainees using the information?  How is this training impacting business?  Has it increased productivity? Decreased re-work? Decreased citizen complaints?


Sometimes the biggest obstacle to answering these questions is being able to identify, from the analysis stage of training development, what is the goal of the training?  It is unlikely, for example, that the goal is simply for trainees to learn a new procedure.  That procedure was not created for the sake of creating a procedure; instead it was created to accomplish a task that works towards a specific goal (increased productivity, decreased errors etc.).  Therefore, the question cannot merely be, did trainees learn the new procedure?  It should be, instead, did trainees implement what they learned and produce some measurable benefit?

Some of the tips Dr. Jack Phillips (ROI Institute) presented were the following:

  • Do not start training development by identifying learning needs, instead, start by identifying the ROI objectives, such as, what are the business needs? Then, build you can begin building your learning objectives.
  • Make your ROI objectives specific and measurable, for example: Decrease accidents by 5% in four months after training has been implemented.
  • Do not wait until the end of a training event to evaluate, you should be evaluating at every stage of the process.




In past blog posts I’ve introduced what CAIRE is doing to support RTTT and discussed the how we are evaluating the implementation and utilization of the projects.  In this post I wanted to share the perspective of a “freshly minted” graduate who has recently joined the CAIRE team.

Jessica Lake

Jessica Lake

Jessica Lake, RESI Research Assistant, recently graduated with a degree in Sociology from Brown University.


What was your first impression of CAIRE’s work?
When I began working on CAIRE, the initial thought of evaluating 54 projects was a bit overwhelming. However, as I’ve spent more time working in-depth on each project, I’ve found that the diversity of topics has made my job more intriguing and has allowed me to develop a higher degree of workplace versatility. Although all projects relate to the broad topic of education reform, each one has a unique purpose and intended impact on the education system. Some projects are focused on broad data systems, others are geared towards aiding educators, some are specifically targets towards students, and so forth. As such, my work has provided me with a broad range of insight, knowledge, and perspectives on the field of education that I could not have gained without such variety.


How are you using what you learned in the classroom?
During my time working with CAIRE, I have relied upon many of the skills that I developed during my undergraduate education. My abilities related to document analysis: formal writing, group work, and conducting research have all contributed to my effective performance of daily job tasks. Additionally, as a Sociology major, I’ve been able to apply some of the academic knowledge I gained to my work and have found real world value in the abstract ideas and concepts from my classes.  Overall, it’s proven that my undergraduate experience was absolutely beneficial for my future career.


What is it like being a part of the CAIRE team?
Although I had internships in various offices during college, they provided only limited time working with professionals because they were part-time and temporary. Now that I’m out of college and working with CAIRE, I’ve found that my collaboration with experienced staff has been enriching and beneficial. Everyone working with CAIRE has many years of experience and, thus, has a great amount of knowledge and advice to share. I’ve not only learned about specific workplace skills and duties, but also about the  importance of strong relationships amongst co-workers,  the ways in which a wide variety of perspectives can  impact a project, and how to solve problems in real life settings. Overall, everything I’m learning from my co- workers is helping me build a great foundation for my years in graduate school and my future career.


When we first started putting this blog together, I was curious to see what Jess would have to say about her work experience so far.  After reading her comments, I’m even more encouraged to know she is not only using the knowledge she gained in college but is enjoying her experience and also learning tons more along the way.