Our Latest Insights & Views

Data & analytics are at the core of the digital transformation. Making sure that the information democracy is advocated across the enterprise has become an imperative. The marketplace for data & analytics solution providers is undergoing a rapid and profound transition as the supporting technologies are also changing. Cloud is becoming the standard choice more and more and pricing models are under pressure from both open-source as well as cloud providers. Successful implementations of digital platforms remain inevitable, but how to build a data architecture that works? How to modernize to level up?

Let the Business Lead with Purpose

My experiences learned me that companies that succeed at meeting their analytics objectives let business goals drive the technology and not vice versa. Data architecture has been consistently identified by IT management as a top challenge to preparing for digitizing business. In 2017 McKinsey already calculated that the difference between companies that use data effectively and those that do not translates to a 1 percent margin improvement for leaders compared to the laggards. In the apparel sector for instance data-driven companies have doubled their EBIT margin as compared to their more traditional peers.

Using data effectively requires the right data architecture, built on a foundation of business requirements. However, many to most companies take a technology-first approach, building major platforms while focusing too little on killer use cases. Many businesses, seeing digital opportunities as well as digital competition in their sectors, rush to invest without a considered, holistic data strategy. But putting together a data architecture design and the necessary technology infrastructure to effectively support data & analytics activities at scale is a tough cookie and usually only based on a small set of business use cases. Doing the technology first produces more problems than successes, including:

• Redundant and inconsistent data storage
• Overlapping functionality
• A lack of sustainability

This strategy is quite different from that employed by next-generation digital leaders, who typically embark on transformation from a business perspective and implement supporting technologies as needed. Meeting leading edge business requirements and large-scale analytics requires the integration of traditional data warehousing with new technologies. With all do respect but the design of such an architecture is not a job for the average enterprise architect. Believe me, I’ve seen more of them nearly choking to death than delivering a solid data architecture.

The Future of Data Infrastructure in Digital Enterprise

As a consultant I’m able to snoop around at many customers and despite the clamoured demise of the traditional data warehouse it still serves as the basis for analytics solutions and remains foundational. However, increased demand for new data types and new use cases continues to expand. Data architectures need to evolve in order to meet these demands in both distributed and centralized solutions. This often means adding new technologies like Hadoop a.o. Advanced architectures like the logical data warehouse help make this a reality. Key questions for the Data Architect are:

• How to puzzle the pieces when it comes down to hubs, lakes and warehouses?
• How do we balance the trade-offs between all the options?
• What are the technology options and how can we integrate them?

There’s a big chance that also your organizations’ data culture is changing. You may need DataOps! More about that in a next article but should you have questions already, do not hesitate to reach out.

With the maturing of the software industry and with an overwhelming acceptance of agility, I am still surprised at the inconsistency and overall confusion between what product managers and product owners do. Adding to the confusion, organizations struggling to make sense of the roles and job titles can’t rely on conflicting information widely spread over the internet to clarify roles and responsibilities.

As a speaker at an Agile Business Intelligence (BI) conference some years ago, the focal point of my talk was on the particular role of the product owner. The ingredients for this session were a mix of real-life experiences and theoretical perspectives. I concluded that the role of Product Owner is hard to fill in the “right” way, which makes Agile Scrum hard to jump-start and makes the process feel either flawed or incompletely designed or described. This observation remained true when I applied Agile BI in practice as a member of a Product Owner community. This article zooms in on a couple of important elements of the implementation of Agile Scrum in general, and more particularly focuses on certain points for attention in the execution of the role of a Proxy Product Owner in a Business Intelligence environment.

The Proxy Product Owner

A Product Owner role as described in the Agile Scrum theory is a business profile, and therefore she or he is a member of one or more business departments, not a member of the IT department. Not having a Product Owner in the business is usually considered to be an adverse organizational setup. A Proxy Product Owner is a person acting as a placeholder for the actual Product Owner. In essence, the Product Owner fills two major roles: proxy client when dealing with the Scrum team, and product management coach when dealing with the customer.

Taking a start with Agile BI

A valid reason for kick starting an Agile Scrum BI organization with Proxy Product Owners was the absolute faith and belief in its advantages, and being ahead of the business departments in terms of knowledge of the subject. A partial or full buy-in was projected as a future goal based on the expected success. However drawbacks of a Proxy Product Owner role are:

• The “distance” to the business, despite all efforts to bridge the gap.
• The latent lack of empowerment in decision-making (mandate) about product backlog prioritization, release planning, and whether to accept or reject work results.

In general, a Proxy Product Owner will need to put in quite a lot more effort not to end up in conflicts and miscommunication, a slowdown in decision-making, and a decrease in productivity and morale. Briefly put, Agile Scrum theory describes a User Story as one or more sentences in the everyday or business language of the end user or user of a system which captures what a user does or needs to do as part of his or her job function. It captures the ‘who’, ‘what’ and ‘why’ of a requirement in a simple, concise way, often limited in detail by what can be handwritten on a small paper note card. It is my belief that a Product Owner must master a mature level of business narrative in order to really capture the essence of what is needed. The sharing of knowledge is one of the cornerstones.  User Stories are crafted to generate understanding, not necessarily only action. Why things happened or occurred as they did needs to be translated into a ‘well-told’ User Story. This does not mean narrowing it down to simply transmitting bulleted tasks, actions and values through narrative. All these communicated abstractions are typically dead on arrival. In this sense, to me, a good User Story is much more than a so-called “reminder to have a conversation with the business”. And I believe that mastering the craftsmanship of the business narrative is an undoubted skill of the Product Owner.

The good Product Owner’s skills and commitments

I’ve had the pleasure, on more than one occasion, of being part of a BI team that decided to make the strategic shift towards an Agile Scrum BI organization. Despite all the time we had to prepare this – in some cases guided by an external Agile coach – and despite a relatively high number of dedicated strategic and tactical workshops, the true sense, the content and the responsibilities of the Product Owner were still being debated frequently many months after the go live. This was within a community that needed to start acting as Proxy Product Owners while still being part of an IT department.

In any case, figuring out what to build and mostly what to build first is the core job of the Product Owner. It is difficult. It is probably a full-time job and it demands close collaboration with the development team on an ongoing basis. The team requires guidance and direction (e.g. actively managing the product backlog, answering questions when they arise, providing feedback, signing off work results, etc.). In simple terms, the Product Owner sits in the driver’s seat, deciding what should be done and when the software should be shipped. To deliver value, Agile Scrum requires an efficient, accurate mechanism for determining the vision for a solution and a feasible pipeline for translating that vision into concrete, deliverable backlog items that can demonstrably deliver tangible benefits. It is for this reason that the performance of the Product Owner becomes the prime limiter of the team’s success. Something that we learned at my current customer very soon after go live with Agile Scrum BI.

Since BI does not equal application development, we probably cannot formally define it as a “product” since it is more of a process, the skills required to do a good job are somewhat more demanding. In general, the Product Owner skill set includes knowledge of the following:

• Business analysis (thorough understanding of the customer needs)
• Product life cycle management
• Configuration management
• Organizational marketing
• Active stakeholder communication and management
• Consensus building
• IT program management
• Basic knowledge of how software is developed and deployed

Agile Scrum requires some proficiency in all the above – and the awareness to solicit additional support when necessary. Key for a Product Owner is:

• Understanding the customer’s needs and how a solution or product will satisfy those needs. This requires a vision already rather than a vague idea.
• To be able to manage solution development and to actually participate in high-level solution design decisions.
• Possessing a degree of innovative and entrepreneurial spirit.

This broad skill set implies that ideally, the Product Owner would be a hybrid: someone who is able to look outward, understanding the end customer’s needs, and someone who looks inward, managing the value stream that transforms the customer’s needs into a solution ready to be used by that customer.

What to do and more importantly what not to do

Many of my observations practicing Agile Scrum BI indicate the difficulty of understanding the actual meaning of creating value. Somehow we get easily tempted to interpret Agile Scrum as welcoming all asks and requests resulting in a bulging product backlog and a situation of just spoon-feeding the development teams with User Stories. Even experienced Agile coaches and lecturers sometimes still fall back on proverbial sayings such as “Agile Scrum is about maximizing output” whereas the theory actually intends to maximize the outcome, a very different meaning. This inspires the unwary Product Owner to focus on the number of Stories and maybe also the size of estimated Story Points. The number and the size of User Stories do not correlate with value.

