| Recommendation | Comments |
| Consider the users as parts of the « product » | The users are more than mere "participants" in the information system project. The users dream of a supportive info system, but would hate a slave-directing automaton. They know what in real life cannot be put under control : unforeseeable needs for quick decisions, appearance of unexpected multivariate random factors, some inevitable level of impure data, etc and well, otherwise, you would not need any user. The users will produce the data, and therefore will need the motivation to translate them into the redesigned data sets in the new information system. To do so, they have to understand and support these data sets as their own productions. The real users as not ignorant in web technology. They possibly have already developed some kind of unofficial collaborative software solution, and some key user may have developed interesting parts of a future info system on their own PCs. These facts should not be ignored. Considering the implications and discussing with the users may considerably simplify the overall project, especially in a view to drop useless needs for automation, overly elaborate data models, unnecessary requirements for real time processing, etc. |
| Be aware of limitations in regular web technology, especially with man-machine interactions | Experiment and realize the limits of what can be done thru regular web technologies regarding man-machine interactions (within the frame and under the control bars of your browser), for example when you need some kind of backtracking in man machine dialogues. Wonder why well established web products (for example the Apache HTTP webserver, the PHP language, the Python language, the Java run time machine, ... last but not least the implementation of Javascript in your browser client, even XML...), maintain parallel families of versions and why they issue so frequent releases. Even the stable kernel of web technologies is perpetually moving. This is a major trap in development, even more with maintenance. Nevertheless, there exists a set of available software products that allow a quick implementation of groupware and communications tools. These web applications are real opportunities in the management of info system project. |
| Consider emergent technologies as risks | Transparency does not exist with emerging technologies. Do not even look for documentation, establish direct contact with the developpers team, contract with them or even hire them ! And realize when they are nothing but marketing fads. Simply booby traps. Newer new technologies will work more or less with such version of such browser with such set of parameters. At the bottom of most of the latest « new technologies » stands the Javascript interpreter that is part of every modern browser. Be aware that this Javascript module is still proprietary to each browser software and that the Javascript language is not entirely standardized. Some new technologies products will even require the installation of a specific software client on your PC to complement your brower. The amount of alien software code lines in your project will grow larger and larger with heavy consequences on the requirement for cpu power. If you envisage using several newer « new technologies » simultaneously, the technical challenge grows exponentially ! Each of these newer technologies has not been designed to collaborate outside of a very strict set of (undocumented) requirements and has been barely tested in its own field. So, good luck ! « Portability » is intended, rarely proven. Nobody could prove it anyway, because of a standardization process in new technologies that is not a cumulative one, but a darwinian one. Some frameworks for software development should be considered as booby traps. They get you stuck to a given OS version and software environment and set of parameters, back to the old days of the first computer technologies. In every project in industry, new technologies are treated as risks. Why not in information systems projects ? |
| Examine the existing modules and data in the information system domain as assets to build upon | New technology should provide no pretext to ignore existing modules and data in the "old" info system nor to automatically consider them as candidates for some kind of elimination or purification. Actually, no new project should be envisaged as starting from scratch. Anyway, there are existing modules to be integrated and there are interfaces to be considered with modules outside of the information systems domain. The decision to kill / replace an existing module should not be made from a narrow computer cost control point of view, especially when you consider solutions with « new technologies » (see following items about modular design and upgrading existing module). Last but not least, the data migration problem and the consistency of man machine interfaces are critical ones, all the more when they are addressed too late. |
| Do NOT attempt «webizing» an existing application module without a preliminary analysis | As soon as they know that their old module is here to stay, the users will demand the correction of bugs and some evolutions that they consider necessary. Naturally, they will define their needs by difference with the software and the man machine interface that they know. All in all, the « webizing process » will turn out as a costly redesign-rewrite operation and will prove the worst solution by far ! The man-machine dialogues of the old module will have to be entirely redesigned according to web dialogue principles and limitations, with a probably most disappointing outcome. The application database management will have to be updgraded as well, simply because the old database company no longer exist and their database management software cannot be maintained. And the contract management of this "webizing" operation will be a nightmare (who will be responsible for bugs, who will be responsible for long term support of what ?) Conclusion : either have the old module replaced with a new software application or have the old module integrated as is into the new info system with some data normalization thru a minimal (weekly, daily, avoid real time by all means) interface. |
| Develop various models of the target information system, aimed primarily at inter-disciplinary communications | Some integrated development frameworks are based upon a progressively refined model of the target information system. This modelling process is clearly for software developers. This model should stay where it belongs : as a tool for programmers. Apart from software developers, there are other valuable points of view : architectural design, system security management, change management, project risk management, etc. Each of these viewpoints may deserve its own models of the info system and of the project. Several relatively simple models will facilitate communications between participants in a project. Much better and easier than a big intricate model for developpers, that would enforce the wrong priorities on the project. Besides, a unique software-development-oriented model will never be accepted by the users. They will regard the big model as a fake not showing essential interactions, and will start believing when they see the product and use it. |
| Design a modular architecture | What do we mean by modular architecture ? Fundamentally, a modular architecture is the result of an overall systems design discipline of the information system. It defines the target application modules of your information system, the minimal flows of data between them and their interfaces with the outside world, the set of common data, the strategy for security, etc. It carefully establishes a distinction between real time, daily, weekly, automated or not flows of data. It established how data consistency and integrity will be maintained, how the defaults will be detected and treated, etc. This is all for internal robustness of the info system, for visibility to the users throughout the project, for transparency to the maintainers, and aiming at cost control by questioning needs and requirements. By definition, a modular architecture can easily be prototyped and its components can be delegated to various developers. The questions "who will be the life cycle overall information system maintainer" and "who will be in charge of the data administration ?" can be made decidable ones. On the contrary, in too many info system projects, the developpers assume that a nodal server (EAI) will be in charge of all dataflows and will represent the solution to all problems. The crucial problem of data integrity and consistency is thought to be implemented by design in a so called object-oriented model. This is a very naive way of superimposing a theoretical model to reality. The eventual product will inevitably prove hardware hungry, difficult to understand, uneasy to test and analyse. Forget any idea of future evolution at reasonable cost : by definition, in a perfect world, there is simply no need for evolution, so why bother ? One last word : object programming is for programmers, it cannot replace a modular systems design in any way. Even within its specific domain, the effectiveness of object programming remains to be proven. For instance, compare a compilable Basic-like language with any object-oriented language (hint : compare documentations) when facing the challenge to manage inter-applications dialogues in a windows-environment. |
| Use the data models of off-the-shelf integrated ERP software as references | Do not pretend reinventing the wheel. Examine thoroughly why you need such or such data field or object which must definitely be different from the established data models in integrated off-the-shelf ERP software. Be aware that the data models in these big software products are reputably consistent and represent a tentative sum of the needs in many companies. This daring enterprise should be parallel to the development of a modular architecture. |
| Deny quality management as a separate discipline | In the abundent litterature in the software engineering field, there usually is a specialist in quality management in the project office, facing opposite numbers in participant organizations and contractors. This kind of organization will produce guidances, indicators, manuals, and lots of self justifying tokens by quality management specialists. Unsurprisingly, they will do their utmost to produce heaps of recorded proofs of the defaults created by other participants, but not much to prevent or solve real problems. Quality is an attribute of success, but the priority is the management for change. In a change-focussed project (instead of a « regular » information system project), you will have to implement some sort of intelligent retroactive loop to capitalize on tests by and with the contractors, show which is the current step in the test phase and accordingly decide which is the best testing method, etc. In essence, this loop is « CMMI ». But you do NOT implement it exclusively within the contractors organizations and you do NOT allocate hundreds of "CMMI" tasks (the model of the factory with thousands of workers is inadequate). On the contrary, simplicity and visibility are keys to success and the users should be in the loop, that can efficiently be implemented thru web software, by the way. Eventually, there should be absolutely no need for permanent specialists once the rules are established. |
| Require a systems design review with a prototype | At the design review, if your (sub)contractor shows up with a simple mock up, an intricate model, a set of flip charts, a handful of promises instead of a real prototype, you must be able to stop the contract. A real prototype can be evaluated by the users. Otherwise your systems design review is worth nothing but its load of paper and promises. Prio to the design review, you must be able to contract for an independent value analysis of the proposed solution and for the definition of an adapted risk management strategy. Then you must be able to recontract to have the new strategy implemented by the main contractor. Consequently, do not (sub) contract « turnkey lump-sum », or other phased variants, or whatever with your main contractor. |
| Focus on change management | Change : that is what the project is all about from day one ! On the contrary, focussing on new technology fads, on development methodology by the book, on project management according to best practices, etc, will obliterate the perception of the project office till the late evidence of a highly predictable disaster. Still worse, some projects managers will hire consultants and delegate change management to them. They simply are not at their right place. Just in case you did not notice : this last recommendation should be useless, as it is implied by other recommendations. |