Should Enterprise Architects be involved during Project Implementation

There's always going to be natural tensions between enterprise architecture and solutions/project architecture, there's possibility EA needs to be more interactive in PPM & PM level when necessary. 

Although EA focuses on conceptual and design level, project implementation is at the more tactical level, the EA team can find itself getting dragged into project issues for sure, often between the technical delivery team and the business stakeholders over requirements & governance issues. It's not always easy to strike the right balance. But for improving overall IT project success rate (statistically 70% of projects fail to satisfy customer), EA needs to become such progress advocate:

• EA governance involvement can vary by projects, something which is business-critical might prompt the CIO (who may, in turn, have been prompted by others) to insist that there are regular meetings between the project team and EA people to "keep an eye on it." Generally, enterprise architecture doesn't run projects themselves, and so rely on projects as 'vehicles of activity' which continue to move towards that future state. 

• EA as a collaborator than a controller: If the EA group is given the impression that they are a controlling force rather than a collaborative group, that works with the project teams to foster the tension between the groups. Measure the EA team based on their ability to mentor, to provide best practice analysis to the PA (project architect) or project teams and their ability to incorporate and implement appropriate lessons learned from the PA requirements back into the overall EA. Companies with a static EA get left behind. 

• Doing PA and then reviewing the final PA in regards to the EA. This allows a consistent application of the common goals of the EA into each project. Also, it provides the opportunity to update the EA if new factors are introduced or new technological advances have come to light from the latest PA. Using this method of review helps to keep the funding for EA stable and ensures the EA does not get out of step with companies changing goals and focus. At project level, PA (Project Architect) are held to project performance ... while PM is the guardians of Timeline and Budget, Project Architecture are a held to Quality of the delivered product, for that organizations, are prepared to pay for.  

• EA is not to be measured by itself, but rather by their influence on the business, governance, and projects. Most of the effort for the EA is in three parts: 
  
  - The initial setup and the buy-in from the stakeholders. This is when the EA will be initially chartered, scope and objectives defined. Usually, the objectives are the business strategies plus the transition approaches.
  - Governance. Ensure the relevance, communications, and compliance with the EA. This is when the EA interacts with the PA.
  - The upkeep. This is when the EA operating charter is realigned to any new business strategies (if any), lessons learned are presented and incorporated into the EA, and approaches that were defined in the charter or updated in previous upkeep sessions are updated. 

• There's always going to be natural tensions between enterprise architecture and solutions/project architecture, because solutions architecture is defined by the scope of the project, and so doesn't always deliver everything the enterprise architecture defines it should (a compliant architecture in TOGAF parlance). However, Agile methodology shapes the new way to do a project, the design to implementation scenario is no longer following the sequential order, but through iterative communication & process, with agility to adapt to changes. Hence, there's possibility EA needs to be more interactive in PPM & PM level when necessary. 

Posted in: EA,Project Management