Archives: Projects

(This was originally published on Optimal Partners’ blog.)

In our first segment of the How to Migrate to An Online LMS (Learning Management System) series, we provided a general overview of the project, covering the three main stages: planning, configuration, and deployment. Our last entry discussed the steps for configuring your new system, but now we will go into more detail on the deployment stage—ranging from the types of training programs you should provide to how to best communicate to your end users. With the right knowledge and tools, you’ll be able to deliver a truly valuable product to your organization.

Communication is Key

Any Higher Ed IT professional will attest that communicating to end users about a system rollout can make or break a project. Even if the implementation goes smoothly up to that point, a botched transition to support can damage the users’ perceptions of the product. This isn’t just our opinion; a recent survey of students and faculty, as well as a series of interviews with university staff that we conducted, showed that users thought their IT departments needed to improve how they contacted users about new systems and how they conveyed the importance of those systems during rollouts. Each type of end user may respond differently to the methods of communication that you choose, so you will need to take special care to ensure that they are made aware of your project, know how it can help them, and understand how to use the product.

One email may initially get your message across to your users, but it will eventually get buried in their inboxes.

Higher Ed users are very busy and always on the go, so email shouldn’t be your only avenue for contacting them. One email may initially get your message across to your users, but it will eventually get buried in their inboxes. To counteract this, you will need to provide a more easily accessible source of information, like a page on your university’s website. This will ensure that your users can quickly find what they need if they ever want to know more, instead of digging through emails or having to contact your support team.

Inspire your end users to want to learn about the new system. This isn’t about trying to sell them on minor upgrades or software updates; you should be able to present each type of user with a series of features that will make their day-to-day work easier. Once they know how the new LMS will benefit them, they’ll be more willing to learn about the project and help support their peers during the transition.

Encourage user engagement by getting students and faculty involved in your outreach campaign. Asking for feedback can help give users a sense of ownership over the new LMS. It doesn’t have to be a boring procedure; you could try having contests for users to incentivize learning about the new system, or set up a forum for users to answer each other’s questions. You could even spur engagement on social media by creating a hashtag for users to link photos of themselves using the new system. If you are going to use the social media route, it is important to maintain your social media presence during any hashtag promotions. It is very easy for one disgruntled user to derail your campaign, but quickly and politely responding to users’ posts will help keep the conversation in line with your message.

It’s good practice to be proactive by expressing how beneficial the new LMS can be and how your team is available to help with the transition.

Positivity is key to a successful transition to support. If users have issues that aren’t dealt with quickly, they’re likely to tell other users about their experiences, spreading negativity about your project before you have the time to respond to everyone’s concerns. It’s good practice to be proactive by expressing how beneficial the new LMS can be and how your team is available to help with the transition. Remember, your users will need to put a lot of work into learning about your new LMS and how to use it, so it’s important to let them know about all of the support options available to them so that they know exactly who to contact if they have any questions or concerns.

Offer Flexible Training Programs

Make sure that your choices reflect the needs of your user base and can accommodate for different types of users.

The next goal in this phase of the project is to train your users how to make use of their system. Luckily, there are many different approaches you can take to adjust your training program to fit your users’ needs. Depending on the preferences of your faculty and staff, you should decide between one of three major approaches for teaching about your new LMS. Asynchronous training involves an online component where users learn about the system on their own time through instructional software. Synchronous training, on the other hand, is primarily done face to face, involving a designated instructor teaching many users at once. The third option is a mix of both strategies, blending online accessibility with the perks of engaging with users in person. However you plan to provide training for your new LMS, make sure that your choices reflect the needs of your user base and can accommodate for different types of users.

Choosing your specific approach for user training isn’t everything, however. The results of our survey and interviews with Higher Ed end users revealed a pattern for their training preferences. Many staff and faculty were frustrated with the one-size-fits-all approach to learning, where each person is given the same amount of training, regardless of varying proficiencies with similar products. Many of the responses we received suggested an approach that would allow more tech-savvy users to test out of extended training while keeping it available for others that need more time with the system.

Last Minute Preparations

Your full go live date is quickly approaching. This is the time to make any last minute preparations to ensure that your project transitions to support without a hitch. Set aside resources initially for a stabilization phase. This involves project team members closely monitoring the use of the new LMS for any possible issues and responding to them in turn. The stabilization phase should take between two weeks to a month, after which the first wave of bugs should subside, and your support team should be ready to take over.

