\ Management Consulting Archives - Strive Consulting, LLC. All Rights Reserved.

Getting Change Management Right

Strategic initiative failure rates remain high but working with the right partner can yield success. As such, executives put tremendous resources into planning and implementing their transformative projects.

However, seasoned executives also know that the success of those projects rests on getting users to adapt to new technologies, new processes, and new ways of working as much as – if not even more so – than any other element of the endeavor.

Unfortunately, successful change remains elusive. The failure rate for all change initiatives has been stuck around 70% for the past two decades and remains there today. 1

Consider figures from Gartner, the tech advisory firm: Its research shows that only 34% of all organizational change initiatives are a clear success, while half are out-and-out failures. 2

Those figures tell only part of the story, though. Here at Strive Consulting, we’ve found that companies without internal Change Management teams generally experience even higher failure rates. Why? Because they have neither the deep knowledge, nor the experience and tools, to enable change.

As a result, these companies often use online tutorials that offer only highlights on the topic, or they rely on overly complex white papers that don’t provide guidance on tailoring a program to the organizations’ own unique needs.

Neither option delivers information on the concrete tools and techniques needed to effectively teach people how to work in new and different ways. Rather, they tend to focus on the psychology – how the end user feels about the changes – and share some generic guiding principles, such as the ‘importance of communication’.

In reality, Change Management is a specialized skill, and it is one that needs to be expertly adapted to each initiative and tailored to every organization to ensure success. Strive’s Change Management framework acknowledges that reality and brings together four critical elements that must be addressed for an organization to successfully navigate transformation.

Those four elements are:

  • Alignment and Engagement
  • Change Impact and Analytics
  • Communication
  • Readiness and Training

Our extensive experience in helping a broad range of clients steer their companies through change has allowed us to hone in on these key areas and build a Change Management framework that leverages each of them to the maximum effect. We’ll focus on five critical tools across three elements of our framework

Let’s look at the first element: Alignment and Engagement. This element ensures that we’re collaborating with the right people in the plan and that their goals and priorities are well understood. With our ‘Story for Change’ we ask five important questions: What is happening, why now, so what, how are we going to achieve this, and now what? Asking these questions and listening to responses from project leaders gives us and, more importantly, the organization a clear, precise understanding on where it wants to be at the end of the transformation. While collaborating with these same leaders, we group and assess different stakeholder cohorts on a 2×2 grid measuring one’s level of influence on success and one’s impact imposed. The Stakeholder Assessment is the backbone to tailoring change, considering that all cohorts are coming from very different starting points and have different roles within the broader future state.

Next, we’re looking at Change Impacts and Analytics. For this, Strive evaluates how someone’s responsibilities will change and by how much. With Change Analysis we document all unique impacts and map against the stakeholder cohorts, identifying whether groups will perceive the impact as positive, negative, or neutral. This lets us understand what users will feel about the changes they’re facing and develop the various engagement, communication, and training activities needed to build understanding, knowledge, and commitment. We also develop metrics that track adoption, so we can confirm success, as well as identify those cohorts who may need additional support.

In tandem, we’re planning necessary Communications. This is all about informing key stakeholders through integrated, targeted, and timely program messaging. It’s also about understanding how communication flows within an organization. We believe there must be a communication cascade strategy within any program undergoing change for it to successfully transform. So, top-level sponsors need to effectively communicate with their direct reports, and in turn those managers need to effectively convey messages to their teams. Moreover, a communication plan compliments this cascade of information for each audience. Communication timed appropriately, focused on the right message, and delivered via the right vehicle helps all parties understand the importance of transformation for the organization as a whole.

On top of all this, we evaluate Readiness and Training. While training is hyper-focused and can be niche, we’ll focus on readiness. Quantitative metrics showing before and after results tell a clear part of the story, but it is one-sided. Qualitative surveying helps leadership understand if, and by how much, do stakeholder cohorts and users understand why the change is taking place, are aware of the impacts to their day-to-day responsibilities, know where they go for resources, and believe the change is overall positive.

Now, none of these four framework elements works in isolation. Rather, we consider them all together. In fact, we factor them into the lifecycle of a broader Change Management approach, creating a timeline from start to go-live that includes markers along the way. This means planning, for example, what milestones should be achieved counting down from 90, 60, 30, 15, 7, and 1 day out.

The payoff for having a structured Change Management workstream is significant, with This alone shows the value of having a solid Change Management strategy in place and the importance of having a partner who can deliver such results.

Looking for sample deliverables? Or maybe a bit more information? Let’s Talk!  

Here at Strive, we take pride in our Management Consulting practice, where we can assist you in your initial digital product development needs, all the way through to completion. Our subject matter experts’ team up with you to understand your core business needs, while taking a deeper dive into your company’s growth strategy.

Categories: blog, Data, Management Consulting, Thought Leadership

The Superpowers of Top Tier Project Managers

Today, it can feel like there is a Project or Program Manager (PM) around every corner. Some have little to no experience, while others are Project Management Professionals (PMP’s) who majored in Project Management and are true subject matter experts. On paper, they can look very similar, but how do you find that one person who will be able to manage implementation of your challenging ‘next big thing’, along with stakeholders, vendors, teams, and competing priorities?

