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. The
names may change from Enterprise to Enterprise or from country to country but
broadly speaking these three roles exist:
The Business Analyst is
accountable for the Functional Fitness for purpose, takes Functional
Requirements as input, and produces a Changed processes and provision of a
functional capability as output.
The Technical Analyst (many times
called the Technical Architect) is accountable for the Technical fitness for
purpose, takes Non-Functional Requirements as input, and produces a Operating
hardware and software as output.
The Project Manager is
accountable for the Project Budget and Deadlines, takes a Project Plan as input
and produces a Completed Project as output.
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
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
It is wrong to say that the Functional fitness for purpose is
more important than the Project budget and deadlines or the Technical fitness
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
Each is as important as the other in contributing to a
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!
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.
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.
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.