You’ll need to make sure that your support team and help desk have the knowledge to quickly and thoroughly respond to any problems your users have once the system is live. This is where all of the documentation you’ve done throughout the project comes in handy. That being said, it’s still important to maintain your documentation efforts throughout this process to keep your support team’s information up to date. Create a dedicated site to keep track of bug fixes and known issues. It may also be useful to create an FAQ for your new LMS, to help catch any common issues and lighten the workload. If a problem becomes too much for your support team, they should bring it to the project team’s attention and continue onto other problems.

Now that everything is ready for your new LMS to go live, you’ll need to work around your users’ schedules to decide the specific time that would be best for the full rollout. Weekends are often preferable so that the transition disturbs as few users as possible. You should also work with your institution’s staff and faculty to assure that training is postponed during your go-live period. A seamless transition to a new LMS requires precise scheduling and coordination between your project team and your end users.

A Job Well Done

Give yourself a pat on the back. You’re now finished migrating to a new online LMS, and your support team is ready to take on the task of responding to user questions. With the right approach, you have successfully communicated with your end users about your project, trained them to use the new LMS, and deployed your new LMS without any major issues.

(This was originally published on Optimal Partners’ blog.)

We recently interviewed and surveyed a group of students, faculty and university staff about their experiences with IT implementations, in an attempt to discover how end users in Higher Ed prefer to be communicated with. Responses were varied, but many were accompanied by suggestions for how IT teams could better inform their users about new system rollouts. Hopefully, the feedback we received will be enlightening about the Higher Ed IT user experience and about how to ensure a smooth transition to support for your next project.

Connecting with Students

As was expected, a majority of the students that we surveyed noted difficulties with the implementation of new Learning Management Systems and how those changes were communicated to them. The impact these systems had on the students’ lives ranged from mild annoyances to causing issues that resulted in missing assignments and unsatisfactory grades. In some cases, students mentioned that, despite using their preferred method of communication, their university’s IT departments still failed to convey the most important information about their new system effectively. Communicating a systems rollout to students may seem daunting at first, considering how different Higher Ed IT users can be, but many of the responses we received suggested solutions that may surprise you.

Contrary to popular belief, however, many of the students surveyed said that they prefered to be contacted by email.

As many professionals in Higher Ed will attest, it is very difficult to connect with students because of how many messages they receive every day. Contrary to popular belief, however, many of the students surveyed said that they preferred to be contacted by email, despite their inboxes becoming cluttered very quickly. Many also mentioned that emails are a great initial way to contact users, but that they should be backed up with more readily available sources of information. This suggests that project teams need to spend more time on their emails for students, while also providing more places to find information on system rollouts that are easily accessible.

Students suggested in-class announcements and on-campus events as the best ways to raise awareness about upcoming rollouts.

Many of the responses we received also mentioned that students prefer being contacted in-person about IT implementations. A student that does not check their email frequently will be much easier to connect with if information is displayed where they spend a majority of their time. Some suggestions included in-class announcements and on-campus events as the best ways to raise awareness about upcoming rollouts. Even faculty and university staff chimed in, suggesting that students would respond best to face-to-face announcements rather than by text or social media. These real-world interactions may be more difficult to coordinate for an IT project team, but they could be very useful in conjunction with other forms of communication.

In addition to suggesting email and in-person events, many students also noted that they wished their universities’ websites were better sources for the information they needed. One student’s school struggled to keep their website up to date, which resulted in misinformed users, while another had thorough training available soon after a system rollout, but failed to provide resources for transfer students coming in afterwards. Both problems could have been prevented if their websites had up-to-date information on the specific system implementations.

If our survey results are any indication, it seems that there isn’t one specific way to meet every student’s needs. Thankfully, there are a lot of different ways to connect with students, making it easier to devise a plan that works best for the majority of your student base. The initial push for information is key to getting users acquainted with your project, but it’s also important to make useful information readily available throughout the transition to support and soon afterwards, while being direct, transparent, and quick to respond to feedback.

Contacting Faculty & Staff

While our feedback from students was fairly similar across the board, the faculty we surveyed had drastically different experiences with IT implementations. One faculty member was very pleased with the communication and training provided to them and had very little to say about how project teams could improve. On the other hand, another faculty member cited that they had “never experienced a seamless IT system implementation.” It’s almost impossible to have a perfectly smooth implementation, but that doesn’t mean it shouldn’t still be our goal.

