Silo behaviour in large organizations militates against agility

At present in large organizations the different functions are usually in silos that don't talk to each other, and don't really care about other. They seem to forget that often what they do is of little value unless it is related to things other do - but they operate in silos.

For example:

• the people who do process models are not the people who do capability maps (which the processes are presumably to enable), 
• different people again may do information models (to describe the information to be used by the processes and support organization's knowledge goals)
• another group manage the application portfolio (which is to support the processes and capabilities, the data etc.)
• another group are responsible for "business analysis" which should relate to processes, capabilities, information etc) 
• another group manage projects (which will affect changes to process, capabilities, applications etc.).

Each group focuses on optimizing how do things for their specialist audiences (who develop increasingly specialist and arcane needs), but the reality is that no matter how well each silo operates it is of no value unless well integrated into the whole. 

It is not that it is of a little less value, it is really of almost no value to the organization. So each silos attempt to excel only benefits the individuals involved, their CVs, their personal satisfaction, etc. 

There needs to a Maslovian hierarchy of needs for these areas - where down the bottom is - who well integrated is what I do with what others do. 

Lightweight Portal based Visual Modelling using Troux

Lightweight Portal based Visual Modelling using Troux

We have developed a simple framework using Troux APIs and a graph path based approached to data to support simple visual modelling. This allows data in a Troux system to be presented to any user using essentially any device (e.g. mobile, tablet, Mac, PC etc.).

We have Troux an excellent solution for aggregating, analyse and present data in many ways. 

Our focus over the last decade has been on creating Troux based solutions.  In doing this we have found ways to unlock more value from data held in Troux, provide users additional ways of interacting with that data.

Our approach ensures that common data is used for all forms of presentation i.e. models, reports, charts and visualisations. This means that set of documents used in project concept and delivery are always consistent. 

Any path through the graph of related objects can be defined and presented without any need for coding (i.e. no XML configurations). Paths can be used to generate: models, reports, analytics, digarams.

There are many BI tools that allow data to presented, charted etc. (and all can be used to access data in Troux). Most adopt a tabular approach to the representation of the data (which is limiting when n-dimensional relationships need to be visualized).

Our frameworks focus predominantly on allowing information to be understood in context by enabling various diagrams or models to be to generated or defined. These diagrams may be: timelines; flow charts; cluster maps; graphs; etc.

Diagrams and visualisation can be configured by users and saved as templates for re-use.They can be presented in stand alone portals or via Troux portals. 

The visualisation framework is device agnostic and oriented at HTML5 browsers. 

Archimate in Troux

Using Archimate for Architectural Design in the Troux Portal and Troux Modelling client.

When designing for an organisation and as part of team it is useful to record and communicate why the design is as it is. We can record through the design process, as and when we see fit, how the solution relates to: requirements, decisions, features, standards, patterns, reference models, etc.

The technical and business architecture of an organisation provide a logical reference point for new solutions. It is particularly important to be able to anchor proposed changes (e.g, new solution elements) back to these when several initiatives are operating in parallel - so all expected changes can be seen and related. We can also relate the design tp the existing assets and items managed in portfolios.

We can analyse and track development of the solution.

EA and F1 - share at least one thing in common

I follow F1. I saw this comment today

"One of the keys to solving a problem is admitting you have one and then working as a group of people to understand it"

http://www.espn.co.uk/f1/story/_/id/13453746/the-key-solving-problem-admitting-one-rob-smedley

How I wish all the EA's and IT Executives would admit that they have problems that need to be solved. These problems don't impinge on most of the individuals happiness or ability to earn a living - but they dramatically reduce the cost and value effectiveness of large organisations. The duplication and inefficiencies please all the vendor community - who can sell more products and services than should ever be required, and the only real losers are the shareholders.

How we use EA to support the path from strategy to execution

In previous items we have discussed the problems with the gap between strategy and execution. We will now have a quick look at the problem and solution.

The problem is largely that the information is tied up in documents associated with a silo view of activities.

To make matters worse this set of documents takes a lot of work to create and includes things that are highly connected. So firstly when done manually it is extremely difficult to do well, very tedious to try and analysis (e.g. or completeness etc.) and soul destroying to try and maintain. This usually means it is poorly done. It also looks a lot of work - where the size of each ellipse below is an indication of effort

However by having the information in a common shared repository we can manage all the information failing easily, produce all the documents, and we actually do real analysis. When we look at each document we realise that there is a very overlap,

So we can substantially reduce the effort required i.e.

And we ensure integrity, we can reuse data from other sources explicitly and we do the analysis that is really needed

To provide other adhoc ways of understanding relationships we can use our SoA extensions to make the information paths available via standard BI tools, or via graph databases so that connections can be examined.

Requirements management needs to be done better - no kidding Sherlock

PMI Pulse of the Profession - on Requirements Management - https://www.youtube.com/watch?v=dSKbnNjrB1Q&feature=youtu.be . The good news is that the PMI doesn't - like most discussing requirements - orient everything around SW requirements management. And they clearly state there is a problem:

• 1 in 3 projects unsuccessful
• Poor requirements management is a major cause of project failure
• There is shortage of research on how to approach requirements management.

