Higher education: Managing risk and change in ERP/SIS implementation 

We humans have a complex attitude toward change. In one sense, we like finding it. For instance: “Now I can buy something from the vending machine!” In reality, we try to avoid change as much as possible. Why? Because it’s frightening. Consider this quote from Mary Shelley’s Frankenstein: “Nothing is so painful to the human mind as a great and sudden change.”

The key word in that quote is “sudden.” Because the more we prepare for change, the less painful it becomes. One crucial way to prepare for change is to assess how ready we are for something new.

Which brings us to you. The fact you are reading a blog post with the words “Readiness for Enterprise Systems” in its title suggests that you have considered, or are considering, changing your institution’s Enterprise Resource Planning (ERP) system or other enterprise software, such as LMS, SIS, CRM, etc. This change is no minor adjustment.

Enterprise systems are complex, impacting institutional activities at many levels, from managing student records, finances, and human resources, to enabling student enrollment and registration. Is your institution prepared for transformation across the organization? To find out, assess your institution’s readiness for change. To help illustrate what an assessment might entail, I’ll outline BerryDunn’s method.

Step #1: Understanding Key Indicators for Readiness
When assisting a client to determine readiness, BerryDunn begins engaging stakeholders from across the institution (e.g., staff, faculty, and students) to understand the current environment. This allows us to address seven key indicators for change readiness:

1. Stakeholder Buy-In. The key to success in changing an ERP platform is for users to understand the value that the change will bring. “Do stakeholders know how the new system will benefit them? Or, from their perspective, ‘What’s in it for me (aka, WIIFM)?’”
2. Executive Sponsorship. In order to obtain stakeholder buy-in, leaders have to communicate effectively with various parties about change. They will be required to display strong and consistent leadership when stakeholders are faced with challenges with vendors, timing, scope creep, or other issues. “Are leaders prepared to lead the charge? Are they committed to change?”
    
3. Vendor Ability. Each institution has specific operational needs and programmatic objectives. ERP vendors will highlight their strengths and may de-emphasize weaknesses that may exist in their products. “Are vendors actually able to meet the institution’s functional needs and align their software with strategic objectives?”
    
4. Business Process Redesign. As mentioned above, it can be a struggle to align operational needs and programmatic objectives with vendor software. It’s even harder to achieve this while ensuring that, in implementing a new ERP system, an institution won’t lose valuable functionality that had been provided by the previous ERP. “Does the client fully understand the impact of a new ERP system on their processes?”
    
5. Project Management. Proactive project management is critical when changing an ERP system. Project managers need to engage institutional stakeholders, project sponsors, and vendors to keep them apprised of progress. “Are project managers empowered to maintain strong communication with all stakeholders?”
    
6. Data Governance. Another key indicator of ERP readiness is how well-defined data management is before implementation. ERP replacement projects are jeopardized when institutions don’t understand their data assets, or don’t know what level of data migration is necessary. “Is the institution prepared for data migration?”
    
7. Software Change Management. As ERP vendors move their products to the cloud, the software they sell will become less customizable, but more configurable. In other words, customers won’t necessarily be able to modify the base software code, but they will have more options in regards to defined fields, workflow, and user interface. Although this sounds limiting, it is actually an opportunity to streamline operations, add discipline to software update timelines, and require organizations to consider how to best complete their administrative functions. It is critical that an institution adapt its software change management practices to meet this reality. “Do the institution’s software change management practices reflect how software is delivered by vendors today?”

Step #2: Establish Agreed-Upon Metrics
Based on our analysis from Step #1, we then score these indicators of readiness based on a maturity scale from 0 – 5, using the following parameters:

Step #3: Score the Readiness of Your Organization
When you work with a consulting firm to assess your institution’s readiness for change, you should expect tangible takeaways that will inform stakeholders and provide a baseline metric. For example, we prepare a brief report that outlines a score for each of the seven maturity indicators of ERP readiness and provides supporting information for the basis of each score.

