Projects are artificial constructs and often managed in ways unsuited to enterprise change initiatives

(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

How buildings differ from enterprise systems

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.

Enterprise transformations and knowledge management and the prisoners' dilemma

Why is that while objective analysis indicates that only a very small change of behaviour is required by many people in an enterprise, especially one undergoing transitions, to significantly improve the outcomes for all - but no one is prepared to make the changes.

Stages of maturity in communications - strategy, architect and governannce functions

(to communicate a simple organisational problem with a few simple pictures)

Overview
When large enterprises are going through transformation (new products, mergers etc.) documents are ineffective in communicating the complex issues (and document and content management systems can exacerbate problems). As a result people involved in transitions spend time much time in meeting, in emailing and on the phone.

Strategy, architecture and governance are roles are established, but they can't manage the knowledge explicitly, don't scale and the reliance on individuals represents a risk to the business. Modelling manages the semantics, and provide powerful analysis and visualisation capabilities, and provides a source of record (reduce the risk) - but they don't scale and most models don't suit most audiences most of the time - so as communications mechanism they fail.

A knowledge repository is required which allows information to be captured as a by-product of day to day work, analysed and presented in the way that suits each audience and allows internal people to focus on actual strategy, architecture and governance while minimising the need for external consulting services.

Documents are ineffective in communicating complex issues in large enterprises Documents which encapsulate business concepts e.g. strategies, plans, initiatives, programmes , designs etc. are ineffective in communicating to most of the people most of the time. Many people create documents that communicate things to them, and their peers i.e. from their perspective and oriented at their interests. They make documents available to others in the expectation that they will effectively communicate to different people, with different interests and different perspectives. Most people if they looked at the evidence would realise this doesn't work (i.e. it demonstrably fails).



The set of all documents contains sets of related concepts (constrains, goals etc.). The set of concepts may relate to any aspect of the business (product, organisation, location, behaviour, risk, projects, technologies etc.). In the documents, usually most of the relationships between concepts are implied and unweighted (semantics are inexplicit) - because the author or original audience would be expected to know these relationship implicitly.


In the real world people need answers to questions quickly (without lots of reading)
When any issue arises or any decision needs to be made what people want is to understand an issue, or set of issues that is currently of interest to them i.e. How the concepts are related.

If one read, understood and internalised all the related documents (assuming they can be located - and were all consistent) one may perhaps get the understanding required. Unfortunately few have the time and capacity to do this.

Document and content management systems can exacerbate the problem
Document and content management systems, or content may help maintain the set of documents - but they don't address the issue knowledge held within the documents it is not explicitly related (often it is not even very explicitly defined) i.e. the semantic is not explicitly recorded (within documents, or across sets of documents), consequentially they can't address the issue that the set of documents are inconsistent. So in a sense these systems exacerbate the problem by facilitating the publication of even more documents, and maintaining the illusion that if the documents can be located people will understand all that they contain.

Meeting mayhem follows
As the business people need to know the answers, and don't have the capacity to read all the documents - what they do is communicate amongst themselves to get a handle on the issue of interest (workshops, meetings, emails, phone calls etc.). They work out what they need to do (though it takes time) and move on - only to repeat the exercise with next issue (or on the same issue sometime latter).


Strategy, architecture and governance functions are implemented
In most organisations eventually people realise that there is an issue and they put in place people (strategy, architect, governance) who aim to consolidate this knowledge. These people may even create their own documents - that aim to consolidate information around different perspectives (there are of course an uncountable number of different perspectives that occur over time in an complex enterprise). They become someone you can ask questions of. Unfortunately their capacity is usually fairly quickly exceeded - so they become people who know a lot (but seldom enough on any topic), but produce little of value.



Strategy, architecture and governance models eventuate
Some organisations realise that implementing this knowledge management function in a person or team (and their documents) doesn't address the issue of the semantics not be explicitly understood so they move to putting models in place. Models can explicitly manage the semantics and aggregate knowledge from all the sources. The models can, in theory, now answer all the questions. However there are two problems.




Models don't suit most people most of the time
The 1st problem is that while the models may be able to answer all the questions most people don't want to deal with these complex models (i.e. so for many they don't act as an effective communciation mechanism).

Models are time consuming to maintain
The 2nd problem is that one creates a bottle neck i.e. in the effort involved in maintaining the models. Usually people start by aggregating a small subset of the knowledge in the enterprise (i.e. the inputs and outputs that relate to a small set of people and issues). People quickly realise that the more knowledge that is in the model the more powerful the models can be a relating information and answering questions. Unfortunately this increases the load of model maintenance and modelling function become a bottleneck. There are bottlenecks on both the input side (maintaining models) and the output side (explaining how to use the models to answer questions).