PMI defines Requirements Management as:

• Planning; Monitoring; Analyzing; Communication and Controlling Requirements
• a continuous process throughout a project

PMI says are Business Analysis:

• to be good an business analysis you need to be good at managing requirements
• it involves determining/identifying problems/needs; identifying viable solutions to meet the needs; managimg requirements to meet business/project objectives

PMI says re skills:

• the gap is not in technical skills
• you need to:
• interpret, align and articulate requirements related to the strategies [e.g. Goals, Strategies in EA]
• deal with ambiguity [which I suggest starts with identifying it - hence our unanimity score]
• communicate to many stakeholder i.e. not just developers [which I suggest is ill-served by the technician oriented artifacts, or loose narrative documents, typically produced  today]

Processes: 87% say improvement are required
Competencies: the need for competencies is recognised, but they just do it. Some areas include:

• ensuring solutions meet business objects [you would think it would be a good place to start with links to the goals, measures, KPIs etc. held in EA]
• identifying current and future states [which are also recorded in an EA]
• quantifying effort for requirements work [e.g. see our effort to elaborate properties]

http://www.federaltimes.com/story/government/management/blog/2015/06/25/managing-federal-acquisition-procurement/29266775/ - said on a related items:
- improving systems acquisition starts with improving requirements definition during program planning

Different languages and models for different purposes

Organisations, and individuals, operate in certain ways and the assets owned and used (we could choose to call these things their business architecture and their technology architecture). They need to manage and maintain their various assets to minimise e.g. cost, risk, etc. To manage these portfolios of things effectively they need to know what they are and if there are many of them be able to analyse them effectively.

They also have demands to change and make things better (i.e. transform and optimise). These demands necessarily relate to how they operate (i.e. changes to how they operate) and own (i.e. changes to what they own and use).

When an initiative(s) (e.g. a project) is put in place these demands are expressed as requirements and for a period a abstract view of future assets is described in designs and the elements of solutions (and how they relate). These requirements and designs are transitory, and specifically the level of detail they go to are transitory. They need to be able to relate to existing assets and ways of operating so the exact affect of desire change is clear.

When the initiative(s) are complete these requirements and solutions effectively cease to exist in the transition form used in the transition. At the end of the initiative and what remains are way things are done and the assets owned and used.

This sounds facile, why does this matter?

 It matters because we need to understand that we need to be able to manage:
a) the business and technology architecture
b) be able to define requirements and designs in the context of the business and technology architectures.
c) that we may used different models and languages for describing things e.g. we may use a different language, terms and concepts when we design a building vs when we own, used and operate a building.

