What to Expect When Building a Custom Software Platform

The reality is OPG serves at your pleasure. OPG considers itself the “extended dev team” for your organization as it relates to the project we are working on together. However, OPG is not the subject matter expert for your industry and platform. OPG needs you and your team to lead our team for direction and key functional requirements. The same is true of writing marketing messages or content. OPG is not the expert in your field, and OPG will need to rely on your team to assist with core content development, and then OPG will help you present it and make it come alive. Of course, OPG will take care of the technical components, but to succeed, OPG has to rely on your expertise so OPG can make the technology you have envisioned a reality. Here are a few key expectations it is important are agreed upon by both your team and the OPG team:

1. Developing a custom software application is an exciting process, but also a learning experience.
2. An iterative approach starts with a foundation of basic features and grows from there. You may not have the Ferrari on launch day, but you will be able to build to that level over time.
3. Brainstorm possible features and workflows, coming up with as many ideas as possible and letting the creativity flow.
   
   1. If building based on an existing system, identify the great things about the existing system and the areas that need improvement.
   2. Filter out less valuable ideas and keep the best.
   3. It is best not to try to do everything at once. Take things one step at a time.
   4. Use a “minimum viable product” method. Think out all of the features you may want or need, then cut that list to only the things you absolutely cannot live without. The other features can be retained for future phases, but your best opportunity for success is keeping the build as simple as possible for each iteration.
4. Identify requirements and be as clear as possible about each one, and any special circumstances of the workflow. Review various use cases.
5. Prioritize requirements according to your budget and other resources (such as human capital).
6. Set work distribution across teams so everyone knows their roles and responsibilities.
7. Identify possible project constraints you can envision from the start. For example, if you are building a platform to replace a system that will go away in 5 months, notify OPG right away so OPG can guide the process to ensure you don’t end up systemless!
8. Your feedback, and most importantly the feedback of your users, is vital to tuning the platform.
9. Plan on a 10-20% time and budget variable. In the nearly 20 years OPG has been doing this, it’s almost a certainty new things will come up, new challenges will arise and additional budget and timing is needed. Some projects have less, some projects have more, but it’s something to plan for when you set your budgets and timeline expectations.

Having high involvement from your team is critical to the success of your custom application. At OPG, we know it isn’t always easy for you to articulate what you need right off the bat – after all, you are not a software developer. If you’ve never participated in a custom software development project, there is a learning curve. Both our team and yours will have to work and grow together over time. We’ll work to understand your business to ensure we are providing solid guidance for any uncertainties that may arise during the process. It is not uncommon to have clients initially opt out of suggestions and in later phases realize the value. A few key items to plan for include:

1. Your project team will need key functional business leaders who understand the current system(s) and workflow along with the new platform direction and goals.  Too often individuals without the proper access, visibility or decision making authority are tasked to lead a software project and that can lead to trouble.  It’s completely ok to have someone that is not the “thought and strategy leader” run the day to day, but be sure those with the grand vision stay involved to keep things on track.
2. It is essential that OPG has 1-2 people who are key contacts.  This makes coordination and communication much easier.  Decision by committee is ok internally, but when it comes to providing OPG with the “final choices” or managing scheduling, having a single point of contact and a backup is always best.
3. You definitely want to involve key stakeholders and decision makers in the discovery phase of the project.  Having these key members involved ensures that all of the possible considerations can be shared and discussed, which means OPG will have a much richer view of the real challenges, workflow and operational imperatives necessary to drive solutions.
4. It is ideal to designate a team member from your firm who can provide or direct screen mock-ups, data needs, integrations, automation, user workflow, and user pools along with desired rights and restrictions. This individual is usually the “subject matter expert” for the platform from your company.  This individual may not be in every meeting, but having a “go to” person readily available internally to make decisions is a huge help and makes the process go much faster and smoother.

When diving into the requirements, it is often best to start at a high level and then add more details and clarity as we progress. Below are some primary requirements areas. When you are meeting internally before or during the discovery process, these types of often forgotten considerations are important to think about.

1. Key problems the solution should solve – what’s the reason you are building the tool?
2. Key requirements – identify the most important things the new solution needs to achieve at a business and functional level, and describe them.
3. Key barriers – Identify any known barriers to the solution.  A good example is getting your data from an existing vendor.  This is not insurmountable, but knowing this early means work can start to get the data, or to find out you can’t get the data, as early as possible.  The sooner barriers are known, the better.
4. Governance/compliance requirements (i.e. HIPAA and GDPR).
5. Data needs – initial data source(s), define each type of record and details. (i.e. Users/Contacts/Members, eCommerce, Invoices, and History/Audit Log).
6. Functional tools (i.e. payment processing, email/campaign management, and mobile device access).
7. User Roles (i.e. member/student, area/branch, corporate, support/admin, super admin).
8. User Workflow – how each user role accesses and moves through the system along with the role’s rights and restrictions.
9. Resource needs – Identify if the hosting provider or hardware requirements are known. If this is not known OPG can provide guidance to provide the proper hosting provider.

