Team Size Competencies

Episode 25

The availability of technology skills between organizations can vary dramatically, and not all organizations can have dedicated technical staff. Regardless, staying technology relevant is a universal challenge no matter the size or sophistication of the organization. To make the most out of the resources available requires understanding their strengths and limitations, and how these resources interact with the rest of the organization.

What if the most technical person in the office handles all the technical stuff? Typically, these individuals are your spreadsheet wizards, printer fixers, VCR programmers, or the youngest employee. There are two elements at play here. The first is that an individual represents a culmination of their lived experience, the second is that a motivated individual can learn what they do not know. The most tech savvy individuals are likely the most curious and have learned technical skills while solving problems. Under the right conditions these individuals can thrive in a highly diverse problem-solving environment building solutions to support the organization. However, it is very easy to overwhelm them. Novel problems require learning before acting. Anyone who has tackled a messy spreadsheet problem, understands that the second time solving the problem goes significantly faster.

What happens when your organization has a single IT person? Compared to the previous example, this individual has formal technology training, whether as a developer or operator. Here expectations are different, as non-technical staff will have a common perception that a technology expert should know everything. With the higher expectations, it is very easy to overwhelm these individuals into a state where all their time is devoted to firefighting. When an organization’s technical needs remain in a “keep the lights on” mentality for too long, the culture will eventually begin to accept that the situation must be the norm, preventing opportunities for innovation. As a single individual they have a significantly smaller support network to call upon. Likewise, it is very difficult to integrate a single individual into many departments of an organization. Therefore, it is difficult to prevent building a silo between the technology stack and the rest of the organization.

Worker Programming A Website On A Laptop

For larger organizations, it is possible to have an entire IT team or department. An IT team is a of a mix of competencies from development, network, server, and security specialists. The dominant difference between the single individual and team is the creation of an alignment and coordination challenge. A single individual can easily self-prioritize as dependencies are singular. With a team, the breadth of lived experience is broader providing individuals within the team a larger support network. Likewise, with specialized training, there is a greater availability of competencies to call upon for problem solving. However, much like the challenges with the single IT individual, it is possible to bog down a team into a perpetual state of fire fighting. What compounds the challenge is the extra requirements for communication and knowledge sharing. Adding more resources will likely not increase productivity if the IT department reaches a critical state.

Thankfully, regardless of which situation your organization is in, there are some universal truths to technology management that can dramatically improve productivity and agility. Channelling learning from the manufacturing sector, it is very important to keep the amount of work in process to a minimum. Make work in process visible to everyone in the organization. If non-technical staff are aware of active projects, there will be greater visibility and appreciation for the work IT staff perform. Likewise, smaller batch sizes allow for greater production throughput as downstream problems can be identified earlier and have a smaller impact on system productivity. For technology projects it is important to make releases to production far more frequent with small changes. Fostering networks for feedback, organizational learning, and experimentation are critical to staying technology relevant. The worst thing that can be done is walling off your technology team and limiting feedback to only when there are big bang changes. Big bang deployments are intense, highly failure prone, and likely feedback is retrospective and unconstructive. Make work visible, keep jobs small and frequent, and talk to each other.

Microsoft Teams – Top 10 practices for running effective meetings online

Chairs Located Around A Table In A Conference Room

As we all shift to working in the virtual world, we thought we would share some best practices that MERAK has built up over the years of working remotely. Microsoft Teams is our platform of choice to facilitate our meetings (internal and external) but these practices likely apply to other platforms.

Familiarize yourself with the toolbox

Every meeting platform is different so take a few minutes to familiarize yourself with all of the tools at your disposal. From screen sharing to muting participants, those that can quickly work their way through will make great meeting moderators. If need be, create a test meeting beforehand to build up your comfort level. Remember, participants might need some extra help the first time too.

Start with a fresh reboot and close apps

Video conferencing tends to consume more resources than our regular work. Give your computer a fresh reboot before your meeting to free up resources. This also includes closing down any non-essential apps, they will just clutter things.

Be aware of your background

Our home offices are typically a bit more personalized than boardrooms. If you have privacy concerns, remove personal items like pictures and books. Use the Blur My Background feature in Microsoft Teams to obfuscate what you can’t remove.

Video over voice only

Video meetings allow us to pick up on physical attributes and mannerisms, but some people need to build up a comfort level with video. As the meeting moderator, start with video off the bat to make it the new normal. A good moderator will also know when to react to quality issues and inform participants to switch audio only for the betterment of the meeting.

Get a good headset

