susan steward


A few weeks ago, I published a blog post regarding nursing demand in Maryland—specifically, demand for registered nurses. At the time, I briefly introduced RESI’s new industry-to-occupation matrix and asked for suggestions for a name. Well, after at least a month of brainstorming (and voting!), we have finally settled on RESI’s Predictive Regional Occupational Matrix, or PROM. We’ll make this blog post RESI’s PROM-posal to you, and a more formal introduction of how PROM can be useful in analyzing the workforce needs of a region.

Goodbye to the Old, Welcome the New!

PROM Workflow

Click to see our Workflow

PROM is a tool that allows RESI to take forecasts for industry-level jobs and determine the specific occupations attributed to those jobs. RESI has also developed a reverse interface to go from occupational data up to industry-level data. This reverse interface allows RESI to look at reintegration of occupations into a workforce. For example, I am currently using the tool to look at the impacts of minimum wage and mandatory sick leave policies, workforce demand/shortages, and targeted training.

For several years, one of the biggest questions that I was asked when presenting job forecasts was, “What are the occupations that will be affected?” It is one thing to report that there will be 100 jobs in a sector, but relating that job count to specific people working in a field was a bit difficult. We knew the types of occupations associated with those fields when we used Occupational Employment Statistics (OES) data, but now we have a better way of answering occupation-related questions from clients and decision makers.

What is PROM?

PROM is a regional matrix that can be customized to suit a group’s specific needs. On October 9th, I will be providing two presentations at the RESI/REMI joint event, Raising the Bar on Policy. One of the presentations looks at identifying an occupation’s growth using the REMI PI+ forecast for Maryland and RESI’s PROM. Since the tool’s reconfiguration, I have used it to work backward from OES data for those impacted by minimum wage and paid sick leave policies for a new analysis on “A Tale of Two Policies.”

“A Tale of Two Policies” will look at the economic and fiscal impacts associated with the continuing change in Maryland’s minimum wage coupled with the possible passage of mandatory paid sick leave. Being able to look at the impact of both policies on Maryland’s economy and see the shifts in occupational data provided RESI with new insights—mainly in determining if there is overlap in occupations across similar industries. This finding may be helpful for workforce agencies attempting to target training offerings for future labor demands in their regions.

Ask Us About PROM!

RESI is proud to introduce the latest addition to our toolkit. If you are interested in learning more or seeing some work completed using PROM, please feel free to join us on October 9th for the joint REMI/RESI event, Raising the Bar on Policy. It’s a free event, but registration is highly encouraged. If you are attending the Economic Outlook Conference in November, please be sure to ask us about the tool and how we can help tailor the tool for your needs.

Dyan Brasington


For more than 35 years, I have served communities and businesses by leading in various economic development roles. Along the way I have gained a great deal of knowledge working with colleagues and community members, each of whom has a distinct viewpoint. Here I share some insights and advice for economic developers serving today and into the future.




Economic Development

1. Stay Motivated in the Purpose of Economic Development

The great thing about economic development is that you’re always working toward something much bigger than yourself. Understanding this is important for keeping us motivated during the difficult times inherent in our profession. For example, we are often asked to uproot our families and move somewhere else. Sometimes this is due to greater opportunities opening up elsewhere; other times, it’s due to changes beyond one’s control.


We are also vulnerable to politics. Changes in political leadership often lead to changes in economic development leadership. Whatever the case, making a move often involves asking those we love to make life changes in support of the work we do.


Our profession also involves dealing with setbacks that range from seeing a company go out of business to dealing with changes in the economic climate. We must remember that economic development success happens in waves over years, where you can look back and see some enduring value of your contributions despite the bumps in the road.


2. Know That Leadership Requires Statesmanship

What does it mean to be a statesman? To me it means having the integrity and courage to do the right thing when you’re making decisions, and to stick to something that you believe is for the greater good. This can be particularly challenging given the complex and competing dynamics that are a natural part of economic development, and balancing the choices that people around us may make.


One of the most important lessons I’ve learned is how important it is to nurture and cultivate those around us to help them do the right thing. As economic developers, we are called to keep the bigger picture and greater good in mind, and can inspire others to lead with a greater vision as well.


3. Remember That it is About the People, Not the Project

We sometimes become very project-focused and forget about the people. You can think you’re doing the right thing and that you’re being strategic in helping your community without realizing you’re not considering the people who may be affected.


For example, we often focus on recruiting or growing jobs in our communities that are highly skilled and highly paid, without including job growth for others in the community that do not fit that profile. When we fail to do this, our economic development efforts are not as inclusive as they could be. We must be able to understand the many voices that will be touched by our leadership, which requires us to listen empathetically to multiple constituencies and to be open to various points of view.


4. Embrace Technology-Led Economic Development

Technological advancements have changed the way we live, work, and do business. Economic developers can provide leadership in advocating for new technologies as well as educating others about their benefits. This is especially important given the uncertainty associated with such technologies.


Bringing together all the stakeholders in the technological ecosystem together, including business, government, higher education, and the investment community, is an ideal role for economic developers to play. I have seen technology-led economic development efforts build the sense of community, the momentum, and the critical mass needed to sustain regional economies.


Looking Ahead

The ability of communities to retain, develop, and attract human capital is essential to success in economic development. First, people now place great value on their ability to balance work, home life, and quality leisure time in the community. Once they find a place with those attributes, they are less willing to move. Second, the resource that drives most industries today is human capital, rather than natural resources. The combination of these two trends are why industries are moving to the workforce, rather than expecting the workforce to come to them, as they did in the past.


Another trend is that the term “status quo” is quickly disappearing from our everyday vocabulary. We are challenged with keeping our knowledge and skills up to date so we can deal with this constant change.


Finally, I see our profession being challenged to help our elected leaders and others, who sometimes have misperceptions about economic development, understand the multi-faceted nature of our work and its impacts on our communities.


I will leave you with this. “There is an old adage that the only two things certain in life are death and taxes. I would add the word ‘change’ to this saying.”




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.