So you've been assigned as a technical expert on a business case.
Thanks for joining the team. You are an essential part of the process of understanding the project scope, request, and the clients, identifying technological options for solving the client's needs, assessing whether products and options are compatible with the USF IT standards and strategies, estimating the amount of work and costs involved, and recommending the best solution for implementation. Your technological and business area expertise, along with critical thinking and problem solving skills, are necessary to ensure that the solutions IT recommends to clients are the best they can be.
What's a business case anyway?
A business case is basically an options document. When there is a need identified at USF that could be helped or solved with technology, and there are multiple possible solutions to the need, the IT Leadership and governing bodies request a business case document to be created. The business case team researches and evaluates the options identified to determine their viability and fit. You can find out more about the business case and how it fits into the process here.
What's expected of me?
As a member of the business case team, you are an equal partner in the creation of the business case document and a key contributor to the knowledge of the team.
You should be engaged in all of the major meetings of the team, and be included in requirements and discovery sessions with the key stakeholders and clients. This will help you to understand the voice of the client, their business needs, and help assess a solution's fit.
Together with your team mates and with the help of other technical contacts within your area, consider and identify potential options to solve the problem. Along with your fellow team mates, you should feel empowered to offer suggestions and ideas as to technology solutions that could be a reasonable fit to the client's needs. These can include systems already in use, expansion of existing systems to acquire/use new modules or licenses, and completely new hardware/software solutions outside of the current offerings at USF.
Consider the possibilities, and bring them to the team. There may be several (or dozens) of options to solve a particular problem. It's ok to get creative (combinations/integrations of software options, combining software and hardware, custom development ideas).
There may be several (or dozens) of options to solve a particular problem. Help the team to prioritize and limit their options under consideration by asking the following:
- Is this close to the client's budget estimate? It's ok to go over somewhat, but be wary of options that are magnitudes beyond what the client is looking to spend.
- Is this solution aligned with IT strategy at USF? Solutions that are in line with key initiatives and principles at work in IT are always preferred. For instance, strategy as of this writing favors SaaS and Cloud software options over those that require on-premesis hosting. Another factor to consider here is maintenance – will this solution be easier or harder to maintain based on your understanding of it?
- Does the solution miss any vital/critical/must-have requirements? If it's missing something the client (or IT) finds really important, take it off the list to investigate further. There's no point in writing up and costing out a solution that doesn't have a chance at being chosen.
- Is any group at USF using this solution? To avoid adding more systems USF and IT have to support, leveraging software/solutions/vendors/brands that USF already has implemented or a relationship with is generally prefered over going with a new system (circumstances may vary based on the project). If department X is using this and you think it may be a good fit for department Y, there's a solid reason to include it in the business case.
- Is another State University System (SUS) using this solution? It is always a good idea to include products/solutions that are being used by another SUS member. Clients and executive leaders are particularly interested in this information, and it gives the team a way to ask for references for the vendor/solution.
If you can, it is best to try to limit the explored options to 5 or less, for the sake of time. Work with your team to make the list.
Sometimes, you may find there is only one solution available. It could be because there is only a proprietary vendor/product that can meet the needs, or because the solution is specific to a particular product line (e.g. if the request is for a change to the FAST payroll screens, PeopleSoft development is the only solution). Work with your team to see if an investment proposal would be more fitting.
Once the top options are identified, you will work with the team to investigate them. This may mean independent research on your part or participating in vendor meetings, demonstrations, and reference calls with other customers of that vendor/solution. You should participate fully in the analysis to help understand what the solution is like and to be sure to gather enough details to provide the option details outlined in the business case template. You will help the team to write these sections for use by the client and executive decision makers.
Note: there are some guidelines for vendor engagement and discussions that must be followed in the event that the project is going to need an Invitation to Negotiate (ITN) or other contract negotiation.
As you explore the tools further, you may identify better solutions and others may not be viable. The list of top options may be fluid, so always let your team know when a new solution presents itself.
As a technical team member, you will be a key resource for helping to map out the cost and time estimates for the distinct options. Using the high-level requirements, you should be prepared to estimate the number of weeks/months/quarters that will be required for technical resources to complete the implementation of an option, and what percentage of the technical team member's time will be allocated for that duration.
In addition to estimating the initial implementation time, you should also help the team determine how many resources and/or how much time will be needed to maintain the new system in the years after the initial setup. Consider whether the technical team will be able to absorb the support for this system/project/hardware without additional people. If not, how will the solution be maintained? You can consider the feasibility of consulting/outsourcing or hiring someone internally.
Depending on your technical expertise, you may also be a part of estimating the costs for technical purchases including hardware or software or combinations of the two. Just like the personnel portion, you should consider the implementation needs, the ongoing support and maintenance, and also any systems that may be able to be retired after the completion of the project. That last will contibute to potential savings.
All of these estimates will go into the TCO Estimator to determine the costs (internal and external) for each solution option.
In the end, the business case should recommend a preferred solution. This should be the best one from both the IT and client perspective whenever possible. As a technical expert, it is your part to weigh in on whether an option considered is viable (would meet the strategies and standards of IT) and which is the best option from IT's perspective. The team will then work with the clients to understand their preferences, and choose an option to recommend. This may sometimes result in the business case team recommending a solution that is not the preference of the client. The team should notify the leadership team when this is the case.
Business case presentation
Once the business case is complete, it is presented to the IT Leadership for their final review before it is considered by the ITMC or one of the other governance workgroups. You will be asked to participate in this meeting so that the leadership team can ask questions about the case, the options you considered and ruled out, and to ensure that all details and costs are accounted for. Be prepared to justify some of the decisions you helped with, and that you may have to do some further research/costing work after this meeting in case anything was missed.
Technical team members are not usually included in the presentation of the business case to the governance committee, though exceptions may take place.