Here is an example of a Software Change Management section from a hypothetical ERP Readiness Report:

Finally, based on the weighted aggregate score of the report, BerryDunn determines the institution’s readiness for change, and provides recommendations on how to remediate low scores, and sustain higher scores.

Now for the good news. By setting a baseline early in your readiness planning, the scoring can be revisited over time to measure progress and provide project leadership with a simple, but effective, approach to tracking change management within the organization.

Next Steps
As you can see, implementing a new ERP doesn’t have to be a monstrous experience. You simply need to determine your ERP readiness, and follow a common-sense plan for change management. If you’d like to talk more about this process, send me an email: dhoule@berrydunn.com. I look forward to learning about the great changes your institution has planned.

We’ve all heard stories about organizations spending thousands on software projects, such as Enterprise Resource Planning (ERP), Electronic Health Record (EHR), or Student Information Systems (SIS) that take longer than expected to implement and exceed original budgets. One of the reasons this occurs is that organizations often don’t realize that purchasing a large, Commercial Off-The-Shelf (COTS) enterprise system is a significant undertaking. If the needs aren’t sufficiently defined, there can be many roadblocks, including implementation delays, increased cost, scope creep, and ultimately, unsatisfactory results (delayed or unfinished projects and cost overruns).

These systems are complex, and implementation efforts impact both internal and external stakeholders. Procurement often requires participation from different departments, each with unique goals and perspectives. Ignore these perspectives at your own peril. Here are key questions to consider for making the best buying decision:

1. Should we purchase software that similar organizations have purchased?
   As vendor consolidation has diminished the number of distinct COTS systems available, this question is increasingly common. Following this approach is similar to deciding to buy the car that your neighbor did, because they seem satisfied. How can you be sure that the systems purchased by similar organizations will meet your needs, particularly if your needs are undefined? One way to identify your organization’s needs—and to avoid costly mistakes down the road—is to identify requirements during the procurement process.

2. What are the functional and technical requirements of the system?Requirements are details that help describe a software system. There are two types of requirements and you need to understand and review both:
   
   Functional requirements. These define specific functions of a system to meet day-to-day needs of an organization or department. They describe the necessary system capabilities that allow users to perform their jobs. For example, “The vendor file must provide a minimum of four (4) remit-to addresses.” Functional requirements may also define the mandated state or federal capabilities required of a system, such as the ability to produce W-2 or 1099 forms.
   
   Technical requirements. These requirements identify criteria used to judge the operation of a system, rather than specific behaviors. They can be requirements that define what database the system must support. For example, “The system must support use of the client preferred database.” They may also describe security capabilities of the system, the ability to import or export data, or the ease of use and overall end-user interface.

3. Who should help define and document requirements for the new enterprise system?
   
   When it comes to documenting and revising requirements, work with your IT staff; incorporating technology standards into a set of requirements is a best practice. Yet it is also necessary to seek input from non-IT individuals, or business process owners from multiple departments, those who will use and/or be affected by the new software system.
   
   Help these individuals or groups understand the capabilities of modern software systems by having them visit the sites of other organizations, or attend software industry conferences. You should also have them document the current system’s deficiencies. As for those in your organization who want to keep the current system, encourage their buy-in by asking them to highlight the system’s most valuable capabilities. Perspectives from both new system supporters and those not so eager to change will help build the best system.
    
4. When do you revise enterprise system requirements? 
   It is always important to begin the software procurement process with a documented set of requirements; you need them to identify the best solution. The same goes for the implementation process where vendors use the requirements to guide the setup and configuration of the new system. But be prepared to revise and enhance requirements when a vendor solution offers an improved capability or a better method to achieve the results. The best way to approach it is to plan to revise requirements constantly. This enables the software to better meet current needs, and often delivers enhanced capabilities.

Be sure to document system requirements for an efficient process

