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.

Improving solution architecture by reducing the need for archaeology and being clear on requirements

I want to start with a simple analogy to avoid the scope for erudite excuses I hear so often from practitioners in IT. The reality is with new classes of solutions a very small change by each party can produce a dramatically different outcome.


Building - something we all know and understand
When a change is required to a building (or any complex technology) there are 4 things to consider when we are doing the high level design (e.g. the level of design done by architect):

1. how things should be built. For a build the building codes and regulations which indicate what things such as: technologies (products, materials) can be used for what purposes and in what way (patterns, best practice, standards, etc.) and; various other constraints re how the new building should relate to other existing, or future, elements in the environment (how it should connect, that it should not obstruct etc.)
2. what exists - For a build what existing buildings, infrastructures, common services, etc. exist (in just enough detail to know how they will be impacted, which is typically a lot less detail than is required to construct them i.e. we don't need to know where every nail or bolt is placed or necessarily where every detailed element exists or why).
3. what the requirements are. For the new building. what products and capabilities it should enable, what it should enable to be done (e.g. functions and processes it should support), what it should store, who should be able to use it (roles, positions, types of people), what characteristics it should have (secure, efficient, safe, etc.), budgets and key dates etc.
4. what will be delivered. For a building. a high design can be created that determines what is to delivered (built or bought) and how. It doesn't need to determine the placement of every building element - just sufficient to be clear what is to be delivered, how it relates to what exists, what requirements it meets (for the client) and that it will code with key codes (for the town planner). Most of detailed engineering designs necessary for constructions are done at follow stages by specialised engineers, designers and trades.

With buildings.
Town planning function aims to ensure:   a) how things should be built is clear
   b) what exists is know - so archaeological for new projects is minimised.
   c) what is built is recorded - so future archaeology is not required.
Architects aim to convey   d) what they understand the requirements to be
   e) what is to be delivered (for the client)
   f) how what is to be delivered meets the requirements
   g) how what is to be delivered relates to what exists
   h) that what is to be delivered is compliant with standards and codes.

Fortunately with building few town planners were once carpenters, who became architectures and then became town planners - and each level is relatively clear on its responsibilities, methods and tools.

IT - something we all know and understand doesn't deliver well.

When we look at changes in IT systems or businesses themselves we need to know the same things.

1. how things should be built e.g. what: technologies can be used for what purposes and in what way (patterns, reference architectures); other constraints re how the new elements should relate to other existing, or future, elements
2. what exists e.g. existing infrastructures or common services exist (in just enough detail to know how they will be impacted, which is typically a lot less detail than is required to construct them - i.e. we don't need to know where every nail or bolt is placed or necessarily where every detailed element exists or why).
3. what the requirements are e.g. products and capabilities enabled, functions and procesess supported, information stores, users (roles, positions), characteristics it should have (secure, efficient, safe, etc.), budgets and key dates, etc.
4. what will be delivered - a high design that shows is to delivered (built or bought) and how. It doesn't need to determine the details of every element - just sufficient to be clear what is to be delivered, how it relates to what exists, what requirements it meets, and that it will code with key codes. Most of detailed engineering designs necessary for constructions are done at follow stages by specialised engineers, designers and implementation specialists.

With IT.
Enterprise Architecture aims to ensure:   a) how things should be built is clear
   b) what exists is know - so archaeological for new projects is minimised.
   c) what is built is recorded - so future archaeology is not required.
Solution Architecture aims to convey  d) what they understand the requirements to be
  e) what is to be delivered (for the client)
  f) how what is to be delivered meets the requirements
  g) how what is to be delivered relates to what exists

  h) that what is to be delivered is compliant with standards and codes.

Unfortunately with IT many of enterprise architects where once are software engineers, who became solutions designers then became enterprise architects - and each level is not very clear on its responsibilities, methods and tools.

To complicate things further in a complex enterprise there are many initiatives operating in parallel and what is required to ensure all the changes fit together is a canonical view (common to all) or the things the requirements relate to: products, capabilities, functions, information, roles, positions etc.  So steps d & e need to allow all to understand overlaps and possible conflicts as early as possible.

How it can be done better With modern EA/EPM solutions the basis is provided for recording:
  a) how things should be built - standards and patterns
  b) what exists - so archaeological for new projects is minimised.
  c) what is actually built - so future archaeology is not required.
  d) what is requirements -

       by all projects and a specific project (explicitly related to a canonical view of the enterprise)
  e) what is to be delivered (solution architecture) can be clearly seen as a set of elements. 

      by all projects and a specific project (explicitly related to current assets and future assets).
  f) how requirements map to solution elements
  g) how what is to be delivered relates to what exists
  h) how what is to be delivered is compliant with standards and codes.

One can see from this that critical to improving how solution architecture is done - and minimising the need for archaeological efforts in this work is improving the recording of a to h. It requires a holistic view that sits above several streams of activity that are frequently siloed. Traditionally: EA has been strong on a, b but relatively weak on c. Solution Architecture has been weak on: d, e & f; Requirements teams have failed to relate their requirements to either a canonical of the business or its assets.