That is where the project management ‘superpowers’, otherwise known as soft skills, come into play. A Project Manager with strong soft skills will have everyone pulling together as one unit in an organization, setting your team up for successful development, growth, and client delivery.

Here’s some of the skills that you should look for and why:


Project Managers with this skill know how to stay in the middle. They don’t play favorites, whether they’re in Information Technology, Project Management Office, or on the business side. Even though they don’t take sides, they should act as a translator, helping all departments understand each other and work together.


A Project Manager without organization is like a boat without a rudder. Their job is to keep everything accessible and stored, so all team members can access information quickly and efficiently. Thinking logically about file structure, communication, and people management across all levels of stakeholders and team members is paramount. An organized Project Manager makes sure nothing languishes. They keep prompts coming in a timely manner, so tasks are not forgotten or take longer than estimated.


Communication is a major skill for keeping all members of a team informed at the appropriate level. When people know what is going on, they are less likely to escalate. A good communicator will present their information in a timely manner, especially in the middle of a project where decisions may need to be made quickly. Top tier Project and Program Managers will be familiar with multiple forms of communication and will know when and where to use them.


One of the most difficult skills throughout any organization or position is transparency. When something goes wrong, it’s natural to want to hide it. A professional Project Manager will encourage team members to keep the team informed of concerns, so everyone can work together to find a satisfactory solution. If the issue impacts the larger project, stakeholders will need to be informed. Through honest communication, Project Managers can build trust between all parties involved. Trust doesn’t mean stakeholders won’t have questions or want to know details, but consistent transparency will make the conversations easier and more productive.

Conflict Resolution

As anyone who has worked on or with a team knows, there will be conflicts. It is the Project Manager’s responsibility to push for resolution. The Project Manager needs to make sure all voices are heard. For example, they won’t let one individual drive the resolution when a quiet team member may have the perfect solution but may be afraid to talk or lacks confidence in their idea. A Project Manager that keeps their head, while all others have lost theirs, is priceless and necessary.


An experienced Project Manager will anticipate where a project may run into problems and work to minimize those chances of occurrence. Skilled Project Managers can pre-empt issues by utilizing their understanding, experience, and knowledge. Identifying issues and addressing them beforehand will save hours, possibly days, of project time, not to mention your budget.


Along with anticipation, proactivity ensures schedules are kept and team members stay busy. Project Manager leaders don’t wait until someone asks them to schedule a meeting for a necessary discussion – they get it on the calendar. Making surer to look ahead and identify things that can be completed ahead of time or in parallel protects the project schedule and time management of all involved. Proactive Project Managers are always looking for ways to implement efficiency in their day to day.

These ‘superpowers’ are hard to teach skills and are often innate, but top tier Project and Program Managers will be able to use them on your next project. Experienced Project or Program managers are invaluable to any organization and should be sought out often….and you’re in luck! Not only does Strive Consulting have a host of qualified Project and Program Managers ready and willing to partner with your organization, we can also help you find your own valuable resource.


Categories: blog, Management Consulting, Thought Leadership

Collaborating as a ‘Team’ Using Microsoft Teams

In March 2020, companies were forced to swiftly adapt to a new reality. While offices emptied out seemingly overnight, an entire workforce adjusted to working remotely for the foreseeable future. Despite most organizations having a disaster recovery playbook to fall back on, many still relied on teams being co-located, usually with a skeleton crew working from an additional temporary office space. Clearly, those presumptions were challenged, as suddenly, living rooms became offices, conference rooms, lunch spots, as well as break room, all in-one, with a need to keep business going on as usual.

Understandably, remote work requires us to have the correct communication tools at our fingertips. Enter Microsoft Teams, a business communication platform that is part of the Microsoft 365 family of products. Microsoft Teams offers workspace chat and videoconferencing, file storage, and application integration utilizing the ubiquitous Microsoft Office suite of applications.

Improved Collaboration

Lack of collaboration negatively impacts the organization, making people feel disengaged and demotivated, ultimately affecting employee morale and cohesiveness across the board. Collaboration tools enable team members to seamlessly cooperate with one another, allowing users to share information and communicate all in one centralized place. Typically, a conversation with a coworker starts as an impromptu chat, whether in-person or remote via a collaboration tool. They discuss new product features, which may in turn, develop into a larger discussion utilizing a phone call or even a video call, potentially looping in broader product teams to continue strategizing.

Within Microsoft Teams, Users can work together within the same document, seeing others’ contributions in real-time, while elaborating on ideas, either via the ‘posts’ functionality or using the Teams conference channel. Additionally, Users can leverage a ‘chat’ feature to share links to external sources, or even render diagrams from embedded PowerBI reports, directly into a collaboration channel. The embedded search functionality allows for fast retrieval of documents, conversations, and guarantees that Users are only served with results for the Teams that they are Members or Owners of.

Internally at Strive Consulting

