Are you Ready to Bring in a Partner to Help Create a Mobile App?

This is a question that organizations should ask themselves when engaging a partner to help with their mobile initiative. As a consulting company Magenic does our best to help the clients understand if they are ready to start the app creation process but we will never fully know until we engage with them. In cases where we engage and find the client isn’t ready, we try to steer them into a soft landing through continued communication of project difficulties which may cause a re-evaluation of the current path. However, it is always better if the client is ready before we engage. A false start can be a source of significant lost time, capital and frustration for all parties.

This leads to the important question, how do you know you are ready? At Magenic, we generally look at the following areas.

Do you understand if you have a project or a product?

Understanding this is key to knowing how the app will be built and setting expectations around the long term financial investment. Projects tend to involve a set amount of scope and have fixed delivery timelines, with a clear start and end date Many B2E applications that are not in a “bring your own device” environment may potentially be viewed as projects. A key expectation for a project type app is that it will be built once and only have minor maintenance over time. A project may also be suitable for either a waterfall approach or agile.

A product, on the under hand, describes an app that will continually change and evolve as time goes on. Most apps that are externally facing should be considered as products. The mobile environment and user expectations and competitive market are continually changing and your app will have to evolve with it as devices, capabilities and desire for features change over time. A key feature of a product is the expectation that there will be a team continually working on improving and evolving the app through its entire lifetime. Products are well suited for an agile methodology and usually falter in Waterfall environments. For more information, see Mobile Project vs. Mobile Product.

Do you understand the vision for your product and is it shared organizationally?

This may seem like an unusual problem problem but it is not. Many organizations have groups with different or incomplete vision and understanding for what the product should do. Sometimes we given guidance “to  make it work like System X”, but no one is able to articulate exactly what system X does or how it does it, because the people who knew are no longer available.  The technologies behind System X may also be considered legacy and reproducing features identically in a new technology may not be feasible. This leads to incomplete requirements and dissatisfaction as it is inevitably realized that something is missing, or that it will cost even more to create. If you are not able to articulate what your product needs are, your partners won’t know them either. Problems manifest themselves in different ways in this situation but the end result is the same: unclear requirements with no way to prioritize the backlog or successfully complete the product.  In many cases, you may have a release which does not align with stakeholder expectations or deliver expected features,

We help our clients reconcile their emerging points of view, and reach consensus on the business needs.  We help  define key application features and it’s into their overall business strategy.  We also help our client understand critical strategies to leverage mobile transformation into a strategic advantage. However, in some cases, we still find it difficult to broker internal reconciliation and shared understanding due to cultural realities. Partners like Magenic can help facilitate the process of defining strategy and how they app supports it but it is clear that understanding and agreement has to come internally. Partners are not going to be able to change, or in many cases overcome, a client’s internal culture or ability to come to consensus.

Have you defined Key Performance Indicators and know how they will be measured?

Like the definition of “done”, the definition of success can be similarly murky. Successful mobile initiatives have defined key performance indicators to track and measure success and have defined the metrics needed to evaluate success.  Without fully understanding how success will be measured, it becomes challenging to prioritize features or adjust the product after initial release to further business goals. The lack of a good definition of success can be an insidious problem because the symptoms associated with it are not always readily apparent. It usually manifests itself in difficulty creating requirements or general dissatisfaction over the perceived value of the product being created.

Do you have a product owner who is empowered to make decisions?

Someone needs to own the business requirements and be empowered to make decisions, at least on a tactical basis. No matter how well planned out a feature is, questions will come up as changes are being made to the application. Additionally, disagreements over direction will arise that need timely resolution. Questions that can’t be answered quickly will lead to a disruption in the development process. This can be particularly hard for organizations used to making decisions by committee or when other organizational stakeholders are allowed to enforce changes or alter decisions made by the backlog owner.  . When there is no clear product owner or the product owner is unable to decide or enforce decisions, at least on a short term basis, then the app development process will almost certainly start to falter as the delivery team becomes idled waiting for decisions to be made or re-working changes to decisions that have already been implemented.

Are you willing to commit to the project lifecycle and understand what it is?

Most mobile projects are better suited for using an Agile methodology, which goes beyond a solid a technical delivery team; it requires a team that includes representatives of the business that have the time and capacity to be involved in the requirements and delivery process, who can commit to the meetings/ceremonies and are willing to abide by other agile rules.  A cardinal rule here is to respect the Sprint commit once it has been made, and not change Sprint deliverables midstream.  If some of these terms seem foreign to a Client, then the Client is not ready to start an agile process. Good partners will be able to help you understand the process but they can’t force you to commit to it. That will need to happen internally and requires full support from all stakeholders.

Can your internal technical team deliver their pieces on time?

Many mobile projects integrate with internal systems that are already in place. Access to these systems can be critical to fulfilling the business requirements of the product. While in many cases integrations can be delayed and worked around for a short period of time, they usually represent a significant source of technical risk and should be addressed as early as possible. Delays in critical integrations will eventually cause project failure as the delivery team becomes delayed and costs mount to an unacceptable level without project completion.

Do you understand that the world of mobility is continually changing?

A source of product dissatisfaction can be around a misunderstanding that a product is never done and that changes to the underlying platforms can interfere with the fulfillment of business objectives. Apps, particularly ones visible to the public, your customers or business partners, need to change and evolve as the platforms change or there is a significant risk of application invalidity. The constant updating of the app to handle platform, expectation and device changes  must be anticipated and accepted.

Can you control scope and expectations internally?

Everyone wants the magic app that will do everything, solve all problems and catapult a client into the Number 1rank in the industry; sometimes, this is expected immediately and without a huge spend.  Apps can take a lot of time to build correctly; in the mobile world, applications are normally created through a long cycle of trial and error. This means that it is critical to control scope to create a minimum viable product (Does an MVP Release Make Sense for your Mobile Initiative?) and set internal expectations that not all features will need to get into the app’s first release. The app will continue to evolve and grow as you organizationally gain more insights into actual usage of the application and validate desired additional features before implementation.  It should be expected that this is “normal” and a significant source of dissatisfaction and eventual project failure is caused either by a “big bang” approach to development and/or a failure to recognize and commit to the level on ongoing investment required.

If all else fails, know when to stop

Sometimes these problems will manifest despite our best efforts or intentions. Project rarely fail due to technical reasons. There are generally 3 main themes behind every project failure: inability to define requirements;  dependencies not being met in a timely matter; and  improper expectations setting. A sign of a great collaborative relationships is when extreme problems are recognized and the group is willing to stop and pause the process so course corrections can be made.

Problems will always occur, but not all problems can be solved merely through by force of will. Knowing the difference and having the courage to call a “stop” can be the difference between long term success or burning through budget, until the project is eventually considered a failure. Good consulting partners will give you ample warning that a stop may be required. An early alert to this eventuality will be in consistent progress warnings on status reports and conversations consistently pointing out missed dependencies and commitments.

Creating a good mobile application is an expensive process and not one you can just throw over the fence and have a partner throw the result back at you. It is an iterative and collaborative process where everyone works as a team to identify and create value, are willing to commit to a shared process and where responsibility for success is likewise shared. Many of our clients cannot afford major misses on mobile initiatives. The questions listed above should be discussed internally and a readiness evaluation should be conducted before making a significant financial investment and engaging a partner.