The software development process used by OPG explicitly prevents decision paralysis by encouraging iterative work cycles. These cycles emphasize the functionality of the software and its underlying results over software complexity.

How much is this software worth to you? Before setting a software project budget, figure out how much you hope to earn (or save) with the software you’re imagining. Otherwise, it’s impossible to know if the project makes business sense—regardless of what it might cost. Budgeting for custom software builds is a key step in the process, and OPG will help you with this along the way. The complexity of the build, the deadlines that are targeted, the burn rate you are comfortable with, and other factors are all variables in the projected budget and final cost. But, start with a basis of what is reasonable for the project and then work from that baseline. Sure, sometimes features may have to move to a phase 2, or, you may find you can fit more into phase 1, but have a baseline and share it with OPG so that all parties can work to the same goal and keep things on track. A standard project will usually include the following documents:

1. “The Spec (Specification)” – Discovery is performed and a specification or “blueprint” of the build will be created.  This document will define the details of the project and what is to be developed. In many cases this process will also include mocks ups or a visual representation of of the end product.
2. A Statement of Work (SOW) is created based on the detailed functional requirements.
3. Each functional section of the SOW is estimated separately allowing the opportunity to remove/push items from this phase.
4. The SOW will include an estimate of cost and risk based on the project.  The risk indicates whether there are still some unknowns that exist at the time of estimate, or if there are items that were directed from your team as “table that, we can work on that once development begins.”  This factor helps you to plan for known areas that could go beyond projected estimates.
5. Each SOW and/or Change Order is reviewed and approved by your team prior to any development work commencing.
6. Always plan for two things:
   1. Changes made during the development phase or testing.
   2. Changes made once you “go live” and users start providing input.
7. Because software platforms are living and evolving entities, it is recommended that you plan budgets for things such as tweaks and changes, adding in features that were overlooked in discovery, and even marketing. Many times firms build a really cool thing, but do not budget to promote the new tool. Don’t forget the software platform is just one piece of the business plan, and often those other pieces need time, attention and budget too.

The timeline for a project will vary by the complexity of the project, however, the following are the phases and segments and “typical” timelines. For some projects, these are much quicker, for others, they are much longer. However, the structure and stages of the project will be the same for both small and large projects.

1. Discovery and Analysis. OPG will work with you to understand your needs and ultimately develop a system specification or “blueprint” that defines your system and what will be created. This process normally takes about 30 days.
2. Development. This is when the OPG team goes to work creating your vision and the platform based off of the approved specifications. This is the most widely variable because the depth and complexity of the build drives it. For most projects, the development phase will run 60-90 days, but can be shorter or longer depending on the complexity of the build.
3. UAT/BETA Testing. This is the period of time when most of the initial build is complete and OPG is ready for you and your stakeholders to begin testing in the staging environment. This is not the “go live” this is the first look you will have at the platform. Your team will test and return feedback, and the OPG team will address the feedback. Feedback comes in many forms including bugs, changes, new feature requests or observations to be managed later. OPG will work with your team to prioritize the feedback and address it. It is not at all unusual for there to be a LOT of change items identified during this process. That can seem scary, but it’s completely normal. Once the feedback is gathered, OPG will help you to prioritize and act on those things you have to have now, and will manage the other items into a backlog that can come later. This process will iterate until all teams agree things are ready for launch. This process can take as little as a few days on small builds to weeks on larger builds.
4. Go Live. Once everyone agrees things are ready to go live, a go live date will be set and OPG will manage the rollout to production for the technical assets. Leading up to this you will be busy preparing marketing or customer communications to announce the new platform and prepare to support it. Go live itself is quick, usually just a few hours, but the prep is often done during the UAT/BETA phase so the go live scheduling can be done quickly.
5. Post Launch. Once you go live, that is just the beginning of the journey. While go live does close the initial development chapter, any healthy technology solution will grow, change and evolve. As customers provide input and feedback, and as your internal users make use of the new platform, ideas will flourish. The important thing is to not think you have to do everything everyone asks. Of course, some higher priority items may develop, but for most items found after launch, they can be reported, added to a backlog and then considered as a “batch” of tasks to discuss with OPG. Most clients will do either monthly or quarterly sprints to address the latest needs and continue this over time. At a certain point, your platform will reach maturity and changes will be far less frequent, but that often takes many months, and sometimes a couple of years for very large platforms.
6. Long-term Maintenance. Over time, you should expect to have to do “platform maintenance.” These are things like patching your servers for security updates, upgrading the versions of the technologies that run your platform, etc. These are normal. Just like you have to do Windows or Chrome updates, you will have to allocate a small amount of budget to manage these items over time. OPG offers a managed web service to help with this, but plan for this imperative so it does not catch you off guard.