Our organization started utilizing Microsoft Teams in 2019, and the tool was adopted eagerly across Strive. Without formal governance guidelines or training in place, it became apparent that action needed to be taken to ensure long term success of this companywide collaboration tool.

Objective: Improve cross-departmental and market utilization of Microsoft Teams and facilitate increased collaboration, by providing guidance and training materials, with key outcomes being:

  • Improve usage of Teams by providing governance guidelines for using the tool, help users decide when to use Teams versus Channels, and provide guidance for the team’s lifecycle (initiation, active use, and sunsetting)
  • Migrate critical artifacts from Microsoft SharePoint to ensure those can be accessed directly in Teams
  • Provide Users with quick role-based access to searchable content across the Teams platform
  • Reduce e-mail threads leveraging Teams conversations and facilitate online collaboration within OneNote or any of the Microsoft Office 365 tools

The project started with an in-depth assessment of Strive’s entire Microsoft Teams inventory, interviewing the respective Team Owners across all departments and markets. Through analyzing content of said Teams and Channels, we quickly found that a third of our existing Teams could be eliminated, and another third could be moved into other higher-level Teams, significantly reducing the time Users spend navigating to relevant content.

MS Teams make teams work

Irrespective of the size of an organization, optimizing collaboration within and across teams will be beneficial to your company. Diverse teams, spread across continents and time zones, can collaborate on joint projects, communicate effectively, and focus on specific deliverables rather than wasting precious time reading through email chains or searching for message threads.

Embracing Microsoft Teams has helped Project, Product, Sales, and Marketing teams adjust to the new normal, allowing for seamless collaboration on various concurrent projects, whilst keeping stakeholders and leadership abreast of progress, opportunities, and pitfalls. For development-focused teams, especially those in technological advanced organizations, integration of Microsoft Teams with the Microsoft Azure platform unlocks a whole new level of collaboration, not only between the developers, but the broader project team, including project managers, testers, and end-users.

So, what’s next?

As companies continue to adapt to this new hybrid model of conducting business, a plethora of applications and tools will be utilized by both in-office and remote workers. Ultimately, the locale from where team members collaborate will be eclipsed by the efficiency and availability of the tools that allow for maximized hybrid teamwork. Unlock potential by deliberately planning and governing upfront, while continuing to add to your collaboration roadmap throughout its lifecycle. Microsoft Teams has the hallmarks allowing for successful collaboration within and across teams, ultimately allowing organizations to deliver for their clients, customers, and internal employees alike.

Is your organization working to collaborate more effectively?

Strive Consulting continues to innovate and grow through modern and ever-changing times. A shared collaboration tool like Microsoft Teams allows us to collaborate, enable trust, and deliver results to our clients and colleagues alike. Strive is here to provide guidance and assist in any way we can – drop us a note to see how we can be your partner, committed to success.

Categories: blog, Management Consulting, Thought Leadership

Messing with the Scrum Recipe

Scrum has been around since the mid-eighties, so why is it that some companies make it work so beautifully, while others end up in such chaos that they run back to old methods? Maybe the companies that flounder or fail, do so because they stray too far from the “Scrum Recipe.”

Companies prefer to put their fingerprint on their version of scrum not unsimilar to today’s health conscious substituting all kinds of things for ingredients in Grandma’s tried and true recipes. They substitute butter with apple sauce; cream cheese with cottage cheese; and sour cream with yogurt. Although the substitutions may make sense, sometimes they don’t work out and you’re left with a plate of cookies that should probably be thrown out. The same can be said for scrum substitutions.

Much like cookies that sit uneaten on the plate, in many cases too many wrong substitutions made to the scrum recipe impacts success. Let’s take a look at some substitutions that may be impacting your successful scrum environment.

IT Product Owners for Business Product Owners

Some companies think IT Product Owners and Business Product Owners are the same thing. That is not true. The whole point of the Business Product Owner is to bring customer facing insight into the development process. The two are measured by different things. The business owner is driven by growing the reach of the product in the market where IT management is measured by things like up-times, responsiveness, speed, and stability. If the product has users and a business owner in charge of strategy and direction of that product, that scrum Product Owner should not reside in technology. The equivalent of this substitution in the cooking world is tantamount to substituting a professional chef with a short-order cook. Are they familiar with food? Yes. Can a short-order cook do with food what a chef can? Not usually.

Make sure Product Owners are part of the group that sets direction for the product. In the case of multiple business product owners driving the direction of the product, a single product owner can be identified in technology to manage the multiple requests and lead the other business owners in the prioritization effort, but the direction should still be driven from a business standpoint. What does it help to have a product that is fast at doing something the users didn’t care about?

Allowing Changes During a Sprint

In the rush to get changes out the door, many companies ignore the directions in the scrum recipe that state no changes after sprint planning. For some reason they believe they can do it without repercussions when others before them have failed. This practice is equivalent to having started making chocolate chip cookies only to switch to brownies. You may not have the resources you need, the work done may have to be thrown out, and worst of all, the team has been impacted negatively.

There’s a rhythm to a sprint as well as a trust that the agreement made in planning will be kept and everyone is working in the same direction. Making changes to a sprint, especially when it becomes habitual, damages the trust and impacts the sprint rhythm never allowing the team to succeed to the best of their capability. It also means you might never get those chocolate chip cookies.

