Every enterprise needs people willing to tackle the seemingly impossible. Years ago, I got to have dinner with one of the original Macintosh development team. He described interviewing top Silicon Valley tech people who declared that building a GUI-based 128k machine was “impossible.” Guess who proved them wrong.
Enterprises laud sales teams that achieve crazy great numbers during downturns, production teams that overcome shortages and line problems, and researchers that solve “unsolvable” problems.
That said, some things are really impossible. What happens to the teams that don’t get those results?
Challenging times make some (Big Data/AI/Data Science) BAD Projects just impossible. A critical tech supplier goes bust. A data feed becomes illegal. A key sponsor gets forced out. Domain knowledge specialists get promoted and can’t help. Critical assumptions prove to be false. Communicating these to management is painful. How do you communicate and what happens next?
Here’s what Project teams need to do should they discover their goal is impossible:
1) Act fast. Courageous honesty is favored over meek acceptance.
a. Time is money, and in BAD projects, it’s often a lot of money - In most enterprise cultures standing up and getting the change out is important. There are better places to apply any elapsed time, resource usage, and talent availability than could be spent ‘extending’ the BAD Project on the news. Better uses of money can help talent move to ]new projects, save spend for platforms/infrastructure, and free up critical domain knowledge people for operational needs.
b. Being seen as wasting enterprise assets is far worse than getting things redirected. Except when a sponsor gets forced out and there’s doubt as to whether the new replacement will support the BAD Project. In that case, continuing work during a changeover period is reasonable.
2) Tech barriers must be identified – Dead Horses are tough to carry
a. Technology stoppers need to be rapidly analyzed and projects shut down. There will always be a tech voice advocating “we can do this ourselves” or “there’s another way”. If this can’t be shown in a week or two, it’s not likely that technologists will have the credibility with executive management to keep burning budget for months.
b. At best a new cost justification and analysis can show another technical path where most often the outlook is bleak – that’s why the original technical choice was made. Dead horses are hard to carry. Concentrating on getting out of the desert is more important.
3) Stop work quickly if new laws and regulations invalidate or stop critical data feeds
a. If you think BAD projects are expensive, legal liability can be orders of magnitude more. At best there is reputational risk involved. At worst, there could be trailing liability. “Turning off” business associations and data feeds might be attention consuming in a short term. Better to be safe than sorry
4) Losing critical talent is always a potential issue
a. Your top Machine Learning expert is promoted to management. The brilliant architect is lured away to another company. When you lose critical talent a short transition may be possible. If the talent is leaving the enterprise then the project may become unlikely to complete. If there’s no backup… “The party’s over”
Have you experienced show stoppers during your time in Big Data/AI/Data Science? We'd like to hear.
Please leave a comment below
Comentários