COVID-

19 and the e-commerce explosion

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.

Read this if your company is considering outsourced information technology services.

For management, it’s the perennial question: Keep things in-house or outsource?

For management, it’s the perennial question: Keep things in-house or outsource? Most companies or organizations have outsourcing opportunities, from revenue cycle to payment processing to IT security. When deciding whether to outsource, you weigh the trade-offs and benefits by considering variables such as cost, internal expertise, cross coverage, and organizational risk.

In IT services, outsourcing may win out as technology becomes more complex. Maintaining expertise and depth for all the IT components in an environment can be resource-intensive.

Outsourced solutions allow IT teams to shift some of their focus from maintaining infrastructure to getting more value out of existing systems, increasing data analytics, and better linking technology to business objectives. The same can be applied to revenue cycle outsourcing, shifting the focus from getting clean bills out and cash coming in, to looking at the financial health of the organization, analyzing service lines, patient experience, or advancing projects.  

Once you’ve decided, there’s another question you need to ask
Lost sometimes in the discussion of whether to use outsourced services is how. Even after you’ve done your due diligence and chosen a great vendor, you need to stay involved. It can be easy to think, “Vendor XYZ is monitoring our servers or our days in AR, so we should be all set. I can stop worrying at night about our system reliability or our cash flow.” Not true.

You may be outsourcing a component of your technology environment or collections, but you are not outsourcing the accountability for it—from an internal administrative standpoint or (in many cases) from a legal standpoint.

Beware of a false state of confidence
No matter how clear the expectations and rules of engagement with your vendor at the onset of a partnership, circumstances can change—regulatory updates, technology advancements, and old-fashioned vendor neglect. In hiring the vendor, you are accountable for oversight of the partnership. Be actively engaged in the ongoing execution of the services. Also, periodically revisit the contract, make sure the vendor is following all terms, and confirm (with an outside audit, when appropriate) that you are getting the services you need.

Take, for example, server monitoring, which applies to every organization or company, large or small, with data on a server. When a managed service vendor wants to contract with you to provide monitoring services, the vendor’s salesperson will likely assure you that you need not worry about the stability of your server infrastructure, that the monitoring will catch issues before they occur, and that any issues that do arise will be resolved before the end user is impacted. Ideally, this is true, but you need to confirm.

Here’s how to stay involved with your vendor
Ask lots of questions. There’s never a question too small. Here are samples of how precisely you should drill down:

• What metrics will be monitored, specifically?
• Why do the metrics being monitored matter to our own business objectives?
• What thresholds must be met to notify us or produce an alert?
• What does exceeding a threshold mean to our business?
• Who on our team will be notified if an alert is warranted?
• What corrective action will be taken?

Ask uncomfortable questions
Being willing to ask challenging questions of your vendors, even when you are not an expert, is critical. You may feel uncomfortable but asking vendors to explain something to you in terms you understand is very reasonable. They’re the experts; you’re not expected to already understand every detail or you wouldn’t have needed to hire them. It’s their job to explain it to you. Without asking these questions, you may end up with a fairly generic solution that does produce a service or monitor something, but not necessarily all the things you need.

Ask obvious questions
You don’t want anything to slip by simply because you or the vendor took it for granted. It is common to assume that more is being done by a vendor than actually is. By asking even obvious questions, you can avoid this trap. All too often we conduct an IT assessment and are told that a vendor is providing a service, only to discover that the tasks are not happening as expected.

You are accountable for your whole team—in-house and outsourced members
An outsourced solution is an extension of your team. Taking an active and engaged role in an outsourcing partnership remains consistent with your management responsibilities. At the end of the day, management is responsible for achieving business objectives and mission. Regularly check in to make sure that the vendor stays focused on that same mission.

It’s one thing for coaching staff to see the need for a new quarterback or pitcher. Selecting and onboarding this talent is a whole new ballgame. Various questions have to be answered before moving forward: How much can we afford? Are they a right fit for the team and its playing style? Do the owners approve?

Management has to answer similar questions when selecting and implementing a cybersecurity maturity model, and form the basis of this blog – chapter 2 in BerryDunn’s Cybersecurity Playbook for Management.

What are the main factors a manager should consider when selecting a maturity model?
RG: All stakeholders, including managment, should be able to easily understand the model. It should be affordable for your organization to implement, and its outcomes achievable. It has to be flexible. And it has to match your industry. It doesn’t make a lot of sense to have an IT-centric maturity model if you’re not an extremely high-tech organization. What are you and your organization trying to accomplish by implementing maturity modeling? If you are trying to improve the confidentiality of data in your organization’s systems, then the maturity model you select should have a data confidentiality domain or subject area.