The quality of the built in video and audio in our various devices differs. Investing in a good quality headset that will reduce background noise and let you be heard clearly. This will not only help your individual audio quality, but when all participants are on headsets, it makes the overall quality so much better. Looking forward, Microsoft Teams is introducing AI noise suppression features to help.

Share only what is needed

Avoid sharing your entire screen with your participants. In some cases, it might seem easier or even required if having to share multiple applications or doing a complex demo but keep in mind, presenters are busy presenting and likely not aware of what is in our screen background. The last thing you want is an inappropriate notification 🙂

Make sure participants can be heard

While the quality of video conferencing is getting better and better, sometimes participant hardware presents some challenges for duplexing which results in people being cut off. Pick up on visual queues when participants are trying to speak and make sure they get their opportunity. Looking forward, Microsoft Teams is introducing a hand raising feature that should help.

Have an agenda

Like any meeting, a good agenda will bring some structure and maximize time. Ensure all participants take away key action items to avoid any confusion on next steps. Leverage the Meeting Notes feature in Teams or OneNote to make your information sharable. If Kanban boards are a tool of choice in your organization, Planner or Azure DevOps are fantastic options.

Whiteboard

If you are a whiteboard person like I am, don’t worry, there is a solution for you. Use the Whiteboard integration within Teams to get your virtual whiteboard up and running. Here’s how.

Record your meetings

This item has been a game changer for us. Using the record functionality in Teams allows us to leverage additional features in Microsoft Stream. Recorded meetings are then automatically transcribed using the power of Azure which creates instant documentation. Want to remember that amazing rant you had about Enterprise Architecture, just search for that keyword in Stream, and poof, there it is. Recording your meetings also allows other teams members to get up to speed when they are unable to participate in the live event. It makes for a fantastic training tool and knowledge base. Make sure you get participant acceptance before recording.

For more information on upcoming features, check out the Microsoft Teams Roadmap

Need help with your Microsoft Teams implementation, please reach out.

Square Pegs Round Holes and Process Play-doh

Episode 24

Matching technology solutions to business problems is no easy task. Custom software development and purchasing off the shelf software are the two most common pathways for solving business problems with technology. With custom development, you get what you want (hopefully), but you pay for the development and future maintenance. With off the shelf software, you get (mostly) what you want, but share the development and maintenance costs through license fees with others that have similar problems. There is an additional variable at play when determining the best pathway for solution development. In this blog, we will explore how adapting processes can help get the most out of a software solution.

To help illustrate the idea, visualize your business problems as a round hole in a wooden chest and the potential software solution as a square peg. Unlike in the material world, the dimensions of the hole and peg change, reflecting the changing client expectations and business needs. When the peg is too large for the opening, the contact points represent solution features that are not needed. Extra features are common with off the shelf solutions that attempt to reach a diverse number of users. If the square peg drops in without issue, the remaining gaps represent the features that are required but not available in the selected solution.

Person Using A Hammer On A Block Of Wood

For instance, digitizing a paper process will likely lead to difficulty in finding a solution with the right fit. If the square peg (solution) is too large, resources will be spent rounding out the peg through configuration, as the solution is larger than the problem requires. Likewise, if the peg (solution) is too small, resources will be spent filling the gaps with custom development. The tighter the fit, the better matched the solution is with the problem. So how do we build flexibility into the system?

System flexibility is gained by adapting processes to work best with the selected solution. Play-doh can be pressed or cut into any shape one desires. Common goals, from a user perspective, of a technology solution are to be robust and frictionless. However, meeting these goals has a price. The more engineering that is required to meet these goals the greater the resource cost, complexity, and learning requirements will be needed to fit the solution to the problem. It is far more effective to change processes upfront before going down the road of solution seeking.

For instance, within a hypothetical organization, job candidates are asked to fill out an application form detailing education, skills, and work history, then upload a resume document at the end. This time-consuming data entry process for candidates leads to top talent reneging, as the archaic hiring process is indicative of a stagnant corporate culture.

Let’s explore some process play-doh options to solve this problem. In this situation the problem is that job candidates are failing to complete the application. It was determined that if applicants could apply via resume upload only, completion rates would increase significantly. However, the data inputted into the existing HR solution is very important to current practices.

One solution would be to purchase off the shelf software to read the text on the applicants resume and perform the data entry. This may solve the problem, but the solution also comes with additional A.I. features for automated rankings, persona profiling, and role matching that are not desired as current hiring managers prefer a hands-on approach to ranking candidates. The additional features represent the extra edges of the square peg. The other solution is a document text reader; however, it lacks the ability to integrate with the current HR database. In order to function optimally, customized APIs need to be developed. This represents a peg that fits, but there are gaps that need to be filled in with custom development.

