New software ideas are exciting. Watching the software take shape is exhilarating. And releasing that new software into the world is fascinating. Without proper prototyping, however, a software release can quickly go from uplifting to crushing.
Releasing software without prototyping invites a number of problems:
- Users may discover that the software is structured in a way that makes it challenging to use.
- The software may lack a key function, which forces users to supplement with another app or to eschew it altogether.
- Bugs in the code may cause problems that render the software unstable or unusable.
These problems add up to big costs for businesses. A 2017 study found that software failures cost U.S. companies more than 268 years worth of downtime, resulting in $1.7 trillion in losses for the economy.
Much of this lost time, money and opportunity could have been avoided with the right plan for building and testing the software.
Why Software Prototyping Matters
Prototyping serves as a rehearsal for software. It allows developers, designers, users and other stakeholders to test the software, offer feedback and make changes to avoid some of the most common major pitfalls that attend a software release.
In other words, prototyping allows teams to test the software before they put in the work of developing a finished product.
At first glance, prototyping may seem like a step that just makes the software development process longer. In reality, however, prototyping tends to save significant time and money. It also gives teams the chance to incorporate research into consumer needs, competing software and other factors, which also result in a better product.
When a team creates a prototype, they’re building a scaled-down version of the finished product or feature. This scaled-down version helps creators spot potential problems and limitations, understand the project from the user’s point of view and plan a more streamlined process to bring the finished product into reality.
Because software creation is a collaborative process, the early stages of prototyping and product development should focus on collaboration and on understanding the current state of affairs.
By understanding what a new software build needs to do — and by building the trust, maintaining lines of communication and securing the buy-in needed for teams to succeed — an organization can handle the prototyping process more effectively.
Understand Your Needs and Set Goals
It’s tough to get somewhere if you don’t know where you’re going. For software development and prototyping, “knowing where you’re going” means setting early goals for the software build.
Know the Why of the Project
The first question to ask when envisioning any new software project is “What problem do we want to solve?” The answer to this question becomes the focal point of further efforts to develop a product.
Adam Jones, chief technology officer at Redington, challenges fintech companies to think big when it comes to goal-setting and envisioning the impact of their offerings. Jones recommends that fintech companies ask themselves two questions:
- “Does this leave the world in a better place than I found it?”
- “Are we, as an organization, taking meaningful steps towards this purpose in the work we do?”
With this big-picture view in place, you can turn to the needs that this particular piece of software will fulfill, and the context in which it will operate.
For example, look at market factors like competing software and services, as well as the company’s own strategy for competition, customer outreach, and other goals the new software affects or advances.
Inventory the technology that’s already available and its functionality. Is the goal to build an entirely new application, or to add functionality to a legacy system? What vision should the new software help the organization reach?
The answers to these questions can help shape software that fits both the business’s needs and the market’s opportunities. It will also help leadership set goals and generate buy-in from both internal and external teams.
Goal-Setting for Greater Impact
For financial companies seeking to build new software or expand their current digital offerings, a lack of planning can lead to a lack of focus and follow-through. Sketchy, abstract plans may fall apart once actual customer needs, expectations or behavior enter the picture.
To address the risk of deviation, develop goals by taking customers’ perspectives into account. What problems do the software’s users have, and how will the new software help them solve those problems?
Make space for the perspectives of the company’s employees and software team, as well. Customers may have grand visions of their ideal software, but those might not align with your team’s capacity nor your actual business needs.
Early goal-setting tends to benefit teams the most when it is flexible, allowing for adaptation or re-imagining of the core goals as the prototyping process proceeds. Creating flexible goals can help a company and its partners incorporate new information as it is discovered. This flexibility allows teams to improve the project in response to new information without derailing the project.
Early goal-setting also helps keep teams on the same page, even as they work on different areas of a project. A clear, shared strategy and a shared set of goals encourages collaboration and ownership, forming a sense of cohesion between internal and external teams. This sense of shared purpose and focus persists even as teams break out their efforts to various parts of the project.
Embrace uncertainty in the early goal-setting process. Emphasize motivation and create an environment in which competing ideas can be voiced, challenged and examined. Such an environment provides space for those involved in shaping a new software idea to plan, innovate and tackle challenges that arise during the development process.
To help teams build their case for a particular piece of software, Eileen O’Loughlin at Capterra recommends focusing on six main points:
- The problem to be solved.
- The solution to the problem.
- The costs.
- The benefits.
- The timeline.
- Practices for change management.
Since all six of these points are also addressed when modeling the lifecycle of software development itself, ideas generated during software development can often be adopted in any presentation or document that must also generate buy-in for the project.
Effective goal-setting is a collaborative process, encompassing not only the project’s ultimate goals but also how that goal will be achieved. To facilitate effective collaborative goal-setting, leadership will need to encourage internal and external teams to buy into the project and its overall purpose.
Get Buy-In From All Necessary Stakeholders
In a software development setting, stakeholders include not only investors and leadership, but also the internal and external teams participating in the development of the project itself. The earlier they embrace the project and its goals, the more effectively they can plan the processes and tasks necessary to reach those goals.
Communicating the Vision
The first step in generating buy-in for a new software build is to articulate a clear vision of the finished software and what impact that software will have on the company.
When articulating the vision for a software build, keep it simple, Joe Byerly at We Are The Mighty writes:
- Answer the question “How does this software idea benefit the organization?”
- List a few key points that support the answer to that question.
- Anticipate questions from leadership and coworkers, and address them briefly.
To communicate the vision for a software project quickly, summarize its key functions and business impact upfront. Emphasize the why of the software build by blending facts with inspiring language. Put the idea itself and its most compelling reasons for support upfront, rather than burying them in a longer presentation.
When summarizing a project’s purpose and goals, keep the summary simple and memorable. The process of refining an idea in order to make it simple and memorable benefits the team because it deepens everyone’s understanding of the idea. Refinement requires clarification of key points and a distilled, focused vision.
Focusing the vision can also help ensure that advocating for a new software idea comes across as a plan to help a financial company meet its business goals, rather than a hard sell. Ideas gain traction when you can offer clarity on how the software will work to drive particular business goals.
The Value of Collaborative Planning
To generate buy-in, include all affected parties not only in setting goals, but also in determining how those goals will be met.
Goal-setting and project planning have a psychological effect. They require everyone to invest mental and emotional energy into a plan, forcing everyone to imagine that the thing is already a reality. In visualizing the goal or plan, the brain starts to believe that the plan is in progress or the goal has been met. The disconnect between the imagined goal and a reality where the goal is not fulfilled conflicts with the brain’s image of a world in which the goal has been realized. The brain, then, strives to make the imagined world match the real one.
This feature can be used to secure buy-in for a software development project. When everyone is involved in setting the goals and the processes for fulfilling them, everyone feels responsible for turning the plan into reality.
Involving everyone in the project from the start can also help ensure everyone has the information they need to understand the goal, the plan for reaching it and the metrics used to track progress.
Building a shared understanding of the software and its goals can address a number of issues:
- When everyone understands the project from the start, requests for changes are easier to integrate as the project progresses.
- The parties involved are also less likely to be surprised if a predicted obstacle becomes a real one.
- When the planning and project management phases involve everyone working on the project — with a shared focus on planning, budget estimates and other details — the project itself can proceed much more smoothly.
Embracing the Power of Co-Creation
Co-creation, in which everyone on the team contributes to the vision, process and goals for a project, is one of the most powerful means of generating buy-in.
By encouraging discussion and debate, co-creation helps people get on board with both the process and the outcome. The resulting sense of ownership increases the chance that others will commit to seeing the idea succeed.
To foster that sense of ownership and encourage co-creation, it’s important for everyone involved to practice perspective-taking. When internal team members can put themselves in the shoes of external developers and vice versa, members of each group can better understand the other’s capabilities, as well as their reasons for suggesting certain ideas or processes.
Co-creation also has the benefit of taking pressure off an idea’s first backer to have all the details figured out before sharing the idea within the organization. Rather, it provides teams with the ability to act, to move from the arena of imagining a software build’s operation and results, to working out the details required to make that vision a reality.
Relationship-building across departments is another benefit of co-creation. By breaking down barriers, teams can communicate more effectively. Relationship-building promotes greater candor and spurs creativity. It helps project participants better understand how an idea or change might affect others within the organization, as well as possible effects on customers and stakeholders.
Emphasizing communication and transparency can give participants the psychological space required to promote frank conversations, which in turn can help generate solutions.
During the co-creation phase, it’s important to relinquish control strategically. Once a software idea has been presented to a team, the team’s plans for how to realize that idea turn that idea into a shared vision.
It can be tempting to micromanage a software idea, especially for the person who has the initial vision. Like day-to-day team managers, however, idea generators can stifle rather than inspire a team if they try too hard to control the details or fail to trust the delegation process. Traits like trust, openness and courage help reduce fear and encourage innovation.
By listening actively and guiding rather than controlling, team leaders and idea generators can help ensure that defensiveness or territorial feelings don’t derail an otherwise promising software idea.
As teams explore a new software idea, setting goals and discussing how to reach them, a plan for the prototype itself may begin to emerge, driven by the buy-in generated by team communication.
Plan the Development of the Prototype
A reliable software product doesn’t appear from the ether, nor does it get built ad hoc. Every software build takes effort, time and commitment.
These factors can be applied in pursuit of a specific goal, or they can be scattered as teams attempt to reach a goal without clearly understanding what they are pursuing (or their roles in that pursuit).
A clear software build plan can prevent team efforts from being wasted.
The software development lifecycle offers a way to understand and organize the process of creating software from start to finish. For project team members who are less familiar with software development, it can also clarify the process, explain why certain steps are necessary and help the project succeed.
What should your software development planning look like? Alexandra Altvater at Stackify recommends focusing on the following phases:
- Requirement analysis: Why has previous software failed to live up to current needs?
- Planning: How will the team correct these problems?
- Design: What does the new software build look like?
- Development: How will the team bring the designed software into reality?
- Testing and deployment: Does the new software work as intended? When and how can it be released for customer use?
The first step, requirement analysis, involves looking back. Where are old systems failing to measure up to current demands or to the organization’s goals? With an understanding of the problems the new software needs to fix, the team can begin to plan by accounting for known risks and strategizing within the confines of their budget.
During the planning phase, discuss exactly what the new software will do. Consider the feasibility of various ideas. Examining whether it’s financially reasonable to invest in the software and whether the team has the time and resources they need to execute the vision play a key role in good planning. Also, examine applicable regulations and laws at this stage to ensure that a completed software development project doesn’t expose the organization to liability.
It’s easiest to avoid getting lost when you have both an accurate map of the terrain ahead and a clear route to navigate it. The same is true when building software. Teams can best stay on track when they understand the goal to be achieved and the methods for reaching that goal.
The design and development phases allow internal and external teams to dig into the details and bring the software to life. Here and in the development phase, strong project management is essential to prototype success.
Testing and deployment ensure that completed software works as intended. It helps prevent the software’s ultimate users from losing data or experiencing other mishaps due to buggy code. During this phase, a plan for rolling out new software expedites the process. Plans for retiring previous versions of software may need to be executed as well.
Teams that have put effort into determining why new software is needed and how to execute it on a budget sometimes feel as if a detailed plan for project management is unnecessary. Yet forgoing good project management and planning can cost more in the long run.
Good planning makes for better software, regardless of the goal or the means for achieving it. While every project is unique, all projects benefit from clarity about the goals, the processes for achieving each goal, each participant’s responsibilities and the deadlines by which certain tasks must be complete.
This clarity helps create a unified vision everyone can understand, whatever their individual expertise in software development. It keeps all participants on the same page, with a shared vision of the completed software build.
Build the Software Prototype
Building the prototype brings goals to reality. The prototype is a basic version of the final software product. Software prototypes tend to focus on high-impact features at first, such as the user interface and how that affects the overall user experience.
Choosing a Starting Point
In some cases, beginning to build a prototype before all the team’s questions are answered can be an effective way to address those questions. The hands-on work of building a prototype quickly demonstrates which questions are relevant. It raises questions the team may not have thought to ask during the planning phase. It helps the team see whether their ideas merit further exploration.
Prototyping is a powerful tool for challenging assumptions and experimenting with ideas. It’s wise to incorporate the flexibility needed for teams to play with the prototype. The ability to make changes and try new things creates the mental space needed for better innovation, resulting in a better finished product.
Ideally, software builds will center the user’s experience and needs from start to finish. Thus, prototyping the user interface (UI) provides an effective point to begin the transition between the planning and design phase and the development of the software itself. Use UI prototyping to think about the user’s stake in the finished product, as well as where plans for architecture or application requirements may be lacking.
A prototype UI also creates a demonstration piece that can be used to help team members understand how the final product will work, or to give investors a glimpse at the finished product. The UI prototype offers a concrete example that team members can focus on while creating additional features or recommending new functionalities.
Similar to creating a prototype UI, creating a mock-up allows teams to visualize the final product. A mock-up can also serve as an outline or framework onto which functionalities are added piece by piece. The mock-up-as-framework model allows the team to define its software design structure as it introduces functionalities.
Regardless of where the prototyping teams begin, a focus on the most vital parts of the software can help teams spot problems more quickly. Likewise, a focus on simplifying the overall project can help teams predict which parts of the actual software build will be most complex or have the biggest negative impact on user experience. Teams that work to identify and reduce complexity in the prototyping stage lay the groundwork for a faster, smoother build of the final product.
Testing and Review
Testing allows teams to drill down into each stage of the software development process, providing specific guidance and feedback about the prototype’s functionality and capabilities.
Testing during the prototyping stage allows teams to anticipate problems before they absorb an onerous quantity of time, money or effort. Prototype testing can also help teams back up their claims about performance and prepare the software for its eventual deployment.
To test software during the prototyping phase, have stakeholders evaluate the prototype. Include customers in these evaluations. Use stakeholders’ feedback to identify what’s going well with the prototype, as well as what may need to be changed, fixed or scrapped.
To get the greatest benefit from the testing phase, consider engaging the organization’s marketing or public relations departments, too. Product testing offers an opportunity to foster customer trust and engagement, as well as to troubleshoot.
Use feedback from the testing phase to make deletions, additions or improvements to the prototype. Consider holding several rounds of testing and editing, especially if changes made after the first round are significant or have effects on the core functions of the software. Generally speaking, the earlier changes are made, the easier it is for developers to incorporate them into the finished software.
The process of turning a software vision into a reality often requires specialized skills. While this stage lends itself most readily to seeking outside help from development teams, incorporating those teams into the project from the start leads to better results in the design, development and testing phases.
Align Internal and External Teams
Many financial executives can visualize the software their organizations need to meet their business goals. Realizing that vision, however, may require hiring an outside software development team.
Bringing in outside developers can lead to conflicts. Team members may interfere with one another or unnecessarily duplicate work if they do not understand every participant’s responsibilities. Team members’ sense of ownership or professional pride may be undermined by lack of clarity in roles and duties, fomenting resentment.
When these risks are managed, however, outside development teams can provide great benefit to a software prototyping and development project.
Outsourcing dev work can enhance a financial company’s ability to meet customer needs while continuing to grow and expand its offerings. It can also help internal staff learn more about software, expanding their skill sets and their understanding of the business’s key goals.
Good teams have good leaders.
Assigning a leader or manager to the program as a whole can help reduce conflicts and keep a project moving. The assigned leader can smoothe communication between in-house and outside teams, stay on top of relevant metrics and information, and manage any problems that arise. The leader can also be in charge of clarifying each team member’s role on the project.
As part of defining team members’ roles and responsibilities, project leaders should clearly define their own role and responsibilities as well. For example, make sure the leader or manager’s duties do not overlap with the duties of anyone on the in-house or outsourced dev teams.
When roles and responsibilities are clearly defined, team members can focus on their own tasks, confident that everyone understands which tasks are theirs. Engagement and ownership help drive the IT team’s energy in positive directions, and away from potential resentment of an external team’s participation.
Communicate Early and Often
A strong communication strategy is a must for coordinating in-house and outside teams to complete a software project.
Good project communication does the following:
- Ensures everyone has the information they need at each stage of the project.
- Enables team members to ask questions or raise issues when needed.
- Reduces bottlenecks by allowing teams to plan for problems faced by other teams.
- Presents problems to the right parties for earlier resolution.
When bringing in an outside software developer, clear communication of every participant’s responsibilities is a must. Sharing the overall vision for the project is likewise vital.
Researchers Bjørnar Tessem and Jon Iden note how well-defined roles for each participant in a software development project can help reduce confusion. Clear communication, including access to error logs and other necessary data, can also help curb frustration and keep each team member on track. Such communication, in turn, may help to reduce lost productivity on the project itself.
In a software prototyping and development project, leaders do more than merely keep everyone else on task. They also play a key role in coordinating communication, providing feedback and guidance, and ensuring that the rest of the organization understands the project’s goals and resource needs.
Software development can be a highly technical process, and it isn’t always easy to see what a dev team has accomplished in any given hour or day. When the team includes a leader to serve as a communication liaison between external developers and internal stakeholders, everyone involved in the project can better understand what’s happening and why.
This is crucial when working with a third-party team of developers. Those responsible for facilitating this alignment must take each team’s coordination needs as they come, rather than assuming similar teams will automatically have similar needs.
As researchers Aivars Sablis, Darja Smite and Nils Moe note in the Journal of Software: Evolution and Process, “Even in the same project, teams may have different expertise and work coordination needs.”
Those researchers found that even when teams are working on the same software build or the same codebase, they may need help with different aspects of the project or with coordinating their efforts with other teams. By taking each issue as it comes, team members and leaders can better position themselves to give each team what it needs to coordinate with others, without wasting undue time attempting to anticipate issues that may never occur.
Tools for Accountability
Good prototyping and product development depend on clear assignments of responsibility and seamless communication. They also require clear means for participants to hold themselves and one another accountable.
Responsibility, communication and accountability matter whether software development proceeds entirely in-house or is shared between internal and external teams. Accountability metrics like timelines, deadlines and other measurements, however, should not be presented or wielded as punishments. Rather, they work best when framed as inspiring challenges, as goals to be reached and wins to be achieved.
In software development, time is usually of the essence. Outsourcing projects may help save time by keeping your core team focused on essential tasks while coordinating with a team of outside developers with expertise on projects like the necessary software build.
By laying out clear timelines and deadlines, internal teams can see exactly what to expect from an external developer and when to expect it. This clarity allows an internal team to better organize its own efforts to coordinate with the external team. Team members can thus focus on their own metrics and deadlines in order to ensure they’re prepared as the external team hits its own milestones.
Both in-house and third-party development teams benefit from clear measurements and deadlines. Clarity on goals and deadlines help team members see where their day-to-day tasks fit into the project as a whole, which can boost engagement and provide a sense of ownership.
Identify the Right Metrics and Benchmarks
A goal provides a single rallying point for effort. To determine how effective any given software development efforts are at reaching their goals, however, the team will need methods for selecting, gathering and analyzing data. It may also need exterior benchmarks in order to tell how the developing program measures up to its competition.
Key Metrics for Software Builds
Software development teams can choose from a number of metrics for evaluating various aspects of a software project’s progress and effectiveness.
For any software development project, measurements that focus on code quality are a must. These measurements play a key role in software testing and ensure that deployment unfolds smoothly.
The more time developers spend fixing code, the less time they have to focus on creating new code or expanding the functionalities of the planned system. Metrics to track code quality allow developers to focus on the work of creation, rather than cleaning up. Implementing metrics for code quality can help keep the team on track and ensure a better finished product.
As with any project, the monetary cost of building the new software provides an essential metric. Software projects intended to expand the capabilities of a legacy system without replacing that system tend to be particularly sensitive to questions of cost, since the tradeoffs are always between the legacy system and the new software.
Ideally, such projects would keep their budgets in a range that makes the new build more cost-effective than struggling along with the legacy system alone, but less costly than replacing the legacy system entirely.
Each project’s most important metrics will depend in part on the goals set at the start of the process. Consequently, discussing how goals will be measured, and by whom, can be a valuable part of that process.
Benchmarks: Software vs. the World
Benchmarks compare a software project and the company creating it against outside factors. They’re a way for companies to understand how their offerings and approaches measure up. They also create clear goals for a team to embrace, celebrating achievements as they occur.
As such, benchmarks also offer a way to understand the organization’s efforts from a customer’s perspective. In a sector like fintech, customers compare offerings to one another all the time. Benchmarks offer a way to see what those customers see.
Like metrics, the benchmarks chosen for exploration and measurement will depend in part on the software’s goals. They will also depend on the position of the company within the industry.
Choosing the right benchmarks can help companies create a stronger online presence, improve the customer experience and stand out from the competition.
The right benchmarks can also help generate engagement among participants in the development project, as they provide clear achievements to reach for in the development of the software. In this way, benchmarks can serve not only as a means to measure software against competing applications but also as a way for project participants to stretch their skills and expand their skill sets.
Having clear metrics allows everyone involved in a software development project to see how that project is progressing at any given moment. Clear benchmarks allow the team to see how their efforts measure up to the industry standard. Both forms of measurement can offer a sense of achievement and a job well done as teams meet them.
Looking Forward: How Better Project Planning Leads to Better Results
Effective project planning leads to more effective software releases. Setting a well-managed release as a goal, in turn, illuminates the necessary tasks and goals to be addressed at each stage of the prototyping and development process.
When planning a new software build through its envisioned launch, the team must focus not only on software release as a goal, but also on the purposes that release is intended to serve. By identifying the problem and envisioning its solution, a fintech company can ensure it builds software that helps meet its business goals.
Software builds are the result of many people working in concert. By understanding the most common challenges in a software build’s lifecycle, making a plan, and setting clear goals and expectations, financial companies ensure that the software they build enhances their core missions.
Putting Prototyping to Work
Every software application requires effort. Prototyping allows that effort to be directed more efficiently by spotting and correcting problems before the software is deployed.
For example, prototyping can help teams ensure the finished software will provide all the essential functionalities to its users. During prototyping, teams can troubleshoot the UI, thereby ensuring that the user experience they’ve designed is simple and intuitive. Rounds of testing and review can build customer goodwill while also ensuring that the final software release proceeds smoothly, speaks well of the company and provides real value to its users.
At first, prototyping can feel like a drain on a team’s time. When a prototyping phase is built into the timelines and expectations for a software build, however, prototyping becomes second nature. Project participants may even come to enjoy the prototyping phase as a chance to explore new ideas and harness their own creativity.
When it comes to creating new software, in-house teams are the resident experts on the company’s business goals, its vision and the needs of its customers. Their outsource partners are the experts in planning a software build, understanding how software achieves certain business goals, and delivering a prototype or finished application.
In this situation, coordinating with outsource development partners can benefit both the company’s core staff and the business as a whole. Their skill sets in these areas complement the internal team’s vision for the business and understanding of customers’ needs.
By coordinating their internal teams and the external dev partners, a company gets the best of both worlds: A clear understanding of business goals and deep experience in software development.