A knowledge repository is required
Eventually people realise what is required is a knowledge repository - which contains the information held in the models (all the models) . This allows the strategy, architect and governance functions to be effective i.e. they are no longer bottlenecks and can add much more value. The repository can be used by all parties to record information, answer questions and produce the documents that each requires.



Why consulting firms don't get this
Well they do get. It just doesn't suit them. Smart consulting firms know that if models are not used at all then the knowledge and expertise they offer will always be required (an almost endless demand for their services). If models are used - and they provide the modellers - they will likewise ensure lots of modelling work. Similarly some of internal the people tasked with peforming these functions may fear that if they used such a solution - their work would evaporate. Ironically what actually happens is that they no longer have to act as typing pool (transcribing information) and actually do what most of them are most interested in doing i.e. doing actual strategy, architecture and governance thinking.

Industrialisation of IT

(prompted by an organisation with a method for really focusing on business value)

A confluence of factors now allows some organisations to adopt dramatically new ways of getting more value from the systems more quickly - with less investment and less risk. Essentially this involves a non-incremental change (revolutionary) as aspects of IT move from being a craft to an industrial process.

The factors include: the existance in many organisations of extant suites that are capable of supporting most of the existing business processes; the adoption of standards for controlling how systems processes are orchestrated; adoption of common mechanism for systems to communicate; and maturity of the approaches to modelling processes and reporting on the execution of those processes. The acronyms associated with these factors include: ERP, BPEL, SOA, BPM and BAM.

These new approaches allow models to be created that represent how the organisation operates and that at the same time link directly to services (existing, well engineering, industrially tested and documented) in the enterprise suites. Optimising the business performance then becomes a matter of analysing the process models and

It will substantially reduce the level of expenditure that has traditionally been associated with the wanton customisation through low level coding of large application suites (e.g. ERP systems). This customisation is usually poorly conceived from a business perspective i.e. it is expensive, time consuming, risky and worst of all moves the understanding of how the organisation actually operates into code (the organisation doesn't really understand or control). What the customisation does ensure is that large development teams are required - usually provided by one of the "independent" consultants who have lead the organisation down the garden path of customisation in the 1st place. Frequently it will also require additional hardware and systems software so all the vendors of products and services win i.e. everyone wins except the end user.

The class of organisations are those whose major systems are these ERP systems (and other such systems as they mature) and scope is determined by what these suites are designed to do.

As with any revolution the people who benefit from status quo (the craft model) will resist these changes. The crafts people in this case are traditional developers who wish to hand craft systems in preference to assembling solutions from parts.

During the industrialisation of manufacturing to stop the resistance they made machine breaking (industrial sabotage) a capital crime, executed some saboteurs and deported transported many as prisoners to Australia. Almost two hundred years latter we can only hope the resistance will be less vociferous.

If organisation move to this paradigm they can largely remove IT as a blocker to change and the IT organisation can be downsized and redesigned to focus on innovation.

Why organisations struggle with managing requirements

Why do organisations struggle to improve their approach to managing requirements.

Essentially because the industry doesn't present a common view of best practice, and frequently doesn't distinguish between different approaches to requirements management – i.e. high level vs low level –, or between the different possible approaches to low level requirements management.

Ideally at a high level enterprises should have a common way of defining requirements and assessing that they are met. At lower levels the methods should diverge depending on how the requirements are to be met – and the role the enterprise needs to play.

We can think of the ways that requirements might be met under four broad headings:

• Development – where major components of software are developed
• Integration – where a number of mainly existing components are integrated
• Package customisation – where essentially an existing solution is customised, configured or extended
• Package off-the-shelf (OTS).
  

Development may be when enterprise builds a solution in-house e.g. developing in Java or C#. (the solution will fit like a glove because it is bespoke). This is usually done when no OTS packages meet the requirements or the business seeks to achieve unique market differentiation based on the solution (which often revolves around the use of some bespoke software). This may or may not involve an adjustment to how the business operates.

Package customisation is where a package or service (such as SAP) is purchased and it is customised, configured or extended (as little as necessary). In this case we usually recognise that we will need to make some adjustments to how the business operates, as presumably the package reflects industry best practice.

Package OTS is where a product or service is used as purchased with no changes made – for example MS Word. This is usually done where an enterprise does not seek to achieve competitive advantage through the use of the tool. Few businesses seek to differentiate themselves based on how well they use a word processor.

Integration may involve all of the above and how different components (including external services) from each area work in concert.

It should be clear that the ideal approach to requirements in each of these four s area differs. The failure in most requirements management approaches is that the lower level methods pollute the higher level approach. By way of analogy - the way the plumber or electrician or bricklayers needs to define what they do, and how they notate their detailed designs, is foisted upon people who simply want to describe what need in their new garage).