Cookie Cutters And Paydoh On A Table

Now let’s look at process play-doh. The hiring managers were asked why candidate data was stored in a database, and they explained that this made searching for candidates for roles other than the one posted significantly easier. Every organization will be different but let’s say in this case we learn that the number of roles filled indirectly was less than 10%. In this situation one process change could be to completely remove the data entry step from the application process as direct applicants were likely to have their resumes screened by hand anyway, and losing out on the few indirect hires will likely not have a material impact. A process change removed the need for a peg (solution) entirely, however, we can see from this example that an examination and refactoring of processes can lead to a dramatic shift in solution requirements.

Understanding the exceptions of the organization’s workflows is critical. The 80-20 rule here is also a good guide for determining the importance of requirements. Another element is understanding how much the current solution and process is covering current needs. If the current state covers the majority needs (~80%), then it is best to look at processes first before considering refactoring an existing solution or acquiring a new one. Lastly, if possible adapting a process to the default experience of an off the shelf solution can dramatically reduce configuration and customization needs.

Development Governance with Power Users

Episode 23

As a society, we have some crazy expectations from the applications we use. Secure, bug-free, and user-friendly. Application development must keep pace with the rapidly changing business environment, increasing client expectations have driven development and iteration times from months to hours. The challenge with such rapid development is the gap between development and the end user. That gap represents a translation challenge of mapping user needs to working software. Agile and DevOps principles have the user highly involved early and throughout the development process. This constant interaction is effective, but expensive in both time and resources. What if we could remove the gap entirely and have the user develop their own applications? Low and no-code platforms are enabling Power Users to build applications that were recently only possible through professional developers. This new development pipeline has much to offer, but how should it be managed?

A Power User is an individual whose skills and expertise are more advanced than most other users. Every office has a spreadsheet wizard who solves problems for their colleagues. Today we have more tools than spreadsheets. Low code automation, application development, and business intelligence platforms are revolutionizing the way business users perform their workflows. Empowered users can skip the resource intense development processes and focus on building what they need. No more artifacts, boards, SCRUM meetings, quality assurance, user acceptance testing, or environments to manage. The entire development team has collapsed to one; therefore, hopefully no more communication gaps when the user is also the developer. With significantly less overhead, rapid prototyping can be done in days. Low code applications built by Power Users are supported by the foundation enabled by the platform they are using, saving months to years worth of development when compared to from scratch development.

A Screenshot Of Matrix Looking Programming Code

Rapid development of applications through a low code interface does have its drawbacks. Reducing the development team to one introduces a single individual dependency risk. What happens when your office’s Power User gets mauled by a cat and is no longer available? When developing for one, the likelihood that the application has any documentation is very low. How well are the office spreadsheets documented? Probably not that well. Despite the rapid development potential of low code systems, much of the velocity is captured through templated features. When Power Users are solving novel problems, the development time can be significant for a single individual. Here are some questions to ask. How is development planned? How are issues tracked? What is being done to prevent building a black box (hello Excel marcos)? What will be done if the application becomes wildly successful and has been adopted widely through the organization? Managing these questions will require some structure.

There are no hard and fast rules for managing application development through Power Users as every environment is different. Let’s define some dimensions to help map your organization’s environment to a potential governance process. The core strength of Power Users is the removal of the development team and the administration layer that such a system requires to coordinate efforts effectively. The greater degree that the project is pathfinding, the less mission critical, fewer total users, and fewer types of users, the greater benefit a Power User can provide. At the end of the day, the exercise falls into risk management; a prudent manager would never allow a critical application touching numerous internal and external stakeholders be dependent on a single individual, no matter how powerful their wizardry skills are.

A Power User can be anyone in the office, and there are some simple structures to build robustness into Power User driven application development. The first is paired development, a common practice in software development, and a simple solution to mitigate the single dependency risk with the additional benefit two minds bring to a problem. The second is the implementation of a continuing education program within your organization to train staff in the use of these platforms. Low-code platforms are more akin to word processing and spreadsheet applications; a few training days a year can do wonders in the organization’s working knowledge. Lastly, define the boundaries to which a low code application will require involvement with your organization’s IT staff. Some questions to explore. When the application is client facing? When the application is used by more than one department? When an application has been actively used for over a year? When the application has an expected operating impact over a determined monetary value? Power Users can unleash innovation in organizations. Boxing in Power Users can stifle creativity, yet unbounded development may lead to fragmentation and creeping system risks. Proper governance of Power Users is a key element to staying technology relevant.