Managers should reach out to their peer groups to see which maturity models industry partners and associates use successfully. For example, Municipality A might look at what Municipality B is doing, and think: “How is Municipality B effectively managing cybersecurity for less money than we are?” Hint: there’s a good chance they’re using an effective maturity model. Therefore, Municipality A should probably select and implement that model. But you also have to be realistic, and know certain other factors—such as location and the ability to acquire talent—play a role in effective and affordable cybersecurity. If you’re a small town, you can’t compare yourself to a state capital.

There’s also the option of simply using the Cybersecurity Capability Maturity Model (C2M2), correct?
RG: Right. C2M2, developed by the U.S. Department of Energy, is easily scalable and can be tailored to meet specific needs. It also has a Risk Management domain to help ensure that an organization’s cybersecurity strategy supports its enterprise risk management strategy.

Once a manager has identified a maturity model that best fits their business or organization, how do they implement it?
RG: STEP ONE: get executive-level buy-in. It’s critical that executive management understands why maturity modeling is crucial to an organization's security. Explain to them how maturity modeling will help ensure the organization is spending money correctly and appropriately on cybersecurity. By sponsoring the effort, providing adequate resources, and accepting the final results, executive management plays a critical role in the process. In turn, you need to listen to executive management to know their priorities, issues, and resource constraints. When facilitating maturity modeling, don’t drive toward a predefined outcome. Understand what executive management is comfortable implementing—and what the business or organization can afford.

STEP TWO: Identify leads who are responsible for each domain or subject area of the maturity model. Explain to these leads why the organization is implementing maturity modeling, expected outcomes, and how their input is invaluable to the effort’s success. Generally speaking, the leads responsible for subject areas are very receptive to maturity modeling, because—unlike an audit—a maturity model is a resource that allows staff to advocate their needs and to say: “These are the resources I need to achieve effective cybersecurity.”

Third, have either management or these subject area leads communicate the project details to the lower levels of the organization, and solicit feedback, because staff at these levels often have unique insight on how best to manage the details.

The fourth step is to just get to work. This work will look a little different from one organization to another, because every organization has its own processes, but overall you need to run the maturity model—that is, use the model to assess the organization and discover where it measures up for each subject area or domain. Afterwards, conduct work sessions, collect suggestions and recommendations for reaching specific maturity levels, determine what it’s going to cost to increase maturity, get approval from executive management to spend the money to make the necessary changes, and create a Plan of Action and Milestones (POA&M). Then move forward and tick off each milestone.

Do you suggest selecting an executive sponsor or an executive steering committee to oversee the implementation?
RG: Absolutely. You just want to make sure the executive sponsors or steering committee members have both the ability and the authority to implement changes necessary for the modeling effort.

Should management consider hiring vendors to help implement their cybersecurity maturity models?
RG: Sure. Most organizations can implement a maturity model on their own, but the good thing about hiring a vendor is that a vendor brings objectivity to the process. Within your organization, you’re probably going to find erroneous assumptions, differing opinions about what needs to be improved, and bias regarding who is responsible for the improvements. An objective third party can help navigate these assumptions, opinions, and biases. Just be aware some vendors will push their own maturity models, because their models require or suggest organizations buy the vendors’ software. While most vendor software is excellent for improving maturity, you want to make sure the model you’re using fits your business objectives and is affordable. Don’t lose sight of that.

How long does it normally take to implement a maturity model?

RG: It depends on a variety of factors and is different for every organization. Keep in mind some maturity levels are fairly easy to reach, while others are harder and more expensive. It goes without saying that well-managed organizations implement maturity models more rapidly than poorly managed organizations.

What should management do after implementation?
RG: Run the maturity model again, and see where the organization currently measures up for each subject area or domain. Do you need to conduct a maturity model assessment every year? No, but you want to make sure you’re tracking the results year over year in order to make sure improvements are occurring. My suggestion is to conduct a maturity model assessment every three years.

One final note: make sure to maintain the effort. If you’re going to spend time and money implementing a maturity model, then make the changes, and continue to reassess maturity levels. Make sure the process becomes part of your organizations’ overall strategic plan. Document and institutionalize maturity modeling. Otherwise, the organization is in danger of losing this knowledge when the people who spearheaded the effort retire or pursue new opportunities elsewhere.

What’s next?
RG: Over the next couple of blogs, we’ll move away from talking about maturity modeling and begin talking about the role capacity plays in cybersecurity. Blog #3 will instruct managers on how to conduct an internal assessment to determine if their organizations have the people, processes, and technologies they need for effective cybersecurity.