Making Scrum Teams Too Large

Scrum team size recommendations vary, with most somewhere between 7-9 team members. Some companies decide, usually based on previous team size or reporting structure, to have large teams. Initially this seems an innocent substitution but over time the issues become obvious. Stand-ups can’t be completed in 15 minutes; collaboration across the entire team is difficult; quieter team members lose their voice along with many other complications.  Seven to nine is recommended to allow the team to have enough expertise but still be nimble. This is equivalent to the age-old reference to too many cooks in the kitchen. If too many people are trying to do something, even the smallest task becomes more complicated.

Stick to the Basics First

When trying a recipe for the first time it is best to stick to the recipe. The same goes for scrum. Sticking to the recipe doesn’t mean you can’t change it in the future and make it your own, but it’s best to get the recipe right before you start making changes. With scrum, start with the scrum tenets. As your teams learn scrum and are empowered to offer improvements through channels like the retrospectives, the substitutions made will make positive impact. Before too long the scrum environment will be running smoothly and will have nuances incorporated that work for the company without impacting effectiveness.

Looking for more information? Let’s Talk!  

Here at Strive, we take pride in our Management Consulting practice, where we can assist you in you organizational Scrum, Project Management, or Agile Transformation needs. Our subject matter experts’ team up with you to understand your core business needs, while taking a deeper dive into your company’s growth strategy.

Categories: blog, Management Consulting, Thought Leadership

Do You Know the 5 Stages that can Affect Agile Team High-Performance?

As the Agile Manifesto celebrates its 20th anniversary this year, it is not lost on anyone that the popularity of the Agile methodology has grown exponentially during this tenure. That growth has now led to many companies instituting enterprise-wide Agile frameworks, such as Scrum-of-Scrums and Scaled Agile Framework (SAFe®) to continue improving Agile efforts. These efforts focus heavily on the higher-level view of Agile; however, it is still good to remember the wisdom and importance of the smaller teams and initiatives that create a solid foundation. Remember, “a chain is only as strong as its weakest link.”

Oftentimes, companies become so laser focused on making the ‘big things’ work, they forget that the small things must still be watched. The smallest unit in the Agile world is the team and if there are any issues at the team level, that becomes the weak link and could break the enterprise, or at a minimum, impair it.

Team Formation

Traditionally, teams are formed based on projects. According to the Project Management Institute (PMI) “a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal.” Projects have defined timeframes, scope and resources routine operations do not. Project teams are usually pulled together at the beginning of a project after funding is obtained and disbanded when the scope is completed. Teams look different for every project.

In 1965, Psychologist Bruce Tuckman identified the four stages teams can follow to reach high performance. He named these stages Forming, Storming, Norming, and Performing. Later, he added a fifth entitled Adjourning.

  • Forming: Members are getting to know each other, and guidelines are established. Sometimes referred to as “the honeymoon phase.”
  • Storming: Resources start establishing their voice within the team and begin to question leadership choices and previously identified guidelines. This is a very individual, self-focused stage.
  • Norming: Teams have identified ways to resolve conflict and have established agreed-upon processes and procedures. They have begun working as a team and focusing on the job at hand, rather than themselves.
  • Performing: Team members now work as a unit solving problems on their own and focusing on team goals. Issues are resolved quickly, often causing no delay in progress.
  • Adjourning: Team members are looking back retrospectively to identify better ways to have done things or are looking to the future to understand what is next for them. Minimal focus is on production at this stage.

5 Stages that can Affect Agile Team High Performance?

The Tuckman cycle repeats itself for every new team. Since projects have a beginning and an end, a team may never reach Norming, much less Performing, depending on the length of projects or number of team challenges. So, if this is the ‘weak link’ in an organization… what can be done?

Get to Performing

One of the most popular and often recommended solutions is dividing teams into Product Teams rather than Project Teams. Team member are assigned based on skills needed for a product, rather than a specific project. The team is then budgeted on an annual basis and prioritizes features and functions for the product. The team remains together for the entire year or until the product is complete. Since the teams remain together, they move through the team phases within the first few months and then reach Performing to produce features and functions at the fastest pace possible. Quality improvement will also be a result of the improved performance.

The second team set-up is still around projects, but the team remains the same. This structure is often used on large products that have multiple projects therefore needing multiple teams. Teams are formed with resources that will be needed for the product. The projects are prioritized by a central representative or committee. When a team completes a project, they are assigned the next prioritized project. Since the teams remain the same, they have the chance to reach the Performing stage. Some teams will become so high-performing they are able to complete one project in a Retrospective one afternoon, and then kick-off another project with  iteration planning the next morning.

Continuous Improvement

Companies who are striving for high-performing Agile structures should continue to look at all aspects of their operations to ensure peak performance. As organizations begin to concentrate on implementing broader Agile frameworks, they should remember Agile is about continuous improvement. Teams and other previously implemented standards and processes should always be under review.