Managing Modern Software Solutions

Episode 22

Aligning business and IT is no easy task. There is a titanic shift underway as industries drive investment toward providing the best possible customer experience. For incumbents and new businesses alike, differentiation is derived by the coordination of people, processes, and technology. Over the last decade, technology has taken the spotlight with the explosion of applications on the market. An application is software designed for a specific task. The abundance of SaaS solutions creates challenges for organizations as these applications lock data into silos. To be competitive today, modern organizations must collaborate at scale. Modern software solutions provide the opportunity to break down silos, but have limitations that must be managed.

Construction Rebar Laid In A Pattern

The SaaS revolution has been a mixed blessing. Organizations were able derive value by adopting Customer Relationship Management (CRM), Enterprise Resource Management (ERP), and instant messaging applications. It is understood now that organizational and business structures mirror the data structures of the solutions that are acquired. If your SaaS solutions cannot share data, how good of a job do you think your people will do to fill the gap? How well does sales and marketing talk to operations? Is collaboration facilitated through exchanging spreadsheets?

In technology terms, a platform is a foundation to develop and deploy differentiating business applications. Technology platforms like Amazon Web Services (AWS) or Microsoft Azure provide the building blocks or services for other applications. Operating systems like Android, Windows, and iOS act as computing platforms that connect developers to users through marketplaces (another platform) like app stores. Like all platforms, they enable value to be derived from the object that is built on top of them.

Modern integrated software solutions blur the line between application and platform. The needs of modern business are driving solutions toward centralized platform “like” solutions. Modern software solutions have the impossible challenge of unifying all business needs under one banner (eliminate data/knowledge silos) and simultaneously operate interchangeably between highly differentiated industries and business strategies. For example, take two engineers operating in the same industry, providing the same service, they will likely build two very different spreadsheets to solve the same problem. Now replace the two engineers’ spreadsheets with a generalized software solution that also works for an HVAC service technician and a hair salon.

Goals of modern solutions are to centralize data, coordinate processes, and foster collaboration and innovation within an organization. These principles underlying modern software solutions are ironically captured in a 20-year-old application/platform, Microsoft SharePoint. SharePoint is a highly customizable web-based platform for document management and collaboration. Loved by some, the bane of existence to many others, SharePoint is an excellent representation of the challenges implementing modern solutions. Modern solutions provide out of the box functionality that target universal problems (email, document creation and storage, task lists), and a platform functionality for building custom services to meet the unique need of the organization.

A Crane On Top Of A Building Being Constructed

The SaaS boom is a product from the desire to have a solution capable of providing value out of the box. Previously, heavy enterprise systems stifled agility and locked organizations into expensive and lengthy implementations. The trade-off between out of the box value and product fit is the tight rope that technology solutions development must walk. Most of us have been touched by SharePoint at some point in our careers. SharePoint is half a file management application, and half a fully customizable collaborative process management platform. SharePoint is a product that can provide both out-of-the-box value through a file management application, as well as provide customized product fit through a configurable platform.

Deep diving into SharePoint, it is the proverbial rabbit hole. MERAK’s most popular blog, SharePoint: Folder vs Meta-data from 2013, debates the pros and cons of two popular file management structures within SharePoint. Modern solutions offer a mix of out of the box solutions and customization; which create two layers of maintenance. The first layer is that the user is responsible for maintaining the object placed on top of the platform, the second is the platform layer for which the user has little control. Updates to the platform can impact user-created solutions. SharePoint is a great example, as it has seen significant development over the years. Raise your hand if the removal of SharePoint designer caused issues at your organization.

City Located In Moscow

To get the most out of modern software solutions, there are some key elements to be aware of. SaaS solutions are most effective when the data and processes can operate in isolation without impacting the customer experience. If collaboration needs are high, develop solutions within a platform. Business process automation is very popular right now, and platforms will not be able to provide all the tools necessary to cleanly solve every problem. Many users will employ workarounds, which are technical debt traps if not used prudently. When building solutions within platforms, be very wary of using workarounds to replicate a feature not available within the platform. Monthly costs between business and enterprise tiers for some service offerings can be dramatic, though, the increased fees can be negligible compared to paying back technical debt for reversing a poorly engineered solution. It is worthwhile to dedicate resources to understanding the feature roadmap of the platform your organization is working with. Modern software solutions are akin to constructing an office tower on a shifting foundation; to prevent failures, know the platform’s development direction, plan development around platform feature releases, limit workarounds and be prudent when accumulating technical debt.