Read our next cybersecurity playbook article, Tapping your internal capacity for better results: Cybersecurity playbook for management #3, here.

Good Practices Are Not Enough

When it comes to IT security, more than one CEO running a small organization has told me they have really good people taking care of “all that.” These CEOs choose to believe their people perform good practices. That may be true, but who defines good practices and how they administer them? And when? If “security is everyone’s job,” then nobody is responsible for getting specific things done. Good practices require consistency, and consistency requires structure.

From an audit perspective, a control not written down does not exist. Why? Because it can’t be tested, measured, or validated. An IT Auditor can’t assess controls if they were never defined. Verbal instruction carries by far the most risk. “I told him to do that,” doesn’t pass the smell test in court.

Why Does it Matter?

Because it’s not IT’s job to write policies. Their job is to implement IT decisions made by management. They’re not at the right level to make decisions that impact the entire organization. Why should small organizations concern themselves with developing policies and procedures? Here are two very good reasons:

1. Regulatory Requirements
2. Lawsuits

No matter how small your organization, if you have a corporate network (even cloud-based) and you store credit card transactions, personal health information, client financial information or valuable intellectual property, being aware of state and federal regulatory requirements for protecting that information is vital. It is the responsibility of management to research and develop a management framework for addressing risk.

Lawsuits happen when information is stolen and/or employees are terminated for inappropriate activities. If you have no policies that mandate what is and isn’t acceptable, and what the penalties are for violations, your terminated employee has grounds for a wrongful termination lawsuit: policy should not be written by the IT Department.

If confidential data you are responsible for is stolen and clients sue you, standing up in court and saying “We don’t have any written policies or procedures,” is a sure way to have both significant financial losses and a negative impact on your reputation. For a small organization, that could mean going out of business.

Even if data is stolen from a third-party vendor who stores your data, your organization owns the data and is responsible for ensuring the data is secure with the vendor and meets organizational requirements. Do you have a vendor management policy? If you work with vendors, you need one.

Consider, too, that every organization expects to grow its business. The longer management doesn’t pay attention to policies and procedures, the more difficult it becomes to develop and implement them.

Medium and Large Organizations Need to Pay Attention, too

A policy document provides a framework for defining activities and decision-making by everyone in the organization. A policy contains standards for the organization, and outlines penalties for non-performance. The organization’s management team or board of directors must drive their creation.
Policies also maintain accountability in the eyes of internal and external stakeholders. Even the smallest organization wants their customers and employees to have confidence the organization is protecting important information. By defining the necessary controls for running business operations that address risk and compliance requirements (and reviewing them annually), your management team demonstrates a commitment to good practices.

Procedures are the “How”

Procedures don’t belong in a policy. Departments need to be able to design their own procedures to meet policy requirements and definitions. HR will have procedures for employee privacy and financial information, finance must manage credit card, student, banking or client financial documentation, and IT will need to develop specific technical procedures to document their compliance with policy.

If all those procedures are in a policy, it makes for unwieldy policy documents that management must review and approve. Departments need to change and update their procedures quickly in order to remain effective. For example, a policy may mandate the minimum number of characters in a password, but IT needs to develop the procedures to implement that requirement on many platforms and devices.

What is a “Plan” Used For?

Consider that organizations commonly have a Business Continuity Plan as well as an Incident Response Plan. How is a “plan” different from a policy or procedure?

A plan (for example, an Information Security Plan, or Privacy Plan, etc.) is a collection of related procedures with a specific focus. I have seen these collections called “programs,” but most organizations use “plan” (plus, the Federal government uses that term). The term “program” implies a beginning and an end, as well as tending to be a little too generic (think “School Lunch Program”).

Three Ways Not to Develop Policies, Procedures and Plans

Consider the Unique Aspects of Your Organization

What electronic information does your organization consider valuable? During an assessment with a state university, we discovered that the farm research the agriculture school was performing was extremely valuable. While we started out with questions about student health and financial information, the university realized the research data was equally critical. The information might not have federal or state regulations attached to it, but if it is valuable to your organization, you need to protect it. By not taking a one-size fits all approach to our assessment, we were able to meet their specific needs.

Multiple Departments or Locations? Standardize.

