How was Training?


“The experience was very good. Questions were answered succinctly, discussion and examples were intertwined with presentation to clarify materials.” - Senior IT/Change Management Consultant, Lynn Kubeck & Associates, USA, Apr 2013

Recommend PEAF?


“Yes - It presents a good frame of reference for beginning an EA program in an organization.” - President, Future Tech Systems, Inc., USA, Feb 2015

Although Enterprise Architecture has more to do with Strategising and Roadmapping than Project Execution, EA still has a role on projects and that is one of Governance & Lobbying. Since much damage can be inflicted upon an Enterprise by how Projects Execute, EA also has a remit to make sure the relationships in “projectland” work together cohesively.

Any project today tends to be run with three key roles:

¨      Project Manager

¨      Business Analyst

¨      Technical Analyst

The names may change from Enterprise to Enterprise or from country to country but broadly speaking these three roles exist. The table below considers the different viewpoints of these roles:





Business Analyst

Functional Fitness for purpose

Functional Requirements

Changed processes and provision of a functional capability.

Technical Analyst

Technical fitness for purpose

Non-Functional Requirements

Operating hardware and software

Project Manager

Project Budget and Deadlines

Project Plan

Completed Project


Functional Requirements

The Functional Requirements define the functions the business requires the solution to perform. It is the job of the Business Analyst to document these requirements by talking to the business and understanding what the business requires.

As the project progresses it is the Business Analyst who is responsible for making sure these requirements are met.

They own the project from the functional point of view.

Non-Functional Requirements

The Non-Functional Requirements define more qualitative requirements (e.g. Performance, Scalability, Availability, Reliability, etc.) that can often be overlooked, but are the requirements that can impact a solution in terms of cost but also in terms of viability. It is the responsibility of the Business Analyst to define these by discussion with the business and support from the Technical Analyst.

As the project progresses, it is the Technical Analyst who is responsible for making sure these requirement are met.

They own the project from the technical point of view.

Project Plan

The Project Plan defines the work required to be undertaken and the order and relationships of those tasks. The initial high level plan is usually put together by the Solution Architect while the options and solution was being formulated priors to the implementation project starting. The detailed plan is (should be) formulated by discussions with the BA and TA regarding what detailed tasks need to be undertaken and the time and resources required for those tasks.

As the project progresses, it is the Project Manager who is responsible for making sure these tasks are done.

They own the project from the resource, timescales and budget point of view.


In the traditional model, the relationships at project level are usually dysfunctional in a lot of Enterprises.

In spite of these dysfunctional relationships (which is at the expense of the Enterprise as a whole) things tend not to change because the people with the power required to change them are usually the ones that are incentivised to perpetuate them.

The BA and TA “report” to the PM, with the PM being “in charge”. The PM’s voice is the loudest and tends to overrule the BA and TA most of the time. This creates fundamental and important (negative) implications, but since the PM is not measured on any of them, he doesn’t really care. And why should he, if that is how he is driven. This is normal and understandable, because everyone agrees that most projects these days run over time, budget etc, etc and therefore we need a “good” hard PM to keep everyone in check and make sure the project hits its budgets and timescales.

It is strange therefore that given this structure most projects fail.

The truth is that while this “power structure” is imposed to ensure projects complete on time and on budget, it is precisely this structure that causes them to fail.


In the Pragmatic model, the relationships are much more cooperative.

¨      It is wrong to say that the Project budget and deadlines is more important than the Functional fitness for purpose or the Technical fitness for purpose.

¨      It is wrong to say that the Functional fitness for purpose is more important than the Project budget and deadlines or the Technical fitness for purpose.

¨      It is wrong to say that the Technical fitness for purpose is more important than the Project budget and deadlines or the Functional fitness for purpose.

Each is as important as the other in contributing to a successful project.

The Pragmatic way to run projects is not by some arbitrary choice of who to “put in charge” but by operating a partnership between these three key roles, which operates much like the cockpit crew of an airliner. In the airline industry it is known as Cockpit Resource Management, so perhaps Enterprises should begin talking more about Project Resource Management, although, that phrase could easily be misinterpreted as just telling people what to do - which is exactly the opposite of what it needs to be!


What structure do you use to run projects?

Does it create any problems?

If so, what do you need to do to solve them?



◄◄◄ Previous Page          

          Next Page ►►►


© 2008-2016 Pragmatic EA Ltd