Agile Scrum BI – Body of Knowledge

Knowledge is theory. We should be thankful if action of management is based on theory. Knowledge has temporal spread. Information is not knowledge. The world is drowning in information but is slow in acquisition of knowledge. There is no substitute for knowledge. (W. Edwards Deming)

Early in any development or project process, uncertainty and risk are the Product Owner’s enemies. Knowledge can be regarded as the opposite of risk. When uncertainty is high, the focus should be on knowledge acquisition. This can be done in many ways, for instance using technical spikes, prototypes or R&D experiments to explore emerging technologies. This cannot immediately be translated into value but it is still very important because it reduces risk, an important Product Owner responsibility. The main objective is to stabilize and preferably boost the customer value curve as much as possible.

Any noticeable lack of the knowledge and skills required by a Product Owner as described above, make an Agile Scrum structure fragile. I have learned that Product Owner guiding principles, methods, tools and techniques are not very well documented in Agile Scrum practices (also there are few useful books). You often need to look elsewhere for this information. I see a great opportunity to contribute to Agile Scrum theory by means of a more detailed “Body of Knowledge”.

Gartner expects the Data & Analytics market to rise to $22.8 billion by 2020 and Reuters foresees additional growth to $29.48 billion by 2022 [1]. According to the Project Management Institute, demand over the next 10 years for project managers is growing faster than demand for workers in any other occupation [2]. With both these disciplines growing at an explosive rate, the toughest challenge will be in the realm of project portfolio management.

Surviving in an era of digital Darwinism

The past years businesses have matured tremendously in the digital competition to stand apart from rivals and respond faster to the marketplace. Adapting to increasingly digital market environments and taking advantage of digital technologies to improve operations and drive new customer value have become obvious goals for nearly every contemporary business. A multitude of additional technology initiatives and projects were started to meet the increasingly demanding expectations of the market. Obviously this urged CIO’s of any size of companies to balance out loads of initiatives and projects, all with their corresponding business cases and ROI targets. A dollar can only be spent once, so needless to say that solid and sound portfolio management practices need to safeguard the coherence of all investments. But when we’re talking about Data & Analytics, this is where the shoe still pinches in too many companies.

Portfolio Approach to Data & Analytics

Data & Analytics solutions are mostly never built in one single effort. In fact they’re best in class examples to design and develop in a flexible and iterative manner to avoid lengthy development cycles, respond to changes quickly and focus on a maximized user engagement. Typically these projects are done individually and in an isolated manner and on occasion they are fitted into programme because of their relationship with each other towards a specific goal.

It is a reality that many different Data & Analytics initiatives are usually run by many different departments or functions in parallel, resulting in quite nasty and costly deficiencies such as shadow IT, contra productive goals, competition for resources, redundant and wasted effort and so on. A lot of time and money can get lost if data driven projects are not aligned with initiatives and projects in the space of master data management or data integration or going cloud or with new kids on the block like artificial intelligence. To only name a few!

In order to capitalize on your organization’s Data & Analytics initiatives it is key to apply an efficient portfolio management process that integrates smoothly into the existing organizational structures.

And yes, of course you’re right, there’s no single right way to do IT portfolio management but a strong portfolio management process can turn all that around and do the following:

• Optimize value of Data & Analytics investments while minimising the risks
• Break down the barriers and improve communication between IT and business leaders
• Encourage business leaders to take their bit of responsibility for data driven projects
• Allow companies to allocate and schedule resources more efficiently
• Make it easy to abort or reduce redundant or low value projects.

Portfolio Management: The Cradle of IT Value

Portfolio management is a good thing but getting to an ideal state requires a serious commitment from both the business and the IT side. Directing an individual Data & Analytics project correctly will ensure it will be done right. Fine. But directing ‘all data centric initiatives’ in an aligned and successful manner will ensure that you’re doing the right projects. To make that happen, companies need to be organised on at least a couple of levels:

• Increase collaboration: IT should be able to detect data & analytics demand signals in the business
• Faster time to delivery: The business should feel confident to share their data & analytics wants and needs with IT
• Streamlined roadmap: All data driven projects should be mapped into clear and transparent ‘maps of meaning’.
• Increase project delivery success: Measure and score the outcome of your Data & Analytics projects against their business cases

Sounds too easy right? But doing it properly is not so easy. First we need to understand what the typical mistakes are that companies make when driving a portfolio management initiative. Let’s look at 5 common mistakes which can turn project portfolio into failure:

• No tangible investment strategies: It is a common practice in many companies, whether start-ups or larger corporations, to directly start with budgeting and funding. The projects scoring higher on the priority list are picked off based on the budget until the funds have been completely exhausted. The remaining projects are simply postponed or backlogged. But have they achieved the broader business goals? Did they contribute to the overall strategy?
• Managing projects only on atomic level: This will prevent organisations of keeping track of the bigger picture and map it to the company strategy. Putting together meaningful and coherent programs and breaking large projects into smaller, manageable pieces will only support better communication and decision making.

• Not prioritizing projects and/or tasks: Many departments have multiple, concurrent projects running, for both internal and external customers. Only when your organisation is able to translate the determining parameters into clear KPI’s that are used and understood across the company, a dialogue can be maintained that will result in the proper selection of things to do and things to drop.
• Letting changes get out of hand: Scope creep is pervasive in project management and difficult to manage because, as the name suggests, it creeps up on you. Without the proper control, it can severely affect your project success and it should be curtailed by a strong project portfolio process.
• Not using a project portfolio tool: Usually because many project tools are already used and there is not much appetite for an additional software burden and cost. However there’s good evidence of the greater chances of success if organisations use a PPM tool. For example, a 2009 survey by the market intelligence provider IDC reported that organizations successfully implementing a project portfolio management tool saw project failure rates drop by 59%, spent 37% less per project, reduced the number of redundant projects by 78% and increased resource productivity by 14%.[3]

To conclude and to make a case for portfolio management and Data & Analytics, Peter Drucker once thought us that you can’t manage what you can’t measure. But you can look at it from another angle as well. Key Performance Indicators (KPI) don’t magically fix blunders, they provide companies contextual information and insights that will help them achieve their objectives. But bear in mind that portfolio management KPI’s are not equal, they can work on one organization, but not on the other. When companies integrate analytics in their portfolio process they need to understand the overall aspects, individual intentions and general objectives.

And there is no mistake about it, this is much like a soul-searching phase for both the business as well as IT.

[1] https://selecthub.com/business-intelligence/business-intelligence-software-market-growing/

[2] https://www.pmi.org/learning/careers/job-growth

[3] IDC Podcast (sponsored by PPM vendor CA), “Measuring the ROI of PPM (Project and Portfolio management)” March 20, 2009.

It should be clear to all of us by now, COVID-19 will change the entire notion of offices. About 74 percent out of 317 CFOs and business finance leaders surveyed by Gartner last week expect some of their employees who were forced to work from home because of the pandemic to continue working remotely after it ends. 

According to S&P Global, the biggest industries affected by COVID-19 will be airlines, automobiles, travel, and oil & gas. Not every part of an industry will be affected equally. Some industries, such as banking, might see a big drop in revenue, but will not see the same impact on personnel compared to manufacturing as this Forbes study brought to light. 

The following three tips can help you to effectively deliver the project portfolio that your company needs in a COVID-19 world:

Tip 1: Evaluate your portfolio

Assess your existing portfolio and any new projects driven by the COVID-19 outbreak. Key considerations include:

• The strategic importance of the project
• Any compelling regulatory or legal compliance
• The project status and stage (On time/in scope/below budget? Close to be monetised?)
• Skills availability
• The likeability to work from home
• Possible new risks, issues and challenges on the horizon 
• Training (Is virtual training available?)
• Testing (Can remote testing cover all testing requirements?)
• Support (Can support activities be guaranteed and performed remotely?)

Tip 2: Re-prioritise your projects

With the answers from step one in place, use scenario analysis techniques to evaluate and re-prioritise your project portfolio. Apply both qualitative and quantitative measures to rank projects, and then select one of the following options for each:

• Slice/merge: Consider whether you can quickly achieve a minimum viable product (MVP) by splitting projects’ scopes or merging their teams.
• Defer: Pause the lowest-ranked projects to adjust to new organisational constraints and priorities.
• Slow down: Reduce the pace of projects ranked in the “middle”, ones that do not immediately contribute to your COVID-19 response and whose benefits are not materially impacted by a longer timeline.
• Accelerate: Speed up initiatives with the highest-ranked projects so they can deliver value quickly, especially if you have identified new (or less costly) resources to support them.

Tip 3: Mitigate the impact of slowed or deferred projects

Slowing or deferring projects is a delicate task and in order to minimise the disruption and make it easier to get the projects back up to speed tomorrow, you will have to navigate a number of complex considerations, including the following:

• Notify all relevant stakeholders: These stakeholders may include the owners of internal controls.
• Consider contractual impacts and communicate with vendors: Work with your legal and procurement teams to understand and address contractual impacts, including possible cancellations. 
• Understand the accounting impacts: Determine whether you have an asset (capex) that can be recognized or if you should expense all work already performed (opex).
• Lay the foundation to restart or reaccelerate later: 
  • Consider now what resources and data the project will require to get back up to speed. You may even need to consider new staffing models such as Project Management as a Service. You may no longer need full time resources on the project(s).
  • Create robust, detailed documentation on open activities and lessons learned to support a rapid, cost-effective continuation.
  • Invest in innovative Agile practices in your project development streams (DevOps, DataOps, …) 

With this initial recalibration complete, your job has just begun! Continue to assess COVID-19’s impact and modify your projects and the overall portfolio accordingly. The following considerations can help successfully monitor and manage a portfolio remotely:

• Leverage a centralised program management office: If not already done, consider the investment in a centralised portfolio solution to share all project information, best practices, including remote tools, guidance and templates.
• Proactively manage vendors and partners: Evaluate service level agreements KPI’s and determine if interim exceptions are needed. 
• Sharpen your risk management focus: Update your risk framework that considers all desired outcomes in light of COVID-19’s continuing evolution.
• Share your virtual management approach: Reassure executive stakeholders by sharing information regularly and report on progress on individual projects and the overall portfolio.
• Regularly re-evaluate assumptions and scenarios: As resource capacity, productivity and business conditions may continue to change.

In the end, sound portfolio management leads to benefits, ONLY if done well.

Meanwhile #staysafe and #goagile

The harsh economic impact of COVID-19 will be beyond any doubt. Budget pressure requires a rapid response, especially during uncertain and turbulent times like this. Most to all companies started budget cut exercises on all levels. Programs and projects are postponed or simply cancelled. But rash decisions can jeopardise your longer-term objectives for success and growth.

Leading companies take a proactive and agile approach to cost optimization. It better equips them to sustain through headwinds and unknowns. What does it take to do that? How to get to an efficient approach in which you know and evaluate the risks and benefits of your cost initiatives, for now and for tomorrow?

Agile can affect the bottom line 

For the record, I’m not exactly a fundamental religious follower of Agile Scrum but even for companies that don’t apply Agile Scrum by the book, the Agile Manifesto foresees quite a useful framework that supports a continuous cost cost/benefit assessment. If for every project, you have broken down the minimum viable product deliverables or even the expectations into small enough units then these can be evaluated individually whether or not to re-prioritise or even stop them. In Agile Scrum it’s a common practice to work your way down to the details from epics or themes to user stories which represent requirements. It’s also a best-practice to apply the INVEST principle when putting together meaningful user stories. 

Well, here you are! If you have done a good job, then the first 5 INVEST characteristics will help you to: 

• Prioritise your projects or cost initiatives by mission and potential outcomes.
• Combine a scoring method and executive judgment, to identify key cost optimisation initiatives to implement over time.
• Assess the level of impact across the entire portfolio (although I need to get back on that in a following article). 
• Evaluate the trade-offs between the benefits, costs, mission risk and viability of cost optimisation initiatives.

If you apply a user story mapping technique that focusses on business value with every activity, you can map your cost optimisation initiatives on a simple grid to show the impacts, trade-offs and help build buy-in from Finance. 

In the end, Agile leads to cost savings because of the principles that form its base!

Meanwhile #staysafe and #goagile