One university faculty member mentioned that they were frustrated with how little importance was placed on end-user preferences during system implementations. “IT staff can go through months of providing samples of new software for us to test out and rate our preferences, only to have budgetary considerations override our consensus on the best software platforms.” It can be very difficult to establish realistic expectations for your end product when you look for feedback from users, but there are precautions you can take to avoid a similar mistake. If you are asking for faculty preferences on a deliverable without any guarantee that it’s a possibility, you’re putting yourself in a lose-lose situation. Before you give them options for how they want something to work, make sure that it’s within your budget to provide once they decide that it’s the best option. There are many factors that go into the Higher Ed IT decision-making process, but it’s vitally important to keep the user’s perspective in focus when deciding how your project will affect their work.

“I can’t remember a time when I had an issue with our IT department”

On the other side of the coin, the university staff that we interviewed had mostly positive experiences with system rollouts, which wasn’t surprising, given that they are more frequently involved in IT implementations than any other type of end user. “I can’t remember a time when I had an issue with our IT department,” one mentioned in our interview. Despite not having many issues personally, most of the staff we talked to still had suggestions for how to improve the end user experience.

Interestingly, neither staff nor faculty seemed to have issues with how information was initially communicated to them. One staff member, however, did mention that it is incredibly important to convey the perks of switching to a new system or software, i.e. how useful a new system will be, to give users an incentive to learn how to use it. The correct information may be available to them, but if busy users (which is often the case in Higher Ed) don’t want to transition to new products, then they’ll be much less willing to learn. Change is often difficult, which is why it’s important to nip any negativity in the bud before it spreads by being transparent, helpful, and positive about the transition.

University IT departments should create flexible training programs to appeal to the different types of end users

The faculty and staff we interviewed seemed much more frustrated with how training for new systems was presented to them during rollouts. Many people noted that project teams often provide a one-size-fits-all approach to training programs, leaving the more technologically proficient individuals annoyed and the less tech savvy ones confused. The consensus seems to be that university IT departments should create flexible training programs to appeal to the different types of end users. These programs should allow users with a strong understanding of the product to finish their training early, and perhaps offer support to their less acclimated peers. Making extended training mandatory to users that already have a firm grasp of the system serves only to irritate and frustrate; any extended program should work towards providing additional assistance for those users that have struggled with the initial training.

Conversation is Key

Preparing Higher Ed end users for a systems rollout can be stressful; there are so many different types of users, each with their own level of technical proficiency, and preferences for how software should operate. Thankfully, it seems like they’re more than willing to express their concerns and suggestions for improvement, as well as their positive experiences. Needless to say, we were at least a little surprised by the results of our survey and interviews, but it’s those surprises that make user feedback so important. We often, whether intentionally or not, take things for granted in regards to how we communicate with end users, and it’s refreshing to have an open forum of ideas to help us circumvent those expectations.

(This was originally published on Optimal Partners’ blog.)

We’ve all heard our fair share of headlines about Virtual Desktop Infrastructure (VDI) success stories at specific universities, but there are still some that advise others to avoid the project at all costs. The problem with VDI adoption is that the benefits are very appealing, but depend heavily on investments that may vary based on the specific institution that’s funding the project. We’re here to break down the pros and cons of VDI to see whether it’s worth the costs.

Shifting Costs

Each individual client will cost significantly less than a PC.

Easily the most attractive quality of VDI is the reduction in costs compared to a university’s traditional PCs. Instead of each client having its own expensive hardware, the bulk of the costs for installing and maintaining VDI is instead shifted to your institution’s data center. This means that each individual client will cost significantly less than a PC, with the added benefit of being able to convert older computers into VDI clients once they’ve reached the end of their lifespan. This may seem like a win-win, and in most cases it is, but you should also consider that your data center may need upgrading to compensate for the additional load of supporting those virtual desktops.

VDI is also popular for helping institutions save money on energy costs. Since each individual client has less hardware, they require less energy to run and therefore, cost less money to power. Having less moving parts also means that there are less individual pieces that will need fixing, making VDI clients last longer overall.

Added Convenience

You also don’t need to wait for spring break to roll out changes on VDI.

Virtual desktops bring with them the convenience of virtual support. Just as users are able to access their applications from any VDI client or personal device on campus, your IT department should be able to manage your virtual desktops from anywhere. You also don’t need to wait for spring break to roll out changes on VDI; your team can seamlessly change, upgrade, or install new applications for your users anytime without interrupting their work. If users need their desktops personalized with specific versions of software or they need access to apps that others won’t need, that can be done without leaving your office.

