Digital Execution Guide

User Manual: Pdf

Open the PDF directly: View PDF PDF.
Page Count: 30

Open PDF In BrowserView PDF
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 different customers
spread over different industries, we have seen many customers be
incredibly successful in their first years of implementing a digital strategy,
and others get stuck within their first 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.

We call this
framework the
Digital Execution
Roald Kruit
Co-Founder and Head of Digital Execution Practice at Mendix

Table of Contents
Introduction........................................................................................................... 4
How to implement bimodal IT............................................................................. 6
Best practices for getting started with digital execution................................. 11
How to organize your first 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


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.
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-fits-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.

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 first highvalue projects in an unprecedented period of time, while
laying the foundation to structure and scale your digital
execution program.


of today’s businesses have a coherent
digital strategy that sets out how the
firm will create customer value as a
digital business.” – Forrester


of organizations
will have a bimodal
capability by 2017.


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 identified four
key aspects to develop the Mode 2 capabilities required to drive
digital innovation. They are called the 4 Ps.






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 StartStructure-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 defining 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 fluctuations and finding the
right skills based on specific 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.


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 defining 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.

Digital Execution Roadmap
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.





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 first initiatives to generate
internal PR. You want your first 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 first projects. In
addition, you want to ensure the necessary prerequisites are in place,
including infrastructure, business case, and the right stakeholders
and team.

The Scale phase is all about applying greater automation in order to realize
the efficiency 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.

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 first 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.

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 first
projects, building your first team, preparing the business
for agile development, and celebrating success.


Best practices for getting
started with digital execution

8 Considerations for picking
your first projects
The first thing you need to do is select your first projects, followed by assembling
your first 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 first projects to ensure they’re successes you can
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 first projects: ones where you can deliver business value quickly but
at the same time, are significant enough that their impact will ripple throughout the





It can go live
quickly, ideally
within 30 days

It’s highly visible and will
deliver direct business

The business needs
to be involved

The application has
limited external





There’s a desire
to take the
application into

The requirements
aren’t completely

You tried to build it in
the past—and failed

It is a Smart App

1. They can go live quickly, ideally
within 30 days
One of the main goals of the first 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 flywheel effect that accelerates momentum for
your digital innovation initiative.

2. They’re highly visible and will deliver
direct business value

Your first 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
wildfire 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 refined 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 difference between average and
great user experience.

One word of caution: limit business involvement
for the first projects to a single department!
The ability to make decisions quickly is crucial.
If you have to get consensus from multiple
departments, with conflicting needs and
priorities, this will slow the project down.

Go live in

30 days

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 offered 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 defined. At one client, it took three
months just to get access to their back-office 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 first application in the Mendix
Cloud. With one-click deployment, you’re able to remove
all friction from the deployment process.

Excel or CSV files. Once the project is successful, you can
go back and optimize the process.

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 efforts 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

• 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 first project (MVP),
instead of building direct integration that might slow
down the project, it is important to be pragmatic and use
less refined methods such as importing and exporting

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

6. The requirements aren’t
completely specified
As discussed above, digital innovation projects are often
marked by unclear business requirements. Don’t worry;
this is a good thing! For your first projects, it is better
to define a high-level goal or purpose, versus detailed
requirements. Then, your team can capture and refine
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 first projects are
often ones that your organization previously failed to
deliver. This will really open eyes and demonstrate the
value of this approach.

8. They’re Smart Apps

their own mobile app. This business decision
led to a better outcome.

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 traffic and weather
data to optimize your commute.

For instance, a Mendix customer initially failed
to build an application that calculated the price
of custom DNA. Because the algorithm was so
specific 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 first version of the application
was delivered successfully in a few days.

It is almost impossible to find projects that cover all eight considerations.
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 specifications. It is nice to have a Smart
App or to choose a project that you have failed to deliver

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.

Your first 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 first projects to deliver a
WOW factor that is worth celebrating. A wow factor is

By picking the right projects you will illustrate several important things:
You can release applications in an 			
unprecedentedly short time to market.

You are able to work with agile processes and
feedback cycles.

Business and IT can effectively collaborate to
deliver new innovations.

Your new approach is a repeatable process, not a
one-off success.

You can achieve results with limited resources
(small teams, low cost).

You will show continuous improvement using a
fail-fast learn-fast approach.

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.


How to organize your
first Mendix team

In addition to picking the right projects, you also need to find the right people for your
initial team. The following are some tips for building your first Mendix team to tackle
your first projects successfully.

Start with a small team of no more
than three people
For your first 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
Jeff 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 different 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

Scrum Master for your first projects, as the lead
developer can fill 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.

Focus on the process and
collaboration, not technology
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 find a balance
between hands-on learning and speed to market.
Start by working with an experienced Mendix business

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

Find people you want to solve
business problems

The most effective 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 coffee breaks to work together so
you are not disrupting the business.

In addition to keeping your team small, you also want
to find team members who care about solving business
problems (rather than people who prefer to build
solutions based on detailed requirements). You also
need to find 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 find a way to
make things work. As Thomas Edison said, “Genius is 1%
inspiration, 99% perspiration.”

Genius is 1%
inspiration, 99%

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
In the end, selecting the right team is the cornerstone of
success, not just for your first 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.

Use coffee breaks to work
together so you are not
disrupting the business.”

