I visit many companies developing AI products and/or online AI-powered services. A constant theme is the excessive cost (and cost-overruns) these projects entail. I give below an outline of my findings, together with some suggested remedies.
The reasons for these cost overruns vary but generally comprise one or more of the following:
Uncontrolled and unrestricted (whatever the development team may promise beforehand) computer processing costs during the development, system testing and user testing phases.
Ill-defined requirements, or requirements that change dramatically, mainly as a result of poor analysis or misleading information or research provided by user management in the early stages of the project. Often these are not identified until user testing is underway.
Changes of staff midway through a project. Even though such changes are inevitable (people are people after all, and will want to switch jobs or go work for someone else), there is an almost universal lack of concern with documenting work-in-progress. As a result, when they leave, their work is effectively written-off.
Delays caused by several factors, most often staff problems (absence through sickness, disputes with outsourced suppliers of people or services), project management missteps (sometimes caused by a key member of staff such as the project manager being reassigned), or knee-jerk budgetary restraints (usually when the finance people receive an unexpected bill from Amazon or Microsoft).
While some of these are inevitable, they are often serious enough to grossly exceed any cost or time provision. My observations on how to limit these cost overruns and time delays are sometimes obvious but keeping them as an aide memoire will be useful to you. My top ten are as follows:
Hold project review meetings weekly, or more often if timescales are short.
Never change project manager during a project.
Assign a deputy project manager prior to commencement, and ensure he is free to attend every weekly review meeting.
Define precise documentation requirements for each phase of the project. The effort involved in this may be reduced by tasking the eam leader of each phase with producing the requirements prior to the project being funded.
Task the project manager (and motivate or penalise him financially) with ensuring strict adherence to documentation requirements during all project phases.
Plan for staff changes during the project as part of the initial project planning phase. In particular, define and resolve 'what if?' scenarios for every member of staff involved.
Ensure the user budget-holder is personally involved at every stage of the project planning phase. Do not accept any deputies.
Ensure the project manager defines and resolves with the user budget-holder all identified risk areas, especially where requrements are not sufficiently clear or are ill-defined. If the user budget-holder is unable to attend any such meeting or if the meeting fails to resolve these issues to the project manager's reasonable satisfaction, halt and do not progress further with the project.
During the project planning phase, separately define and then quadruple the estimated processing costs required for the development and testing phases. This will likely result in a decision to abandon non-dedicated servers as provided by the major cloud service providers.
Consider and ignore the protests of your development and testing teams when they tell you they cannot work within the confines of a dedicated server. Do not allow them to use the major cloud services during these phases.
There are other problems I could list but, from what I have seen, keeping to the above will dramatically reduce your project risks, and thus protect your career from harm.
Stephen Hill
Comments