While the convenience of VDI for users is substantial, it’s what they won’t notice that may benefit them the most. Since nearly everything is stored server-side, your IT department won’t need to worry about users downloading viruses or stealing sensitive data from individual clients. That’s not to say that security is a non-issue, of course, but having your data center’s security deal with everything means less work for your tech support team in the long run.

A Lack of Processing Power

A classroom of graphic designers may require more processing power than a VDI client is reasonably suited to provide.

While it may seem like the benefits of adopting a VDI outweigh the costs, there is a reason why not every university is taking advantage of it: not all computing processes are created equal, which is easily demonstrated by what should and shouldn’t be done over VDI. A classroom of graphic designers may require more processing power than a VDI client is reasonably suited to provide. This is why most of the institutions that have adopted VDI do so gradually with a few clients at a time while maintaining a healthy supply of traditional clients.

Before adopting VDI, you should ensure that your institution has the framework to support it. The workload that would traditionally be done by an individual PC is instead transferred to your data center, meaning that your VDI clients will require a fast and stable network, both wired and wireless, to transfer all of their information, and a data center that is up to the task of handling the extra traffic.

If all of this sounds great to you and your IT department is ready to take on the project, then we suggest you take the time to consider your university’s specific needs. Long-term cost benefits, energy-saving, and convenience are all well and good, but in the end of the day, the decision of whether to adopt VDI is entirely based on what problems you aim to solve by implementing it.

(This was originally published on Optimal Partners’ blog.)

The phrase “time management” is thrown around a lot and it’s an essential tool for project management, but there are still some managers that are better at keeping track of their team’s time than their own. This can create bottlenecks and slow their team’s progress significantly, which is detrimental to Higher Ed IT projects where every stage of the project is time sensitive, leaving very little wiggle room for managers to work with. Luckily, there are a few key strategies that will help you get your work done quickly, so that you have the time to focus on how the rest of your project is doing.

10. Identify Your Bad Habits

Everyone has them. Sometimes it can feel like you are your own distraction, but that doesn’t have to be the case. If you need to get a task done at a specific time, try to put yourself in an environment that promotes giving the task your undivided attention. Make a list of the habits that could distract you, or help you procrastinate; maybe you’re always reading email from student services or advancement, or getting sidetracked by scheduling upcoming meetings. Whatever is on your list should be avoided for the time that you put aside for your current task, even if it’s an important part of your job. Everything that’s not an emergency can wait until you’re done with the task at hand.

9. Get Off of Social Media

We live in a world dominated by social media; important news and updates fly by your news feed at the speed of sound and disappear just as quickly. It’s very tempting to constantly check Facebook or Twitter to ensure that you never miss a beat. In spite of all its benefits, social media is the number one time waster for busy people like you. Just because many universities use social networks to engage with users does not mean you need to be constantly plugged in to those outlets. Everything has it’s place, but checking social media is bound to distract you from the task at hand. The next time you sit down to work, make sure to turn off notifications on your phone and be prepared to catch yourself anytime your cursor reaches to check your favorite news feed.

8. Focus on One Task at a Time

Many Higher Ed IT professionals pride themselves on their ability to multitask, especially when they have five meetings in any given day. The problem isn’t with multitasking itself, but rather in its application. Some tasks can be done on the go or when your mind is already on something else, but that’s not going to work for every situation. If your current job needs to be done quickly, give it the focus it deserves. You’d be surprised by just how many things you can complete when you focus on each one individually, rather than trying to complete three at a time.

7. Take a Break

Sometimes it feels like your project requires your undivided attention at all times. What if something happens right after you turn off your phone to take a break from work? Don’t worry, your project will be right where you left it when you come back from giving your mind a rest. Time management isn’t always about trying to cram as much productivity into the shortest amount of time; sometimes it’s about rationing your mental resources to get your work done well and on schedule. Instead of jumping to your next task, look at the work you’ve already completed and decide whether it’s time to take a break. If you’re working on campus, take advantage of what that environment affords you: go to a cafeteria for lunch or eat outside, or relax at a coffee shop and catch up on emails. Sometimes a break isn’t realistic given your schedule, but if time permits, a pause in your day could give you the energy and enthusiasm you need to be even more productive afterward.

6. Start Small, Build Big