Digital Twins

Episode 21

A digital twin is a digital replica of a living or non-living physical entity. In our last blog, we explored the concept of business intelligence where intuition is replaced with data driven decision making. The data that drives the decision has an underlying model based on a new layer of assumptions. The generation of model requires a new set of skills and experiences that are very different from traditional business decision making practices. There is little doubt that objectively gathered data is superior to opinions, so what happens when the model is sophisticated enough to capture the entire system? Digital twins represent the pinnacle of model development within a data driven decision making system.

A Person Pointing At An Exact Copy Of Themselves

We live in two worlds: a world of atoms and a world of electrons. The world of atoms is the analog realm that can be best thought of as reality. It is the world of stuff. In the world of electrons, we create digital universes represented in strings of binary digits processed by computers. In the world of atoms if we want to perform an experiment we must gather and assemble materials and expend time to capture insights. In the realm of electrons, gathering and assembling resources is only limited by the ability to store and process information by the computers we use.

Materials and time are fixed constraints in the realm of atoms; and dynamic variables in the realm of electrons. Who wouldn’t want to copy and paste pizza if they could? The dramatic shift we see today is driven by the exponential decline in computation costs we have seen over the last 50 years in computation. The drop is so dramatic that any comparison to the physical world is nonsensical. If the realm of atoms experienced its own Moore’s law, all essential needs would be free, and the price of a cup of coffee in 1970 could cover the cost of a personal Apollo program today.

The scaling power of computation over the last half century is a challenging concept to comprehend. Digital twins are revolutionizing design practices and are helping to usher in the manufacturing 4.0 era. Traditionally business processes were locked into the physical constraints of the realm of atoms, and these business practices continue to persist to this day. Imagine if labour, material, transportation, or manufacturing requirements began falling exponentially. Business models would be shattered in short order.

The Apollo Moon Landing Site

There are two limiting factors to digital twins. The first, data informing the digital model must first originate in the physical world. Without observations of the realm of atoms, the realm of electrons has no connection back to reality. The second is that the accuracy of the simulation cannot perfectly represent the real world. Chaotic systems like weather and financial markets make long term predictions extremely challenging despite exponential improvements in computation.

Despite these limitations, the exponential decline in computation costs have enabled organizations to ask ever more complex questions of the digital models they create. Powerful software platforms enable business users to perform complex analysis on immense datasets, these workflows are no longer limited to the data professional. Computation is an exponential system, yet we operate in a far less dynamic reality of atoms, but organizations that can capture the exponential gains offered by digital systems can fast track their evolution away from their competitors.

What is Business Intelligence

Episode 20

Business intelligence is a commonly misunderstood buzzword. Intelligence is the ability to acquire and apply knowledge and skills. Applying intelligence in the context of business is all about the what, why, and how of the decision-making process. Leaders are looked upon for certainty and confidence, yet uncertainty is inescapable. Increasingly organizations are turning to data to make better decisions. However, converting data into knowledge and skills, and applying that intelligence into an improved decision-making process is no easy task.

Business intelligence is a process that commonly employs data to manage uncertainty. Traditionally, decision makers would be reliant on their intuition alone. The human mind is amazing, but it is optimized for a very different environment from our modern workplace. We are limited to our senses and our minds have limited bandwidth. Despite the limitations, we have little trouble acting on little information (at least compared to current implementations of machine learning systems), making this ability one of our core strengths. Modern organizations typically have the opposite problem, they contain too much information.

When tackling messy problems, there are numerous moments in my life when early assumptions were rendered false after some exploration. This realization can be exciting and humbling, and each time it was a lesson in the limitations of my perception. Business intelligence is commonly linked with the idea of data driven decision-making. This is a noble goal, however, where I believe organizations struggle, is that they fail to realize that this system adds a layer of complexity into the process, but does not completely remove the limitations of our intuition. Instead business intelligence systems require a different set of assumptions and will continue to rely upon our intuition. The new system augments our perception with data captured through measurements of the system, but this additional layer comes with its own set of limitations and challenges.

Powerbi

