Typical exchanges between project managers and enterprise architects have historically, anecdotally, and sterotypically been predictable, unconstructive, and unsatisfactory affairs that juggle and irritate tensions across dimensions such as:
- enterprise context vs project scope
- change-friendly capability delivery2 vs project delivery
- methodological and framework differences
- open/collaborative vs closed/secret
The nature of these exchanges has led to the creation of an eternal-looking disconnect between project managers and enterprise architects. Flummoxed recently by a representative exchange that ran like this:
- EA: “those requirements still need a lot of work, not least because they don’t provide the necessary coverage, and because there are mistakes throughout them”
- PM: “no, we don’t have time to make them better, because we’ll then be behind schedule”
- EA: “…but they’re wrong, inadequate, and embarrassing, and intended for publication externally to vendors!”
- PM: “they were circulated to a reference group before you saw them, so, under the project charter, we’re not allowed to change them now anyway”
- EA: “…but they’re wrong, inadequate, and embarrassing”
- PM: “it is what it is, so just eat it! you enterprise architects are all the same, you’re all annoying, and not one of you understands what a successful project is, or how important following the correct methodology and controlling scope is to ensuring success”
…i have become certain the fundamental issue here is context.
In terms of the Zachman Framework3, the audience perspectives illustrate the context neatly, ranging from high-level whole-enterprise-and-beyond context:
- executive = business context planners
…down to constrained appropriately-defined task-scoped context:
- implementers = business component implementers
Traditional concerns of the project manager are all about landing something, landing anything approved by a steering group, landing an awkward three-legged contraption on the fluid trampoline of a go-live date. Traditional concerns of the enterprise architect are all about understanding how any change is incorporated into the functioning enterprise, and how to ensure that change is sustainable, able to be integrated within the business and technology bedrock of the enterprise, and consists of repeatable patterns and reusable artefacts for good, generating business value beyond the immediate at-hand implementation scenario.
The three legs of the awkward contraption are, essentially: effort, money, and time… but, just as Todd Biske outlined recently and eloquently1, the project-delivery obsession with being on-time and on-budget readily sacrifices scope, scope, the reason for and the justification of the project being commissioned in the first place.
The disconnect spans a greater distance than the relationship between project managers and enterprise architects. The disconnect is cultural, and relies upon much better project execution, much better portfolio and programme management, and much better procurement processes. It’s a core responsibility of the enterprise architecture profession to ensure these activities work together well, create business value, and facilitate change-friendly capability delivery.
Ultimately, the disconnect can be healed only by participants with broad-context viewpoints and strong commitment to ensure that change delivers sustainable business value. In this ecosystem, the only suitable relationship leader is enterprise architecture, enterprise architecture doing its job as advertised, and doing it well.
Notes:
- Think Enterprise First, Todd Biske: http://www.biske.com/blog/?p=878
- Enterprise Architecture in 140 Characters, Brenda Michelson, Elemental Links, http://www.elementallinks.com/2010/02/17/enterprise-architecture-in-140-characters/
- About The Zachman Framework at Zachman International: http://www.zachman.com/about-the-zachman-framework