When you’re faced with a large job to finish, one of the hardest things to do is start. Get the ball rolling by separating your task into smaller parts and giving yourself a short amount of time to complete each one. Once you’ve finished your first attempt, it’ll be much easier to keep going, using the momentum you’ve built up to finish the job without having to worry about splitting your task up any further.

5. Keep Yourself Accountable

Working on a team can help keep you motivated and productive, especially when others rely on you to get your job done on time. If you’re having trouble keeping on track for your own tasks, think about all of the other tasks that you’ll be able to complete once your current one is done. If that’s not encouraging enough, ask one of your team members or an assistant to remind you how important your current job is. Promise your team that you’ll demo some of your deliverables at your next daily standup meeting. It may sound silly, but a lot of people work better when others are relying on them, and creating those expectations for yourself or asking someone to motivate you can drastically help with your productivity.

4. Set Deadlines

Proper time management is about convincing yourself to get work done within an appropriate amount of time, but setting a specific time frame for your job can often be the most important piece of the puzzle. Without a set start and end time, it can be difficult to keep track of your progress and keep yourself motivated to finish your current task. Set a deadline for each task, even if it’s not necessarily a high priority for your project. It may also help to let other people know about your deadlines, to help keep yourself from pushing them back further and further on your schedule.

3. Break Up Larger Tasks

If your first thought when sitting down to chip away at your list of tasks is to complete the smaller ones first, you may find it hard to ever get to your larger tasks. Instead, try taking your more time-consuming jobs, breaking them into smaller chunks, and mixing those pieces in with your other tasks. If you’re creating a project plan for a large, complex project, try breaking that process into phases and deal with each phase individually. This will guarantee that you always have time to make progress on the jobs that require more investment, without forgoing the smaller ones that can quickly accumulate and bring your productivity to a standstill.

2. Delegate Less Important Tasks

If you’re getting overwhelmed with the number of tasks you need to complete in any given day, then it may be time for you to think about hiring a project assistant. Many managers would prefer to get everything done themselves, but that’s just not reasonable in most cases. Make the best use of your time by delegating tasksthat don’t require your specific expertise to someone else. This will ensure that the tasks that your team is relying on you to complete will get done without letting the smaller jobs pile up.

1. Learn to Say “No”

As a Higher Ed IT project manager, this may be the most difficult change to get accustomed to, considering that your job involves checking in on your project team leaders, making sure everything is going as planned, and helping people whenever possible. We’re not going to suggest that you stop doing your job, but it may be necessary to set aside time for your own work. If you notice yourself responding to emails throughout the day, schedule specific times to read them, and spend the time in between focusing on the tasks that you need to complete. If something is brought up that is low priority compared to your current task, put it aside and schedule a time later on for you to deal with it. Your team will understand if you close your door, whether metaphorically or otherwise, at a specific time each day. High priority issues will arise once in awhile, but the majority of your distractions can be kept on the backburner until your most important job is completed.

Project managers like yourself may deserve a chance to procrastinate, considering they spend their workdays making sure that deadlines are met, but sometimes it can be just as important to get the tasks that don’t have a specific deadline met done. The last thing you want is for your list of jobs to pile up, especially if someone on your project team is relying on them. Hopefully, these tips can help you keep track of your own time, so that you can focus on managing everyone else’s.

(This was originally published on Optimal Partners’ blog.)

The Agile method is a project management strategy used by thousands of companies and Higher Ed institutions alike. Agile projects involve continuously updating clients with working products and iterating on development throughout a series of work cycles called sprints. After a sprint, an Agile team will reevaluate their development processes to ensure that their client’s vision is carried out. Once necessary changes have been made from previous sprints, a new sprint is started and the cycle continues. While the Agile method is often used for software development, its core philosophies can be applied to almost any type of project, team, or process. In fact, this blog is developed and managed through our own form of Agile methodology.

The Agile Manifesto

Agile development has a long history, which culminated in the creation of the Agile Manifesto, a document that outlines twelve principles that each Agile project should follow:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
  Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity–the art of maximizing the amount of work not done–is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The Agile method values interaction and collaboration over extensive planning, contract negotiation and doing things “by the book.” Sometimes things change, visions evolve, and scopes require adjustment, but instead of going back to the drawing board entirely, Agile allows teams to respond to those changes quickly and efficiently to the benefit of their clients. Although it’s not a cure-all for every project that needs improvement, Agile allows teams to thrive in environments where it is difficult to estimate the duration or scope of a project.

Learn the Lingo