Strive Consulting has direct experience in Agile Transformation and working with teams across industries and technology platforms to make sure organizations are operating at the highest level possible. Take a moment to read our previous publication ‘Moving from ‘Project-Based’ to ‘Product Based’ where we discuss benefits such as, quicker business outcomes, improved customer experiences, reduced organizational friction, and increased trust between impacted stakeholders.

Interested in learning more about how Strive can help teams operate at peak performance? Join Strive Consulting and our client JLL on April 29th, 2021 @ 11:00AM CST for our upcoming webinar ‘Accelerating Growth Through the Development of High-Performing Teams’. We’ll walk through the key elements needed to analyze and diagnose core organizational growth issues with tools like:
– Conducting interviews and synthesizing into themes and root causes
– Organizational design
– Process design
– RACI and Responsibility definition
– Governance and KPI measures
– Implementation best practices to roll out change

Categories: blog, Management Consulting, Thought Leadership

Preparing Your Digital Product Teams for the Hybrid Workplace

Like it or not, the hybrid workplace is likely the new normal for companies. Numerous articles have been written on the topic of people and culture management in this operating model, along with their benefits and challenges.

Most of the articles focus on the individual impacts to workers and the larger impacts to business that this shift will make.  What I’d like to focus on are the impacts I’ve seen this shift make to teams, particularly the ones responsible for delivering digital products to customers.

The challenge (and subsequent opportunity) to this dynamic revolves around the limited amount of natural human interaction that occurs to collaborate on solving problems. I call this dynamic “water coolers and delivery heroes (WC/DH)”. It’s when your delivery heroes have impromptu interactions with key team members and stakeholders to figure out a way to move forward through problems…it’s why job descriptions include language like: “must be able to work in complex environments and influence/collaborate with key stakeholders across multiple areas”… that’s code for “need people who can figure things out as a team and execute”. These interactions happen regularly and naturally when everyone is under one roof, but these blockers tend to become more problematic when handled in a hybrid model.

There are two types of problems the WC/DH dynamic typically addresses: novel and systemic.

The novel problems are the ones you want your delivery heroes working on. They are the ones they want to work on. They are the interesting, and often high-value, problems where they should focus their time. They will find a way to address these in any work environment.

It’s the systemic problems that need more attention: “It’s not the mountain to climb that exhausts you. It’s the pebble in your shoe.”

The systemic problems are the avoidable, yet all too common, shoe pebbles. You might be surprised how much time your delivery heroes spend on those, as opposed to climbing novel mountains. It’s our job as delivery leaders to improve our systems and processes to proactively remove these nagging blockers to keep our valuable resources working on valuable problems. It was important before, but it’s imperative in a hybrid model.

Here are some common systemic problems to explore:

Poor Enterprise Technology Standards, Design Patterns, and Conventions

Delivery heroes are mentors to junior and mid-level teammates. When there’s uncertainty around how to move forward with a technical solution, instead of being paralyzed with how to move forward, they turn to their respected voice of experience for guidance.

I actually often find that delivery heroes enjoy these activities, so the shoe pebble metaphor doesn’t exactly fit. But it is a hindrance to the team’s ability to performance and scale in a hybrid model when the same lessons need to be re-taught over and over.

Mitigating Strategy: Document and govern architecture, design, and solutioning standards. There should be a living repository of standards, patterns, and reference implementations. It should be the first source of information when a delivery resource is blocked. It should be the standard for code quality at scale.

Murky Story Requirements

How much times does your delivery team spend chasing down requirements or understanding an unclear backlog? I was on a project with a large financial institution where the team re-wrote features several times over before they were given clarity on the actual intent of the requirements. This would happen repeatedly causing delays in production code and delivery team frustration.

After some time, the delivery hero gained a sense of how to interpret what was being requested versus what the business stakeholders actually wanted. This resulted in a boost in efficiency until this person found a new job that did not require large time investments as a requirements interpreter.

This is a difficult ask when sharing space with the relevant stakeholders. It becomes untenable in a hybrid environment.

Mitigating Strategy: Hold your user story and backlog quality to the highest possible standards and rigor. Get feedback and constantly retro how well the requirements are understood by the delivery team. Your delivery heroes aren’t going to be as accessible as they once were.

No Buried Bodies

How many times have we heard that expression? “We can’t lose X. She knows where the bodies are buried.”It reveals a fragility to the delivery process and development environment. Often, the symptom is the reliance on someone’s institutional knowledge in order for a larger system to operate. There have been a number of times I’ve been asked to come in and evaluate a process because someone was nearing the retirement age. Not a great place for a company to be. This becomes more problematic when the physical proximity isn’t there anymore. There’s too much at risk with people who are no longer enabled because they don’t have physical access to a person who holds the key to a manual process.

This person spends way too much time “pushing buttons”. In a hybrid world, this gets even slower and backs up all of the people dependent on the pushed button to do work.

Mitigating Strategy: Automate where you can. Understand areas that are manual dependencies to driving a process and invest in automation. Rule of thumb: if it needs to be done more than twice, or is a critical dependency for others, invest in automating it.

In Conclusion