There may be thousands of requirements for an enterprise system. To make the procurement process as efficient as possible, continually define and refine requirements. While this takes time and resources, there are clear benefits:

• Having requirements defined in an RFP helps vendors match the capabilities of their software systems to your organization’s needs and functional expectations. Without requirements, the software procurement and selection process has little framework, and from a vendor perspective becomes a subjective process — making it hard to get consistent information from all vendors.
• Requirements help determine specific tasks and activities to address during the implementation process. While applications can’t always meet 100% of the requested functionalities, it’s important to emphasize the requirements that are most important to users, to help find the system that best meets the needs of your organization.
• Requirements prove valuable even after implementation has begun, as they can help you test your system to make sure the software meets your organization’s particular needs before production use of the new system.

Our experienced consultants have led many software procurement projects and have firsthand knowledge about the challenges and opportunities associated with purchasing and implementing systems large and small. BerryDunn maintains an active database of requirements that we continually enhance, based on work performed for various clients and on technological advancements in the marketplace. Please contact us and we can help you define your requirements for large software system purchases.

There’s a good chance that your organization is in the position of needing to do more with less under the strain of staffing constraints and competing initiatives. With fewer resources to work with, you’ll need to be persuasive to get the green light on new enterprise technology initiatives. To do that, you need to present decision makers with well-thought-out and targeted business cases that show your initiative will have impact and will be successful. Yet developing such a business case is no walk in the park. Perhaps because our firm has its roots in New England, we sometimes compare this process to leading a hiking trip into the woods—into the wild. 

Just as in hiking, success in developing a business case for a new initiative boils down to planning, preparation, and applying a few key concepts we’ve learned from our travels. 

Consensus is critical when planning new technology initiatives

Before you can start the hike, everyone has to agree on some fundamentals: 

Who's going? 

Where are we going? 

When do we go and for how long? 

Getting everyone to agree requires clear communication and, yes, even a little salesmanship: “Trust me. The bears aren’t bad this time of year.” The same principle applies in proposing new technology initiatives; making sure everyone has bought into the basic framework of the initiative is critical to success.

Although many hiking trips involve groups of people similar in age, ability, and whereabouts, for your business initiative you need to communicate with diverse groups of colleagues at every level of the organization. Gaining consensus among people who bring a wide variety of skills and perspectives to the project can be complex.

To gain consensus, consider the intended audiences of your message and target the content to what will work for them. It should provide enough information for executive-level stakeholders to quickly understand the initiative and the path forward. It should give people responsible for implementation or who will provide specific skills substantive information to implement the plan. And remember: one of the most common reasons projects struggle to meet their stated objectives (and why some projects never materialize to begin with), is a lack of sponsorship and buy-in. The goal of a business case is to gain buy-in before project initiation, so your sponsors will actively support the project during implementation. 

Set clear goals for your enterprise technology project 

It’s refreshing to take the first steps, to feel that initial sense of freedom as you set off down the trail. Yet few people truly enjoy wandering around aimlessly in the wilderness for an extended period of time. Hikers need goals, like reaching a mountain peak or seeing famous landmarks, or hiking a predetermined number of miles per day. And having a trail guide is key in meeting those goals. 

For a new initiative, clearly define goals and objectives, as well as pain points your organization wishes to address. This is critical to ensuring that the project’s sponsors and implementation team are all on the same page. Identifying specific benefits of completing your initiative can help people keep their “eyes on the prize” when the project feels like an uphill climb.

Timelines provide additional detail and direction—and demonstrate to decision makers that you have considered multiple facets of the project, including any constraints, resource limitations, or scheduling conflicts. Identifying best practices to incorporate throughout the initiative enhances the value of a business case proposition, and positions the organization for success. By leveraging lessons learned on previous projects, and planning for and mitigating risk, the organization will begin to clear the path for a successful endeavor. 

Don’t compromise on the right equipment