Like most lessons in project management, the Agile method has its own terminology to learn before starting off. Some Agile-specific phrases are more self-explanatory than others, such as the product roadmap, an overarching plan for the development of the product’s features, or sprint review, but others may require some explanation.

First, and possibly most important of all, is the story. A story describes a requirement that must be met by a team in one iterative development cycle or sprint. It should describe the needs of a specific type of user and should be simple enough to be written out in a short sentence. A standard story template would read as follows:

Those individual stories come together to represent the functionality that the team needs to deliver to complete each sprint within the project.

Stories often combine together to create what are known as epics, or more overarching goals for the project that may have to be completed over multiple sprints. In the context of the previous example, allowing users to adjust account settings would be one story within the epic of allowing users to log in and use their accounts on the website.

Once stories have been established for a project, they are divided up among the development team and prioritized into sprints. The velocity of any given sprint describes the amount of stories that are available for that sprint.

During Agile projects, working directly with your client is ideal, but is often not viable.
A specific team member, known as the Product Owner, will be responsible for representing the client’s vision in their absence, and working with the development team to ensure that their work reflects the client’s needs at all times.

Before jumping into development, an Agile team must also assign one team member to the role of Scrum Master. The Scrum Master acts not as a manager for the team, but rather as a middleman between the Product Owner/client and the developers. They ensure efficiency throughout the development process and make sure that everyone is on the same page at all times.

THE STRUCTURE OF AN AGILE PROJECT

Agile development is all about the iterative process, where each overarching step should be returned to and reevaluated eventually. To be truly Agile you’re going to need to get rid of your one hundred page planning document and be prepared to iterate on any procedure that needs improvement to develop the best product for your client. With that in mind, we’re going to break an Agile project into six stages that individually represent iterative development cycles with vastly different durations.

It Starts With A Vision

Each project starts off with a product vision, or a planned goal for the product being developed. In Agile’s case, the product vision may change drastically over the lifespan of the project, depending largely on its scope and time frame. Once the product vision is established, the Agile team then works alongside the Product Owner to create the product roadmap.

Releasing On Time

An important part of Agile development is getting working functionality in front of the client as soon as possible. The release planning process tasks Agile teams with establishing loose deadlines for specific functionality and prioritizing development to get the most important stories in a functional state. Your team will want to return to release planning once the new releases need to be planned for. This could be at the end of every sprint or it could be every 4 months, and relies entirely on the progress and scope of your project.

On Your Mark, Get Set…

Sprints require their own planning sessions to establish what features will be developed and what each team member will be working on during that sprint. Developers should provide estimates for how long the development of each story will take during the sprint planning meeting. A sprint could last from one to four weeks, meaning that stories should be chosen not only by priority, but also by whether or not they can be finished on time. A popular tool used during these meetings is the sprint board, a visual representation of each story and the tasks needed to complete them within the time frame.

The Daily Scrum

The shortest iterative cycle in Agile is the daily scrum or stand up meeting. A scrum is a daily meeting in which the team takes approximately 15 minutes to discuss what was accomplished the day prior, what will be worked on that day, what obstacles each person is facing, and what needs to be worked on to meet daily goals. Having multiple layers of iterative development from annual reevaluations to daily stand ups allows Agile teams to react to changing requirements quickly and reprioritize to match any new goals.

Reviewing the Sprint

Once a sprint is completed and product functionality is in a working form, it’s time for the Agile team to present the resulting stories to the client. This meeting allows the client a chance to give feedback on the product in its current form, so that any concerns or additions can be accommodated in the next sprint. Depending on the specific team, an Agile project may require acceptance testing during the sprint review. Put simply, Acceptance Testing is the process of testing the product’s functionality based on the requirements set out in the product vision. Whether a team tests in between sprints or not, they should perform Acceptance Testing at the end of the project to ensure that the product meets the requirements that were initially agreed upon.

A Look Back

The end of each sprint also offers Agile teams a chance to reevaluate their development processes and learn from past mistakes during the sprint retrospective. While the sprint review is more about functional deliverables, the sprint retrospective is more concerned with adjusting procedure than dealing with specific functionality. Once the team has learned all there is to learn from their latest sprint, the cycle repeats itself until the product is finished and the client is pleased with the results.

The Cycle Continues

The Agile method may not be for everyone, and in fact, many teams aren’t able to commit themselves entirely to its methodologies, but it does offer developers the flexibility to deal with significant changes, even those late in a project. If this is the kind of process that your project could benefit from, we hope that our guide has given you enough information to at least get you started. If you’re interested in learning more about Agile development, let us know in the comments below and we’ll be glad to explore it more in-depth in a future article.