The approach to requirements management also needs to be aligned with the approach to project management. This introduces another issue: project management in IT.

The failure of requirements management is matched with the failures to recognise the difference between project management in IT and project management for buildings. The reality is that in IT the requirements and specifications often evolve right to the end. This is because what people want to do with the technology elements is partially determined by what the technologies can do: the technologies change behaviour. To pick to generic consumer oriented examples: a GPS navigation phone changes how one navigates, a video conferencing phone changes how one communcates (as do a texting/SMS phone, instant messaging, etc.), and Google and others have changed how we find things. By contrast, with buildings this is far less often the case: we pretty well know exactly how we want to use, say, a toilet, a door, a bed, a bedroom or a lift.

In IT delivery a great deal of the time is spent on understanding precisely what the requirements are, and therefore what the design is (including engineering calculations), what construction is required, and how things should be tested. In buildings the requirements are far more precisely understood at the start, the design is well articulated and precise before construction starts, the testing is usually more obvious (or it is covered fairly well by defined industry conventions), and so on. In buildings the scope is very well defined and the focus of the project is far more on costs, time and variance - whereas in IT the scope is seldom well defined at the start, and the focus of project management is on managing the refinement of scope (while seeing how cost and time can be contained).

For organisations in which this is not a main focus, asking how they want to manage requirements is probably unrealistic. It is a bit like a building architect asking a home owner how the plans should be drawn up, or an electrician asking the home owner how the electrical diagrams should be drawn.

So what is needed is to show some leadership . Clients need an explanation of how requirements can be managed – and how this is related to detailed SDLCs, approaches to project management, and enterprise architecture. The enterprise architecture is a logical starting point for understanding the needs as it should describes:

• how the business operates or seeks to operate, which is turn grounded in the business drivers and constraints, (which include technological, organisational and environmental considerations)
• the existing asset inventory e.g. systems, skills, services (it is also a logical bridge to operations and costs)
  
• known issues and constraints e.g. issues, risks
  
• key design standards and preferred practices e.g. standards, patterns, template

Sadly few organisations have a mature EA processes, and it is if anything less mature than the processes which it should be key to co-ordinating e.g. those associated with requirements, business cases, development, operations.

Requirements management - further thoughts

(based on various discussions)

The focus is on requirements capture and working with business people that can lead as quickly as possible through to contract acceptance. The requirements will be capture in essentially the same way irrespective of how the solution is engineered (e.g. bought, customised, built/developed, assembled from an amalgam of bought/customised/built components). It is expect the requirements and the design (solution) will progressively elaborated (and related).

The model/reposiotory will:

• act as a hub or aggregator for many sources of data
• produce documents (word, PDF etc.) for different audiences often document unique to a time, purpose and stakeholder
• allow access to authorised users, any time/any where, via a broswer
• allow visual modelling and analysis
• allow requirements to be elaborated in design oriented modelling techniques as and where needed e.g. UML, ER, BPEL etc.
• allow requirements to be elaborated into acceptance and testing documents
• assign requirements to owners
• support requirements lifecycle
• support programme and project (e.g. allocate requirements to programmes, prohects, phases, SCRUM-sprints etc.)

Our approach to requirements management will record how Requirements relate to:

• Business drivers: goals, measures/KPIs, products/services etc.
• Business operations: interactions, functions, information, rules etc. (and will link to IRMs)
• Acceptance - criteria, plans, scripts, steps (repeatable, atomic, objective)
• Solution elements - as this allows us to understand impact and is the connection to work
• Programmes and projects - management and delivery work.

Our focus will be on Web portal interfaces, reporting (e.g. dashboards, PDFs, Word docs etc.), model analysis templates for requirements capture reporting now and the initial focus will be on 4 areas:

