Artificial intelligence is an emerging field with wide applications. Although trying to solve every problem with artificial intelligence is not the right approach, care should be taken to explore new potential avenues and ensure that your focus is not too narrow. During the ideation stage, it is essential to be as broad-minded as possible. For instance, consider how AI might be able to improve not only your core business but also auxiliary functions such as accounting. Doing so while acknowledging the limits of real-world applications will facilitate idea generation. Some applications for AI can also be relatively abstract, benefiting from lots of creative input. All ideas that are considered plausible, even those in the indeterminate future, should be included in the idea bank.
It is easy to get carried away with rituals, thus sidelining the ultimate goal of generating new ideas. Rituals such as having regular meetings and discussions where people are free to air their opinions are extremely important. Apart from these bare necessities, however, the focus should be placed on generating ideas and exploring creativity, rather than getting bogged down by the whole process. The process should never detract from the primary goal of creating new ideas.
For an organization, the focus should be on creating a culture of innovation and creativity rather than generating ideas for current projects. A culture of innovation will outlast any singular project and take your organization to new heights as fresh ideas are implemented. Creating such a culture might involve a change in the mindset around adhering to old processes, striving to become a modern organization that questions and challenges all its existing practices, regardless of how long things have been done that way. Such a culture will help your organization much more in the long run than just being concerned with implementing the ideas of the hour.
Given machine learning's popularity in the current tech scene, there are more startups and enterprises putting out AI-based systems and software than ever before. This generates a tremendous pressure to stay ahead of the competition, sometimes using just marketing alone. Although incidents of outright fraud are rare, many companies will spin their performance results to show their products in the best possible light. It can therefore be a challenge to determine whether today's AI can fulfill your lofty goals or if the technology is still a few years out. This fact should not prevent you from starting your AI journey since even simple AI adoption can transform your organization. Rather, let it serve as a warning to be aware that AI marketing may not always be as it seems.
AI solutions tend to affect all parts of an organization. Their transformative nature requires data from multiple groups and stakeholders. As a whole, organizations are often resistant to change, so it is important that each stakeholder's input is incorporated at the earliest stages of the project. It is in every project's best interest to ensure that its projected benefits have been clearly explained to everyone involved. The only possible path to shaking the fear of change is to explain why that change is in the best interest of the stakeholders. The current users of the system might be facing a problem that the proposed system is not addressing. New research may have revealed an alternative revenue prospect that your organization was previously unaware of. Whatever the cause for change, in the event that a stakeholder is not consulted beforehand, they may become the biggest roadblock for your project's adoption. The effects of this pitfall will likely not be felt until you've deployed your solution in production during step 5, but it is important to address this pitfall during the project definition step, before it has time to snowball.
One way to avoid this is to have an initial kickoff meeting that includes all possible stakeholders. It is important to be liberal with the attendee list because this is the meeting where everyone will formerly discuss the project for the first time. Although people may have heard about the project in hallway conversations, they must at some point be officially informed about the project and invited to participate in its development and success. Keeping people in the loop, with a clear channel to propose comments and suggestions, will enable them to have a sense of ownership with the project down the line during its implementation.
One hazard when exploring a new technology is searching for a problem you can solve with it, rather than the other way around. Just because you have this shiny new hammer does not mean the world is suddenly full of nails. The focus, as we have discussed, should be on the pain points of your organization. Decide what problems exist or what opportunities are out of reach, and then develop a solution to resolve the problem. If you avoid this advice, you will end up trying to fix things that are not broken or addressing problems that never even existed in the first place. Do not try to fix what is not broken; that will only lead to extra costs and delays. Having a firm grasp of what the process flows of the company look like will help you target only the deficient areas.
As you work through developing your project plan, you may be peripherally aware of services and commercial technologies available today that provide AI capabilities. It would be a mistake, at this point, to select a particular vendor with whom to partner. This is a common mistake made by organizations that, by selecting a vendor too early, unintentionally limit themselves to the capabilities offered by that vendor. Instead, continue focusing exclusively on developing your user stories. Think about the users of your system and how you can make their lives easier. If you know your users use social media, for example, consider making social media integration part of your scope. Establishing these requirements during the project definition phase will greatly simplify selecting a vendor once you reach that stage.
Another risk you run in prematurely selecting a vendor is being tempted to include features available through your vendor that have no relevance to your users. For example, if that chat technology you found provides a text-to-speech capability, you might be tempted to include that in your project, not because it is helpful to your users, but because you want to fully take advantage of your investment. This runs the risk of complicating your efforts, obscuring your project's aim, and unintentionally spending your limited resources on capabilities with minimal value. Again, your focus at this stage must be your users and defining your project plan, not on picking a technology or partner.
Change is a natural part of the Agile process. Although this change can be a great thing, it is also possible for projects to become bogged down or impeded by a lack of consistency. If the requirements of a project change too often, or without sufficient cause, that can lead to developer confusion and a failed project. For this reason, it is vital to establish a lightweight but formal change request procedure. Every change should be approved by the product manager, as they have the ultimate responsibility for the project. The product owner should scrutinize and evaluate each change request carefully to assess the impact on the project. Requests that have no clearly illustrated necessity or benefit should be ignored and not passed on to the developers.
For large and small projects, it is imperative to assess their impact on the organization. Such an assessment will identify shortcomings and lessons for future projects. In order for this kind of assessment to take place, the project's scope and success, as discussed earlier in the section “The Components of a Project Plan,” need to be defined clearly. Projects can fail. It is what you learn from each one as an organization that will separate you from the rest. People who are afraid to fail might neglect to set empirical goals by which to measure their success or failure. However, it is vitally important for you to know if you are off track sooner than later so that you can make course corrections. Agile is built around the philosophy of fail quickly, fail regularly, and fail tiny. Small failures are easier to recover from and allow learning in a nondestructive manner.
When it comes to data, having sufficient licensing is critical. Using unlicensed data for your use case is the quickest way to derail a system just as it is about to launch. Sometimes, developers will take liberties with data in the name of exploration, stating “I am just seeing if this approach will even work first.” As time goes on, the solution is built using this “temporary” data while the sales and marketing teams run with it, without knowing that the underlying data licensing has not been resolved. At this point, hopefully, the data licensing problem surfaces before users are onboarded to the system. In the worst case, you find the issue when the data owners bring legal action against your organization. To prevent this, it is imperative to have a final audit (or even better, periodic audits) to review all the data being used to build the system. This audit should also include validation of third-party code packages, because this is another area where licensing tends to be ignored for the sake of exploration.
This pitfall relates primarily to the role data plays in training a machine learning system. Specifically selected data will serve as the system's ground truth, which means the knowledge it will use to provide its answers. It is important that your ground truth contains the necessary knowledge to answer these questions. For instance, if you are building the aforementioned daytime and nighttime classifier but your ground truth does not include any nighttime images, it will be impossible for your model to know what a nighttime image is. In this case, the ground truth is not representative given the target use case, and it should have included training data for every class you wished to identify.
For information to be useful, it has to satisfy three major conditions: confidentiality, integrity, and accessibility. In practice, however, accessibility and integrity overpower confidentiality. In order to ensure legal, ethical, and cost-effective compliance, security should not be an afterthought, especially for your data storage systems. Data stores should be carefully designed from the start of the project. Data leakage can lead to major trust issues among your customers and can prove to be very costly. Companies have gone bankrupt over inefficient security. Customer data should be stored only in an encrypted format. This will ensure that even if the entire database is leaked, the data will be meaningless to the hackers. It should be confirmed that the encryption method that is selected has sufficient key strength and is used as an industry standard, like RSA (Rivest–Shamir–Adleman) or Advanced Encryption Standard (AES). The key size should be sufficiently long to avoid brute-force attempts; as of this writing, anything above 2,048 bits should be sufficient. The keys should not be stored in the same location as the data store. Otherwise, you could have the most advanced encryption in the world and it would still be useless.
Employees also need to be trained in security best practices. Humans are almost always the weakest link in the chain. Spear phishing is the technique of using targeted phishing scams on key persons in the organization. Such techniques can be thwarted only through adequate training of personnel. It is important to include not only employees but also any contract resources that you are using to ensure that they are trained in the best security practices. Training and hardening your organization's managers, engineers, and other resources, just like your software, is the best way to avoid security compromises.
Computer security is a race between hackers and security researchers. In such a scenario, one other critical component to winning is to patch everything as soon as possible. Auditing your infrastructure and servers by professional penetration testers will go a long way in achieving your organization's security goals. These specialists think like hackers and use the same tools that are used by hackers to try to break into your system and give you precise recommendations to improve your security. Although getting security right on the first attempt might not be possible, it is nonetheless necessary to take the first steps and consider security from the beginning of the design phase.
Dark designs are design choices that trick the user into giving away their privacy. These designs work in such a way that a user might have given consent for their data to be analyzed/stored without the user understanding what they have consented to. Dark design should be avoided on an ethical and, depending on your jurisdiction, legal basis. As the world progresses into an AI era, more data than ever is being collected and stored, and it is in the interest of everyone involved that the users understand the purposes for which their consent is being recorded. A quick way to judge whether your design choices are ethical is to check whether answering “no” to data collection and analysis imposes a penalty on the user beyond the results of analysis.
If third-party vendors are used for data analysis, it becomes imperative to ensure that anonymization of the data has taken place. This is to lessen the likelihood that the third party will misuse the data. With third-party vendors, it becomes necessary to take further measures like row-level security, tokenization, and similar strategies. Conducting software checks to ensure that the terms of a contract are upheld is very important if third parties are going to be allowed to collect data on your behalf. Cambridge Analytica abused its terms of service as Facebook merely relied on the good nature and assumed integrity of Cambridge Analytica's practices. Having software checks that ensured third parties could access data only as defined in their contracts would have shortened Cambridge Analytica's reach by a huge amount, as it would not have been able to then collect data on the friends of people taking their quizzes.
Respecting users' rights and privacy in spirit is a process. Although it might be costly, it is necessary given the amount of data that is now possible to collect and analyze. When fed into automated decision-making AIs, these large amounts of data have the potential to cause indefinite and undue misery. It is in this interest that it becomes necessary to implement policies that make the user aware of how their data is being collected, how it will be analyzed, and most importantly, with whom it will be shared.
Although most people today understand the importance of backups, what they often fail to do is implement correct backup procedures. At a minimum, a good backup plan should involve the following steps: backing up the data (raw data, analyzed data, etc.), storing the backup safely, and routinely testing backup restorations. This last step is frequently missed and leads to problems when the system actually breaks. Untested backups fail to recover lost data or produce errors and require a lot of time to restore, thus costing the organization time and money to fix the problems. To resolve this, you should routinely restore full backups and ensure that everything still works while operating on the backup systems. A full data-restore operation should be undertaken on preselected days of every year, and all live systems should be loaded with data from the backups. Such a mock drill will identify potential engineering issues and help locate other problems as well, enabling you to develop a coherent and reliable restoration plan should the actual need for one ever arise.
With cloud storage becoming so commonplace, it is essential to remember that the cloud is “just another person's computer” and it can go down, too. Although cloud solutions are typically more stable than a homegrown solution because they are able to rely on the economies of scale and the intelligence of industry experts, they can still have issues. Relying only on cloud backups may make your life easier in the short term, but it is a bad long-term strategy. Cloud providers could turn off their systems. They could have downtime when you need to do that critical data recovery procedure. It is therefore necessary to implement off-site and on-site physical storage media backups. These physical backups should also be regularly tested and the hardware regularly upgraded to ensure that everything will work smoothly in the case of a disaster.
All data backups should be encrypted as well. This is especially important to prevent a rogue employee from directly copying the physical media or grabbing it to take home. With encrypted backups, you will have peace of mind and your customers will sleep soundly, knowing their data is safe.
Although the majority of this chapter dealt with how to break down the prototype requirements and select technologies, it is important not to dwell too much on designing and planning your solution. Given that you will be using an Agile approach and starting a feedback loop as soon as possible, design changes can happen quickly. The start of the project is the point when you necessarily have the least amount of information known. Therefore, it only makes sense to start sooner than later, gaining knowledge by implementing and updating your design as you go. In the end, you will be able to create value more quickly using this approach.
Another frequent pitfall that developers run into during the prototyping phase is setting themselves up for failure by trying to implement too much. A prototype should be limited in scope, provide real value, and be realistically feasible. There will be plenty of time to build large, complex, even moonshot systems once the prototype has been built. However, the prototype is your time to demonstrate value and prove to the stakeholders that AI systems are worth the investment. A prototype that takes too long or that is too ambitious and fails will hurt your organization's chances of ever transforming into an AI-integrated business.
Continuing the chatbot example, it is important to include only a few types of chat interactions during the prototyping phase. For instance, if you are building a chatbot for a movie theater chain, perhaps the prototype version would only handle the ticket purchasing flow. Concepts such as refunds or concessions should be deferred until the production phase. In this way, the prototype can demonstrate the concept and value of purchasing tickets with the understanding that the other interactions can be added later with further investment.
The other common problem is correctly identifying a problem but then assuming it can be solved with the technology du jour. During the technology selection process, you have to ensure that currently popular technologies do not cloud your judgment. Otherwise, at best you will have a needlessly more complex solution. At worst, you will need to replace a core technology midway through development. If your problem requires a hammer, it does not matter how awesome and new that shovel is, it is not the right tool for the job.
With regard to AI, this frequently happens with the misapplication of neural networks. Although it is true that neural networks can solve a large class of problems, it is not the right solution for every problem. For example, naïve Bayes can be a better approach when you do not have a large amount of data. Additionally, if you are in an industry that has to be able to explain its results, neural networks (especially large ones) are notorious for being opaque. They might be accurate given the training data, but because the features it learned are a complex combination of the inputs it is impossible to give a coherent reason why it made the decision it did.
This pitfall is common with all new technology but especially with AI solutions. Automation technology can be unsettling for end users, since it replaces some of the work they are used to doing themselves. Opinions range from “This technology will just be a hindrance to how I work,” to “It's only a matter of time until my skills are obsolete, the robots take over, and I'm out of a job.” Change is hard, no matter what form it takes.
Another issue with AI solutions in particular is that most AI systems require input from a subject matter expert (SME) to create the ground truth used to train the underlying machine learning models. These SMEs are also typically the ones directly affected by the integration of a new AI solution. For many reasons, it is important that the AI solution be an augment to the SMEs' knowledge and capabilities, instead of a direct replacement of their role. Remember that a machine learning model is only as good as the ground truth used to train it.
To avoid this pitfall, early end user engagement is critical. End users need to be part of the planning process to ensure that they fully understand the solution and feel they have contributed to the end product. This might even mean inviting a few influential end users during the Ideation/Use Case phases to build excitement and a voice for your user base. While early input is in no way a guarantee (end users might think they want one thing at first, only to realize they need something else once they start using the solution), it will help mitigate the fear associated with adopting new technology.
Under Agile, the development team is given full responsibility for the successful technical implementation of the project. The team works on the combined values of transparency and mutual trust. In such an environment, it would not be prudent to control every aspect of the development team. Nor would it be a good practice to set the targets for each sprint for the developers. This will lead to a lack of motivation, weakening Agile. The development team should be able to focus on the project by themselves with minimal intervention from the product owner. Some teams pick the Scrum manager from among the dev team as well. This is to ensure that the benefits of Agile are preserved.
Since building a machine learning system requires a number of specialized skills, it is critical to have these skills available and ready to go before your project starts. Whether this means hiring full-time employees or establishing relationships with contracting firms, it is worth the up-front effort to avoid delays. Skills we have mentioned thus far that will be required include AI, data science, software engineering, and DevOps. The hiring issue is twofold in that you must find the individuals with the proper skillsets for your project and, of course, have the appropriate budget in place to fund them. With these items addressed, there should not be any skill roadblocks in the way of getting your system deployed.
Quite a few project managers and businesses assume that once a project is implemented, the project is done. This is incorrect. Once released, projects are subject to entropy, like everything else, and will start decaying quickly unless maintained. This means that the project plan should include some developer time for postimplementation bugs and improvements. The allocation need not be more than 10 percent of the total implementation time, but it can make all the difference between a successful implementation and a failed one. It is also important to limit the scope of these fixes so as to not derail the existing system as a whole. Additionally, there can be other complications with implementation in large projects, like a last-minute hardware failure, and such complications will also need to be managed.
After implementation, it is vital to collect and analyze user feedback. Ignoring feedback will doom most projects to eventual failure. Users who feel like they are not being heard may fail to utilize the software's full benefits or resist using the software altogether. This reluctance to change can be justified, and in such a case, the only option can be to tweak the released software. A heavy-handed approach that fails to consider users' needs will hamper productivity and efficiency, ultimately wiping away gains made by the implementation of the new software. Forcing users to use broken or incomplete software is not a sustainable option—eventually, the users will abandon the software entirely, tarnishing your organization's reputation. Software is made for the users, so gathering their input and making changes based on their feedback is a critical requirement for success.
Software can be made user-friendly only up to a certain point. To ensure that users can utilize the software correctly and receive the maximum benefit, it is vital to train them to use the new software correctly. There is a good chance that the majority of AI projects will be used by business analysts and the like, having little to no knowledge of computer science. It then becomes important to explain the tool they will be using to do their jobs properly. Training should be more than just quickly explaining the menus and the UI. It should be a full introduction to the software and how it can positively impact a user's day-to-day work. Training should also span a few days, rather than just one sitting, to help users better absorb the information and give them an opportunity to ask questions. Well-trained employees can do their job more efficiently and accurately by making the best use of the software tools provided to them.