Changes to systems are driven by changing conditions, requiring system documentation to be maintained in line with strategy. But being able to adapt systems to the changing environment is also about documenting management experience.
The Specification Process
System changes start with the business. The main issue in systems development is the translation of business requirements into technical specifications. Business people cannot be experts on technical matters, and technicians cannot be experts in Business Management. This is why we do functional requirements’ analysis.
Using graphical specification tools such as UML in systems analysis is the best way to overcome the language issue. UML is a notation which can describe both the summary and detail of required functionality. We use Enterprise Architect from Sparx Systems.
The need for system documentation
Projects bring together experts in implementation and those with full knowledge of the requirements. And the quality of the system depends on their mutual understanding. To assist this understanding, we document in UML. It is a graphical language understandable by both parties.
Project management methods such as PRINCE (PRojects In Controlled Environments) and Kepner Tregoe demonstrate that project management requires control.
The risk of wasted resources, time and the number of failed projects justify the need for control methods. Some project management methods themselves are too complicated.
In software development, there are also diverse approaches such as the waterfall method (iterations), test modelling.
The Software development process (coding, infrastructure, technical choices) has been surrounded by other methods (Project, Service and Quality Management) that are riven with processes and multiple actors.
There are several levels of control, serving to raise development costs and increase overall system complexity. Is there not something fundamentally missing, that requires all of these controls?
Agile methods aim to solve this over documentation problem by bringing business customers closer to developers. Specifications are then about discussion. Diagrams are useful here to document common understanding of system models.
The turbulence of markets, of economies, of political systems, lead to a short-term approach. These in turn make strategic thinking more difficult and lead to reactive management.
In the ‘old days’ one would establish a five-year plan, but this has reduced to three years in recent times. Sometimes a business strategy may simply be to see clearly ahead for one year. What has happened to strategic thinking?
How can businesses invest in a climate of uncertainty? I call for a return to stable and confident conditions, but with that innovation that drives managed change.
Documenting management experience
Some of the material here is about documenting management experience, providing guidelines and tips, techniques and recommendations for using business management software.
Having spent many years in information technology, I have a vision of the world as a set of systems.
I originally published some of my experience as an IT professional in systems development on a pbwiki that I called docbase.
Evernote to feed Docbase online
The original idea was to use Evernote to feed an online repository of business knowledge. I originaly chose a wiki format on pkwiki.
Part of the experiment was to determine how wikis differs from blogs, as a medium. Blogs are largely article-based, once the articles are in place often do not evolve. A wiki, however, is an invitation to improve content continuously.
I was interested to see to what extent the incremental updates and update history of the wiki was of use.
Wiki systems are now prevalent. Notion is a good example of a system which operates like a wiki in collaborative mode. It allows for multiple users, comments and comment resolution.
I used Ayoa to organize and prioritize content held in Evernote. I tried a similar approach with Kanbanote to filter and sort Evernotes . In the end, it may be Microsoft Access that does the job of organizing themes.
I originally set up this site on a pbworks wiki to document experience of IT professionals in systems development projects, quality and service management. I also intended to provide reviews and technical tips of favourite software, interesting sites and general IT tips and hits.
Originally used a wiki following a search for an online collaborative workspace such as Huddle.
Part of the experiment was to determine how, as a medium, wiki differs from blogs, the hypothesis being that while blogs are largely article-based, the articles once in place do not evolve. In a wiki, the approach is to improve content continuously.
We aim to document lessons learnt for academic use or for reference in Evernote.
Evernote and Enterprise Architect
I wanted to create a technical repository, starting with some Management Guidelines, quality and technical issues that I have met over the years.
For instance, I was interested to see the incremental update of the wiki as opposed to the linear database format.
The idea of documenting management experience originally started with #Evernote . The idea that a system could capture experience and later collate and use it to save time next time a similar problem arises.
However, while Evernote produced a large number of notes, it was difficult to aggregate them despite trying. I also tried to aggregate notes with moh.io, with kanbanote, and #Ayoa to a greater or lesser degree of success. #Obsidian is now the tool of choice for that aggregation.
The objective was ultimately to collate experience and distil from it guidelines and tips, techniques, and recommendations for using management software. In the end, the journey has been about trying a good deal of different software in different configurations.
Obsidian appears now to provide the functionality sought after in so many of these other tools. See a [critique of Evernote] which discusses further the limitations of Evernote and the tortuous development path taken by Evernote corporate which will I believe lead to its demise.
I started project #Docbase on PBworks, but folded it into other sites and into Evernote. Here I am tempted to try again. I hope to be more prolific and yet remain reasonably structured.