(This was originally published on Optimal Partners’ blog.)

We’ve heard our fair share of opinions on whether working in Higher Ed IT is “worth it,” but while we recognize that it’s not for everyone, we’d like to confront some lingering misconceptions about the field that are especially popular. After browsing through several online communities that involved IT professionals looking to get into Higher Ed IT, we decided to deal with each of the most prominent issues.

You’ll Get Left Behind

The most common problem people cite about working in Higher Ed IT is that the field is slow to adopt new technologies. Being “left behind” is something that any IT professional should be careful to avoid, but it’s not nearly as big of a deal in Higher Ed as people seem to think. Consider this: students are about as cutting-edge as you can get when it comes to user expectations, especially in terms of how they prefer to be communicated with. Faculty members may require access to new tools and services to ensure that what they’re teaching is actually preparing their students for future careers. If universities are as slow to keep up with the newest trends as people say, then they wouldn’t be able to supply their faculty with the tools they need to teach or the resources their students need to learn.

Not all institutions are early adopters, as there are a lot of different factors that play into what technologies a university IT department has access to. They’re often working with very tight budgets, and trying to appease different types of users, so they have to be judicious when deciding where their funds go. It’s also not always the best idea to upgrade for the sake of upgrading; many faculty, staff, and students simply want their devices and software to function, so that they can focus on their work. Adopting a new piece of tech comes at the additional cost of forcing users to relearn how to do something that, in many cases, they could do well with what they already had.

Higher Ed Users Are…

There’s a distinct culture in Higher Ed that draws in people that are often more friendly, understanding, and willing to learn than others.

We’ve all heard user interaction horror stories, whether it’s from a coworker at the water cooler or from a Dilbert comic strip, but some seem to think that Higher Ed users are worse than others. There are always going to be difficult users to work with at any IT job, from students that need their passwords reset, to professors that call you asking how to get rid of pop-ups, but the idea that users at universities or colleges are any worse to deal with than any other type of user is preposterous. The fact is, there’s a distinct culture in Higher Ed that draws in people that are often more friendly, understanding, and willing to learn than others. University IT professionals deal with users whose job it is to be receptive to new ideas, users that are trained to be patient with others, and users that are at the cutting edge of their fields. You’re bound to find a bad egg once in awhile, but Higher Ed users are usually easier to work with.

A Great Work/Life Balance

Despite what you’ve read so far, not all of the misconceptions about working in Higher Ed are necessarily negative. One of the biggest reasons we found that people like working in the field is the balance it provides between one’s work and personal life. While there is a higher likelihood that IT professionals will enjoy more vacation time and a more flexible workload, that’s not always going to be true. There are times, especially when a project is about to go live, that IT departments can go through serious crunch time. There’s also going to be a large degree of variety based on what type of project you’re working on at any given time, which can be further complicated by your seniority and job description. While it may seem backward to correct a positive generalization, we’d rather any prospective Higher Ed IT professionals know what they’re getting into rather than jump into a job based on misunderstandings.

Not a Viable Career Path

Higher Ed thrives off of personal development, both in the classroom and the work environment.

While it is true that some IT jobs in Higher Ed pay less than a comparable job in the corporate world, it’s not true that your career paths will be limited. Higher Ed thrives off of personal development, both in the classroom and the work environment, meaning that you will inevitably meet people that are invested in your success and will help you achieve your goals. Financially, Higher Ed IT jobs vary just as jobs in other fields, based mostly on your job description and specific institution, so you’re not guaranteed to take a pay cut by accepting a job at a university. Rest assured that there are thousands of IT professionals that take jobs in Higher Ed every year and continue to advance their careers in the field.

Higher Ed IT Isn’t Worth It

When everything’s said and done, the ultimate question that people ask about working in university IT is whether or not it is “worth it.” The problem with that question is that the answer depends entirely on your end goals and expectations for your new job. Is your shiny new office at a university going to make you money hand over fist and provide a hassle-free work environment? Probably not, but that doesn’t mean it’s not a future worth investing in. If fantastic benefits, vacation time, and a work culture devoted to making the world a better place sound appealing, then Higher Ed IT may be for you.

