In any business environment employees have different ways of solving problems. Defining clear processes will document each step in solving those problems, saving both valuable time and money. Process documentation can take many forms, including data flow diagrams and process modeling. Through data flow diagrams (DFD), they provide a visual view of how information flows through a system or process. Through process modeling, the company’s AS-IS (or current) and TO-BE (or future) processes are documented in easy to understand language. What does all of this mean? and Which model should I use?


Which Model is Right for My Problem ?


The first step is to define the problem. Are your current processes slowing down output? If the answer is “yes,” then a Process Model should be created to document the sequence of steps/processes that occur to produce the product or service. If the answer to the question is about wanting to know how data flows, then the Data Flow Diagram is the correct tool.


Choosing A Process Model


The second step is to choose between In the AS-IS model, you are documenting how the process currently flows. Sometimes this is useful to see how the process may have evolved over time. Each area within the process may have made individual changes and that change is only known at the lower level. Documenting the AS-IS process may reveal a different process than perceived.


The TO-BE model, is either modified from the AS-IS or a TO-BE model can be created without any knowledge of how the current process is being performed. It answers the “what do we want it to be?” question. If you find the current process is working relatively well then you may only want to make minimal changes. Starting with the AS-IS flow and making modification would be the correct solution. However, if you wish to start with a completely new process, then developing the TO-BE model from scratch is the right choice.


Selecting Data Flow Diagrams


Data Flow Diagrams is used to visually represent the flow of data. In its purest form, DFD’s illustrates how data is moving throughout an information technology (IT) system and/or process, such as the flow from databases to users to output reports. They can also be combined with process models to illustrate both how the process flows and where data is flowing through the process and IT systems involved.


Being able to visualize the work flow, whether it is process or data-driven, promotes the discussion, do improvements need to occur? and/or is the work/data flowing efficiently?





In my previous blog, I spoke of the importance of project initiation and the 5 W’s.  When you begin a new project, there is another important process that should be completed during the initiation phase—business process management.


What is business process management?

Business process management focuses on improving the performance of a company or organization’s workflow to make it more adaptable, efficient, and effective.  I’d argue, business process management focuses on how the product or service is created/provided vs. the management surrounding the business model.


Why is business process management worth doing?

There are many reasons for utilizing business process management including:

  • Removes non value added steps by evaluating activities
  • Implements efficient process flows
  • Removes unwanted errors that may occur between departments or other processes
  • Helps managers understand how things flow and how to best explain the process in training materials

In any case, knowing and seeing the flow on paper is a great way to educate and have discussions with stakeholders. Sometimes the perception of how the business operates is not reality.


How many times have you heard why do you/we do it this way? And the answer is because that is how we’ve always done it!


Business process management provides the opportunity to challenge the norm.


The world changes, new technologies are developed, market demand shifts, the economy rises and falls, people’s attitudes change, or a host of variables can cause your product, services, and processes to become outdated. Spend the time to understand how your product or service is provided. It’s cheaper to change the process during planning than to change a poorly implemented process that failed to deliver.

The Regional Economic Studies Institute (RESI) , partnering with HR&A Advisors of Washington, D.C., is currently conducting a study on behalf of the Maryland Center for Construction Education & Innovation (MCCEI) . The aim of the study is to understand the gap between the demand from the Maryland construction industry for Bachelor’s degree holders and the number of Bachelor’s degree graduates in the construction/built environment field that academic institutions in Maryland produce. This study builds on MCCEI’s study published in 2012 entitled “The Critical Path,”  which outlined the major trends of the construction industry in Maryland.

To complete this research, the project team created and implemented a comprehensive methodology using the following methods:

  • A review of the existing data,
  • A survey of the firms in the construction industry in Maryland,
  • Interviews with firms in the construction industry in Maryland, and
  • Interviews with in-state academic institutions offering Bachelor’s degree programs in the construction/built environment field.


Using these methods, RESI and HR&A Advisors began conducting this research in September 2014. Shortly after analyzing the survey responses, the project team quickly noticed that several major employers in the construction industry in Maryland were hiring a large number of construction/built environment graduates from the same out-of-state schools. To gain a better understanding of the what these out-of-state schools were doing to attract students to their programs and to have out-of-state employers recruit their students post-graduation, RESI added onsite visits to these best practice institutions to the project. These onsite visits served to reveal what makes their Bachelor’s degree programs in the construction/built environment field special.


