Digital Execution Guide
User Manual: Pdf
Open the PDF directly: View PDF 
.
Page Count: 30
Your Starter Guide to
Digital Execution
Customer success is one of the key pillars of Mendix. We know that
implementing a digital strategy is more than just buying a technology
platform. From our experience with more than 500 dierent customers
spread over dierent industries, we have seen many customers be
incredibly successful in their rst years of implementing a digital strategy,
and others get stuck within their rst few apps. Over time, we have used this
collective knowledge from our customers to develop a framework and set of
best practices to ensure that all of our customers are successful with their
digital initiatives.
Roald Kruit
Co-Founder and Head of Digital Execution Practice at Mendix
We call this
framework the
Digital Execution
Roadmap.
Table of Contents
Introduction........................................................................................................... 4
How to implement bimodal IT............................................................................. 6
Best practices for getting started with digital execution................................. 11
How to organize your rst Mendix team.......................................................... 16
Best practices for applying agile within your mode-2 team........................... 21
Prepare the business for rapid, iterative development................................. 23
Why celebrating success is crucial..................................................................... 26
Key requirements for your mode-2 platform.................................................. 27
Transformation value management................................................................. 28
Conclusion........................................................................................................... 30
Introduction
This guide outlines a proven, best practices-based
approach to getting your digital execution underway,
from how to implement a bimodal IT strategy
successfully to addressing the Portfolio, People, Process
and Platform aspects of a successful digital execution.
You’ll have everything you need to deliver your rst high-
value projects in an unprecedented period of time, while
laying the foundation to structure and scale your digital
execution program.
The CIO’s biggest challenge driving digital innovation
is not technology, but leading change. According to
Gartner, the biggest barriers for leading this change
are skills and resources, funding, culture and structure
of the organization, and IT-business alignment. Digital
execution requires new approaches and unprecedented
collaboration between IT and business.
For any organization faced with the need to innovate
quickly in the digital world, it is important to stay clear
of a one-size-ts-all strategy and instead implement
a bimodal IT approach. A bimodal IT strategy calls for
two parallel modes: Mode 1 recognizes that there are
areas of the enterprise that have more certainty, clear
objectives and a predicted plan. Mode 2 recognizes
that in other areas of the enterprise, requirements are
unclear and changing, and things are less understood at
the start.
One of the biggest challenges companies face today is how to evolve with the
digital era to stay relevant. Technology trends like the Internet of things (IoT),
big data and machine learning are reshaping entire industries. These trends
are creating enormous opportunities to transform their internal operations,
customer experience and even their underlying business models.
27%
of today’s businesses have a coherent
digital strategy that sets out how the
rm will create customer value as a
digital business.” – Forrester
75%
of organizations
will have a bimodal
capability by 2017.
50%
will make a mess of it.
How to implement
bimodal IT To cope with a high degree of uncertainty, Mode 2 emphasizes
agility and speed, like a digital startup. Mendix has identied four
key aspects to develop the Mode 2 capabilities required to drive
digital innovation. They are called the 4 Ps.
Portfolio People Process Platform
The starting point is all about identifying the right projects, which should combine
quick wins and high-value initiatives. Quick wins allow you to realize immediate
success and create a wow factor, while high-value initiatives justify broader
organizational change. Initially focus on creating a portfolio based on the Start-
Structure-Scale roadmap (see below), followed by implementing processes to
encourage and manage ideation. It helps to include new, innovative types of Smart
Apps that are intelligent, contextual and proactive. Download the Smart Apps
eBook to learn more.
Senior executive buy-in is absolutely crucial for successful digital execution
programs. Equally important is dening the person who will drive the program
and the teams who will deliver on those projects. This generally entails creating
multiple small, cross-functional teams made up of tech-savvy business people
and/or business-savvy tech people.
As demand for these teams is often unpredictable, implementing an adaptive
sourcing strategy over time is essential to coping with uctuations and nding the
right skills based on specic project requirements. Moreover, an internal center
of excellence helps ensure continuity of essential talent while providing shared
services and best practices to support the overall program.
People
Portfolio
Establish processes for rapid, iterative development and instant deployment
in a fail-fast, test and learn approach. While establishing the right governance
and DevOps practices is ultimately critical to scaling, the initial focus is on the
collaboration between business and IT and the agility required to continuously
release and iterate based on user feedback.
The platform piece is not just about selecting the right rapid application
development platform or IoT, Big Data and Machine Learning technologies. It
is also about dening a cloud strategy to minimize costs and time-to-market,
positioning the platform in your enterprise architecture to use it for the right
reasons, integrating this with your existing landscape, applying best practices (e.g.
microservices) to get optimal results, and ensuring security.
All of the above should be one coherent architecture supporting your Mode-2
processes, teams and portfolio.
Process Platform
Digital Execution Roadmap
Start Structure Scale
These 4 Ps are essential to your digital execution, but you can’t boil the ocean.
Trying to do everything all at once and immediately focusing on scale will cause
you to fail for two reasons:
1. It is too much to swallow at once.
The organization simply cannot manage that much change at once. The sheer
size of the initiative will inevitably force it to stall.
2. Change is too disruptive without proof.
It is exactly for these reasons that Mendix created the Digital Execution
Roadmap, guiding organizations through three distinct phases of execution:
Start, Structure and Scale.
Start
The Start phase is all about starting small, gaining broader support
for your digital execution program by proving the value of your new
approach, and celebrating the success of your rst initiatives to generate
internal PR. You want your rst projects to have a WOW factor that is
unexpected and high impact so they can be a catalyst for additional
projects and spread buzz throughout the company. As Plautus said, “One
eye-witness weighs more than ten hearsays – Seeing is believing all the
world over.” This is why it is important to pick the right rst projects. In
addition, you want to ensure the necessary prerequisites are in place,
including infrastructure, business case, and the right stakeholders
and team.
Structure
As you move to the Structure phase you begin to focus on formalizing
your team and strategy to accelerate digital execution. In this phase,
along with building out your team, identifying training needs and
deciding on a sourcing strategy are key objectives. It is also important
to formalize the methodology used during the rst projects to make
success replicable. As the number of applications grows, other topics
become important, such as implementing DevOps to enable fast,
continuous delivery, and focusing on governance and architecture to
ensure your apps are maintainable and compliant.
Scale
The Scale phase is all about applying greater automation in order to realize
the eciency required to deliver and manage hundreds of applications to
become a digital enterprise. This includes, among other things, automating
deployment and maintenance to support a large portfolio, automating
quality assurance to proactively monitor the maintainability of your projects,
and enabling greater reusability by establishing a private app store. With
these capabilities in place, you can maximize value and productivity by
creating distributed innovation capabilities throughout the enterprise, with
multiple teams developing simultaneously.
Now that you are familiar with the Digital Execution
Roadmap and the focus of the 4 Ps in the Start phase,
this guide will dive into best practices to get you started
with your digital execution, including picking your rst
projects, building your rst team, preparing the business
for agile development, and celebrating success.
Best practices for getting
started with digital execution
Portfolio
8 Considerations for picking
your rst projects
The rst thing you need to do is select your rst projects, followed by assembling
your rst team. Once these elements are in place, the next steps are to learn agile
best practices and to prepare the business for rapid, collaborative and iterative
development. The last step is to celebrate success and use it as a catalyst for change.
Let’s start by choosing the right rst projects to ensure they’re successes you can
celebrate.
The Start phase is about starting small and celebrating success to build internal
excitement—and momentum—for your digital innovation program. It is important
to pick the right rst projects: ones where you can deliver business value quickly but
at the same time, are signicant enough that their impact will ripple throughout the
organization.
1234
It’s highly visible and will
deliver direct business
value
The business needs
to be involved
The application has
limited external
dependencies
It can go live
quickly, ideally
within 30 days
78
You tried to build it in
the past—and failed
It is a Smart App
5
There’s a desire
to take the
application into
production
6
The requirements
aren’t completely
specied
1. They can go live quickly, ideally
within 30 days
One of the main goals of the rst projects is to validate
your ability to rapidly bring new ideas to market. You
want these applications to be something that gets the
organization excited and open to experimentation.
Therefore, it’s important that you identify quick wins that
can go live quickly, typically in 30 days. Gartner calls them
‘Island’ projects, as they are limited in scope and can stand
alone in production. The key is to show results quickly to
create a ywheel eect that accelerates momentum for
your digital innovation initiative.
2. They’re highly visible and will deliver
direct business value
Your rst projects should also be highly visible within
the organization. They must have the right urgency and
executive support, as well as deliver tangible business
value. You want to ensure the results get noticed and your
success gets shared.
You want word of your initial successes to spread like
wildre throughout the organization. Suddenly, you’ll
have colleagues banging at your door, saying things like,
“I heard you delivered that application in 30 days. How did
you do that? Will it work for my project?”
3. The business needs to be involved
In addition to executive support, you want projects that
require direct business involvement. This isn’t unusual
with digital innovation projects, as the requirements
are often unclear and need to be rened through
collaboration with, and feedback from, the business.
The goal is to illustrate the higher level of creativity and
collaboration facilitated by this new approach.
A common theme is that user involvement in the
development process leads to much higher acceptance.
And while this collaboration is important to delivering
on the core business requirements, it is also about
uncovering those small features that aren’t known
at the beginning of the project but ultimately
determine the dierence between average and
great user experience.
Go live in
30 days
One word of caution: limit business involvement
for the rst projects to a single department!
The ability to make decisions quickly is crucial.
If you have to get consensus from multiple
departments, with conicting needs and
priorities, this will slow the project down.
4. The applications have limited
external dependencies
To deliver applications quickly, in as little as 30 days, you
need to limit external dependencies. The productivity
advantage oered by a platform like Mendix can be
quickly mitigated by external factors over which you have
no control. Examples include:
• Integration with existing systems, particularly those
where APIs aren’t dened. At one client, it took three
months just to get access to their back-oce system. You
simply cannot wait that long.
• Deployment infrastructure. It’s not uncommon at large
companies to wait two months for the required hardware.
For this reason, deploy your rst application in the Mendix
Cloud. With one-click deployment, you’re able to remove
all friction from the deployment process.
• Industry regulations. Often, application needs emerge
in response to new regulations. However, if all the
requirements aren’t available, you’ll be forced to wait,
causing project delays. For your rst project (MVP),
instead of building direct integration that might slow
down the project, it is important to be pragmatic and use
less rened methods such as importing and exporting
5. There’s a desire to take the
applications into production
Another important consideration is that you can take
the applications into production. You will gain a clearer
picture of the time to market advantage. Plus, you will
help your internal PR eorts with a live application that’s
delivering real business value. (As an aside, starting with
a prototype might lead others to believe this approach is
only suitable for prototyping, selling the impact short.)
If you decide not to take an application live, the decision
should be made for business—not technical—reasons.
For instance, a Mendix customer built a
customer self-service portal in six weeks, only
to discover a week before go-live that their
biggest competitor launched a mobile app.
They delayed the launch a few weeks to build
their own mobile app. This business decision
led to a better outcome.
6. The requirements aren’t
completely specied
As discussed above, digital innovation projects are often
marked by unclear business requirements. Don’t worry;
this is a good thing! For your rst projects, it is better
to dene a high-level goal or purpose, versus detailed
requirements. Then, your team can capture and rene
requirements using an iterative development approach.
The process of getting from idea to production is
traditionally a lot of work, so when your users see an
idea come to fruition in just 30 days, they will
be amazed.
7. You tried to build it in the past—
and failed
It may sound contradictory, but good rst projects are
often ones that your organization previously failed to
deliver. This will really open eyes and demonstrate the
value of this approach.
For instance, a Mendix customer initially failed
to build an application that calculated the price
of custom DNA. Because the algorithm was so
specic to the business, the .NET developer wasn’t
able to grasp all the nuances. Using Mendix,
business and IT were able to collaborate much
more closely and a rst version of the application
was delivered successfully in a few days.
Excel or CSV les. Once the project is successful, you can
go back and optimize the process.
8. They’re Smart Apps
To ensure that apps deliver the best possible experience
to the user, they should be intelligent, contextual
and proactive – Smart Apps. For example, Waze is a
navigation app that is smart and personalized for the
user because it knows where you are in real-time, knows
whether you are in transit and knows when you typically
arrive to work in the morning. It combines contextual
and historical data with real-time trac and weather
data to optimize your commute.
You can release applications in an
unprecedentedly short time to market.
Business and IT can eectively collaborate to
deliver new innovations.
You can achieve results with limited resources
(small teams, low cost).
Your rst projects shouldn’t focus on things like scaling
or operations. Ultimately, the focus is on delivering
business value quickly, in an experimental way where
creativity and close cooperation between business and
IT are central.
Lastly, it is important for your rst projects to deliver a
WOW factor that is worth celebrating. A wow factor is
To break down the priorities, the project must be
highly visible, involve the business and be built quickly.
The project should result in a desire to take it into
production, ideally have limited external dependencies
or no complete specications. It is nice to have a Smart
App or to choose a project that you have failed to deliver
previously.
achieved by building something with high value that is
unexpected: whether the app itself or a cool feature.
Other people throughout your organization should
come to you, asking you to apply your new approach to
their problems so they can share in that success.
By picking the right projects you will illustrate several important things:
You are able to work with agile processes and
feedback cycles.
Your new approach is a repeatable process, not a
one-o success.
You will show continuous improvement using a
fail-fast learn-fast approach.
Furthermore, the more you progress from the Start
phase to the Structure phase, the looser these
requirements become. For example, you can select
applications with multiple integration points.
It is almost impossible to nd projects that cover all eight considerations.
How to organize your
rst Mendix team
People
Start with a small team of no more
than three people
Focus on the process and
collaboration, not technology
For your rst projects, it is important to limit your
dependencies and keep your team small, no more than
three people. Ultimately, we’ve found that it is easier for
a few people to learn a lot in a short period of time, than
for a large group to achieve the same results.
A small team ensures that you can deliver new
applications quickly, avoiding much of the
miscommunication and delay associated with larger
development teams. There are plenty of examples
promoting smaller teams as a means to encourage
productivity and creativity—for instance, Amazon CEO
Je Bezos’ “two pizza rule.” Ultimately, the smaller the
team, the more brainstorming and peer review, which
drives the group to further improvement.
One pitfall to avoid is assigning a dierent team member
for each project role. Each member can be responsible
for multiple roles. Instead of a formal structure,
team members take on work based on their areas of
expertise. For example, you don’t need a dedicated
In your initial projects, you need to show results quickly
and justify the continued use of a new approach (the
platform). With this in mind, you need to nd a balance
between hands-on learning and speed to market.
Start by working with an experienced Mendix business
engineer.
Scrum Master for your rst projects, as the lead
developer can ll these roles on top of his or her existing
development tasks.
Once these three people are up to speed, you can add
two to three more people and then split them into
two teams so you have multiple teams developing and
maintaining multiple applications. Keep in mind that
because these initial people will be at the heart of your
Center of Excellence, they should be A players.
In addition to picking the right projects, you also need to nd the right people for your
initial team. The following are some tips for building your rst Mendix team to tackle
your rst projects successfully.
We’ve found that it is easier for a few
people to learn a lot in a short period of
time, than for a large group to achieve the
same results."
Work together onsite with
the business
The most eective Mode 2 teams are onsite together,
ideally located with the business, working through
frequent iterations based on user feedback. Your
development resources need daily access to business
stakeholders so that they can discuss progress, review
changes, and ensure everyone is on the same page. It’s
all about enabling creativity to solve business challenges
faster. Moreover, by keeping your team close together,
you can keep the group excited and motivated to keep
showing results. Use coee breaks to work together so
you are not disrupting the business.
Find people you want to solve
business problems
In addition to keeping your team small, you also want
to nd team members who care about solving business
problems (rather than people who prefer to build
solutions based on detailed requirements). You also
need to nd people who have a “can-do” attitude. This
is important because there will be many obstacles to
overcome due to existing processes and the culture of
the business. The team needs to be made up of people
who won’t give up and who will always nd a way to
make things work. As Thomas Edison said, “Genius is 1%
inspiration, 99% perspiration.”
Look for people who want to test their limits, have
some technical acumen, but also understand business
challenges. A host of individuals are able to successfully
make the transition, coming from business analyst,
UX, front-end web design, and business intelligence
backgrounds.
In the end, selecting the right team is the cornerstone of
success, not just for your rst project but for your entire
bimodal IT program.
Two-pizza rule:
The smaller the team, the more brainstorming
and peer review, which drives the group to
further improvement.
Genius is 1%
inspiration, 99%
perspiration.”
Use coee breaks to work
together so you are not
disrupting the business.”
Nicolas Delord:
Java Developer turned Business Analyst turned Product Owner and
Creative Technologist with the ADP Product Incubator, with experience in
software development and UML models.
Pim van der Noll:
Mendix Business Engineer at Appronto, with experience as a programmer,
coder, project designer and experience with model-driven development.
Mendix Developers come with all types of skill-sets
Julio Salazar:
Moved from business analyst to development lead and is now Senior
Business Solutions Engineer at Digital Risk.
Marcel Groeneweg:
Technical Consultant at Synnobsys with over 25 years of development
experience across a number of platforms, languages and projects.
MENDIX
CERTIFIE D
MENDIX
CERTIFIE D
MENDIX
CERTIFIE D
MENDIX
CERTIFIE D
MENDIX MENDIX
CERTIFIE D
MENDIX
CERTIFIE D
MENDIX
CERTIFIE D
MENDIX
MENDIX
Best practices for
applying agile within
your mode-2 team
Process
Start with shorter sprints Divide work based on user stories
Make sure to demo each sprint
Scrum typically calls for two to four week sprints.
However, because Mendix oers signicant productivity
advantages over traditional approaches, you should cut
that in half. Otherwise, assumptions made by developers
early on can really propagate four weeks later when
you nally demo the application. At the beginning of the
project, hold weekly sprints to facilitate rapid discovery
and renement of the business requirements. Then as
the application starts to take shape, you can move to two-
week sprints.
Your recently selected small teams of 2-3 Business
Engineers can do 80-90% of the work themselves (thanks
to Mendix). Then, when necessary, you can bring y-
in experts for specic technical issues like integration
or performance tuning. Instead of organizing around
technical responsibilities, divide work based on user
stories. Give people full ownership of their requirements,
versus only being held accountable for 20% of each
requirement.
Systems design can be a very abstract exercise. Two
people can literally sit in the same room for hours and
think they are talking about the same thing, when in
reality, that are on completely dierent pages. That’s why
it is crucial to show a good working demo during each
sprint review meeting. The demo should help validate
existing business requirements and uncover new needs.
If there is nothing to show, that is a red ag, as the team
may be too focused on a generic technical level instead of
building functionality that supports the business goal.
Allocate time to process user feedback
In your sprints, you should allocate enough
time (approximately 30%) to making user-driven
enhancements, versus strictly delivering new features.
The business is used to not being listened to in
development projects. You want to set the tone that they
are being heard and that you are able to incorporate their
feedback remarkably quick. For the rst time, they will
feel they can truly make an impact on the project.
Now that you have set up your Mode 2 team, they have to deliver their rst app in
this new method of working: rapid app delivery. While Agile methodologies like Scrum
are a good starting point and a critical component of digital execution, not all Scrum
principles work in practice with Mode 2 organizations.
To ensure that you are properly applying Scrum within your team, focus on the
following best practices.
At the beginning of the project, hold weekly
sprints to facilitate rapid discovery and
renement of the business requirements.”
Prepare the business
for rapid, iterative
development
Process
The following are some guidelines for changing the culture of IT and eectively engaging the business in rapid,
iterative and feedback-driven development cycles. Focusing on four key project meetings – Intake, Kicko, Sprint
Review and Retrospective – these guidelines will address why and how to perform the following:
• Dene and maintain a constant focus on the business goal
• Dene clear rules of engagement for how you will work together
• Actively show that you are listening to the business
• Work together to continuously improve IT-business collaboration
To make the above guidelines more tangible and executable, Mendix has developed a set of best practices and
necessary workshops/meetings.
Your Mode 2 team is now prepared for agile development with the right process
and attitude to work together with the business to deliver the app. However, if the
business is unwilling or unprepared, the eort is in vain. You also need to prepare the
business for rapid, iterative development. Digital innovation happens at
the intersection of a business
person with a good idea and
someone with the technical
aptitude to bring it to life.”
2. Kicko Workshop
The kicko workshop should cover several topics,
including project roles and responsibilities, a high-level
delivery plan, agile awareness and a lean-and-mean
Mode 2 governance approach. In terms of business
engagement, start by sharing the strategic business
goals and application goals, as dened in the intake
workshop. Then show how you are going to make the
project a success by dening clear rules of engagement.
Once you have dened the new rules of engagement,
work out the rst 10-20 user stories as a team. Go
through the exercise of having one person write a user
story and someone else interpret it. This helps to create
a shared vocabulary and understanding, including
a denition of “ready” that indicated when the team
collectively feels a user story is ready for development.
As a last step, prioritize the user stories for the rst
development sprint.
3. (1st) Sprint Review Meeting
In each sprint review meeting, but particularly the rst,
it is critical to show a good working demo.
• Show how you solve business problems. Don’t
just demonstrate features; tie the demo back
their advice on how to develop a more structured
Mode 2 approach that further enhances engagement
and collaboration with other business units.
One of the most important questions to ask the business
stakeholders in the retrospective is “how would you tell
your friends/colleagues about this project to make them
enthusiastic?” This elevator pitch is great fodder for
internal feedback and celebrating success, with the goal
of implementing this approach more broadly across the
organization.
The retrospective should also act as input for celebrating
success. It is especially important to capture any quotes
during this process to share at the celebration.
Remember, for digital execution to be successful, the
business must be actively involved throughout the
project lifecycle. To eectively engage the business,
you may have to reverse years of perception. The key
is constant communication and proof. Once business
users see that you have done what you said you would
do—and that they can have a signicant impact on the
project—they will quickly embrace this new approach.
to the business objectives and challenges
shared at the onset of the project.
• Make sure the UI looks good. Users will judge
the book by its cover, even early in the
development process. Make sure they don’t
tune out because you have underinvested in UI.
• Use good demo data. The data needs to be
representative so that the demo feels real to
business users. They will start to get excited for
the impact of the new solution.
4. The retrospective should look back
on the project, including successes
and lessons learned.
• Did the project achieve its business goal?
• Did you have the right people on the team?
• How well was the business engaged in the
process?
Embrace all feedback, whether it’s perception or reality.
Again, let the business know they have a voice and that
their input is vital to improving future projects. Seek
1. Intake Workshop
This workshop is where the real collaboration begins.
The purpose of the intake workshop is to dene the
project business goal—not what you want to build, but
what you want to achieve. The meeting should include
the following people:
• The Mode 2 sponsor: The leader of the Mode 2
initiative, who can articulate the strategic value of
the new approach.
• The business owner: Who can describe the
problem the application should address.
• Power users: A subset of end users, to
dene requirements.
While the business owner plays a crucial role, it is
important not to overlook the value of including
power users. They have rsthand knowledge of the
organization’s challenges and needs.
This type of interaction will help create a dierent
attitude towards IT and set the stage with the rest of the
organization. While this workshop alone won’t reverse
years of distrust, getting the business to think “this just
might work” is a victory that you can build upon.
When you celebrate success you generate internal PR—
creating awareness for the value you’ve delivered and
what it means for other individuals and departments
across your organization. The celebration will drive
executive sponsorship, broader support and attract
new talent. According to McKinsey, “Involvement
from company leaders is critical. Companies with CEO
sponsors are twice as likely to be high performers as
companies whose CEOs are not directly engaged
in digital”.
People like to be associated with success and when they
see it, they will very quickly want to be a part of it. This
is especially true for business unit chiefs, who may not
understand the inner workings of technology but will be
motivated to replicate the success of their peers.
Here are some tips to maximize the impact of your
internal celebration:
Why celebrating
success is crucial
Your initial applications should become a catalyst for change throughout the
organization. To ensure the organization knows about the successes of the apps and
understands their value, you need to celebrate success.
By celebrating your successes, you will show the rest
of the organization that this new approach is real and
eective, helping to create widespread buy-in and
support. In the process, you will almost always identify
new project ideas you weren’t aware of, creating
a ywheel eect that allows your digital execution
program to take o.
• Invite as many people as possible, not just your
development team.
• Host the party in a central location so other departments
take notice.
• Bring the largest cake you can nd with project details, it
is a great conversation starter.
• Make sure your most senior sponsor is in the room to
reinforces executive.
• Present the results of your project to your captive
audience.
Process
Though it is often tempting to think about the platform in its entirety right from the
start, because there are so many unknowns, including proof that the organization
can actually adopt this new way of working, it is better to wait until you have your
rst results and learnings. It is for this reason that we have structured the Digital
Execution Roadmap with three dierent phases.
The Start phase
is an excellent
time to start
exploring cloud.
In the initial Start phase of your digital execution, most of the platform
considerations, such as reusability and best practice patterns, are not
immediately relevant. Although, the Start phase is an excellent time to
start exploring cloud, and to use this knowledge as input for strategic
choices in the future.
Use this time to experience the benets of instant provisioning, not
just of the application environment, but all the software needed
to support the entire lifecycle, from project management to
repositories. Learning more about how easy it should be to
deploy and operate apps shows how developers can do this
themselves. A key element will be to implement DevOps in
a later stage.
Last but not least, your organization can begin to
understand the security features of cloud, and you
can assess how this will t into your existing security
framework.
Key requirements for your
mode-2 platform
Platform
Transformation
value management
As the role of IT departments
evolves, so too should their
capabilities to manage and
measure value.”
After the celebration, the next challenge is to quantify the value of your digital
program. While many in your company might be excited by the perceived value of
innovative digital solutions, others such as the CFO and line-of-business leaders need
to stay focused on business value that can be measured. Sweeping statements of
digitization and nebulous notions of new value won’t be enough to satisfy leaders
who need to report numbers to their Boards.
Despite widespread acceptance that social, mobile, analytics and cloud should have a place in every company’s future,
it’s wise to demonstrate how the business value of digital solutions can and will be managed and measured. As the role
of IT departments evolves, so too should their capabilities to manage and measure value.
Measuring Value to Win Executive
Hearts and Minds
Rob Llewellyn
Founder of CXO Transform and THRIVE
Digital Business Transformation
Start by identifying the value drivers that your digital
solution can contribute to, then determine the current
status of the value driver. Only by doing this will you
know how your new digital solutions are impacting the
business.
If you need to prove the quantitative impact of a new app
on the business, you need to capture the data relating to
customer behavior to identify how, when, and where the
app inuences customers at each step of their journey.
Next you illustrate how your app has increased customer
engagement and satisfaction, and how it also might have
led to improvements in operational eciencies.
Establish KPIs, benchmark them, then dene the value
potential of your new solutions. When your digital
solution is in production, report its return-on-investment
and forecast the benets for the next 2 to 3 years.
With the right choice of digital solutions and some
basic value management, you can be sure to whet the
appetite of not only the workforce in general, but also
that of executives.
There is a natural tendency to proceed with caution, but Hans
Luijendijk, director of business enterprise architecture and
strategy for KLM, says “Just do it” when it comes to building
your rst project and getting those rst results. Showing o
the WOW factor is the best way to prove the value of this new
way of working.
The Digital Execution Roadmap is set up to help you take
your business through the right steps to digital success. After
reading this starter guide, you should have the information
you need to take your business through the Start phase and
one step closer to becoming a digital master.
Becoming an innovative digital enterprise cannot be done in a single day.