Hiking can be an expensive, time-consuming hobby. While the quality of your equipment and the accuracy of your maps are crucial, you can do things with limited resources if you’re careful. Taking the time to research and purchase the right equipment, (like the right hiking boots), keeps your fun expedition from becoming a tortuous slog. 

Similarly, in developing a business case for a new initiative, you need to make sure that you identify the right resources in the right areas. We all live with resource constraints of one sort or another. The process of identifying resources, particularly for funding and staffing the project, will lead to fewer surprises down the path. As many government employees know all too well, it is better to be thorough in the budget planning process than to return to authorizing sources for additional funding while midstream in a project. 

Consider your possible outcomes

You cannot be too singularly focused in the wild; weather conditions change quickly, unexpected opportunities reveal themselves, and being able to adapt quickly is absolutely necessary in order for everyone to come home safely. Sometimes, you should take the trail less traveled, rest in the random lean-to that you and your group stumble upon, or go for a refreshing dip in a lake. By focusing on more than just one single objective, it often leads to more enjoyable, safe, and successful excursions.

This type of outlook is necessary to build a business case for a new initiative. You may need to step back during your initial planning and consider the full impact of the process, including on those outside your organization. For example, you may begin to identify ways in which the initiative could benefit both internal and external stakeholders, and plan to move forward in a slightly new direction. Let’s say you’re building a business case for a new land management and permitting software system. Take time to consider that this system may benefit citizens, contractors, and other organizations that interact with your department. This new perspective can help you strengthen your business case. 

Expect teamwork

A group that doesn’t practice teamwork won’t last long in the wild. In order to facilitate and promote teamwork, it’s important to recognize the skills and contributions of each and every person. Some have a better sense of direction, while some can more easily start campfires. And if you find yourself fortunate enough to be joined by a truly experienced hiker, make sure that you listen to what they have to say.

Doing the hard work to present a business case for a new initiative may feel like a solitary action at times, but it’s not. Most likely, there are other people in your organization who see the value in the initiative. Recognize and utilize their skills in your planning. We also suggest working with an experienced advisor who can leverage best practices and lessons learned from similar projects. Their experience will help you anticipate potential resistance and develop and articulate the mitigation strategies necessary to gain support for your initiative.

If you have thoughts, concerns, or questions, contact our team. We love to discuss the potential and pitfalls of new initiatives, and can help prepare you to head out into the wild. We’d love to hear any parallels with hiking and wilderness adventuring that you have as well. Let us know! 

BerryDunn’s local government consulting team has the experience to lead technology planning initiatives and develop actionable plans that help you think strategically and improve service delivery. We partner with you, maintaining flexibility and open lines of communication to help ensure that your team has the resources it needs.

Our team has broad and deep experience partnering with local government clients across the country to modernize technology-based business transformation projects and the decision-making and planning efforts. Our expertise includes software system assessments/planning/procurement and implementation project management; operational, management, and staffing assessments; information security; cost allocation studies; and data management.  

Read this if your organization is planning on upgrading or replacing an enterprise technology system.

It can be challenging and stressful to plan for technology initiatives, especially those that involve and impact every area of your organization. Common initiatives include software upgrades or replacements for:

• Financial management, such as Enterprise Resource Planning (ERP) systems
• Asset management systems
• Electronic health records (EHR) systems
• Permitting and inspections systems

Though the number of considerations when planning enterprise technology projects can be daunting, the greatest mistake you can make is not planning at all. By addressing just a few key areas, you can avoid some of the most common pitfalls, such as exceeding budget and schedule targets, experiencing scope creep, and losing buy-in among stakeholders. Here are some tips to help you navigate your next project:

Identify your IT project roles and resources

While most organizations understand the importance of identifying project stakeholder groups, it is often an afterthought. Defining these roles at the outset of your project helps you accurately estimate the work effort.

Your stakeholder groups may include:

• An executive sponsor
• A steering committee
• A project manager
• Functional leads
• A technical team

