(project management for enterprise systems needs to be suited to the task)
Much of the approach management comes from project disciplines developed and honed in the construction industry e.g. focused on building a building. Unfortunately enterprises, and many of their elements, are quite different in nature to buildings (e.g. enterprises are more like a city). This is especially so of enterprise systems. Until the differences are recognised, understood and analysed - and the project management approaches revised to better reflect the differences - project management in an enterprise will under perform on the expectations (i.e. they will not typically result in on-time, on-budget and on-scope delivery). This extends to a set of projects or programmes and non-time bounded initiatives
Usage is clear and doesn't change - of a building and most components of a building. Before building commences (and usually almost at conception i.e. before design commences) the expected use is clear to all parties and doesn't change substantially. That is to say that we all know what a house, garage, etc. is for (how we expect to use it); what a bathroom, kitchen, bedroom, etc. is for; what a bath, window, bed, etc. is for; what a door handle, sink tap, bed side lam, etc. is for. In all cases usage is clear and doesn't change and it is known before construction starts, and in the vast majority of cases before design starts. To suggest that all parties clearly know what an enterprise system is for (and exactly how it is to be used), what a major module is for (precisely and how it will be used), what a user interface is for, or what a UI widget will do precisely - at the start of most projects is simply untrue.
Construction of a building is largely assembly - Constructing systems (systems: development, integration, tuning, customisation, configuration etc.) are not assembly tasks they are largely design tasks. The small design decisions made by the various building trades do not approximate in scope (e.g. the extent to which the design could be got wrong) to the level of design undertaken on the fly for systems.
Building's design is defined and explicit - As a result of a clear understanding of usage, material, methods and a way of communicating about buildings (that has evolved and matured), a building's scope is very well understood before construction commences. New systems enterprise's design is very seldom defined with the same degree of certainty so in practice much of the project management is associated with design of the enterprise systems
Buildings are completed - Buildings can be built and once built are essentially complete (and often remain largely unchanged for extended periods of time). Most enterprise systems are never really complete, they continue to evolve on an ongoing basis - so while the there may be a period during which major changes are made, the nature of work does not stop at the end of a project (it may diminish, or be postponed briefly).
Buildings are more discrete externally - A building can be seen as successful by itself - and while they connect to other built-elements (things) the nature of the boundaries are, by enlarge, well understood by all parties. Another way of seeing this is to recognise that my house can be complete and useful irrespective of the state of most of the other buildings in my street - but most enterprise systems rely on a very complex web of interconnections with other systems to operate (networks, identity, office suites, printers, third party systems etc.).
Buildings are more discrete internally - Similarly the internal elements of a building can be seen quite discretely by all parties. Another way of seeing this is to recognise that my bedroom can be completed and useable - even if my kitchen is not. In enterprise systems it is far more difficult to confirm that discrete elements are working.
Technologies and materials understood - The characteristics of a materials used are well understood. Frequently enterprise systems are built using technologies that have not be used extensively before by the people doing the work (at best similar of analogous technologies, or earlier versions, may have been used). Often regulatory codes are in place reflecting what does and does not work
Methods are mature - The exact methods of design and construction are not understood or agreed to on an industry wide basis. With buildings the set of documents used to describe the building is fairly standardised irrespective of which organisation does the design and within each area the detailed documents are also well defined (structural, HVAC, electrical, plumbing, etc.). So codes of practice exist and usually WBS for sub-aspects. Compliance with best practice is by regulation and not determined by a planners powers of persuasion. This is not true for enterprise systems - practioners argue over both high level methods, and how detailed methods should be applied.
Reasonable tests are well understood - As usage, materials and methods are well understood the functional and non-functional behaviour is well understood e.g. I know I should be able to walk through a door, and that a brick that is thrown can be expected to break a window - but not destroy a column.
The reason the words "by all parties" occur so often in the above is because specialists associated with enterprise systems may assert that their level of knowledge approximates that of their building counterparts. But the issue is that everything needs to work together - so what we really need is for all parties (user, designer, construction trades, operators) to all know how everything is intended to work together. For buildings there are exceptions to all of these rules - by in large they are true - and where they are not true specialised buildings (opera houses, stadia etc. ) these projects run into difficulty as well.
So projects are, in many of the uses they are put by an enterprise, artifical constructs used to provide certainty regarding cost and time - implicitly recognising the scope is a variable. Unfortunately most traditional project management assumes scope is fixed - and often project management becomes a function that communciates how far time and cost are to exceeded.
Essentially, enterprises want to make changes to how their business operates (which can be described in a business architecture) and the technologies, assets and services they use (which can be described in a technology architecture) based on strategy (constraints, goals, strategies, initiatives, plans etc.).
What is needed is a way to describe the changes required (holistically) then to understand what aspects of change are to be made in each project silo (and where common elements are affected) and to allow analysis to be undertaken across all projects as new information comes to light e.g. usage becomes clearer, design matures (as more is learned about the materials and how they are best assembled); as boundaries with and between elements clarify; as tests of quality and success are refined. The exact requirements; exact design; and exact project definitions and boundaries and inter-dependencies emergence from mists in parallel.
The approach I advocate achieves this.
No comments:
Post a Comment