The global pandemic and resultant cultural shift in workplace dynamics to a hybrid model has introduced challenges to effective digital delivery. Relying on delivery heroes to save the day becomes less tenable without the benefit of physical proximity.

The good news is that once the crutch of these key resources has been removed, it starts to surface process issues that were likely masked by their presence. It’s painful now, but addressing these issues will improve your company’s ability to deliver quality digital products to your customer in a more scaled and dependable fashion.

Document, train, and automate your processes to enable your delivery teams and free your delivery heroes to work on high-value problems that are deserving of their focus.

But I Need Help Now!

Ok – I get it. These recommendations require investments in time, money, and effort. The improvements will be slow and costly at first. But if delivering quality digital product value to your customers is important to your business, these investments will pay off in the long-term – but here’s something you can do in the short-term: Create A Virtual Water Cooler.

I’ve seen success where key delivery heroes open up a virtual gathering place or office hours to invite other team members to ask questions of the delivery hero, anyone else in the room, or just hangout to be closer to the group. People can come and go as they please, but the idea is that it is a virtual collaboration space.

It won’t scale or be a long-term solve, but it’s not a bad intermediate best practice to keep the train rolling.

Categories: blog, Data & Analytics, Digital, Management Consulting, Technology Enablement, Thought Leadership

Are Your Project Managers Prepared for the Cloud?

The previous year has brought about new changes to many work environments, while accelerating other planned changes such as Cloud deployments. According to the July 2020 Forbes article “Why Enterprises Are Accelerating Cloud Adoption: The swift move to working remotely has meant a spike in the number of companies moving to the Cloud.”, companies like Microsoft and AWS have shown significant increases in their Cloud products in recent months. Consequently, more and more projects will be green-lighted to move systems to the Cloud, which increases the need for Project Managers who understand the unique challenges such projects require. Organizations need to ask themselves…are your Project Managers prepared?

Vendor Management Experience

Cloud projects are inherently different than onsite projects that use local and internal resources. Organizations are now managing systems through remote, third parties, so strong vendor management skills are a must for Project Managers. Instead of resources that are dedicated to the company, Cloud resources serve another master. Project Managers need to ensure the Cloud vendor understands the company’s needs and priorities. Stakeholder desired timelines should be reviewed with the vendor to identify any concerns with any challenges addressed early in the project.

Additionally, the Project Manager needs to identify any processes or restrictions varying vendors may have, such as lead time for equipment delivery or holiday freezes. The Cloud vendor standards will drive most of the processes and need to be clearly understood. For example, if a vendor only does quarterly releases for all clients, then a planned delivery date outside of these standards cannot happen. Flexibility for delivery dates will be more limited in the Cloud, so all parties need to understand expectations.

Deeper Software Understanding

Companies have been installing software onsite for years and have become accustomed to making software adjustments to fit very specific needs. When companies select shared Cloud environments to assist with budget restrictions, this flexibility can be greatly reduced. A Project Manager should ensure restrictions are clearly understood or delivery can be disappointing.

A good example is how sign-on’s are managed. Can single sign-on (SSO) be used? If possible, what exactly does that mean? If a software can maintain data from multiple customers of a company, does a corporate resource have to have multiple logins to access each different customer data set or can they access all via single log-in? If able to access via a single login, does that mean customers could potentially see each other?

Do not assume the answers to the questions. In a previous project, this exact scenario occurred. The Cloud vendor said SSO was possible. Internal resources managed many different clients. When the situation was drilled into, clients were able to see each other via a pop-up menu. The onsite version of the software had the capability to block this view, but the Cloud version did not because a software change would impact all clients of the vendor. The only way to prevent the viewing was for each client to be in another “Cloud instance” that further required a separate login for each client. That meant the internal resource needed a different log-in for each supported client. Does that sound like traditional SSO? No, but from the vendor’s side, it was possible as a pass-off from the company to the vendor, but using the SSO, would have created an insurmountable issue.

Gap Analysis Skills

Many companies choose Cloud offerings to allow for focus on core capabilities. Moving hosting and release management to a vendor can provide significant cost benefits. This often means that companies decide to transition on-site versions of software to the Cloud. The challenge is, even when the software is moving to the Cloud version of itself, there is often a gap. These versions differ for various reasons. One of the most common is they are constructed separately. One version is created for flexibility onsite and based on a single company’s requirements. The other is developed to work with multiple companies in a shared infrastructure. Although the product is the same brand, the software codes are developed separately. These differences are usually discussed at a high-level during sales meetings, but when the project kicks-off, the Project Manager and team need to understand differences at a detailed level. Understanding differences in menus or terminology, as well as infrastructure and outputs.

A good example is how is data handled? When moving programs to the Cloud there is almost always data that must be moved for historic reasons. A Project Manager should not assume it is a one-to-one transfer. It is not unusual for two programs to be developed in totally different teams who may never talk to each other. Knowing that data mapping is critical to the success of any Cloud product, some vendors will provide processes for easy transfer if the data infrastructure is different, but others will place that work on the client. Clarification on these types of organizational pitfalls is crucial before kick-off or before schedule baselining.

