Christina

Christina

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.

 

Capture

HCPI4

 


Larry

Larry

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.


Dawn

Dawn

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!


Dawn

Dawn

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.

 

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

 

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


Dawn

Dawn

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.

Sharyn

Sharyn

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.


Dawn

Dawn

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


Dawn

Dawn

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.


Dawn

Dawn

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.


Dawn

Dawn

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?

 

You:

  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!