A Technology Roadmap for Regis College

August 18, 2018

When Regis College, a private university in greater Boston, sought to create a technology plan to support their performance goals, they turned to Systems Flow.

Like many higher education institutions, Regis was grappling with a series of questions regarding the ability of its technology environment to manage data and information flow. How well was data being shared, if at all, between admissions, student services, and alumni relations? Was the school’s procurement system meeting the needs of its stakeholders? And, which of these challenges should Regis address first?

By listening to and mapping the needs of multiple stakeholders across the campus, we helped Regis identify gaps and align technology solutions to business goals.

Identifying Business Drivers for Technology Decisions

First, it was crucial to understand, document, and socialize the key business goals and challenges surrounding the college’s technology infrastructure. We actively elicited business strategy from groups representing every business function at the college to identify key business drivers that inform IT investment decisions. Our analysis outlined challenges and recommendations, and identified several immediate solutions to ongoing technology problems.

Making an Informed Technology Investment

The culmination of our analysis of Regis’ business strategy and current-state technology environment was a 5-year Technology Roadmap. This plan detailed recommended technology approaches to realize institutional strategic objectives, and:

  • Provided a complete view of Regis’ current technology architecture, including metrics on users and hosting disposition (cloud or on-premise)
  • Identified relationships between business challenges and IT challenges
  • Analyzed trends in the technology application landscape
  • Identified gaps in automation capabilities, information management and business intelligence, ERP functions, and process, governance, and training
  • Involved facilitation of several onsite elicitation worksessions, that not only settled long-standing disagreements on how data was defined, but also formulated a baseline for future data transformation
  • Created an Enterprise Data Dictionary to better ensure cross-functional understanding and data consistency; defining over 150 business terms spread throughout multiple disparate databases across the institution
  • Proposed actionable recommendations and a roadmap to achieve them

“What Systems Flow produced was a succinct and actionable set of recommendations that, when realized over the next 3-5 years, will ensure that technology is a valuable contributor to reaching our strategic goals,” said Kate Korzendorfer, Regis CIO.

With this business-aligned technology roadmap in hand, Regis College is able to strategically focus its technology investments in areas such as data intelligence and information management, student engagement through mobile technology, process automation, and lean IT process and governance.

You, too, can achieve visible value and sustainable results.
Systems Flow can help.
Strategic thinking. Put into action.



5 Rules for Writing Effective Use Cases

July 10, 2018

In a previous blog entry we introduced you to use case types and use case presentation methods (textual use cases or use case diagrams). In this entry, we will cover the five most important rules for creating use cases.

Rule #1: Follow a straight path to achieve a use case goal

A use case should be as concise as possible; when another possible route becomes evident, consider the following:

  • Is the path achieving the same goal with the same actor?
  • Is another actor now involved?
  • Has the goal changed?
  • Is the path an alternative to the main path?

In part 1 of this blog series, we had the following use case example:

 

Use Case Name Complete Customer Profile
Goal Input personal information into ABC Corp online portal
Use Case ID UC001
Actors Customer
PreCondition Customer has login credentials provided by ABC Corp System Admin
Primary Course 1.       User accesses ABC Corp’s portal

2.       User logs in using credentials provided by System Admin

3.       System verifies customer and displays personal details entry form

4.       User enters personal details into form and clicks save

5.       System presents a confirmation screen informing the user that the  information has been saved

6.       End Use Case

Alternative Course 1a.     System is down

1a1.   User emails personal information to System Admin

1a2.   Proceed with Alternative Course 1b.

1b.     System Admin enters customer information

1b1.   System Admin User accesses “customer information” functionality

1b2.   System Admin User enters personal information emailed by customer

1b3.   End Use Case

3a. System Cannot verify User

3a1.   Customer emails System Admin for credentials reset

3a2.  Resume at step 3

As shown in this use case example, there is more than one way to provide personal information to complete a customer profile. We could have done one of two things to illustrate this:

  1. Create a new use case to indicate the email route
  2. Create an alternative path in this use case

We chose to go with option 2 and created the alternative path. The reason being that the alternative path still concerns the same actor, system, and use case goal (complete customer profile). In addition, there are relatively few steps involved in this alternative course to warrant creating a new use case. If there were too many steps, then a new use case would have been the appropriate action to take. If new actors and goals are introduced, it is ideal to create different use cases even though the steps may seem similar.

Rule #2: Don’t confuse use cases with user stories

Use cases and user stories are two different animals. Use cases represent formal requirements while user stories capture the benefits derived from a system function in one or two sentences  (e.g., “As a customer, I want to enter personal information to complete my customer profile”) in the language of the everyday user.

Rule #3: Focus on process vs. system functionality

When working with use cases, make sure that the language and flow of the courses (primary or alternative) focus on the user’s execution of a process rather than the underlying system functionality. In a use case, we aim to capture the interaction of the user with the system and not necessarily detailed system logic.

Rule #4: Reference other use cases when appropriate

Let’s take the use case example above, which has a primary course that started to become too long. Ideally, a use case’s primary course should have no more than 10 steps. If you run into a scenario like this, determine if there are parts of the primary course that can be made into their own use case.

For instance, if a user had to go through user confirmation were they had to receive an email and confirm their credentials, then a new use case would likely need to be created. We might call this new use case “UC004: Confirm Registration”. In UC001’s primary course, instead of including steps to confirm the account, we can instead replace the steps with something like:

“Step 9. Confirm account registration see Use Case UC004”

This reference just saved us five plus lines of steps in one use case!

Rule #5: Treat “if” statements with caution

Using “if” statements as triggers to indicate different states in the interaction of the user with the system can be a bit tricky. Using the same use case example above, suppose we had not created an alternative course for an email request for login credentials. Instead, we could have stated in the primary use case that “If the system is not available, then email System Administrator” for login credentials. This could work. However, it is not a good practice because  a use case with multiple “IF” triggers quickly becomes difficult to follow and the distinction between the primary and alternative courses becomes obscured. When the “if” statements start to increase, it is best to create separate use cases and, where necessary, reference them as mentioned in Rule #4.

Conclusion

Following these five rules for effective use cases will help you write use cases that capture system requirements and concisely describe the system’s functionality from the user’s (actor’s) perspective.



Traceability 101

February 8, 2012

You’re the project manager of a large project and from a requirements perspective it looks like everything is on track for success:

  • Business Requirements. Written and Approved. Check.
  • Functional Requirements. Written and Approved. Check.

Seems like everything is covered. Except… where’s your traceability matrix? You have one, right? Read more



The Venn of IT Solution Success

December 27, 2011

Changing technology in an enterprise requires that you have the following “must have” skills in your people:

  1. Leadership & organization
  2. Business acumen
  3. Technical chops

Normally, labor in a project is divided up according to these specialties – i.e. developers have the technical chops, business analysts have the business chops, project managers organize themselves and everyone else. Throw them all into a pot, stir vigorously and…presto! A successful project.

Hardly. Read more