Once you’ve established the necessary roles, you can begin reviewing your organization’s resources to determine the people who will be available to fill them. Planning for resource availability will help you avoid delays, minimize impact to regular business processes, and reduce the likelihood of burnout. But this plan won’t remain static—you can expect to make updates throughout the project.

Establish clear goals and objectives to keep your technology project on track

It’s important that an enterprise technology project has established goals and objectives statements. These statements will help inform decision-making, provide benchmarks for progress, and measure your project’s success. They can then be referenced when key stakeholders have differing perspectives on the direction to take with a pending decision. For example, if the objective of your project is to reduce paper-based processes, you may plan for additional computer workstations and focus technical resources on provisioning them. You’ll also be able to measure your success in the reduction of paper-based tasks.

Estimate your IT project budget accurately

Project funding is hardly ever overlooked, but can be complex with project budgets that are either underestimated or estimated without sufficient rationale to withstand approval processes and subsequent budget analysis. You may find that breaking down estimates to a lower level of detail helps address these challenges. Most technology projects incur costs in three key areas:

• Vendor cost: This could include both one-time software implementation costs as well as recurring costs for maintenance and ongoing support.
• Infrastructure cost: Consider the cost of any investments needed to support your project, such as data center hardware, networking components, or computing devices.
• Supplemental resource cost: Don’t forget to include the cost of any additional resources needed for their specialized knowledge or to simply backfill project staff. This could include contracted resources or the additional cost of existing resources (i.e., overtime).

A good technology project budget also includes a contingency amount. This amount will depend on your organization’s standards, the relative level of confidence in your estimates, and the relative risk.

Anticipate the need for change management

Depending on the project, staff in many areas of your organization will be impacted by some level of change during a technology implementation. External stakeholders, such as vendors and the public, may also be affected. You can effectively manage this change by proactively identifying areas of likely change resistance and creating strategies to address them.

In any technology implementation, you will encounter change resistance you did not predict. Having strategies in place will help you react quickly and effectively. Some proven change management strategies include communicating throughout your project, involving stakeholders to get their buy-in, and helping ensure management has the right amount of information to share with their employees.

Maintain focus and stay flexible as you manage your IT project

Even with the most thought-out planning, unforeseen events and external factors may impact your technology project. Establish mechanisms to regularly and proactively monitor project status so that you can address material risks and issues before their impact to the project grows. Reacting to these items as they arise requires key project stakeholders to be flexible. Key stakeholders must recognize that new information does not necessarily mean previous decisions were made in error, and that it is better to adapt than to stick to the initial direction.

Whether you’re implementing an ERP, an EHR, or enterprise human resources or asset management systems, any enterprise technology project is a massive undertaking, involving significant investment and a coordinated effort with individuals across multiple areas of an organization. Common mistakes can be costly, but having a structured approach to your planning can help avoid pitfalls. Our experienced, objective advisors have worked with public and private organizations across the country to oversee large enterprise projects from inception to successful completion.

Contact our software consulting team with any questions.

While new software applications help you speed up processes and operations, deciding which ones will work best for your organization can quickly evolve into analysis paralysis, as there are so many considerations.

Case in point: Software as a Service (SaaS) model
The benefits of the SaaS model, in which a vendor remotely hosts an organization’s applications, are fairly well known: your organization doesn’t have to shell out for costly hardware, the vendor tackles upgrades, backups, data recovery, and security, and you have more time and money to focus on your business goals.

There are multiple factors to look at when determining whether a SaaS solution is right for you. We’ve compiled a list of the top three SaaS considerations:

1. Infrastructure and capacity
Your organization should consider your own people, processes, and tools when determining whether SaaS makes sense. While an on-site solution may require purchasing new technologies, hiring new staff, and realigning current roles and responsibilities to maintain the system, maintaining a SaaS solution may also require infrastructure updates, such as increased bandwidth to sufficiently connect to the vendor's hosting site.