If the business intelligence system is an extra layer, what exactly is it? Most often it is a digital representation or model of a system we want to manage. Let’s say we are in the business of predicting coin flips. Heads or tails. Our intuition would say that there is an equal probability for the coin to land on either heads or tails. For each prediction we have a 50% chance of being correct. Let’s assume market forces shift, requiring an accuracy level greater than 50%. If we wanted to add a business intelligence layer to this system, we would begin by constructing a model of this system and start collecting data. With some trial and error, it would become clear that a coin flip is not random, but deterministic when enough initial conditions are known. With better knowledge of the system a better decision-making process can be implemented, however, no matter how sophisticated the model, it will never perfectly represent reality. While I do not see coin flipping prediction as a service (CFPAAS) as the next unicorn business opportunity, the process is no different when predicting sales, market prices, customer satisfaction, churn, productivity, etc. The development of such systems are part art and part science, and still reliant on our intuition to construct. The knowledge and skills required to build such models are vastly different from traditional decision-making processes that relied on intuition derived from lived experience. With increasing abstractness within a model, the new difficulty decision makers will have is mapping the model results to actionable insights.

Harnessing data within your organization to drive better decision-making should be a priority. It is important to reflect on how decisions are currently being made at your organization. Is it purely based on experience and intuition? If data is included, what weight is it given? What assumptions were made in the development of the model? Have the limitations been identified? Are the results taken for granted and; how deeply are the assumptions debated? If business intelligence processes are new to your organization, what problem would a data driven decision-making process solve? What information sources are available? What indicators, if measurable, would provide insights that would facilitate a better decision? Can the system be accurately described? Are there skills inside the organization to effectively answer these questions? How does this system integrate with the existing decision-making process? Business intelligence is another tool that can aid the decision-making process, but like any tool, its value is derived by users who understand its strengths and limitations.

Microsoft Office 365 is a gateway drug

Episode 19

Throughout this blog series we emphasized that humility is a necessity. We won’t know all the answers and we must collaboratively experiment to bring truth to unknowns. The complexity of the problems we solve today is bigger than any single individual, team, or organization. The coordination of both human and technological systems is challenging. There is a struggle between the need for standardized processes to capture economies of scale, yet we must remain flexible to allow room for innovation. All organizations have a certain amount of momentum that leaders must contend with as they guide change. Fostering curiosity and building a practice of experimentation will lead organizations along paths of setbacks and discovery. It is this process that forms the gateway toward organizational transformation. A gateway drug is a habit-forming drug that, while not itself addictive, may lead to the use of other addictive drugs. Over the last few years we have helped organizations modernize and replace legacy systems, many of which moved to Microsoft as the foundational platform for their system. In many ways Microsoft Office is a gateway drug, the very inexpensive monthly licensing model offers users access to enterprise level functionality. Most would agree that drugs are bad, mmmmkay, but what can be gained by exploring Microsoft’s platform while avoiding a bad platform addiction?

Out of the gate, Office 365 for Business provides Outlook, Word, Excel, PowerPoint, and One-Drive. With a few clicks, you have a communication tool, productivity apps, and storage. For many S&MEs these applications are likely going to cover most workflows. Additionally, these foundational applications require almost no staff onboarding as nearly all of us have had exposure through our education. For organizations that require a collaboration tool, an upgrade to Office Premium nets you not only Microsoft Teams and SharePoint but entry into Microsoft’s Power Platform suite of solutions. Microsoft Teams on its own is a powerful collaboration platform which integrates natively with every other Microsoft product, making using a third-party collaboration platform almost pointless if your organization is already an Office user. With access to the Power Platform, more technical users within your organizations have the tools to build solutions without the need of a professional developer. Power BI for data driven insights, PowerApps for internal app development, Power Automate (formally known as Microsoft Flow) for process automation, and Power Virtual Agent for chatbots to engage with both employees and customers. This steppingstone progression system is masterfully engineered to help leaders manage the momentum challenges organizations face when adopting new platforms and services. You only pay for what you use, and the platform scales with the organization’s needs. For larger or more complex problems, the Dynamics 365 platform is where we find the hard stuff. Starting with a small hit, organizations are on a pathway for Microsoft to completely take over all the organization’s technology needs. From office productivity and collaboration, to truly massive enterprise solutions all under one roof. Amazing! Right?

A Pile Of Pills Laying On A Table

