Menu
Data/AI/Power Platform Practice Leader
In my last post, we tackled some BIG questions around AI—what it is and how it works, along with potential dangers and benefits. Pretty heady stuff! This time, let’s shift gears and dive deeper into how to implement AI successfully. As I mentioned before, as a consulting team, we are presented with many questions around AI and these questions vary greatly depending on where the person/organization is on their journey to implement AI. The questions in this post are asked most often by those about to start an AI implementation, and they want to gain clarity as to what the design/build/deploy experience is like. Are you curious? Read on!
Modern AI capabilities seem nothing short of astounding, and with enough time and money, almost anything can be possible. Does that sound familiar? It should if you have ever taken on a custom development project. AI projects are no different. They too should focus on building functionality that solves a well-defined business problem—they just employ novel technology to do so– Because the technology is so new (and frequently evolving), there is increased uncertainty around project duration, cost, and effectiveness. In order to manage that uncertainty, and the risks that come with it, we highly recommend going through a process called a “Design Sprint” before committing to any kind of development effort.
A Design Sprint is a 2-3 week undertaking (typically), during which the initiative stakeholders (from both IT and the business team(s)) get together to identify the problem, understand the challenges, map out the underlying business process, and outline the desired solution outcomes. The technologists on the team can then outline possible technical solutions and begin to develop a level of effort to realize the desired solution. It is important to note that a Design Sprint isn’t going to provide you with exact and comprehensive cost and effort numbers. This is custom development after all, and it is foolish to believe that you can accurately predict what will happen during the implementation phase. However, now you are armed with much more detail and understanding than you were when the original problem statement was introduced.
The short answer to this question is to use whatever methodology your team is familiar and comfortable with. It is unwise to force a new way of working on a team unless you are willing to invest the time needed to teach a new approach. The longer answer starts with a counterpoint—does the official methodology even matter, or is it more important how you approach the phasing of the work? What the heck does that mean?
Follow along for a second…
Waterfall implementation has been scoffed at over the years as being less effective in getting results quickly and helping an implementation team navigate changing requirements as users begin to use a product. This attitude stems from multi-month/year projects where all requirements were gathered and a team then sequestered themselves until they believed that the solution has been adequately developed and was ready for its big reveal… a reveal that often missed the mark since there was little user feedback incorporated into the development process.
So, what if we moved away from this literal “all or nothing” waterfall approach and adopted an iterative mindset? We could still gather all the requirements, but then, instead of developing the entire tool, requirements were broken down into phases and even levels of detail. The team could then develop parts of the solution and showcase the features, gather feedback, and refine the requirements. This is not as “scary” or challenging as adopting a full-blown Agile methodology may feel like to those who have not practiced it before. Key in on the concept of iterations and your AI project will move forward with a greater likelihood of success.
Nope, it’s not your Most Valuable Player on the team, though they are just as important and celebrated loudly and often. MVP, with regards to AI solution development, refers to a Minimum Viable Product. It represents a solution that is deployed to users that is functional and begins to address their overall needs. It will not incorporate every feature. It will likely still require additional user interface tweaks, and it may not provide the full promised ROI on the project. But it works—and it gives users the opportunity to provide feedback, and builds confidence in the team and stakeholders that progress is being made and a better future is possible.
Defining the MVP is more art than science. Stakeholder negotiations will prioritize feature sets and align everyone on what this important milestone represents. Use time to force a decision on which features are in or out for a given solution. Ideally, MVP status can be reached in 4 to 6 weeks. Use that constraint as a negotiating tactic. It will be uncomfortable at first, but in the long run, users will appreciate the process and the fact that they are getting value over time.
Are you reading these answers and finding yourself yelling at the screen, “Stop with the iterations and MVPs already. How much is this going to cost me?!” I’m going to stick to my comments above and point out again that coming up with THE pricing estimate is a fool’s errand. However, if you embrace an iterative mindset and adopt the MVP approach, then you have all you need to provide a relatively firm estimate for the first release.
Do this…
First, form your team: a project manager, change manager, solution owner, tester(s), architects/engineers, and so forth. You can assign a weekly cost to each of these resources. Then, with the iterative approach, estimate how long it would take to get to MVP. Again, ideally you can reach this state with two to three 2-week sprints. Now you can do the math and come up with a total cost. OK, there are some nuances that I’m glossing over, but this is a logical and defensible way to create a project estimate. Given the uncertainty of custom development, it is the best you can do. If your sponsoring stakeholders do not have the appetite for uncertainty and the idea that there will be additional costs, maybe it’s time to explore purchasing a solution instead of building one.
Hoo boy, there are books written on this one.–So let me just point out that custom development, especially with new tools like AI, is a complex venture. If you’ve read my answers above, you know this to be true. Without a dedicated project manager leading the charge, who will negotiate the MVP scope? Who will manage the iterative sprint cycles? Who will communicate the updates? Who will coordinate testing and launch? There is no acceptable answer to these questions other than the project manager.
As for change management, let me ask this question—if we are taking an MVP approach, who will manage user expectations, provide training, and quell the mass hysteria surrounding the idea that, “AI is coming for my job?” The project manager and change management roles are non-negotiable. Not paying for them will lead to a project incurring multiples of the avoided cost in time overruns and unnecessary churn. 25 years of implementing solutions gives me the right to say just trust me on this one.
Never. Not if you want to embrace all that AI has to offer. The technology will continue to evolve, and your business processes should be continuously evaluated for new efficiency improvements. Set up a Center of Excellence so that you can vet new developments and prioritize which initiative to tackle next. With a robust ROI evaluation model and strong development practices, your projects can fund themselves. Go explore!
If you have any questions or you’re looking for assistance with implementing AI , please reach out to info@eGroup-us.com or complete the form below.
Contact our team today to schedule a call with one of our experts.
