1. Build a Business Case (A Real One…You Know, With Numbers)
2. Choose a Partner You Can Trust
3. Recognize the Symptoms (of Scope Creep)
4. Give a Little, Get a Lot (of Adoption)
5. Deciding to Go Custom or Off-the-Shelf
Software development is a lot like human evolution — there’s no end to the madness. There will never be a grand finale or moment of total IT actualization. The IT ecosystem is a rolling stone we’re all chasing, in a desperate attempt to remain relevant to our target markets and out fear of becoming antiquated.
Sometimes, mid-sprint we see the shiny, new tech in front of us and impulsively declare, “the future of my business depends on this!” It’s in these pockets of spontaneity that sustainability is lost and a long, half-baked road-map takes its first breath.
I’m here to remind you that half-baked road-maps rarely lead to long-term success, and that more software isn’t always better. In other words, participation is not enough — intent is really what matters here.
Nail down the programming. Prepare best-in-class code for deployment. Without a detailed plan for implementation, you’re committing IT malpractice, prescribing a solution without defining the problem and articulating end goals.
There’s a lot of pressure of businesses to remain agile and the number of software vendors reflect this demand. Right now, IT hardware and software represent a $1 trillion industry. If we reject digital transformation, we’re rejecting sustainability. IT investments yield greater efficiency, and it’s no secret that efficiency supercharges monetization.
On the same train of thought, participation does not equal sustainability if the participation lacks direction. Adoption equals sustainability. We drive adoption with a detailed software implementation plan. Here’s five steps to follow:
1) Build a Business Case (A Real One…You Know, With Numbers)
When we were young, we made impulsive decisions, knee-jerk reactions based on what our friends were doing or whatever would satisfy our need for immediate gratification. We did this even when our parents advise us not to. Here’s the reality you need to face: no business is above some basic cost-benefit analysis
Find the voice of reason whispering in the back of your mind, before you move forward with any project. All successful software implementation projects are the product of strategic planning and idea-mapping — all of them.
Every business model has an Achilles’s heel. Smaller businesses have the ability to pivot quickly, but they have the most to lose when a project goes South. The bigger corporations on the scale are subject to a long, drawn-out implementation because they have to bring together a million moving parts to move forward.
If we think of larger corporations as a machine, inevitably some of the gears will rust over, breakdowns will occur, and the network will need to be oiled. This is exactly how software implementation goes for bigger companies.
Smaller businesses flip a switch and the lights go on, those on the other end of the scale have to reinstall the light bulb and fixture every time they need to see.
Chetu recently worked with Imprint Group, an event management company with a few different locations in the US, medium-sized, who was looking to engineer a custom CRM. They were dishing out an absurd amount for Salesforce, despite the lack of relevant features and limited toolbox.
They recognized the deficit. They calculated how much the system would cost to custom-build. They listed their must-haves (customer segmentation modules, a fluid calendar, pipeline tacking, a responsive UX). They illustrated their value proposition — the who, what, where, when, and why — before making the final call. Imprint Group had boiled their project down to the bare bones and analyzed whether the bones were dense enough to support their business model.
Your intended users are the most important ingredient of your business proposition. Reach out to whoever will be integrating the software into their day-to-day and ask for their input. Zoom in on the reoccurring pain points, and build your business case around those arduous tasks.
Don’t let yourself regress to adolescent impulsivity. Like all decisions during adulthood, you want to form an unbreakable cost-benefit postulate. Nail down the answers starts with asking yourself the right questions: how do you stand to benefit and how do you stand to lose? Do loss and gain equalize, or is the result skewed in one direction?
Obviously, here we’re looking for return on investment (ROI), an old friend (or enemy) we’re forever indebted to. The simple version? We want the good to greatly outweigh the bad, and we want the returns to exile the investment into oblivion. Desperation clouds our judgment here, those times we make a last-ditch effort to evolve our IT systems or remain technologically trendy.
Yes, we’re amidst an era of digital metamorphosis, where software modernization is a survival tactic and an inevitability for companies with any intention of creating a sustainable path for themselves. However, we need to forget about being trendy and develop a resilience to peer pressure. Just because everyone you know is developing a mobile application using Xamarin’s cross-platform development framework, does not mean it will yield an ROI in the context of your business.
ROI is a shapeshifter. Sometimes, returns translate into traditional monetization and investments take more indirect forms. The context dictates the formula. The moral of the story is to let ROI calculations be a forethought, rather than an afterthought.
Preemptively define your intentions to avoid surprises. If you’re looking at returns in terms of a dollar amount, round down estimations to accommodate unexpected investments along the journey. If the returns are operational, map the anatomy — how workflows will improve, how the software will cohabit with your existing ecosystem, how you will educate your end-users and how long the adoption period will be.
Cost of investment equates to time and resources, expenditure and project timeline. Unfortunately, the stakes are high for IT projects and when they fail, the losses are irrevocable.
Gartner estimates that this year, companies will invest a cumulative $201 billion on enterprise-level software applications alone. We have to wonder what percentage of those projects will fail due to ROI fallacies.
FloQast has a free SaaS ROI calculator on their website that’s free to download. You can use this to give you a quick baseline.
2) Choose a Partner You Can Trust
The trickiest (and most important) part of any software project. We live in a world where most things are not as they seem, and this certainly rings true for most back-end development partners.
When you’re asked, tell me about yourself, during a job interview, do you ever tell the employer about that time you missed a deadline or skipped out on work for the day to go skiing? No, you show them the highlight reel.
Vendors do the same thing. They replay their best moments and let those moments shape your perception of them. We interview clients for our case studies. It’s a way for us to ignite a more holistic discussion and give dimension to an engagement that is inherently more complex than our own perspective. It’s also a way for us to collect feedback on ourselves.
Do the same when you’re vetting software implementation partners. Ask questions, ask for referrals, anything that will excavate your relationship down to granular levels. By defining the parameters and expectations immediately, you are decreasing your margin for failure significantly.
Software vendors and engineers thing very practically. They align the final code with the requirements you dictated. In other words, if you ask for A, B, and C, done in the order of B, A, C, this is exactly what you will receive when your account rolls off and the final source code is released. If you’re not quite sure how you want A to operate, you’ll most likely wind up providing vague explanations representative of a half-baked vision.
A half-baked vision is an internal issue, not operational deficiency on the vendor-side. You can mitigate ambiguity by conducting ideation sessions, interviewing your intended users, and analyzing historical data depicting the inefficiencies you’re looking to alleviate. As your parameters come include incidentals, the gap between vision and execution narrows. The best software is the mirror image of the vision, rather than a distant relative.
There is a duality here: having the parameters squared away and partnering with an engineer who is willing to work within the parameters. Just as there are two sides to every coin, there’s the development and the implementation. Once you dissect your project and label the organelles, you need to locate someone capable of suturing the project back to its natural, usable form.
Scale your partnership to your internal deficits — meaning, where there is a hole in your bandwidth, patch it with development support. Businesses with minimal development resources in-house should explore full-service options (programming, integration, implementation), and vet candidates like they would during an interview.
Hold yourself accountable for a vivid and solidified vision. The partner is accountable for translating that vision into a tangible deliverable. Software implementation cannot succeed without a detailed blueprint.
Build a project board of your most trusted advisers. Essential personnel only. They’ll serve as voice of reason, a filtrate for lofty, idealized plans. You deliver the block of clay, and they throw it to the wheel, sculpting your vision into a carafe you will fire and all drink from. Keep this group close-knit, and be forewarned that bringing too many cooks to the kitchen will dilute your vision.
Finalize your business proposition. Calculate ROI by factoring in all the dimensions. Know exactly which streams will carry you returns in and which ones will carry your investments out.
Get down to the nitty gritty. If you can’t articulate your vision, it’s not ready for execution, and you should return to the drawing board.
We’re probably a little biased, but full-service development seems like the obvious choice in comparison to come of the more focused solutions providers. Find a partner that allows you to set the agenda, define the parameters, and scale your resources to the scope of your project. Analyze their partnerships. Who are they collaborating with in the digital landscape? Are they relevant to you?
Locating a partner in crime, one willing to occupy your perspective and do the leg work, will free up internal bandwidth that you can allocate to more pressing objectives. Check out their portfolio and see where their experience and your vision overlap. If you can’t find overlap, they’re not the right fit.
3) Recognize the Symptoms (of Scope Creep)
There’s a malicious force lurking in the background of every software implementation project an inconspicuous, money-hungry monster waiting to rob you blind. Its name? Scope Creep.
We battle Scope Creep using a magic potion called incremental development.
We’re going to let you in on a little secret: no project yields a perfect software product the first go-around. Software development is feedback-driven, meaning we isolate system deficiencies through use-testing and make adjustments incrementally. It’s better to see software as a dynamic entity, rather than a one-and-done scenario.
All companies improve incrementally. Remember the parameters we discussed as we were building a business case? Well, these parameters change over time and inevitably we forgot to cross the t’s and dot the I’s somewhere.
Often, decision makers become obsessed with perfection, losing sight of the big picture. Fixating on the minute details causes a financial butterfly effect, where the project snowballs. Deadlines come and go without a deliverable to bring to market, kickoff is moved to a later date, and the initial investment triples. This is scope creep.
In Step 2, we discussed the nitty gritty. What we meant was getting proactively granular, rather than retroactively. When we get retroactively granular, we find ourselves asking our development team, well what about this? Did we consider this? Why don’t we add this? These conversations are a symptom of scope creep. It’s a slippery slope, and as soon as you start justifying adjustments to the original project plan, uncontrolled project growth is not far over the horizon.
Here are the causes:
· Too many cooks in the kitchen
· Poorly executed design document
· Impossible timeline
· Miscalculated cost projections
· Project kickoff without doing the proper research
· Communication barriers with your development team
· Cutting corner in some development areas
· Incomplete vision or initial idea
Here are the symptoms:
· Deadlines passing without meeting goals
· Straying significantly from the original plan
· Running out of money
· No end-goal in sight
· Cost-benefit analysis becoming a secondary concern
· ROI doesn’t seem achievable
· Unable to articulate the intended user
· Resources beyond your primary board have a say
· Amendments to functionalities
If recognized yourself in any of these symptoms, you may be the victim of scope creep. They good news is, you can always put the brakes on, backtrack, and rediscover your original mission. If you don’t know how to get back where you came, start by analyzing the preliminary plans and revisiting your business case. This should give you some clarity.
Avoiding scope creep is easy once you admit to yourself that you won’t be able to release a perfect code. Recognize you are part of an evolution and end-user feedback is the natural progression after implementation.
We adopt. We analyze. We amend. Keep your core features close to you. You software is a new pair of shoes, it’s bound to give your end-users a few blisters. The sole will mold to your footprint if you let it.
4) Give a Little, Get a Lot (of Adoption)
Just like everything in life, we’ve got to give a little to get a little. Only in this scenario, we give a little, we get a lot. The software life-cycle embodies that ancient adage, if a tree falls in the woods, but no one is there to hear it does it make a sound? We can nail down the back-end development, steer clear of scope creep, and keep investments low, but if your intended users never take the bait, was the project really a success?
Most would answer with a resounding, no. Your project is only as powerful as your rate of adoption. Find something to offer your target market in exchange for their participation.
Newsflash: human being are change averse. They become comfortable in their ways and resist the integration of new tools, new interactions, and new processes into their every day.
Regardless if your user-base is external (part of your monetization model) or internal (part of your workforce), make adoption your priority. Under-utilization bogs down ROI and drives investors to examine their portfolio going into their next engagement. The way you engage your end-users depends on who they are.
For internal staff, it can really be anything. If you want to take the positive route, you can incentivize adoption with kudos, earned PTO, certifications, or company merchandise. If you want to take the disciplinary course, incorporate adoption into the review cycle.
When you’re monetizing the solution, it’s much easier to incentivize as long as you master product placements, getting your deliverable accessible to the right audience. This model uses consumer needs as a crutch and adoption meets little resistance.
Internal workforces are an unrelenting adversary. You could craft a bleeding-edge solution, propagate the most innovative technology of our time. Innovation is not enough to drive internal adoption — a smart home without any inhabitants. Subpar user experience and lack of training modules tends inhibit inhabitance.
Poor UX can lower productivity, debilitating workflow and making it impossible to navigate the platform efficiently. In this case, end-users use more time navigating the system than they do leveraging the added functionalities.
We conquer employee training and deployment bottlenecks by investing in a much-needed (and often overlooked) IT support team. This team is responsible for training users and holding them accountable for underutilization.
Incremental development requires continued education. There’s a Jekyll and Hyde component to this. On one hands, it elongates the process, on the other hand, you’re breaking up training modules over a long period of time which breeds greater retention (less questions in the long run).
Be careful with who you are targeting. In other words, make sure the solution is relevant to your intended users. Analyze your demographics — if 70% of your staff exhibits mid-level data analysis skills and only 30% are highly skilled at the same, it makes sense to tailor your solution to the skillset of your majority. This way all users will be capable of learning, and the 30% will be able to assist the 70% during the adoption period. Designing around the 30% is a recipe for disaster.
5) Deciding to Go Custom or Off-the-Shelf
The decision depends on your internal resource pool. It’s simple; you have the resources to support your project or you do not. In reality, even off-the-shelf solutions require custom implementations. As the adoption wave crashes and user-feedback funnels in, you will need a development team alongside you to analyze the results and make adjustments accordingly.
Implementation is a disorienting part of the project lifecycle and it demands support. Oddly, post-implementation support is not a mainstream choice, even though it probably should be, especially for noncommercial projects.
When you’re engineering codebase to deploy internally ROI becomes more abstract, and there greater opportunity for loss. Commercialized solutions see direct ROI — more sales, greater returns — and it’s easier to determine whether the implementation was a success.
How hands off do you want to be? Custom development allows you to be as involved as you want to be. Off-the-shelf demands intimate involvement with the implementation and deep understanding of the underlying architecture. An outside perspective also brings a refreshing objectivity, objectivity you can use to immunize yourself to scope creep.
There’s also the burden of accountability. Outsourced implementation comes with total accountability from the testing to feedback stage.
Regardless which direction you’re pulled in, document everything. We put this in bold because there is nothing worse than losing your own source code or a buggy update you can’t rollback from. Keep your code in a repository for later access. When you’re developing incrementally you never know when you might need to regress to the OG code.
There’s a lot freedom that comes with bespoke. Imprint Group, Chetu’s client who engineered a custom CRM, was about to attack ROI from all angles. First, they deployed the CRM across their network, mitigating a very serious internal problem, and then they packaged the solution and sold it commercially to other businesses within the event management landscape encountering a similar set of pain points.
Sure, software kits like Salesforce and Oracle offer their users maturity, but they lack flexibility. There are limits to the customization where vendors draw a line in the sand and say, thou shall not pass. If you need to pass those lines, maybe off-the-shelf is not the right option. Take the path of least resistance.
Let’s recap what we know. We know dormancy is the antithesis of evolution, and we know the digital revolution moves frenetically, morphing from one form to the next. We know IT implementation projects must be ongoing, and we know these projects must be resilient in the face of incremental adjustments. What do we know? We know dormancy is the fast-track to software implementation catastrophe.
A 5-Step Plan For Software Implementation (That Actually Works) was originally published in Startup Grind on Medium, where people are continuing the conversation by highlighting and responding to this story.
