“Fairy Bright Eyes”, Projects, and Decay

Image

“Fairy Bright Eyes” is an installation by Ryan Monro, one of a dozen artworks in Auckland’s Learning Precinct Micro Sites initiative1.  A unexpected curiousity in an unusual location on a university campus, this piece represents beautiful aspirations and their subsequent inevitable decay:

  • A chandelier hangs over an alleyway. At first it symbolises luxury and hope but as it degrades over time it becomes a symbol of dystopia.

i’ve recently encountered a number of situations in which problems have appeared or changes are needed to the deliverables of projects that were closed as success stories, and the organisation’s ability to address those problems or make those changes has been wavering between absent and resentful, and for extraordinary, though predictable, reasons including:

  • the project didn’t deliver that function, and we’re forbidden to work on it now as a business-as-usual activity.
  • the project was outsourced, and nobody here knows how it works, and the documentation we were promised never materialised.
  • the project went live, but there was a lot that got moved into Phase 2, but they spent all the money on Phase 2 fixing problems with Phase 1, and now we don’t have anything that was promised in Phase 2.
  • the project delivered a product, but the only person that knows how it works has moved onto another project, and we’re not allowed to speak with him.
  • the project couldn’t deliver that integration because we failed to overcome political problems with the other system owner, and now there is no funding left anyway.

At once, i was reminded of the chandelier and its spectacular decay from a thing of sparkling beauty into an exhaust-tarnished relic, and reminded of two essential takes on the problem with projects and their definition of success:

  • energy, funding, and resource are assembled and brought to bear in the greenfields stage of a project, and those elements, along with the peculiar nature of the early greenfields condition, enable projects to move quickly and make initial changes and delivery with reasonable agility… but subsequent changes are soon required on top of initial changes, and then the project ends, and a prolonged stagnation period ensues2.
  • the success of an application project can be judged only by its long-term ability to deliver business benefit and by the change-friendliness of its capability delivery3, which is determined by the extent to which its non-functional characteristics have been understood and quality-assured4.

As an industry, we’re doing a terrible job of delivering application projects.  A big part of the solution to turning this terribleness around and improving these projects must come from the enterprise architecture discipline, embedding good behavoiurs, patterns, principles throughout the project lifecycle, from inception through design and delivery to long-term benefits realisation and, eventually, into managed decay.

 

 

 

  1. Various Artists. (2010) Learning Quarter Microsites, described at http://www.aucklandcouncil.govt.nz/EN/newseventsculture/Arts/publicart/Pages/learningquartermicrosites.aspx
  2. Krafzig, D., Banke, K., & Slama, D. (2005) Enterprise SOA: Service-Oriented Architecture Best Practices. Prentice Hall. ISBN 0-13-146575-9
  3. Enterprise Architecture in 140 Characters, Brenda Michelson, Elemental Links, http://www.elementallinks.com/2010/02/17/enterprise-architecture-in-140-characters/
  4. Kyte, A. (2011) In Application Projects, ‘Success’ Needs Many Definitions. Gartner Research, Article ID #G00210218.
Advertisements

Heal the Eternal Disconnect Between Project Managers and Enterprise Architects!

flexible fire loopTypical 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:

  1. Think Enterprise First, Todd Biske: http://www.biske.com/blog/?p=878
  2. Enterprise Architecture in 140 Characters, Brenda Michelson, Elemental Links, http://www.elementallinks.com/2010/02/17/enterprise-architecture-in-140-characters/
  3. About The Zachman Framework at Zachman International: http://www.zachman.com/about-the-zachman-framework