• Context - which will look at relationships in the context of business drivers and perspectives on business operation (communicate, do/function/process, decide/rules, know/information, technology feature)
• Acceptance - which will look at relationships elaborated through to Acceptance tests (more or less as per our Acceptance Management approach)
• Solution - which will look at relationships to solution elements (existing elements, OTS elements, developed elements, configuration etc.)
• Project - which will look at grouping e.g. into SCRUM lists; relationships to: Risks, Issues, Assumptions, Constraints, Changes

To start with I will focus on the top two areas and in short term I won't look at connection to an IRM, estimation etc. or data collectors, data extractor, or linking to other sources e.g. bug tracking (JIRA), document repositories (e.g. Team Rooms etc.) as this should be simple enough to add in due course.

Some properties that we will record about requirements are their: State/Lifecycle, Owner, Priority etc.

The expected use of the different elements of the solution:

• Web portal interfaces - are expected to be the main source of capture and review by most of the people on a project. [using Troux Explorer, Workflow]
• Reporting (e.g. dashboards, PDFs, Word docs etc.) - will be typically how information is presented (i.e. reports generated from the model/repository) [using Troux Intelligence]
• Collectors - will collect bulk information from existing electronic information e.g. XLS (Visio etc.), Idiom, Lattix etc. [using Troux Collectors]
• Extractors - will provide information for other systems [using Troux API]
• Model analysis templates - will mainly be used by power users for analysis, or for presenting diagramatic views for selected audiences and purposes [using Troux Architect]

Requirements management - some thoughts

(work on requirements management solutions)
[WIP]

I am focused on requirements for ICT systems in general.

There are a number of constituencies that need to be considered - i.e. people with different orientations. Their views need to be considered as they will provides insights into how requirements should captured, though the orientations are in technology domain not in the requirements domain e.g. :
- Functionally oriented - much development done in the 1970/80s was oriented around functional definitions of requirements
- Data oriented - who are focused on data models and databases
- Object oriented - as many modern general purpose development languages are OO
- GUI/Web oriented - as the systems is often defined by the UI, and RAD approaches are used for this
- Business process oriented - where workflows to define systems
- Business rule oriented - where business rules are key to defining systems
- Service oriented - where the systems are defined by their SI (systems interfaces) and orchestration.
- MDA oriented - where the goal is code generation via platform indendent models
- Microsoft oriented people - where the goal is code generation to a proprietary platform (i.e. with no platform indendence)
- Mobile oriented
etc i.e. there are lots of religious sacred cows in this area.

An approach to requirements management should demonstrate how Requirements relate to:
1 - How the business operates (interactions, functions/processes, information/data, rules, roles/parties) which will be the real world test of fit. This also allows industry reference models to be linked in.
2 - How the requirements are elaborated into definitive acceptance tests/scripts (repeatable, atomic, objective). As these are an expression of requirements.
3 - The solution and its solution elements (screens and/or UI elements, interfaces, reports, queries/searches etc.). As this allows us to understand which elements of a solution are affected by a change in requirements, and which elements are required i.e. expected to meet a requirement.
4 - Project management and delivery work.

What I am interested in is pure requirements capture that will work with business people - and can lead through to contract acceptance (irrespective of how the solution is engineered e.g. bought, customised, built/developed, assembled from an amalgam of bought/customised/built components).

Clearly the various ways of specialised modelling e.g. data modelling, object oriented modelling (e.g. UML), BP modelling, RAD/UI prototyping, etc. are useful. But they are design and designer oriented.

The requirements and the design (solution) is progressively elaborated and we need to avoid a gestalt problem e.g. where the "requirement" is defined using a "technology oriented language" e.g. referencing "objects" - when in fact the solution the implementation technology/strategy may not yet have been fixed. To use a non-IT example - if the technology was "masonry" - and mason may say an "arch" needs to be built, or a "lintel" installed - where are what is required is egress or access (perhaps a doorway).

The requirements management solution must:
- act as a hub for many sources of data (e.g. from many specialised modellers)
- produce documents (word, PDF etc.) for different audiences often document unique to a time, purpose and stakeholder
- allow access to details by any authorised user, at any time, from any where, via a broswer
- allows visual modelling of requirements
- allows requirements to be elaborated in design oriented modelling techniques as and where needed e.g. UML, ER, BPEL etc.
- allows requirements to be elaborated into acceptance and testing documents
- assignment of requirements to owners
- supports analysis of change over time, impact assessments
- requirements to project management (e.g. scrum concepts - to Product Backlogs, Sprints etc.)


RHE has invest a lot of time and energy in exploring most of the methods related to the various delivery technologies list above. RHE has also invested a lot of time and money in looking core enabling technology platforms that would enable a requirements management