I use the analogy of a building above because the average person is more familiar with a building and because therefore less easily mislead (as Dawkins's law of obscurantism is rife in IT). The reality is that designers need design languages and details to perform transitions e.g. Archimate is really a design language i.e. it is not oriented at the management of large sets of assets or holding comprehensive views of how business operate i.e. the business or technology architecture - but it needs to be to relate to these. Just as an architect needs to be able to relate his designs to the level held in the town plan and the property managers portfolio view - but his design views are not town plans - and different languages and models may be used.

Further - to summarise what I said here (http://enterprisesto.blogspot.com/2013/10/what-is-ea-and-what-is-epm.html)

Royal of Academy of Engineering and British Computer Society identified:

• "there is a broad reluctance to accept that complex IT projects have many similarities with major engineering projects and would benefit from greater application of well established engineering and project management ..."
• "a striking proportion of ... difficulties stem from people ... failing to implement known best practice. This can be ascribed to the general absence of collective professionalism in the IT industry..."
• "...  problems relate to the people and processes but further in developments in methods and tools is required to support the design and delivery ..."

No one it their right mind would suggest that the same tooling, modelling and language for:

• Portfolio Management - is not about design (it is about economics).
• Planning - is not about design either. it is about having view of the future at different points in time and mapping out, usually broadly, how to get make these views reality.
• Standards Management - is not about design of any specific solution it is about saying what we should build with and how we should assemble
• Enterprise Architecture - is about the design of enterprise and has fluid relationships to the extant, but it is not about design solutions or engineering.
• Solution Architecture - is about design, though not really about detailed engineering or construction and need to apply languages like Archimate.
• Software Engineering and  Systems engineering - are about design and need to apply languages like UML.

See also http://ea-in-anz.blogspot.co.nz/2007/09/ea-and-analogies-with-built-environment.html

Inferring purpose from artefact

I am often presented with an artefact that is has been created at some stage to address some problem. Inferring the purpose of the artefact can be difficult. What is amazing is that often the people creating artefacts have only vaguest idea of its purpose e.g. for whom, to do what, when, why etc.

It is a bit like someone showing you Stone Henge and expecting you to know its function is to tell the time.

And you are meant to work out they want to tell time.

Or being shown an ancient Pesian bowl and expecting to know they want to tell time

Or being presented with a grand a complication and being expected to know its function is similar to the above.

And you are meant to work out that they want a chime on the quarter hour.

In all cases they may really want something else entirely e.g. they may want a ceremonial assembly point, a lovely ceramic or a beautiful items of jewellery. The real point is that it is very difficult to infer purpose from an entity.

So you need to try and look as clearly as you can at what you want to achieve, rather than assuming what is wanted is a replacement for a current artefact.

http://enterprisesto.blogspot.com/2013/08/technology-architects-need-to-realize.html
http://enterprisesto.blogspot.com/2010/03/artifacts-vs-business-results.html

PMO Best Practices have never been effective enough for large enterprise transformation

I recently saw this: PMO Best Practices Are No Longer Good Enough. I had high hopes, but it identifies some issues - but fails to identify the real issue or the real solutions.

"... study after study concludes that investments in traditional PPM fail to deliver the
anticipated results ",

".. companies who are failing to realize the planned business value from project portfolios are facing three main problem areas – Annual Planning, Project Success Rates and Budget Utilization."

Failure to be clear about exactly what projects are doing - gaps, overlap, conflicts - as things change over time is the real issue. So yes "annual" vs continious is an issue and "success rate" are a problem - but more accurately tracking how quickly money is going down the drain, or identifying more money that can poured drain-wards isn't the answer

"... annual planning ...the business case for each investment often includes unreliable estimates. ... Unless those decisions are revisited throughout the year  ..."

This hints at the need for agile and continuous planning - but fails to recognise the need for agile managements and consider what information is really needed for continuous planning and management. As projects proceed they proceed from relatively vague understandings to very explicit undestanding - the real question are how is this knowledge captured and used.

"- ... Reliance on inadequate software tools is often the reason companies fail to successfully integrate investment planning and controls into the overall PPM lifecycle. Excel ... disconnected, difficult to govern and prone to hidden input errors; ERP ... great for finance teams not for PPM teams; Project Management Tools – strong at execution-oriented project and resource management capabilities ... "

Yes, but the issues lie above all of these. The issue in defining the details of scope and impact. The PPM tools/teams fail because the paradigm is flawed.

"... one thing is certain ... the days of “set it and forget it” are clearly over."

If only people got that it would be a start.

"... enterprise-focused PMO ... continuously evaluating the portfolio throughout the year.."

This will fail if PPM people continue to treat projects as black boxes and have no real ability to see with and across them to the details of the demands they address; what they deliver; and how they affect the business. They do this because PPM/PMO practice is based on a construction industry model which is a bad fit to business transfomation.

Dynamic planning requires dynamic understanding; and relies on dynamic management.

The issue isn't how to better ensure money is spent. The issue is how to better ensure that the set of projects as a whole produce the business outcome desire. This needs to start with an understanding that:
- Projects are artificial constructs managed in ways unsuited to enterprise transformation (see http://ict-tech-and-industry.blogspot.com/2008/08/projects-are-artifical-constructs.html)
- Classical project management fails in enterprise transformation - http://enterprisesto.blogspot.com/2014/01/why-classical-project-management-fails.html
- Complex transformation requires better ways to manage complexity - http://ea-in-anz.blogspot.com/2007/11/need-to-manage-complexity-better-in.html

Fortunately using a combination of a set of disciplines Semantic Precision has developed solutions that address the real issues.The approach involved a confluence of methods from: project and portfolio management; solution design management; requirements management; business architecture; enterprise architecture.

Plans and Strategies and the weakest link

Plans and Strategies are only really useful if they executed to produce the intended outcomes

To support strategic transformation and optimization three things are required:

1. Strategies and Plans: that can be demonstrated to be: based on facts (or explicitly stated testable beliefs) and produce the business outcomes desired if effectively and coherently executed.

2. Coherent orchestrated execution: so that the set of changes taking place within the various silos of activity are orchestrated as a set so that gaps, overlaps and conflicts are identified and resolved.

3. Agile and adaptive: that is the ability to adapt as changes occur to the facts, the beliefs or other circumstances. Often as a result of discovery during the execution activities themselves.

An issue with how things are usually done at present in business and IT transformation is that there is an ugly document layer that exists between what are typically two precisely modelled (i.e. sets of explicitly related concepts) layers. 

In this layer documents like: Project Definitions (Charters, SoWs etc.), Requirements Documents, Solution Design Documents (SAD, etc.), DR/BCP Plans are produced manually. This is time consuming, often obscures root cause analysis, and the artefacts themselves are seldom suited to most the audiences that are presented to (because most are only interested in a small subset of the information contained within them) and can't easily be maintained (or verified).

They are not explicitly connected to the layer above and provide no hooks for explicitly linking to the layer below. They provide scope for fictional narratives that executives, business stakeholder, et al may be persuaded to believe by the silver tongued.

We offer solutions that allow the middle layer to also be modelled (i.e. treated as data). The documents become reports. As they are reports it is easy to produce subsets specifically tailored to different audiences.  The contents of the documents (goals, requirements, solutions, milestones) are explicity related to each other and to the concepts above. Then they can be analysed (e.g. impact, overlap, cost, complexity, risk etc.) and the data managed (i.e. as change occurs over time). This allows agile approaches to be adopted while maintaining the integrity, coherence of the information and allowing the impact of changes (from bottom or top) to be understood in context.