The skills above are a good start to identifying stronger Project Management skills needed for Cloud environment projects. Overall, when running Cloud projects, Project Managers need to increase diligence in several areas to ensure quality performance as more and more projects will involve Cloud implementations. Strive prides themselves on not only excellent project management experience, but first-hand knowledge when it comes to Cloud adoption and enablement. With our successful and extensive channel partner relationships, with companies like Microsoft and Snowflake, and our robust in-house Management Consulting and Technology Enablement practice areas, our subject matter experts make navigating the Cloud easier and more efficient.

Categories: blog, Digital, Management Consulting, Technology Enablement, Thought Leadership

Continuous Integration and Continuous Delivery (CI/CD): Delivering High Quality Software to Your Customers Quickly

Prior to COVID, consumers had already been relentlessly engaging with brands through digital platforms, products, and services. The abrupt change that came as a result of early lockdowns, and then continued (physical) social distancing during the past nine months, have dramatically accelerated the shift to interacting with friends, colleagues, and brands through digital interfaces. This, along with the continuing evolution of customer expectations has made it even more imperative to deliver new experiences and products even more quickly while maintaining both high quality interactions and software in general. It is crucial for companies to develop software at a rapid pace that can immediately run effectively and generate value to adhere to market demands.

Companies of all industries varying from retail to financial services have incorporated software as a means of interacting with their clients or customers through digital products and services. Whether an organization has a website, mobile application, or full-blown digital products, it is vital for the company to provide their consumers with a compelling user experience that ultimately adds value to both the consumer and the company.  With the market demands today, developers need to be capable of building software quickly to both introduce and test new products and enhance existing products, services, and applications. DevOps paved the way for these capabilities by allowing for infrastructure and operations to be delivered as code as opposed to hardware, thus significantly shortening the lifecycle from idea to consumable product. However, while DevOps is foundational, it alone doesn’t allow for the speed to market necessitated by today’s landscape – this is where CI/CD comes into play.

Continuous Integration and Continuous Delivery (CI/CD) is a practice that makes it possible for companies to drastically improve their software development lifecycle to meet the demands of consumers. A CI/CD pipeline builds upon agile framework and DevOps concepts, where organizations can automate many steps within the software development process to more quickly build, test, and deploy new code to customers. CI and CD are both development approaches that are usually executed in sequence – however, these practices have differentiating purposes.

Continuous Integration

Continuous Integration (CI) is the practice of development teams combining their code and submitting it into a repository; this usually occurs multiple times a day. In this process, developers run automated tests to detect any issues immediately upon each potential code change. Conducting tests at this point prior to integration of code allows for early detection and resolution of bugs and programmatically not allowing that code into higher risk environments without the bug being resolved – ultimately, saving the company time and money by identifying and resolving conflicts before any further developments are made to the software.

Continuous Delivery

Continuous Delivery is a continuation of CI that extends the automation process to more effectively deploy software. With the CD approach, product and development teams have the ability to more quickly adjust software as user feedback is generated or as the business strategy evolves. Various functions across an organization including product, development, support, testing, and operations collaborate throughout the software development lifecycle to make improvements to the end-product. The collaboration between these individuals allows for more consistency in updates to a product that are not only operational but also effective. This practice allows for organizations to rapidly release any changes and updates to their software on a frequent basis.

Benefits of Implementing Successful Continuous Integration and Continuous Delivery 

CI/CD offers a number of benefits to organizations if it is implemented successfully. First and foremost, companies have the ability to release software at an accelerated rate leading to faster delivery to consumers.  This allows for quicker feedback loops to better understand what changes are adding value to both customers and the organization so Product Managers can better understand what to prioritize next.  While the deployment process is shortened, the chance of bugs is also reduced, due to the frequent testing during CI. The transparency of CI/CD gives teams visibility into which part of the software has issues further encouraging collaboration among colleagues to improve. Ultimately, the benefits provided by CI/CD pipelines lead to better end-products for organizations and more value for end-users. However, it’s crucial for organizations to avoid pitfalls in leveraging CI/CD to realize the potential value it can create; below we dive deeper into guidelines to follow throughout the CI/CD pipeline process.

Guidelines to follow in successfully leveraging Continuous Integration and Continuous Delivery Pipelines:

Focus on Small Changes

In the past, developers had been accustomed to creating code for weeks on end and conducting testing afterwards. Moving to agile frameworks began the transition to smaller, incremental changes. While practicing CI, it’s crucial that developers submit smaller amounts of code and run automated tests to pinpoint any issues within the software development process. By running tests on smaller pieces of code, teams minimize any arising issues by detecting problems immediately more quickly determining root cause.

Peer Review upon checking in Code

Code reviews are a necessary part of CI/CD. By leveraging others to evaluate the code being introduced, organizations can stop bugs before they happen. This also enables better consistency in how code is written, commented on, and unit tested to allow for better maintainability over the long term.  Developers can also learn from others through this process. Once code is reviewed and approved, a new build can be created, and tests can be run immediately.

Unit Testing

