How Can Corporates Leverage Software Prototyping?

How Can Corporates Leverage Software Prototyping?

Building a software solution can be expensive. A prototype can save time and money by delivering the right solution to solve the right problem. This agile software development method is more and more popular in startups but rarely used in corporate projects. It can deliver outstanding results in corporate projects.

1. What is a Prototype?

It is not a Proof of Concept

A Proof of Concept’s objective is to demonstrate the feasibility of a methodology or a technology. Corporates use POC when trying a new technology that is not guaranteed to operate correctly. The POC will remove a technology or methodology risk. The POC does not necessarily have any practical use and may be discarded after the demonstration. One commonality between a POC and a Prototype is that it will use the target technology.

It is not a Mockup

A Mockup is a scaled version of the final product. In software development, the mockups give a preview of what the user interface will look like. In engineering, mockups are usually scaled-down versions of the final physical product. A mockup does not use the same technology, or material, as the final product. Another issue with mockups is that the final product always differs from the original mockups. A common approach between prototyping and mockup is that both can be built and refined with each cycle.

What is a Prototype?

A prototype provides the essential features and interactions of the final target software. It is not fully featured, not fully fleshed out, not perfect visually. It may also use partial or dummy data. A prototype uses the target technology for most of its components. It is acceptable to implement some of the minor features in static or mocked modes. A prototype will give the target users an experience close to the final product and collect constructive feedback.

NB: in this article, we don’t consider paper prototypes or other forms of low-technology prototyping. More information about these technics in this excellent article.

2. Convincing Users to use a Prototype

Few users are used to working with prototypes. In most organizations, a software project will typically start with specifications and mockups, followed by a long period of building the software and then delivering the software.

Avoid the Tunnel Effect

The first advantage of building prototypes is eliminating the tunnel between the specifications validation and the software delivery. At that point, business users won’t have a perfect recollection of the specifications. Building in fast iterative prototypes will eliminate that long period. Instead, users will see the prototype unfold cycle by cycle and keep their focus on the final product.

Reduce the level of Abstraction

It is often difficult for business users to project themselves into a detailed specification document. The design choices are more challenging to understand on paper than when working with the application. Reading a business process mapping is as far from operating software as looking from the blueprint of a cathedral is from walking into the monument. Working with a prototype will feel as natural as working with the final software. The user will give constructive feedback right away during the demonstration, eliminating the review delay.

Final Delivery Effect

Using prototyping will make the final delivery a non-event. The final delivery will be an incremental version of a product the users have already experienced, fitting their objective.

3. First Version

For prototyping to be efficient, development teams must produce the first version as fast as possible. Engaging users early, avoiding the tunnel effect, and continuously correct the project course is critical.

Key Business Case

As discussed in this article, a software project must serve a business purpose. It must deliver a critical improvement in its performance, profitability, or any other business dimension. The first version of a prototype must concentrate on the core of the business case. It must deliver the critical element that unlocks the return on investment of the project.

What are the Acceptable Shortcuts?

If a project delivers the key benefit in the first weeks, why not stop there? Because the first version is a prototype and does not deliver all features, support functions, nor the final application’s scalability or stability. Users must understand that what they have at hand is not the finished product and what is missing from the final version. Amongst the acceptable shortcuts are:

• partial or dummy data,
• some static functions,
• limited error management,
• minimal user security,
• no scalability,
• only a few critical use cases,

4. Carving out the Final Version

Prototyping is like sculpture; from a general form, we carve out more fine details, step by step, to achieve the final product. Each step is a more refined, richer, enhanced version of the previous one. It requires a precise understanding of priorities to build from the highest to the lowest priority.

Frequency

The higher the frequency of user reviews, the better. There is no limit to how often we can involve users in reviews, feedback, and discussion. The desire to present a polished product often stands in the way of showing early releases. A few principles are necessary to increase the frequency of feedback: always forward, never backward: each release must be richer, better than the previous one, users must understand what they are looking at, the maturity and coverage of each prototype, the feedback must be valued, understood, and integrated in the following release,

Progress Tracking

If the project team respects the agile principles, any prototype version can go into production. Depending on the size of the project, it may take several iterations to get to a minimum set of features, but from that point onwards, every release is a release candidate. Once the team has achieved this goal, project completion and project tracking questions change in nature. If any version is a candidate for production, the project is immediately completed. Later versions will be enhancements to increase the business value of the project.

5. How to Apply Prototyping for the First Time?

Partner

An organization that never used prototyping or agile methodology will find applying these principles the first time challenging. Seeking help from a partner will be a good start. A team with experience in agile projects can guide an organization towards its first success.

Buy-In

Before launching an agile project, it is essential to convince all stakeholders of the benefits of agile methodology. If this is not the norm in the organization, there will be pushback and resistance to change.

Steering

At every checkpoint in a project, the sponsor and project team must reiterate the benefits of agile methodology and ensure that old habits don’t come back.

Celebrating

As agile projects deliver high business value faster, it is important to celebrate these benefits across the organization, so prototyping starts to spread.

Credits: Picture from Andrej Gajdos

We are Here to Help

At System in Motion, we are committed to building long-term solutions and solid foundations for your Information System. We can help you optimize your Information System, generating value for your business. Contact us for any inquiry.