It doesn’t matter what type of software project you’re working on, whether ERP, CRM, PLM, E-Commerce, or Business Process Automation (i.e. RPA/IPA) if you haven’t figured out the “People Dynamic” part to the equation- get ready for a roller-coaster ride.
Let’s address some project-related risks and project risk mitigation best practices. As we are seeing the COVID-19 pandemic unfold, it’s a solid reminder to always be prepared for anything.
In this piece, we want to focus on the People Dynamic, but we’re by no means dismissing other project-related risks such as:
- Financial health for project funding
- Client business risks (i.e. marketplace, cybersecurity, political, social, regulatory and more)
- Product selection
- Software vendor stability
- Technology integration / infrastructure / mobile challenges
- Quality of data
The People Dynamic is a force to be reckoned with and depending on your view, can trump other project risks. Withum’s Management Consulting Advisory team sees this every day with their software implementation projects.
We’re fortunate that most of our clients acknowledge the importance to support a User Adoption Program (aka Change Management) which focuses on the People Dynamic. The point we want to emphasize, and share is when to backfill for the project team who have their everyday job to do and are being asked to take on more responsibility.
We encourage all our clients to approach software implementation in a collaborative shared resource model versus a “turn-key” solution, where the software integrator performs all the heavy lifting and then trains people. In our opinion, too much value is lost with hands-on learning before going live into production. We measure self-sufficiency and sustainability readiness as a project success metric as we want our clients NOT to spend more dollars with us afterwards for life support measures.
Hopefully at this point I have your attention. Let’s dive in.
Planning the Implementation
It starts with planning the implementation. A detailed work plan down to an actionable task level is necessary. By the way, we favor a very easy to use Cloud Software tool that fosters straight forward collaboration with our clients.
The actionable task needs work effort driver assumptions. The assumptions should factor in variables such as complexity, iterations, preparation, documentation and other time dimension contributors. Clearly every task will have a resource or resources assigned and estimated hours.
Producing a Resource Load Plan
Now we can produce a resource load plan to see what we are asking of the project team members. Once you factor in the day job, it is quite clear to point out periods of time where expectations are unrealistic. We agree it is an estimate and need to consider the work effort drivers along with a resource’s capability to perform the task. It is not untypical to work with people who have very little if any experience implementing software.
User Adoption Team Analysis
In comes the User Adoption team to help analyze what is needed, assess and define a remediation plan to tackle the capability risk. There are many examples to share for remediation, but it ultimately comes back to people, time and possibly more dollars.
Implementing software is not entirely an exact science and requires some art which we call “experience”, “been there done that” and have “the scars to show for it” to infuse into the planning stage. We have discussions with project sponsor(s) to address all project risks but spend more time on the People Dynamic. We see heads shake up and down, acknowledgment and positive feedback about their people.
We completely understand software projects are costly but can very quickly become intensely more expensive and possibly impact workplace culture where people leave and share their experience socially. Our recommendation here is to grab the bull by the horns from the start and conclude where part-time and/or full-time resources might be necessary to backfill everyday operations and/or possibly hire to acquire talent with the skills necessary. Be ready to act fast as today’s labor market is highly competitive and available talent could take time that you probably don’t have.
Another recommendation we have when there is not total buy-in or doubt with your software implementation advisor is to review the work effort drivers and adjust collaboratively. Now you are in the know which makes for a better future discussion when/if the backfill risk surfaces.
Backfill doesn’t suggest handing over the reins completely for everyday operations. It is intended for relief with expectations that work is being accomplished both with the project and everyday operations. We have seen some abuses around this with our clients so, measure effectiveness.
Unfortunately, we have seen clients expect too much from their people. Picture a crowd with torches and pitchforks at the gate. Not good. Backfill investment fuels more time for your software advisors to enable the people you are relying upon to support the system and drive the expected ROI. At some clients, the backfill resources ultimately were hired full-time. At Withum we believe Talent Wins the Day!
If by chance you favor a turn-key approach where the consultants perform the heavy lift then teach your people, you still must exercise due care. Withum has rescued projects with this approach and in the most extreme case, had to restart the entire project as knowledge transfer did not occur or occurred ineffectively, with little to no documentation.
At Withum we have many beliefs that cause us to be our Client’s Catalyst for Growth and Success. When it comes to implementing software and the support thereafter, there is a Chinese Proverb that we can relate to:
Give a Man a Fish, and You Feed Him for a Day. Teach a Man to Fish, and You Feed Him for a Lifetime.
In case you are thinking more broadly about project risk, perhaps the following content can help:
We encourage that all projects incorporate an overall contingency to match your detail risk management plan which should include details around remediation in case the risk becomes a real issue.
The contingency becomes a percentage of overall fees. So, what percentage should you use? Here again, not an exact science, but experience tells us to assign a complexity category (i.e. Low, Medium or High) to the project.
For example, if we are implementing finance only, no expected customizations, data quality is good and reliable and integrations are with known third-party vendors- you should be okay with 8 to 10%. An example at the other end of the spectrum, High, would be associated with changing out finance, supply chain, logistics, e-commerce, Point of Sale, Human Resources for U.S. and other international countries, some customizations are expected, data quality is suspect, integrations have many handoffs, working with many third parties- you could be okay with 20 to 25%.
Whether you are just planning or are getting ready to start a software project, we strongly recommend dissecting the necessary hours for everyday work. Don’t forget to include other competing projects if applicable, then work with your software integrator to review a detailed task/resource load forecast. Something we also uncovered during this type of work with clients are not outwardly obvious inefficiencies and challenges that ended up being detrimental to other projects. We were able to find these by deploying our 2-Day Diagnostic. Learn more about the diagnostic here.
Here is to successful software implementation!
Business and Management Consulting