The death of Excel has been announced many times but it seems to be tougher than officer McClane and still saves the day for many organizations. However, implementation is riddled with problems and dangers that could have detrimental effect on careers or businesses. I have long developed and fought for standards and procedures to minimize the risks and pains coming from badly placed, designed and developed spreadsheets and I am not alone in that as there are numerous evangelists of good Excel practices. However, their impact is limited and there are larger opposing forces at play. They come from the organizations and the accessibility of Excel itself.
As an integral part of the office landscape Excel is considered to be easy to understand and use and having short track to results. Which it is of course. However, this accessibility is deceiving when things come to its implementation as part of the corporate processes of decision making, monitoring and communication. Bad policies mixed with careless design proved to be a recipe for a disaster. Well, disaster is maybe bit overstated but calculations of losses in time or missed opportunities could be have dramatic outcome. Policies establish and enforce proper versioning, documentation, sharing and everything else applicable to documents in general as spreadsheets are not different in this sense. The lack of policies or presence of bad ones (even worse) could place the spreadsheets in an ineffective way with respect to general data and decision flow in the organization. The requirements and their enforcement are lessen for the spreadsheets more often than we like to admit. Spreadsheets also usually do not go through rigorous testing and acceptance procedures that apply to a new software.
Design and implementation considers the viability of spreadsheet solution, organization of its data, tabs, dashboards, reports and the numerous algorithmic and technical considerations that produce a good spreadsheet solution. Unfortunately, the majority of Excel developers withing organization are either some business person who is not aware of all the good design or development practices or an IT guy who does not really like developing in Excel as it is not a proper developing environment and considers it a lesser tool. Excel could easily misleads the inexperienced one with its features and tools. How hard could it be to create a dashboard after all? It all comes down to the personal qualities and skills of the spreadsheet developer. The organization depends on this sole individual and their access to good practices, strive for perfection, hard work, curiosity and all other qualities that make a good developer. In addition to that, Excel development work is not very well appreciated due to its accessibility and low entry skills.
My observations confirm majority of organizations suffer from bad spreadsheet policies mixed with badly designed and developed Excel workbooks. I hope to be wrong but unlikely. The path for improvement is obvious - better spreadsheet policies, acceptance testing and careful consideration of developing teams and process as well as proper training. Most organizations provide some training but it is limited to basic functionalities and is expected the employees to educate themselves for further improvement. A problem is organizations tend to not consider hiring external consultant for their spreadsheets or training in more advanced techniques and methods - again mostly because of understating its importance and difficulties in development. However, it could save immense amounts of effort and time while achieving great quality.