It is best practice for organizations to partake in unit testing. Conducting unit testing is the first line of defense to curtail the introduction of escaped defects into a production environment by having developers add code to test each function that they build. This tests that the specific intended function is working correctly and can be augmented by additional tests that can provide a broader perspective on the quality of the software.

Variety of Automated Tests

Automated testing is a crucial component within CI/CD pipeline; to properly test software it’s important for an organization to have an array of tests to ensure the solution is operational from an end user’s perspective. These include integration tests, functional tests, UI tests, etc.  Running a variety of these tests provides clear insights into any defects in the code, but it is important to determine what tests need to be automated to get the most return.  Although some organizations automate all testing, a mix of automated testing for the most critical use cases with additional manual testing on lower priority areas of software can suffice.

CI/CD Delivery Pipeline

Continuous Delivery (CD) should only be executed once Continuous Integration (CI) has been hardened and confidence in the processes have been built. While CI allows for code changes to be introduced to test environments more quickly, in order to realize the added value that these changes provide, those changes must also be deployed quickly to customers. However, without first building confidence in the CI aspect of the process, organizations can run the risk of introducing changes to customers that haven’t been properly vetted, thus adding escaped defects and risking a quality customer experience. Once confidence is built in the quality of code being produced through CI, organizations can begin shift to CD in an incremental fashion.

Team up with Strive to begin your CI/CD Journey!

Here at Strive, we take pride in our 3 main practice areas, Management Consulting, Technology Enablement, and Data & Analytics. Within these areas, we can help you discover and navigate if the CI/CD practice is right for your organization. Our subject matter experts’ team up with you to understand your core business needs, while taking a deeper dive into your company’s growth strategy.

Categories: blog, Data & Analytics, Management Consulting, Technology Enablement, Thought Leadership

Moving from ‘Project-based’ to ‘Product-based’

“We’re spending a lot of time, money, and resources in these meetings” … “I don’t feel like this project is going anywhere” … “I can’t even remember why we’re doing this” … Have you ever asked yourself this question while on your 7th conference call of the day? We see companies invest in making the transformation to the interactive approach to project management and software development, Agile, but to no surprise still have the same angst as they did in their previous way of delivering solutions.

According to a recent Gartner study, 55% of organizations say they are moving from traditional project delivery to product-centric 1. Why are companies choosing to make this shift? By moving to a product-centric delivery model, companies are realizing quicker business outcomes, improved customer experiences, reduced organizational friction, and increased trust between impacted stakeholders.

In short: companies are delivering products that their customers love, all while being more efficient, more collaborative, and realizing short and long-term value along the way. The good news is that most companies already have the people and tools in place, and with a few adjustments to their operating models, can steer the ship toward a product-centric delivery model. To help identify where your company is on the spectrum between project- and product-, we will walk through the common challenges and pain points of a traditional project-focused delivery model, describe the benefits and ROI that can be achieved from shifting to a product-centric delivery model, and provide a foundational framework for how to begin this organizational shift.

Pain points of a ‘Project-based’ Operating Model 

One of the most prevalent pitfalls of the traditional operating model is the disjointed application of both Waterfall and Agile delivery methodologies. The result of this half-measured application and its subsequent pain points is a lack of collaboration across business and IT, and the perception of technology projects being too expensive or taking too long.

The graphic below describes these pain points, and how they can serve as a barrier to an efficient operating model.

Moving from a 'Project-based' to 'Product-based' Model

Benefits of a ‘Product-based’ Operating Model

By introducing a product-centric means of operating, companies can achieve a more collaborative culture, accelerate through ideas, and unlock speed-to-value by solving underlying organizational challenges and driving toward business results, faster.

The graphic below describes the benefits of an efficient, product-centric operating model:

Moving from a 'Project-based' to 'Product-based' Model

Accelerate ROI

There is an unspoken assumption that the development of products and features will result in added value to both your company and your customers. As such, companies seek to adopt Agile practices in order to build products and features faster, but this only adds more holes to a sinking ship; holes that are traced by committed product teams and punched by the sunk-cost fallacy attached to a feature that customers will not end up using.

The reality is that without proper end-user validation, product ideas and features are often hit-or-miss, and will not provide the ROI-driving dollars that many hope for when building a product roadmap. While there is incremental value in adopting an Agile methodology only, pairing Agile with a Product-Centric framework will increase overall ROI and decrease the time it takes to get there

Moving from a 'Project-based' to 'Product-based' Model

‘Product-based’ Framework

There are four fundamental areas that should be focused on when evaluating how to bring a Product-Centric operating model to your company. These areas are explained below:

Moving from a 'Project-based' to 'Product-based' Model

The foundation of these four components provides a different approach for how an idea drives shared value across a company and its customers. By focusing on building a strong foundation based on these components, companies can begin to introduce a new approach to delivering products to customers, shortening the time-to-market and time-to-value.

Looking for more information? Let’s Talk!  

Here at Strive, we take pride in our Management Consulting practice, where we can assist you in your initial digital product development needs, all the way through to completion. Our subject matter experts’ team up with you to understand your core business needs, while taking a deeper dive into your company’s growth strategy.

Categories: blog, Management Consulting, Thought Leadership