A very small change by each party can produce a dramatically different outcome.

Six keys to EA success

I recently read the six hereries for EA (www,eight2late.wordpress.com/2014/10/08/six-heresies-for-enterprise-architecture/). My thoughts follow

Distinguish between planning and design - The "self-referential" problems of EA extend past the frameworks to the practice and practitioners. This is because most of the have a background in engineering rather than planning (or architecture for that matter). By in large engineers create designs for engineers i.e. design practice to an extent is intrinsically self-referential. Plans are created for a broader audience.

Only consumption of a plan leads to value - The reason EA "rarely leads to anything of genuine business value" - is because too attention is paid to how the information can be consumed, acted on, etc - and the failure to realises the artefacts are not where the value lies.

Accretional rather than agile - What is required is an accretional approach. That is to say an approach where knowledge accrets. This is incremental, but has a different ethos to agile as applied in SW engineering i.e. where knowledge is transactional, transitory and related to a specific individual or outcome.

Virtuous feedback cycles - Planning assumptions and decision need constant testing and refinement. EA at present is too much like riding a bike, in a business city, with your eyes closed. You know where you want to get to and think you want know the direction. You close your eyes and take off. What you need to do is constantly assess knew information and adjust. The only way to get knew information is to apply the information you have, and this way have it tested and corrected. (see: www.enterprisesto.blogspot.com/2010/05/virtuous-circles-of-strategy.html)

Problem finding rather than problem solving - is great advice, but it is challenge for many who have a legacy as engineers or designers and secretly yearn to return to the comforting and satisfying realm of design i.e. solving problems.

Understand the social implications - is good advice, because the most of the impediments to EA are organisation and structural. (see www.ea-in-anz.blogspot.com/2008/07/focus-on-ea-is-inversing-proportional.html)

Demand and Requirements Management for Business Transformation

Demand and Requirements Management for Business Transformation

