Creating an App Factory to enable the digital transformation of your business further requires a repeatable process that allows communication, provides visibility, and enforces your guardrails. From the initial request of the App maker to create an application, the application goes through different prescribed stages that can be managed and tracked. The following sections outline several recommended stages that make up the life cycle of an App Factory application.

Application request

The starting point for any App maker is to create an application in your App Factory. The request should ask the App maker for enough information to enable the App Factory governors to determine if the request is a good fit for the program. The guardrails established for your App Factory influence the questions posed on the application form.

It is recommended that the application process begin with getting a commitment from App makers to follow program guidelines. Obtaining this agreement from the App maker starts their journey off with a clear understanding of what is expected from them and what they can expect from the App Factory team. After building the agreement, the practice managers need information to determine if the App maker and the business need are good fits for the App Factory.

The following list contains examples of questions that can be asked to help the practice managers determine if the request to create an application should be approved.

• Does this person have a clear understanding of business objectives?
• How is the process managed today?
• Have they ever built their own webpage or created an Excel macro?
• What systems might their application need to interact with?
• Does the application work with financial, healthcare or personal information?

Request review

As potential App makers submit requests to create applications in your App Factory, the practice committee must review the requests to determine if they are a good fit for your program. An application form can attempt to gather the necessary information for the practice managers to decide, but there are cases where additional information is required. Remembering that many of your potential App makers are not trained developers or IT professionals, it might be best to gather the needed information through a conversation. Doing so allows the App makers the opportunity to demonstrate the business need, which can provide invaluable insight.

Many requests might not be good fits for your program. Applications might be rejected due to the existence of another system or application already addressing the use case. The request might identify a business need that is not being addressed by the existing solution. This information can be invaluable input to the team that is supporting and maintain the existing application. In the case the application is an application in your App Factory, it is a best practice to introduce the applicant to the App maker team.

When defining your review process, consider the following suggestions:

• Review request on a schedule, so App makers know when they can expect feedback
• Have conversations with App makers when more details are required
• Facilitate team growth when overlap exists between App Factory applications

Build an application

After the request to create an application in your App Factory has been approved, it is time to enable your App makers to implement their vision. How App makers need to be enabled in order to find success will be unique for each Maker and application. When your program is starting, you might find that coaches are able to personally enable each team of App makers. This one on one coaching and guidance, while extremely helpful, might not scale well as the number of App makers increases. Create resources that App makers can consume independently to provide them with the knowledge they require, in order to make the most of the time your coaches have to offer.

The following are examples of resources that can help enable App makers:

• Online training programs
• A set of FAQs providing guidance on solving common problems

As App makers effort to implement their vision to address the business problems that affect them, at some point, the application development process must involve coaches. Coaches are a great resource for your App makers to learn how to build an application within your program guardrails. By providing additional technical guidance and education, coaches can help App makers learn how to build a loved application in an Agile manner. App makers might have a grand vision of the solution that they want to create for the business need, but there is often something short of that vision that provides value and helps address the need. Coaches can help guide App makers on how to deliver value as quickly as possible, and to start gathering feedback.

Evaluate for release

When App makers are ready to release their application, it is a best practice to review the application to ensure everything that users need to adopt the application is present.

The following examples are items to consider for your product launch checklist.

• Documentation on how to use the application
• Process for users to report issues with or seek assistance using the application
• Configuration of initial user access
• Launch plan to notify users of the availability of the application

This stage also provides an additional opportunity to guard against the rise of rogue applications. As applications launch into production, it is a best practice that the practice committee perform a design and architecture review. Practice managers view the security of the application data to ensure that none of the data being process requires additional security.

Monitoring

Monitoring is the stage in which an application is considered “Live” or “Released.” At this point in the application life cycle, you might think there is nothing left to do, because an application is available to the user base to address the business need. The App maker and the practice committee should monitor the application to understand how the business is adopting it. The gathered information can help determine the future of the application.

The following items are some key performance indicators that you can monitor to help inform any decisions about the future of the application.

• User logins – Whether unique or cumulative measurement, this metric indicates if the user base is adopting the application
• Case volume – Daily, weekly, and monthly metrics indicate how much work the application is managing
• Session length – Understanding how long a user spends in the application indicates application adoption
• Support requests – A low number of support requests might indicate a usable application, while higher levels could suggest the application needs some refinement

App makers and practice managers must understand what success is for an application and attempt to gather metrics to determine if the success criteria have been met. The application might be departmental, so high user volumes might not be a reasonable expectation. Knowing you must process 200 requests per week might be a good measurement to determine if the application has and continues to meet goals.

Retirement

As technology, business processes, and business needs change, the value that an application launched through your App Factory brings to the business might also change. Other corporate applications might see the value offered by an App Factory application and create a solution for the business problem. Businesses reorganize, eliminating the need for certain business solutions. It is possible that metrics suggest the application is not getting adopted, and the App maker can choose to no longer invest their time to build and support the application.

There are many plausible reasons for the usefulness of an application to end. When this happens, the application should be removed from the program. Letting the application languish when the maker no longer supports the application can have some adverse effects. Users who continue to use the application and need support could place a burden on your IT team. Users who have a bad experience with the application could negatively impact the perception of your App Factory.

The following are suggestions of actions to take when retiring an application:

• Remove all user access to the application
• Freeze the application, preventing the creation of new work items
• Migrate all active work other systems or processes
• Package up the application and assets in case of a future need

Graduation

When an application meets all the success criteria and becomes a critical part of the business, your App Factory might not be the appropriate location to host the application. When the user base and business require more than what your App Factory program and App maker can provide, it is time to consider graduation. Graduation is when the hosting, maintenance, support, and development of the application moves more to a traditional IT team. When an application reaches the graduation stage, it is beneficial to have IT partnership and representation on your practice committee to aid in the transition of the application from the App Factory to IT.

If an application runs successfully in your App Factory, how do you know when it is time to graduate the application? The limitations of your App Factory determine when the application is a candidate for graduation.

The following items are some indicators that might suggest the application needs are more than you can provide:

• High availability – If the application is down or unavailable, regular operations of the business will be adversely affected
• Urgent support requests – Your practice managers, makers, and coaches are receiving urgent requests to address production issues
• Maker limitations – Change requests for improvements exceed the ability of the App maker
• Security – The data that the application works with needs a higher level of security
• Necessary Integrations – Interactions with systems not available to your App Factory are required