Needless to say, it’s one thing to maintain a solution; it’s an entirely different thing to keep it secure. An on-site hosting solution requires constant security upgrades, internal audits, and a backup system—all of which takes time and money. A SaaS model requires trust in your vendor to provide security. Make sure your potential vendor uses the latest security measures and standards to keep your critical business data safe and secure.

2. Expense
When you purchase major assets—for example, hardware to host its applications—it incurs capital expenses. Conversely, when you spend money on day-to-day operations (SaaS subscriptions), it incurs operating expenses.

You should weigh the pros and cons of each type of expense when considering a SaaS model. On-site upfront capital expenses for hosting hardware are generally high, and expenses can spike overtime when you update the technology, which can be difficult to predict. And don’t forget about ongoing costs for maintenance, software upgrades, and security patches.

In the SaaS model, you spread out operating costs over time and can predict costs because you are paying via subscription—which generally includes costs for maintenance, software upgrades, and security patches. However, remember you can depreciate capital expenses over time, whereas the deductibility of operating expenses are generally for the year you use them.

3. Vendor viability
Finally, you need to conduct due diligence and vet SaaS vendors before closing the deal. Because SaaS vendors assume the responsibility for vital processes, such as data recovery and security, you need to make sure the potential vendor is financially stable and has a sustainable business model. To help ensure you receive the best possible service, select a vendor considered a leader in its market sector. Prepare a viable exit strategy beforehand so you can migrate your business processes and data easily in case you have any issues with the SaaS provider.

You must read—and understand—the fine print. This is especially important when it comes to the vendor’s policies toward data ownership and future migrations to other service providers, should that become necessary. In other words: Make sure you have final say and control over your data.

Every organization has different aspects of their situation to consider when making a SaaS determination. Want to learn more? It’s a snap! Contact the authors: Clark Lathrum and Matthew Tremblay. 

As a leader in a higher education institution, you'll be familiar with this paradox: Every solution can lead to more problems, and every answer can lead to more questions. It’s like navigating an endless maze. When it comes to mobile apps, the same holds true. So, the question: Should your institution have a mobile app? The Answer? Absolutely.

Devices, not computers, are how millenials communicate, gather, inform, and engage. Millennials, on average, spend 90 hours per month on mobile apps, not including web searches and website visits.

Students are no exception. A 2016 Nielsen study showed that 98% of millennials aged 18 – 24, and 97% of millennials aged 25 – 34, owned a smartphone, while a 2017 comScore report stated that one out of five millennials no longer use desktop devices, including laptops. Mobile apps have quickly filled the desktop void, and as students grow more reliant on mobile technology, colleges and universities are in the mix, creating apps to bolster student engagement.

So should you create an app? Here are some questions you should answer before creating a mobile app. Welcome to the labyrinth! But don’t be frustrated—answer these questions to help you avoid dead ends and overspending.

1. Is a mobile app part of your IT Strategy? Including a mobile app in your IT strategy minimizes confusion at all levels about the objectives of mobile app implementation. It also helps dictate whether an institution needs multiple mobile apps for various functions, or a primary app that connects users with other functionality. If an institution has multiple campuses, should you align all campuses with a single app, or if will each campus develop their own?

2. What will the app do? Mobile apps can perform a multitude of functions, but for the initial implementation, select a few key functions in one main area, such as academics or student life. Institutions can then add functionality in the future as mobile adoption grows, and demand for more functions increases.

3. Who will use the app? Mobile apps certainly improve engagement throughout the student life cycle—from prospect to student to alumni—but they also present opportunities for increased faculty, staff, and community engagement. And while institutions should identify the immediate audience of the app, they should also identify future users, based upon functionality.

4. Who will manage the app? Institutions should determine who is going to manage the mobile app, and how. The discussion should focus on access, content, and functionality. Is the institution going to manage everything in house, from development to release to support, or will a mobile app vendor provide this support under contract? Depending on your institution, these discussions will vary.

