My long-term readers know that I function as an enterprise architect and project manager (but not both simultaneously) and that I have taught (and continue to teach) project management courses at the university level for over 10 years.
Over the years, there has always been a measure of uncertainty and in more extreme cases, distrust of project management by EAs when applied to enterprise achitecture efforts. As I reveal later in this post, I find this situation to be unfounded in most cases, provided that certain conditions are met and adhered to by all parties involved.
Principle #1: Enterprise Architecure is a Function of The Business, Not a Project
Enterprise Architecture is currently undergoing a metamorphasis from a solution-oriented, IT-centric function to one that serves the entire business, including strategy and execution well beyond IT and IT solution delivery. While these changes will take a fair amount of time to fully realize, suffice it to say that EA will eventually morph into a department or division of organizations in their own right - organizationally independent of IT departments and divisions.
As such, certain functions of an independent EA organzation are not project-based, as certain other business and IT functions (accounting and network operations, for example) are not projects, but on-going operations.
Principle #2: Enterprise Architects Are NOT Members of IT Project Teams
Two of the scariest proclamations about EAs and IT project teams that I've seen over the years are:
- Enterprise Architects should know how to write code (or have done so in a previous life)
- Enterprise Architects should be members of IT project teams
There are no studies, laws, regulations, or proclamations that decree that EAs should be (or have been) software developers in past jobs. Enterprise Architecture is not about writing or specifying software code or systems - it is about architecting optimized business processes and systems based on management's strategies for the organization. While software development certainly has its place in organizations, that is an IT function best left to IT and more IT-specific solution, data, and information architects (who are not, by the way, enterprise architects - even if the organization calls them such).
Since EA is evolving away from IT-centricity and IT project teams, it doesn't make much sense to make them members of IT project teams. However, it may make sense for IT project teams to utilize EAs as subject matter experts - who are advisors and give guidance to specific projects, but are not members of the specific teams OR responsible for any of their scope, timeline, or deliverables.
Principle #3: Enterprise Architects are Accountable for Scope, Deliverables, and Timelines for Major Bodies of Enterprise Architecture Work
Although Principle #1 above states that EA is a function within organizations - and optimally realized in practice as a department or other organized body in its own right with its own direct management, it is not immune from organizing major bodies of its work output as projects. Although the EA department or group may be persistent, its scope and subsequent work activities and output are not. Oftentimes, these activities and output are unique both in terms of the type of work performed and the results achieved - which fits the commonly accepted definition of projects - temporary endeavors to create a unique deliverable or outcome.
EA, like every other business function, must also prove its value to the organization, and not only at the end of the effort. Organizational sponsors of EA efforts must be reassured on a continuous basis that progress is being made and capital funding the effort is being spent prudently. Such assurances usually cannot be made on an ad hoc, verbal basis for very long. These various metrics are going to have to be proven on a consistent basis.
Finally, this principle applies to EA-specific efforts, not to those the EA group lends experise or assistance to with no formal, defined role in those efforts.
Principle #4: Certain Enterprise Architecture Activities are Project-based, and are Managed as Such
Some EA bloggers and twitterers show outright disdain for project management for various reasons. While that is unfortunate for whatever reasons they have, it does not relieve the organization or the EA function within it of its obligations in managing all standalone enterprise architecture projects in a prudent fashion. The old adage "you cannot control what you cannot (or don't) measure" applies to such EA efforts as it does to any of the organizations' other projects in every department or division.
What this means, in general, is this:
- All EA efforts that have project characteristics (temporary effort of significant duration, unique product developed, substantial financial outlay and risk) are best managed as a project, with a project plan, timeline, budget, and...surprise...a project manager.
- The detail of project plans suporting these efforts, while largely situational, must be coherent and detailed enough that management funding the effort can get information on project progress, timeline, risk, budget, and performance easily. A judgement must be made on how much information about EA projects is relevant, when it must be updated and communicated, and what the risk scenarios are for the project. It is generally a mistake to either: follow an established project methodology (i.e. PMBOK) down to uneccessary and irrelevant detail; or call the project "Agile" with the intent of winging-it-as-we-go-along (which is what I have seen on a lot of projects proclaiming themselves to be 'Agile').
- Project managers involved in these works are managing the project and outcome/deliverables, not the EA team directly. If management intervention is necessary at some point, it is done by EA leadership, not the project managers (although the project managers may have input into such situations).
- A threshold must be established on EA projects where project management is required. Efforts that take a week to, say, a month are generally off the PM radar screen. Longer than that, or with substantial sums of capital being deployed make these issues more important and the ability to communicate status and issues to project sponsors and management is essential
I have remarked previously that enterprise architecture efforts and project management are often complimentary disciplines in many respects, not diametrically opposed to each other. If both groups appoach EA projects as a collaboration with agreement on scope, measurement, reporting, and other project nuances agreed to in advance and consistently applied/maintained, the sides should not only find the relationship satisfactory, but very benefical to both - as well as to the organizations they serve.
