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.