The goal of this article is not to convince every aspiring IT professional that Higher Ed is the guaranteed best route for them to take in their career. Instead, we aim to show that working in a college or university isn’t as black and white as some people would like you to think. Not every potential job is a pay cut, not all of the users are insufferable, and it doesn’t always offer a better work/life balance, but in the end, whether or not applying for a job in Higher Ed IT is worth it is entirely up to you.

(This was originally published on Optimal Partners’ blog.)

Each new Higher Ed IT implementation presents the challenge of balancing the unique needs of each type of user with the needs of the institution as a whole. You can’t always please everyone, but with the right communication channels, your team can do their best to create a product that meets the expectations of as many faculty, staff, and students as possible. Proper communication isn’t just about engaging with users on new implementations or training them to use new technology, however; it is just as important to listen to your user base about how technology can help improve their experiences on campus.

This past summer we had the pleasure to sit down with Melissa Pacheco and Tobias “Toby” Stapleton from the University of Massachusetts, Dartmouth to discuss their thoughts on technology in Higher Ed. We also sent out survey questions to faculty members on social media to hear from part of the user base that is traditionally less involved in IT implementations. The responses we received brought up many important topics, providing insight into what Higher Ed users expect from IT projects as technology advances and new challenges arise.

Universities should be better utilizing social media to engage with prospective students, as well as those currently enrolled.

Melissa Pacheco, Senior Programs Specialist of the Charlton College of Business, told us that she thinks technology should be used to better engage with students, getting them to work together and become more active in the campus community. She explained that “everyone is getting glossy eyed over email and text alerts,” making it all the more important for universities to find new avenues to communicate and engage with students. Toby Stapleton, Director of the Center of Innovation and Entrepreneurship, had similar concerns, adding that university enrollment is one of the biggest issues facing Higher Ed. He suggested that universities should be better utilizing social media to engage with prospective students, as well as those currently enrolled.

While the future of university IT is a much-debated topic, there are a few key points that are largely agreed upon: in the next few years, universities will continue to improve user engagement through new technology, Ed-tech professionals will have to negotiate funding for new projects, and Higher Ed’s use of information technology will become progressively more optimized to accommodate for smaller budgets.

“Technology in Higher Ed needs to slow down” and become “increasingly invisible.”-university faculty member

What may be the most important discussion to have with your user base is how much colleges and universities should rely on new technology. For example, when asked how IT could improve Higher Ed, Stapleton told us that more technology is a must, specifically in how staff, administrators, and IT teams communicate. He expressed frustration over the fact that current procedures in Higher Ed give little wiggle room for attending meetings, explaining that “if you’re not physically at the meeting, you’re not at the meeting.” Video conferencing and other forms of communication beyond text and email could help alleviate this issue, Stapleton suggested. On the other hand, a university faculty member responded to our survey question with a very different perspective, writing that “technology in Higher Ed needs to slow down” and become “increasingly invisible.” They hoped that the future of university IT would focus more on making faculty members’ jobs easier, as well as making it easier for students to learn, rather than being innovative for the accolades of university administrators.

Pacheco predicted that the popularity of e-learning would not increase until programs are specifically designed to help get students more involved.

One of the most popular examples of technological advances in Higher Ed is the continued development of MOOCs. The faculty and staff we interviewed, however, seemed less than enthused about the highly publicized trend. While acknowledging that online courses create opportunities for those that aren’t as comfortable in the traditional classroom, Pacheco predicted that the popularity of e-learning would not increase until programs are specifically designed to help get students more involved. She expressed concerns about whether fully online courses were teaching the “essential learning skills” to help students succeed in their future careers. When asked about MOOCs, Stapleton drew on his experience in the private sector, explaining that “networking and interaction” are very important for many students studying business. He continued, saying that face-to-face courses can offer many learning opportunities that e-learning, in its current state, cannot provide. An anonymous faculty member was more open to the idea, writing that students “can truly learn online.” They then admitted, however, that the e-learning courses that they had taught did not resemble “a MOOC in any way, shape or hype.”

The future of technology in Higher Ed will no doubt be driven by innovation, but it’s important to remind ourselves that new does not necessarily equate to helpful. Sometimes the solution to a problem can be just a case of process improvement or optimization. It’s important to remember that, while new tech has the potential to have a huge impact on your institution, it’s essential to define your goal and figure out how technology can help get you there, not the other way around. Higher Ed is an intricate ecosystem of users, each with their own specific wants and needs for the technology they use every day, and it’s the goal of IT project teams to ensure that their products meets those needs.