In total, RESI visited four out-of-state institutions including Drexel University, Virginia Polytechnic Institute and State University, Penn State–Harrisburg, and the Penn College of Technology. Each institution—as well as their numerous program offerings—had its own unique characteristics that would be attractive for incoming students. Each program provided its students with a unique advantage that would enable their graduates to be marketable in a competitive labor market post-graduation. The overarching similarity amongst these programs was providing their students with access to industry representatives in a number of ways, starting at the beginning of the program. This industry engagement enables the students to understand what aspects of the industry that they were interested in (or not interested in) as well as make contacts and effectively network themselves to potential future employers. How these individual students function as employees in the Maryland construction industry is unknown. However, many Maryland construction industry firms regularly attend recruitment events at these institutions, supporting the notion that their alumni are transitioning to employment well.


The remainder of the study will focus on conducting a gap analysis and, specifically from these visits, forming recommendations to make the construction/built environment programs at in-state academic institutions more attractive to new students and to make their graduates more attractive to employers. The long-term aim is to retain the talent educated in the state in the Maryland construction industry.



This winter, staff from the Center for GIS and RESI took on a data visualization project for the Johns Hopkins University and the associated anchor institution strategy entitled Homewood Community Partners Initiative (HCPI). The partnership is built around stakeholder engagement with the vision of a “vibrant urban center,” a “livable community,” and ongoing community projects in ten neighborhoods and one commercial district surrounding the Johns Hopkins Homewood campus.



HCPI3The TU team selected Tableau business intelligence software for the project. Tableau is focused on “making databases and spreadsheets understandable” and allows for the creation of charts, tables, and maps that are dynamic and interactive. For this effort, HCPI wanted to create themed dashboards that reflect the conditions, trends, and progress toward goals in several focus areas: public education, commercial development, the housing market, quality of life, and JHU community influence. HCPI plans to use these dashboards to share information with their partners and as an aid in planning and decision-making.


To build these dashboards, our team collected and processed data from a variety of sources such as the American Community Survey (Census), Baltimore City Department of Planning, Open Baltimore, the Maryland State Department of Education, and several HCPI partner organizations. Although the dashboards feature far more charts than maps, GIS played an integral role in the project. In many cases, we obtained tabular data for Baltimore City or Maryland and then geocoded the records to determine which fell inside our specific interest area, or to make calculations by specific neighborhood. Using GIS capabilities in conjunction with Tableau allowed a great degree of flexibility and customization in the data presentation.


A few reflections on using Tableau for this project:

  • The visualizations are dynamic in the sense that as more years of data are added to the underlying spreadsheets, data points and totals will change, and the axes will expand.
  • We can maximize use of space by building charts that contain selectors that allow the user to switch between years, or other aspects of the data, or both.
  • While Tableau’s mapping capabilities are somewhat limited as compared to other mapping-specific software, we were able to build focused, interactive maps into the dashboards. These allow users to zoom in and out and identify on a data layer.
  • Every visualization—maps included—has built-in tooltips so users can hover over areas and see numbers and information from the spreadsheets.
  • Creating the dashboards has been an iterative process of exploring the data and experimenting to determine which techniques best illustrate trends in data, or best fit a particular metric.
  • While experimenting with color schemes and switching among the template chart types is quick in Tableau, adding final touches to produce a finished look can be time-consuming.

While the HCPI dashboard is intended to be internal, we are excited to share a few screenshots of the work we’ve done to help the partnership track and evaluate progress toward their goals.







As a consultant working with many clients in developing an information technology system or software application, there is a critical phase in the product life cycle that is almost always overlooked. The process of project initiation.


Project initiation is the process of defining the who, what, where, when, and why.  It provides the business a high level road map defining what the system or application is to accomplish. It  defines who will be the leaders of the project, why the organization is doing the project and when in the life cycle of the business do they wish to have this project completed. This phase provides the information in making a decision to proceed or stop the project before resources are allocated. By bringing all stakeholders together, this ensures that the project will meet the business needs and be aligned with the business strategy.


More importantly, this phase of a project is the opportunity for the business to align its strategic objectives with the right tools. Technology for most businesses is a tool. An like all tools, you need the right tool to complete the job. Implementing a new system without the strategic view of the business, could result in a negative return on investment and failing to deliver a good, product or service.


During this phase it is a great time to document the following:

  • How the business flows.
  • Where data is stored and who has access.
  • Are there duplications?
  • How old are the current systems?
  • What experience are you providing to your customers?

There is an old saying; you can’t automate what you can’t document.



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.”