Mendix Developers come with all types of skill-sets
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.

Julio Salazar:

Moved from business analyst to development lead and is now Senior
Business Solutions Engineer at Digital Risk.



Pim van der Noll:

Mendix Business Engineer at Appronto, with experience as a programmer,
coder, project designer and experience with model-driven development.







Marcel Groeneweg:

Technical Consultant at Synnobsys with over 25 years of development
experience across a number of platforms, languages and projects.








Best practices for
applying agile within
your mode-2 team

Now that you have set up your Mode 2 team, they have to deliver their first 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.

Start with shorter sprints

Divide work based on user stories

Scrum typically calls for two to four week sprints.
However, because Mendix offers significant 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 finally demo the application. At the beginning of the
project, hold weekly sprints to facilitate rapid discovery
and refinement of the business requirements. Then as
the application starts to take shape, you can move to twoweek 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 flyin experts for specific 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

Make sure to demo each sprint

Allocate time to process user feedback

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 different 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.

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 first time, they will
feel they can truly make an impact on the project.

If there is nothing to show, that is a red flag, as the team
may be too focused on a generic technical level instead of
building functionality that supports the business goal.

At the beginning of the project, hold weekly
sprints to facilitate rapid discovery and
refinement of the business requirements.”


Prepare the business
for rapid, iterative

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 effort is in vain. You also need to prepare the
business for rapid, iterative development.
The following are some guidelines for changing the culture of IT and effectively engaging the business in rapid,
iterative and feedback-driven development cycles. Focusing on four key project meetings – Intake, Kickoff, Sprint
Review and Retrospective – these guidelines will address why and how to perform the following:
• Define and maintain a constant focus on the business goal
• Define 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.

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.”

1. Intake Workshop

2. Kickoff Workshop

This workshop is where the real collaboration begins.
The purpose of the intake workshop is to define the
project business goal—not what you want to build, but
what you want to achieve. The meeting should include
the following people:

The kickoff 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 defined in the intake
workshop. Then show how you are going to make the
project a success by defining clear rules of engagement.

• 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
define requirements.
While the business owner plays a crucial role, it is
important not to overlook the value of including
power users. They have firsthand knowledge of the
organization’s challenges and needs.
This type of interaction will help create a different
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.

Once you have defined the new rules of engagement,
work out the first 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 definition 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 first
development sprint.

3. (1st) Sprint Review Meeting
In each sprint review meeting, but particularly the first,
it is critical to show a good working demo.

• Show how you solve business problems. Don’t
just demonstrate features; tie the demo back

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
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

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
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 effectively 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 significant impact on the
project—they will quickly embrace this new approach.

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.

Why celebrating
success is crucial

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”.


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 find with project details, it
is a great conversation starter.


Make sure your most senior sponsor is in the room to
reinforces executive.

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:


Present the results of your project to your captive 		

By celebrating your successes, you will show the rest
of the organization that this new approach is real and
effective, 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 flywheel effect that allows your digital execution
program to take off.


Key requirements for your
mode-2 platform

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
first results and learnings. It is for this reason that we have structured the Digital
Execution Roadmap with three different phases.
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 benefits 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 fit into your existing security

The Start phase
is an excellent
time to start
exploring cloud.

value management

Rob Llewellyn
Founder of CXO Transform and THRIVE
Digital Business Transformation

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
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

As the role of IT departments
evolves, so too should their
capabilities to manage and
measure value.”

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 influences 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 efficiencies.

Establish KPIs, benchmark them, then define the value
potential of your new solutions. When your digital
solution is in production, report its return-on-investment
and forecast the benefits 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.

Becoming an innovative digital enterprise cannot be done in a single day.
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 first project and getting those first results. Showing off
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.


Source Exif Data:
File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.7
Linearized                      : Yes
Language                        : en-US
XMP Toolkit                     : Adobe XMP Core 5.6-c138 79.159824, 2016/09/14-01:09:01
Create Date                     : 2017:09:14 13:56:54-04:00
Metadata Date                   : 2017:09:14 13:57:38-04:00
Modify Date                     : 2017:09:14 13:57:38-04:00
Creator Tool                    : Adobe InDesign CC 2017 (Macintosh)
Instance ID                     : uuid:ddcad2ba-f231-3840-9a4e-7e3e321249bd
Original Document ID            : xmp.did:6989ac2f-2b23-46bc-8ec6-011ad59a11d3
Document ID                     :
Rendition Class                 : proof:pdf
Derived From Instance ID        : xmp.iid:26c50006-3e29-416f-bdb0-8ffd08d1f645
Derived From Document ID        : xmp.did:742c7f4f-5ff7-45e8-8a6a-f0b7dc280978
Derived From Original Document ID: xmp.did:6989ac2f-2b23-46bc-8ec6-011ad59a11d3
Derived From Rendition Class    : default
History Action                  : converted
History Parameters              : from application/x-indesign to application/pdf
History Software Agent          : Adobe InDesign CC 2017 (Macintosh)
History Changed                 : /
History When                    : 2017:09:14 13:56:54-04:00
Format                          : application/pdf
Producer                        : Adobe PDF Library 15.0
Trapped                         : False
Page Layout                     : SinglePage
Page Count                      : 30
Creator                         : Adobe InDesign CC 2017 (Macintosh)
EXIF Metadata provided by

Navigation menu