5. What data will the app use? Like any new software system, an app is only as good as its supporting data. It’s important to assess the systems to integrate with the mobile app, and determine if the systems’ data is up-to-date and ready for integration. Consider the use of application program interfaces, or APIs. APIs allow apps and platforms to interact with one another. They can enable social media, news, weather, and entertainment apps to connect with your institution’s app, enhancing the user experience with more content for users.

6. How much data security does your app need? Depending on the functionality of the app you create, you will need varying degrees of security, including user authentication safeguards and other protections to keep information safe.

7. How much can you spend for the app? Your institution should decide how much you will spend on initial app development, with an eye toward including maintenance and development costs for future functionality. Complexity increases costs, so you will need to  budget accordingly. Include budget planning for updates and functionality improvements after launch.

You will also need to establish a timeline for the project and roll out. And note that apps deployed toward the end of the academic year experience less adoption than apps deployed at the beginning of the academic year.

Once your institution answers these questions, you will be off to a good start. And as I stated earlier, every answer to a question can lead to more questions. If your institution needs help navigating the mobile app labyrinth, please reach out to me. 

Most of us have been (or should have been) instructed to avoid using clichés in our writing. These overstated phrases and expressions add little value, and often only increase sentence length. We should also avoid clichés in our thinking, for what we think can often influence how we act.

Consider, for example, “death by committee.” This cliché has greatly — and negatively — skewed views on the benefits of committees in managing projects. Sure, sometimes committee members have difficulty agreeing with one another, which can lead to delays and other issues. In most cases, though, an individual can’t possibly oversee all aspects of a project, or represent all interests in an organization. Committees are vital for project success — and arguably the most important project committee is the steering committee.

What Exactly is a Steering Committee?
It is a group of high-level stakeholders that provides strategic direction for a project, and supports the project manager. Ideally, the group increases the chances for project success by closely aligning project goals to organizational goals. However, it is important to point out that the group’s top priority is project success.

The committee should represent the different departments and agencies affected by the project, but remain relatively small in size, chaired by someone who is not an executive sponsor of the project (in order to avoid conflicts of interest). While the project manager should serve on the steering committee, they should not participate in decision-making; the project manager’s role is to update members on the project’s progress, areas of concern, current issues, and options for addressing these issues.

Overall, the main responsibilities of a steering committee include:

1. Approving the Project Charter
2. Resolving conflicts between stakeholder groups
3. Monitoring project progress against the project management plan
4. Fostering positive communicating about the project within the organization
5. Addressing external threats and issues emerging outside of the project that could impact it
6. Reviewing and approving changes made to the project resource plan, scope, schedules, cost estimates, etc.

What Are the Pros and Cons of Utilizing a Steering Committee?
A group of executive stakeholders providing strategic direction should benefit any project. Because steering committee members are organizational decision-makers, they have the access and credibility to address tough issues that can put the project at a risk, and have the best opportunities to negotiate positive outcomes. In addition, steering committees can engage executive management, and make sure the project meshes with executive management’s vision, mission, and long-range strategic plan. Steering committees can empower project managers, and ensure that all departments and agencies are on the same page in regards to project status, goals, and expectations. In a 2009 article in Project Management Journal, authors Thomas G. Lechler and Martin Cohen concluded that steering committees are important to implementing and maintaining project management standards on an operational level — not only do steering committees directly support project success, they are instrumental in deriving value from an organization's investments in its project management system.

A steering committee is only as effective as it’s allowed to be. A poorly structured steering committee that lacks formal authority, clear roles, and clear responsibilities can impede the success of a project by being slow to respond to project issues. A proactive project manager can help the organization avoid this major pitfall by helping develop project documents, such as the governance document or project plan that clearly define the steering committee structure, roles, responsibilities and authority.

Steer Toward Success!
Steering committees can benefit your organization and its major projects. Yet understanding the roles and responsibilities — and pros and cons — is only a preliminary step in creating a steering committee. Need some advice on how to organize a steering committee? Want to learn more about steering committee best practices? Together, we can steer your project toward success.