It is Microsoft’s vision to help people and businesses throughout the world realize their full potential. Microsoft has a ridiculously hard job building a solution platform that, at least in theory, works for everyone. We know from the last blog that this matching problem is very difficult and is not perfect. Organizations that start with the gateway drug of Office 365 have a high probability of experiencing quick and significant wins. This is attributed to the extremely low cost of entry, rich functionality, and that the expense of staff onboarding was effectively prepaid prior to the employees entering the workforce. As organizations move up the adoption curve, the license fees begin to accumulate as well as the learning need requirements. The value potential provided by solutions within the Power Platform scales with the additional adoption risks. This is where the very real risk of adoption failure begins to increase. The Power Platform can provide organizations with amazing tools; however, it takes time and resources to learn, to experiment, and to answer unknowns with these products. The real cost to the organization is not just the incremental increase in licenses. With time and effort, wins can accumulate, and the organization can use these tools to scale their business. For enterprise solutions, the Dynamics 365 suite of products are available, but the jump in licensing costs is larger than that from Office 365 to Office Premium. For a significant increase in monthly fees, you are provided with a product that provides a significant increase in capabilities. Likewise, the increase in capacity is matched in magnitude with the increase in expected staff onboarding costs.

While the Microsoft platform is not sticky, people and their processes are. The effective potential of Microsoft’s platform is undeniable, but the value added to your organization is a function of user competency and application fit. Competitive gains can evaporate if the organization attempts to use brute force the adoption of a late stage solution like Dynamics Business Central, when the application might not be a great fit for the problem that needs solving. Additionally, if learning and onboarding time are underestimated, the application might not be used to its full potential. If processes solidify before the applications capacity is fully explored, the organization will face a hidden recurring opportunity loss. Just think of a time when you discover a “hidden” button or feature that solves a complicated problem, or removes a messy, time consuming work around. Paying large license fees while unable to derive the full benefits of the platform like Dynamics 365 is the software equivalent of the later stages of drug addiction.

To avoid a bad platform addiction there are some questions to ask. What problems are we trying to solve and how will this platform address them? Is our organization ready and does it have the capacity to learn a new platform? Does our organization have enough resources to cover the later tier licensing fees if early wins show great promise? Microsoft has built an amazing platform: the journey starts easy but can become progressively more challenging if mismanaged. Knowing what to expect will arm you with the tools to more effectively manage your organization’s transformation.

Purchasing off the shelf software

Episode 18

Modern organizations are dependent on technology solutions to enable the successful execution of the processes that deliver products and/or services to their clients. The state of technology is forever in flux and to remain technology relevant, organizations must continuously adapt the solutions they employ. Over the last decade, the software solutions targeting business productivity have exploded. It is very common to find a solution that claims to solve every problem. Yet with the space maturing, why do so many implementations of off the shelf products run into trouble? “You can’t always get what you want, you just might find, you get what you need”.

No, you can’t always get what you want

The vast majority of off the shelf products do not start as a product, but as a custom solution developed for Customer #1. These pathfinding projects typically come at a higher cost to the first customer as numerous unknowns must be answered and uncovered. Firms that provide custom development services build up domain knowledge in that area. Domain knowledge in software development is very valuable and these firms have a strong desire to find customer #2 in the same industry. When Customer #2 is found, it is extremely common that the custom solution for #1 is not exactly what #2 wants, and the solution must be refactored, features must be added, and the product grows in complexity. Fast forward to Customer #100; to meet the requirements of all these similar yet different users, the custom solution has morphed into a one size fits all off the shelf solution for the entire industry. At this point the software vendor has shifted its competencies from a custom solution builder to a specialized product provider. Now you are Customer #101; what are the dynamics to be aware of? Is this product what you want?

But if you try sometimes, well, you might find

With off the shelf software, it is impossible to know before attempting implementation if the proposed solution will be successful. Off the shelf product vendors have powerful incentives to oversell the capabilities of their solution; of course their solution is best and can do everything you want. It is in the best interest for this vendor to not probe too deeply into the client’s problem, because the risk of uncovering that the solution is a poor fit. Monetarily, it is far better for the vendor to uncover that the solution requires deep customization after the customer has committed to it. Enterprise resource planning and customer relationship management solutions are often plagued by these problems, not because the products are bad, but because there is bound to be friction when taking a completed solution into a new environment. With mature products, they are likely capable of doing everything you want, however, they are so large that any single client might only use 10% of the features available. Adopting and implementing the solution becomes a challenge due to the sheer size of the product. If the change management need is too great, the implementation will face strong internal resistance, putting the project at risk, regardless of how awesome the solution is. A “can do everything product” can be amazing, but that magic typically comes with a high configuration and adoption price.

A Person Sorting Through Vinyl Records Stored In A Box

Without acting, there is no way for an organization to discover their true needs. Many off the shelf products are browser based requiring no implementation expenditure. Today, it is possible to get access to enterprise functionality for very little upfront capital. By working with these solutions, it is entirely possible to discover that one product is not what you want, but the process allows the organization to discover what they actually need. When there is a high degree of uncertainty for what the needs are, do not make a commitment that cannot be reversed. Seek out options that give the problem in your organization a platform to become visible.

