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