The relationship between people, processes, and technology is as elemental as earth—and older than civilization. From the first sharpened rock to the Internet of Things, the three have been crucially intertwined and interdependent. There would have been no Industrial Revolution, for instance, without entrepreneurs who developed new tools to facilitate new manufacturing methods.

Of course, the increasing complexity of processes and the rapid innovations in technology tend to eclipse the present role that people play in progress. On the surface the trend seems understandable, even reasonable, when it comes to implementing a new Enterprise Resource Planning (ERP) system. Implementing a new ERP system is one of the most daunting projects an institution can undertake. Some sobering statistics—over 70% of all implementations take longer than planned, while over 50% go over budget—illustrate why many institutions focus on selecting the right ERP model and purchasing the right software. This is important, yet there are two excellent and connected reasons why your institution should focus on the “people component” of an ERP implementation.

Reason #1: The Technology is Tenable

Companies have improved and vetted ERP systems over time, so that today there’s little chance your institution will purchase poorly designed ERP software. And you have multiple options. For example, you could pursue a hosted ERP model in which a data center houses your ERP system, or a Software as a Service (SaaS) model, in which a third party administers your ERP software. These options help minimize hardware implementation, maintenance, and incomplete attempts at full system utilization—which in turn saves you time, money, and headaches.

In short: You won’t have to bear the full brunt of the tech burden, and the software and hardware you purchase should work. This enables you to concentrate on the people component of the system.

Reason #2: People Propel the Processes

A higher education institution can optimize an ERP system to complete countless processes: automating registration, onboarding staff, processing financial aid, improving self-service capabilities, simplifying record-keeping, etc. Yet a system can’t do all this on its own (not yet, at least). People—both functional and IT staff—propel these processes. For this to happen, your institution needs to secure buy-in and equip people with vision, training, and resources.

People are wary of ERP projects, for good reason. When an institution decides to tackle an ERP implementation the onus often falls on already busy staff, some of whom may rather find a new career than manage a new system implementation. Your staff and their institutional knowledge are your greatest assets. It is important to empower staff to define how future-state business processes should work—and for you to remember that a common reason for ERP implementation failure is lack of engagement. Sometimes, those at the executive level make decisions without adequate input from the people who actually do the work. You will need to sharpen your “people skills” in order to educate stakeholders on the value of a new ERP system, and how the software will make their day-to-day roles and responsibilities more efficient and effective. To ensure that staff have the bandwidth to engage in this change, it is advisable to provide backfill for key administrative functions.

Designing business processes of a future-state system is arguably the most challenging part of an ERP implementation. Often, stakeholders don’t understand the new functionality that a future system can offer because they have only used the prior system. It is important to engage the ERP vendor early and educate your staff to ensure that they understand the possibilities when designing future-state processes.

Once you have designed processes, training should take center stage. And once again, people play a pivotal role in this process. Modern ERP systems usually require staff to fundamentally conduct business differently; this can require training not only on the new system, but also on other foundational technologies (e.g., the office suite) not relied upon before. It is important to identify these needs and incorporate them into your institution’s training plan up front.

An effective training plan needs to balance multiple types of training, ranging from formal classroom sessions to online learning and train-the-trainer sessions. Tech-savvy staff will be able to train other staff in using the new ERP system, which will not only increase the skill sets of said staff, but will also help them better understand how their roles fit within the larger picture of the institution. This, in turn, will organically improve communication and workflow, as well as lead to more collaboration and teamwork. The result: positive institution-wide change.

Moving Forward

Think about your institution’s focus when implementing a new ERP system—and be aware of the benefits that it could have for your staff, your students, and your bottom line. You will face other ERP-related challenges, such as selecting the right third-party vendor and facilitating change management. If you’d like to discuss some strategies for tackling these challenges, this process is easy—just send me an email.