Whether your organization is a university, non-profit organization, government agency, medical center or business, you frequently have sub-entities. Each sub-entity or location may have different terms for different functions. For example, at a recent engagement for another university, Information Security “Programs,” “Plans” and “Policies” meant different things on different campuses. This caused confusion on the part of all stakeholders. It also showed a lack of cohesion in the approach to security of the university as a whole. Standardizing language is one of the best ways to have everyone in the organization on the same page, even if the documents are unique to a location, agency or site. This makes planning, implementation, and system upgrade projects run more effectively.

Demonstrate Competence

No matter what terms your organization chooses, using consistent terms is a good way to demonstrate a thoughtful approach. Everyone needs to be talking the same language. Having documents that specify management decisions provides assurance to internal and external stakeholders. Good policies, procedures and plans can mean the difference between a manageable crisis and a business failure.

To receive IT security updates, please sign up here.

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.

For professional baseball players who get paid millions to swing a bat, going through a slump is daunting. The mere thought of a slump conjures up frustration, anxiety and humiliation, and in extreme cases, the possibility of job loss.

The concept of a slump transcends sports. Just glance at the recent headlines about Yahoo, Equifax, Deloitte, and the Democratic National Committee. Data breaches occur on a regular basis. Like a baseball team experiencing a downswing, these organizations need to make adjustments, tough decisions, and major changes. Most importantly, they need to realize that cybersecurity is no longer the exclusive domain of Chief Information Security Officers and IT departments. Cybersecurity is the responsibility of all employees and managers: it takes a team.

When a cybersecurity breach occurs, people tend to focus on what goes wrong at the technical level. They often fail to see that cybersecurity begins at the strategic level. With this in mind, I am writing a blog series to outline the activities managers need to take to properly oversee cybersecurity, and remind readers that good cybersecurity takes a top-down approach. Consider the series a cybersecurity playbook for management. This Q&A blog — chapter 1 — highlights a basic concept of maturity modeling.

Let’s start with the basics. What exactly is a maturity model?
RG: A maturity model is a framework that assesses certain elements in an organization, and provides direction to improve these elements. There are project management, quality management, and cybersecurity maturity models.

Cybersecurity maturity modeling is used to set a cybersecurity target for management. It’s like creating and following an individual development program. It provides definitive steps to take to reach a maturity level that you’re comfortable with — both from a staffing perspective, and from a financial perspective. It’s a logical road map to make a business or organization more secure.

What are some well-known maturity models that agencies and companies use?
RG: One of the first, and most popular is the Program Review for Information Security Management Assistance (PRISMA), still in use today. Another is the Capability Maturity Model Integration (CMMI) model, which focuses on technology. Then there are some commercial maturity models, such as the Gartner Maturity Model, that organizations can pay to use.

The model I prefer is the Cybersecurity Capability Maturity Model (C2M2), developed by the U.S. Department of Energy. I like C2M2 because it directly maps to the U.S. Department of Commerce’s National Institute of Standards and Technology (NIST) compliance, which is a prominent industry standard. C2M2 is easily understandable and digestible, it scales to the size of the organization, and it is constantly updated to reflect the most recent U.S. government standards. So, it’s relevant to today’s operational environment.

Communication is one of C2M2’s strengths. Because there is a mechanism in the model requiring management to engage and support the technical staff, it facilitates communication and feedback at not just the operational level, but at the tactical level, and more significantly, the management level, where well-designed security programs start.

What’s the difference between processed-based and capability-based models?
RG: Processed-based models focus on performance or technical aspects — for example, how mature are processes for access controls? Capability-based models focus on management aspects — is management adequately training people to manage access controls?

C2M2 combines the two approaches. It provides practical steps your organization can take, both operationally and strategically. Not only does it provide the technical team with direction on what to do on a daily basis to help ensure cybersecurity, it also provides management with direction to help ensure that strategic goals are achieved.

Looking at the bigger picture, what does an organization look like from a managerial point of view?
RG: First, a mature organization communicates effectively. Management knows what is going on in their environment.

Most of them have very competent staff. However, staff members don’t always coordinate with others. I once did some security work for a company that had an insider threat. The insider threat was detected and dismissed from the company, but management didn’t know the details of why or how the situation occurred. Had there been an incident response plan in place (one of the dimensions C2M2 measures) — or even some degree of cybersecurity maturity in the company, they would’ve had clearly defined steps to take to handle the insider threat, and management would have been aware from an early stage. When management did find out about the insider threat, it became a much bigger issue than it had to be, and wasted time and resources. At the same time, the insider threat exposed the company to a high degree of risk. Because upper management was unaware, they were unable to make a strategic decision on how to act or react to the threat.