• the information relating to things in light blue stuff, at the top, are basically recorded in business architectures and asset portfolios solutions (i.e. they are canonical enterprise wide source)
• most of the money is spent on the green stuff - with the hope that it affects positively the light blue stuff
• sadly there is usually a disconnect between the light blue green 
• what purports to be the connections are created by lots of "consultants", "business analysts", etc. who create a plethora of persuasive, convenient, documents and presentations (essentially disconnected from the facts). 
• this disconnect militates against the real world value of business architectures and asset portfolios (which is why they are often rightly seen as ivory tower or academic exercises).
• that is to say that strangely in in most organisatons there is no source of record (canonical, complete or connected) for the darker blue boxes? 
• for most business the orange stuff is a necessary evil yet
• the approach to requirements is driven from engineer needs in the bottom right hand corner (on essentially a waterfall model)
• in an agile approach, which the only thing that can work, the information flows both ways
• (which is why the blue arrows go both ways i.e. as you define requirements in the context of existing views of capabilities and systems (i.e. business operational procedures, business assets etc.)
• you will discover things that are missing or need to be updated - which is good. That is because when you data you find issues with it and you improve it (this is what makes it non-ivory tower). 
• If you don't use the data in the business architectures and asset portfolios to actually make the changes happen who really cares about it - other than a few planners or startegists (when in reality it needs to be at the heart of business transformation)

BTM Decision Support - Agile Solutions

BTM Decision support solution — requirements 

Agility is key and there is a need to iterate rapidly through questions, answers ("art of the possible") and refinement cycles. 

Support the 4 common scenarios (see agile decision making for BTM ):

1. BTM tool experts to use tools to give the answers. In BTM these questions will arise often from many different people. They need to be answered quickly (an hour) with little effort (5-10 mins work)
2. End users experts need to get good enough answers for themselves (without recourse to an BTM tool expert). Of questions arising perhaps 20% will require this. Solutions need to be able put in place quickly (within an hour) with little effort (30 mins work)
3. Non-expert end users may want simple portal solutions with on-line analytics. Of questions arising perhaps 10% will require this. Solutons need to be put in place fairly quickly (a day or so) and with relatively little work (a few hours).
4. Non-expert end users may want simple task specific tablet/phone applications. Of questions arising perhaps 5% will require this. Solutions need to be put in place moderately quickly (a week or so) and with only moderate effort (a few days)

In all cases:

• the exact path through the labyrinth of data may be different for every question (and in some cases changes to the data model may be required on the fly). 
• the data may be presented in many different ways (report, diagram, chart, an interactive graphic etc.)
• the data may be captured and aggregated (from systems, people, models etc.) and it may be mechanism may be needed by which this data can be validated, maintained, trigger reviews, interrogated. etc.
• data access rules need to be applied to constrain who can see and change what.
• the solution used on a early scenarios provides a prototype for the solution to the next scenario

Our approach - we build our solutions on the world's best BTM/EPM platform and extend that so that:

1. BTM tool experts give the answers: we use dynamic reporting (which defined paths through the data); dynamic model templates; dynamic visualizations to support this.
2. End users experts get answers for themselves: we place the dynamic reports/analytics in a user accessible information portal to support this. 
3. Non-expert end users may want simple portal solutions with on-line analytics: we use sing a mix of  reporting/visualizations tools (using the data paths defined in early steps); dynamic portal configurations (navigators, layouts, workflows, etc.).
4. Non-expert end users may want simple task specific tablet/phone applications: we do this using a simple framework that re-uses the paths defined in earlier steps and some common extendable display templates.

Usually the data is reasonable well defined in the 1st two scenarios and the latter two scenarios are principally focused on supporting better interactions with the data and provider clearer insights.

Why many fixed OTB solutions fail:

• they make it too hard to change the data model
• they make it too hard to change the specific path through the data
• they don't provide interfaces for preferred device mix (PC, tablet, phone)

Why many flexible solutions fail

• they don't provide the full mix of output types (report, chart, diagram, interactive)
• they don't provide access control
• they don't provide mechanism for data aggregation, maintenance and integration

Agile Decision Making for Business Transformation Management

BTM method are immature and evolving

The fact is that BTM remains today as much an art as it is a science and consequently the methods used to support it are still evolving and maturing. 

Agility is key

People often have known unknowns and unknown unknowns i.e. things that, until they know more, they don't know they need to know, but don't know.

They will say things like "I we need to achieve this and I need to know more about that. But I don't know exactly what I want, but if you show me something I will be able to tell you if that is what I want, or if it is a bit different". 

This is why the "art of the possible" is important and the process to support decision making (and many other things) needs to be agile.

People need to rapidly iterate, through trial and error, until what is needed emerges. In fact the process may even be serendipitous. 

The real world isn't perfect but it is the one we live in


In the real world many ad-hoc questions arise and need to be answered in minutes (or within an hour). If the  stakeholder gets frustrated and can't get answers based on facts in these timeframes there is risk they will just guess (or go to someone who can make up an answer). These questions may only be only partially thought through, specific questions may never recur, and may change rapidly and iteratively as answers are provided.

Learning is about questions that lead to questions

You can see this even with a small child is trying to understand something. They ask question, which leads to another question and another and another. This is the process of learning i.e. intelligence requires iteration and agility.

Out of the box solutions provide a starting point - not an end point

Out of the box solutions for BTM decision support can only for the foreseeable future provide a starting point. They can't encapsulate definitive present best practice because best practice is inchoate and changing quickly as the industry as whole learns (unlike in relatively mature disciplines e.g. accounting, architecture, personnel management, etc.)

OTB solutions provide an idea of the "art of the possible" - but it is critical that they not seen as the way things must be done i.e. cast in stone. 

As it is inevitable that the questions asked will evolve, it follows that the data required (to answer the questions) must evolve, and the ways in which information is presented (and captured) will evolve. It is enabling this evolution which is critical and it must start with the data (if one things of a model, it is the metamodel).

Four BTM Decision support scenarios

1. Expert answer specific questions for specific users - Ad Hoc questions, needing quick answers, arise all the time. They may be the wrong questions (they may never be asked again). They need to be answered quickly and people will come to an expert is necessary to get an answer e.g. a specific report, number, chart, diagram etc. In answering these question it may be necessary to analyse or present data that is currently not recorded (so data model/metamodel changes are needed).

2. Expert user can get answers themselves - a small percentage of questions that arise will want to be asked and answered fairly often. People will want to be able produce the answer themselves e.g. a specific report, number, chart, diagram etc. It may require some expertise, but it doesn't require an expert.

A small percentage of questions from 1/2 will be of use to many users often (users with no specific expertise or knowledge).
3. Expert solution with generic tools - In some cases generic ad-hoc analytical tools, dashboards etc. may be able to be used to create answers
4. Expert Customised solution - In other cases highly customised and optimised user interfaces and analytics may be required e.g. for tablet, phone and watch interactions (with voice activited interfaces, continuous data collection etc.)

Let us take a non-BTM related every day example - how is my heart health

1. Expert answer specific questions  - I go to an expert to get my blood pressure checked, my blood tested etc. These tests may lead to others depending on what the answer are. In the following I just focus on one path (blood pressure)
2. Expert user can get answers - I want to monitor my blood pressure daily and track it
3. Expert solution with Generic tools - I can dump my blood pressure results into a spreadsheet and chart/analyse them

4. Expert customised solution - I have phone based application that monitors and records by blood pressure, sends alerts, and analyses the results (and compares with my diary, my diet record) presenting results on my phone or tablet - when I ask for them

BTM Decision support solutions.

They need to support all 4 scenarios and allow rapid evolution from one stage to the next ideally reusing information and solution elements from earlier stages.

1. Expert answer specific questions - solution needs 5-10 mins work with hour turn around

2. Expert user can get answers - solution needs 10-30 mins work and 1-2 hour turn around

3. Expert solution with Generic - solution needs less than an hours work and 1-2 days turn around 

4. Expert customised solution - solution needs a 4-24 hours work and 5-10 days turnaround (and results in an asset)