What pills are being used to keep your IT system alive? It is common for organizations to get trapped into a “keep the lights on” mentality, where most resources are devoted to putting out fires. Sometimes it is just sheer determination, but this mentality rarely looks beyond the needs of today. With off the shelf products available with a simple monthly subscription, requiring no downloads; or installation, it is very easy for IT systems to quickly fragment into a cluster of independent solutions. With dedicated IT staff focused on fire fighting, there are few resources available to ensure that there is a unified strategy linking IT systems to corporate outcomes. Frustrated staff under pressure to perform, will build their own solutions and processes to compensate. It is far too common where spreadsheets are the glue that keeps everything together. Therefore, there is a need to experiment, but under a unified strategy and vision. Getting to this state is no easy task.

You get what you need

Be wary of a product that can do everything, perform managed experiments that are allowed to fail, and focus on defining the problem. Technology for its sake, is rarely the answer. Can exceptions in your process be removed? You can’t always get what you want, you just might find, you get what you need.

Solution Design Dynamics

Episode 17

Software runs the world. As we strive to find ways to boost productivity and launch innovative solutions, there comes a time when an off the shelf product is not available to meet the need. When designing software solutions, there are elements of the process that are unpredictable. Custom solution development is like knowing there is a need for a service to provide personal transportation but not knowing if a car, bicycle, airplane, or Star Trek transporter is the best solution to deliver such service. Often in the technology industry, what we all thought was the right path turns out to be a dead end.

Red Car, Bicycle, Jet, And Transporter From Star Trek

For the purpose of this blog post, we will assume that off the shelf products do not effectively meet the needs outlined, and a custom solution is the best path forward. In a future blog post, we will expand on a previous discussion; the challenges of selecting and using off the shelf solutions.

The most common method to deal with the unknowns of solution design is to front load all the design before any development or implementation takes place. This is commonly seen in software development as the waterfall method. While easier to manage, the waterfall method engineers out flexibility in favour of a more predictable development path. However, Agile development methodologies acknowledge that it is impossible to forecast all the variables a solution requires without experiencing application in the wild. Over the course of 20 years, more development is being led by Agile principles.

Defining the solution upfront is risky, but we often see potential clients define the solution upfront in totality. At MERAK, the first question we always ask is, “what problem are you looking to solve?” The second question we always ask is, “why?” In today’s world, our IT systems are interwoven with the organization’s strategy, business processes, IT systems, and people. While asking for and building bigger, better, faster systems might provide quick wins, the process of matching needs with a solution is far more nuanced. Innovative solutions require experimentation and iteration. True discoveries require an investment and commitment to understanding the problem and matching a solution to the organization’s purpose.

Experimentation and iteration when designing a solution requires answering the obvious questions (“known unknowns”) and discovering new questions (“unknown unknowns”). A known unknown might be how long it will take to update a platform version and perform the necessary quality assurance functions on a legacy system. Unknown unknowns are the surprises that pop up requiring a refactoring of assumptions and in extreme cases pivoting the direction of the project. If we look at the example of personal transportation, early users of the Star Trek transporter discovered that on the other side of the transporter; they are actually copies of themselves. With this knowledge they are now no longer comfortable using a transporter despite it being a far superior transportation service compared to traditional alternatives. Users experiencing an existential crisis post-transportation was an unknown unknown, not foreseeable without experimentation. While painful, discovering unknown unknowns, and dealing with them early provides massive savings long-term by minimizing the “unforeseeable” technical debt in the project.

A Person Who Visibly Looks Stressed Out

Ok great, we have a great plan now. We also have a fixed budget, want it done by next week, and want all the bells and whistles. There are three dimensions to manage the design and delivery of a technology solution: budget, schedule, and scope. Waterfall methodologies are able to “de-risk” the variability of these dimensions at the cost of later technical debt.

At best we can only control for two dimensions at the expense of leaving one dimension open to float. For instance, if you have a fixed budget and schedule, it is realistic to expect that the scope of the project will need to be flexible. The greater flexibility given to this “floating” dimension the higher probability that unknown unknowns can be discovered up front.

Experimentation and iteration requires a change management process not only for the culture, but an understanding that a transformational vision is required to drive what is an incremental change process. An explorative design process can be scary, however, when using an appropriate management process, the explorative design allows the dynamic dimensions of solution design to be controlled. Just remember, a goal without a plan is a wish.