That’s the beauty of C2M2. It takes into account the responsibilities of both technical staff and management, and has a built-in communication plan that enables the team to work proactively instead of reactively, and shares cybersecurity initiatives between both management and technical staff.

Second, management in a mature organization knows they can’t protect everything in the environment — but they have a keen awareness of what is really important. Maturity modeling forces management to look at operations and identify what is critical and what really needs to be protected. Once management knows what is important, they can better align resources to meet particular challenges.

Third, in a mature organization, management knows they have a vital role to play in supporting the staff who address the day-to-day operational and technical tasks that ultimately support the organization’s cybersecurity strategy.

What types of businesses, not-for-profits, and government agencies should practice maturity modeling?
RG: All of them. I’ve been in this industry a long time, and I always hear people say: “We’re too small; no one would take any interest in us.”

I conducted some work for a four-person firm that had been hired by the U.S. military. My company discovered that the firm had a breach and the four of them couldn’t believe it because they thought they were too small to be breached. It doesn’t matter what the size of your company is: if you have something someone finds very valuable, they’re going to try to steal it. Even very small companies should use cybersecurity models to reduce risk and help focus their limited resources on what is truly important. That’s maturity modeling: reducing risk by using approaches that make the most sense for your organization.

What’s management’s big takeaway?
RG: Cybersecurity maturity modeling aligns your assets with your funding and resources. One of the most difficult challenges for every organization is finding and retaining experienced security talent. Because maturity modeling outlines what expertise is needed where, it can help match the right talent to roles that meet the established goals.

So what’s next?
RG: In our next installment, we’ll analyze what a successful maturity modeling effort looks like. We’ll discuss the approach, what the outcome should be, and who should be involved in the process. We’ll discuss internal and external cybersecurity assessments, and incident response and recovery.

You can read our next chapter, Selecting and implementing a maturity model: Cybersecurity playbook for management #2, here.

We all know them. In fact, you might be one of them — people who worry the words “go live” will lead to job loss (theirs). This feeling is not entirely irrational. When an organization is ready to go live from an existing legacy system to a new enterprise system, stress levels rise and doubts emerge: What can go wrong? How much time will be lost? Are we really ready for this?

We’re here to help. Here is a list of go-live essentials to help you mitigate stress and assess your readiness. While not all-encompassing, it’s a good place to start. Here’s what you need:

1. A detailed project plan which specifies all of the implementation tasks
   A project plan is one of the most important parts of an implementation. A detailed plan that identifies all of the implementation tasks along with an assigned resource for each task is critical to success. The implementation vendor and the organization should develop this plan together to get buy-in from both teams.

2. A completed system configuration
   New system configuration is one of the most time-consuming aspects of a technology implementation. If you don’t complete the implementation in a timely manner, it will impact your go-live date. Configure the new system based upon the best practices of the system — not how the existing system was — for timely implementation.

3. External system interface identification
   While replacement of some external systems may be a goal of an implementation, there may be situations where external systems are not replaced or the organization has to send and/or receive data from external organizations. And while new systems have advanced interface technology capabilities, the external systems may not share these capabilities. Therefore it is imperative that you identify external system interfaces to avoid gaps in functionality.

4. Testing, testing, testing
   End-to-end testing or User Acceptance Testing (UAT) is often overlooked. It involves completing testing scenarios for each module to ensure appropriate system configuration. While the timing of UAT may vary, allow adequate time to identify solutions to issues that may result from UAT.

5. Data conversion validation
   When you begin using a new system, it’s best to ensure you’re working with clean, up-to-date data. Identify data conversion tasks in the project plan and include multiple data conversion passes. You must also determine if the existing data is actually worth converting. When you complete the data conversion, check for accuracy.

6. End user training
   You must train all end users to ensure proper utilization across the organization. Don’t underestimate the amount of time needed for end user training. It is also important to provide a feedback mechanism for end users to determine if the training was successful.

7. A go-live cutover plan
   The overall project plan may indicate go-live as an activity. List specific activities to complete as part of go-live. You can build these tasks into the project plan or maintain them as a separate checklist to promote a smooth transition.

8. Support structure
   Establish an internal support structure when preparing for go-live to help address issues that may arise. Most organizations take time to configure and test the system and provide training to end users prior to go-live. Questions will arise as part of this process — establish a process to track and address these questions.

Technology implementations can significantly impact your organization, and it’s common for stress levels to rise during the go-live process. But with the right assessment and preparation, you can lessen their impact and reduce staff stress. Our experienced, objective advisors work with public and private sector organizations across the country to oversee large enterprise projects from inception to successful completion. Please reach out to us to learn more about preparing for your next big project.