Feeds:
Posts
Comments

A day at the cricket.

We know that attitude, culture, and engagement underpin the performance of a team.  Despite knowing this, the announcement yesterday that four key players in the Austalian cricket squad currently touring India will be excluded from selection to play in the third test-match of the series was chillingly clear and startlingly decisive1,2.

Together, the coach, captain, and team manager triumvirate detailed the situation, the behaviour, and the impact on the team — the essence of which is reproduced here, statement-by-statement, and with the cricketing context removed:

  1. This is a line-in-the-sand moment.
  2. We have given the team absolute clarity.
  3. We have given the team a huge amount of time to buy into with what we want to achieve.
  4. We have given a vision to the team that is spelt out.
  5. We’ve given an expectation that is spelt out.

The four suspended players failed to meet the expectation, which of itself could be viewed as trivial, and the consequences punitive, but the leadership fundamentals here are strong, sound, and clear:

  • attitude and culture really matter
  • engagement is crucial for performance
  • every team member must be on board
  • clarity of vision, values, strategy, and aspirations is essential
  • opportunities to live the values and buy into the vision must be provided
  • clarity of expectations is essential
  • good leadership involves taking hard decisions, and acting upon them

…and, crucially:

  • individual performances are too expensive if they come at a cost to the team culture

i’m often finding analogies between the honourable and proper form of cricket (the five-day test match) and the execution of projects and other change initiatives, though not always very good analogies.  The variety of roles required within a cricket team necessarily mean that different team members have different specialisations, yet must share and be bonded deeply by common values.

Here, we’re seeing a spectacular demonstration of long-term thinking and strong leadership, setting the agenda not for the next two test matches, but for years to come.  It’s a risky, courageous, galling, dramatic, and bold step, taken to bolster, sustain, and grow the team as a whole.

It’s leadership.

  1. Barrett, C. (2013) Up In The Air: Watson flies home after Test axing, The Melbourne Age at http://www.theage.com.au/sport/cricket/up-in-the-air-watson-flies-home-after-test-axing-20130311-2fw9i.html
  2. Coverdale, B. (2013) It’s Not Just About One Incident, ESPN cricinfo at http://www.espncricinfo.com/india-v-australia-2013/content/current/story/624571.html

screaming_at_the_business_case_with_you

The Business Analyst and the Project Manager have yet another impossible timeframe forced upon them, which they accept.  Faced with the prospect of losing the confidence of their Project Sponsor, they somehow manage to squeeze out their Business Case.  The Business Case is such a success that they circulate it to the usual suspects for formal review.  However, when a nosy enterprise architect begins poking around in the details, he finds more than he bargained for!

Just like the horrible undead creatures from in B-grade horror movies like Attack of the Vegan Zombies!1, the business cases keep coming through the door and through the email, and they are unstoppable, fully-formed, dangerous, and perfectly hideous.

  • The business cases arrive after being bred in captivity, never before having seen the outside world or a strategic context, and they are packed with impenetrable, unusual, misused, and idiosyncratic language: their intentions are unclear, and we are unsettled by not being certain what they are requesting or justifying.
  • The business cases arrive after ten o’clock at night, sixty dense and confused pages long, demanding detailed review before morning to justify a case for change requiring substantial investment.  In the dead of night we unwrap them, afraid at the what inevitably lies within, and as powerless to change their course as the archtypal naked home-alone victim showering behind a flimsy plastic curtain as the evil murderer approaches.
  • The business cases arrive packed with imperatives: we must make this investment because the life, sustainability, and reputation of the business depends upon it, and because we were denied unfairly last time we asked, please!  The very essence of life and death is at your feet, morality and emotion and heartstrings are tugged and implored.
  • The business cases arrive in generalisation-based disguises, cunning wolves dressed as sheep: the case for change is supported unequivocally by the “really expensive” support that will be avoided, by the “drastic risk reduction” that will result, and by the “hugely increased user experience and effiency gains” the organisation will receive from undertaking the work, none of it quantified, well-imagined, or offered with a timeframe in which the benefits will be realised.

Here, now, in 2013, we should be good at business cases, both at creating them and at approving or rejecting them.  Much too often, a business case comes along as an urgently-needed administrative chore to mop up paperwork requirements after an investment decision has been made.  The business cases are bad! However, there are some practical steps to start turning this around:

  1. Collaboration: business cases must not be allowed to grow in isolation, not even to first-draft condition, because so much is set in stone by the time first-draft condition is reached.  Creating a business case must be an open, social, collaborative endeavour.
  2. Context: business cases must be created with context, which means that the projects and initiatives for which cases for change are made must have their own context devolved to the business case and to the team charged with its creation.  The business-case-initiation phase modelled by Gartner2 includes the tasks:
    • define how the initiative addresses business strategy
    • identify business case stakeholders
    • identify business case audience
  3. Betterment: initiatives such as the New Zealand Government’s Better Business Cases3 model (based upon similar models in the UK and Australia) seek to improve the rigour and repeatability of good business cases that support clearly the case for change across five domains: the strategic case, the economic case, the commercial case, the financial case, and the management case.

There is good reason to hope and expect that the quality of business cases will improve, but achieving that improvement does require soup-to-nuts involvement of enterprise architecture and program/portfolio governance teams.  It’s when the business cases appear with a shock factor that things invariably go bad, not least because it’s all too late to recover.

  1. Attack of the Vegan Zombies (2010) synopsis from IMDb at http://www.imdb.com/title/tt1380852/plotsummary
  2. Ganly, D. (2012) Use a Robust Business Case Process to Avoid the Seven Common ERP Pitfalls. Gartner Research, Article ID #G00232378.
  3. New Zealand Government (2010–) Better Business Cases, http://www.infrastructure.govt.nz/publications/betterbusinesscases

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.

tessellations as repeatable solution patternsAfter some prompting, the technical requirements arrived for architectural review.  They had been prepared from a well-intentioned place and under the pressure of project timelines.  Scanning through them revealed serious problems: these requirements were much too far progressed, and were based upon several fundamental anti-patterns.  Needing to deliver some new information from one ERP system to another, the proposed integration solution:

  • specified silent discards in favour of raising alerts when errors were detected
  • favoured unsustainable side-door integration techniques over the use of established patterns
  • was disconnected from the business requirements it has to deliver
  • specifies data-exchange and transformation rules at the wrong layer of the stack

These are unacceptably-bad things, and while their origin is understandable and of an environmental and historical nature, rather than of an individual or other nature, they must be addressed, and the course proposed redirected towards simple compliance with basic established delivery patterns.  This work is not supporting an isolated endeavour, a proof-of-concept experiment, or an early innovation — this is a mainstream production deliverable where there is genuinely no latitude for managed diversity.

Perhaps inevitably, the project machine responded as follows, heavily paraphrased:

  1. why are you making us have to do this properly?
  2. what is the value of involving a solutions architect?
  3. don’t you know we’re busy?

The spectrum of governance ranges from assistive governance through to directive goverance, in both proscriptive (you must not do these things) and prescriptive (you must do these things) flavours.

While there might not always be uniquely-right or best-ever answers and solutions, there is a sense of universal truth and rightness here, and sometimes the architecture function must adopt a directive position, generally when assistive positions have failed to achieve a sustainable business-value-driven outcome.

Facilitating the use of established repeatable patterns, ensuring change-friendly sustainable outcomes, and sometimes veering into directive governance, that’s the value of a solutions architect.

busoto is collaboration

build something together

In 2011, and again in 2012, while preparing to cofacilitate with Ric Phillips1 a workshop about collaboration across an enterprise-architecture community of practice, we were reminded with jarringly clarity that the word collaboration is misunderstood and misused, and that unhelpful behaviours result from this misunderstanding and misuse.  Under the banner of collaboration are in fact three broad classes of behaviour:

  1. Connecting
  2. Sharing
  3. Collaborating

…and the expectations upon participants and on the elements needed to support those behaviours vary greatly from one broad class to the next, as:

  1. Connecting is simply establishing and in some way monitoring connections between people in environments such as LinkedIn and, to a certain extent, Twitter and Yammer.  Connecting gives rise to ambient intimacy2 — knowing what is happening, knowing something of what your peers are doing.
  2. Sharing is making available to others some or all information, decisions, and other artefacts (e.g., strategies, templates, documents, diagrams, code) that are generated by doing work. Sharing can be mediated by websites, blogs, Twitter, and so forth.
  3. Collaborating is the deliberate cooperative creation of something new: new products, new artefacts, new understanding — in any form, new value.

Selected good definitions of collaboration include:

  • two or more people working together towards shared goals3
  • creative coordinated goal-oriented4
  • working together to achieve a goal5

…and three random examples are offered below:

  • busoto is a new portmanteau of the phrase build something together, illustrated by the drawing at the head of this post, which my five-year-old daughter and i built together deliberately.
  • Wai Notes6, 7 is a music album containing early/demonstration versions of songs that were recorded by Will Oldham and Dawn McCarthy by exchanging tapes in the postal mail.
  • A group of architects from different organisations obtain local sponsorship to work together to define and create business capability models for their sector.

Collaboration, busoto, is a deliberate and identifiable behavioral style.  It builds upon, depends upon, and is a higher form of connecting and sharing. Communicators and collaborators must acknowledge and stay actively aware of the difference between connecting, sharing, and collaboration.

  1. Ric Phillips and his excellent eapatterns blog at http://eapatterns.tumblr.com/
  2. Ambient Intimacy coined and defined at http://www.reboot.dk/page/1236/en
  3. Ephraim Freed’s August 2012 post What Collaboration Really Means at http://www.thoughtfarmer.com/blog/2012/08/14/what-collaboration-really-means/ includes a useful list of behaviours often confused with or labelled as being collaborative, but that are not collaboration.
  4. Jane McConnell’s May 2012 post Clarifying the word “collaboration” to reduce confusion and conflict at http://netjmc.com/social-collaboration/clarify-to-reduce-confusion-and-conflict includes some helpful models indicating how collaboration fits into the digital workplace and other work and organisational patterns, alongside intranet/content and people-connectedness.
  5. The wikipedia definition at http://en.wikipedia.org/wiki/Collaboration
  6. Wai Notes at Drag City http://www.dragcity.com/products/wai-notes
  7. Wai Notes at Wikipedia http://en.wikipedia.org/wiki/Wai_Notes

not my monkey

It is fair to say that the project in question has not started well. A lengthy incubation period executed in isolation from business and delivery partners has seen resources consumed in exchange for very little demonstrable progress, and high-level commitment waning. Faced with challenges like these, project managers will often retreat into their defensive belief systems — the heavily-dogmatic linear methodologies. Under such circumstances, the project manager looked me in the eye and uttered the incredible words:

  • “The architecture for this project is out of scope for this project.”

This statement dumbfounded me, and made me think. Another literal expression had been made of the natural tensions between enterprise architects (and their broad-context thinking and striving for change-friendly capability delivery1) and project managers (and their project-constrained and limited-context viewpoint and striving to achieve traditionally-measured project success). Variously, while i am:

  • accepting that enterprise architecture does not have a strong track record in the successful application of its own heavyweight frameworks
  • holding strong personal convictions that well-executed P3M (Portfolio, Programme, and Project Management2) has transformative potential for good
  • noting signs that enterprise architecture and P3M practices can deliver better business outcomes working together harmoniously3

…i’m too often seeing struggling projects “remedied” through the application of portfolio-grade heavy management and governance techniques, with the primary effects being:

  • greater focus on time and budget, at the sacrifice of scope and benefit
  • more expensive (in terms of both effort, money, and time) project contols
  • blossoming of the infamous opportunities register

For this to change, the culture of projects, and the culture of enterprise architecture, needs to change, meld, and align — a new conversation is needed, needed to lift every project’s context for decision-making up to at least the portfolio level.

It was much later before i established the link with this item doing the rounds on Twitter:

  • “Not my problem” in Polish is “nie moj cyrk, nie moje malpy.” Literally “not my circus, not my monkey.”4

There it is, the crux of the execution-time tension: “not my circus, not my monkey“.

As we step down through the layers of P3M we find portfolios (selected circuses and selected monkeys), programmes (small numbers of circuses, small numbers of monkeys), and projects (one circus and some of its monkeys).

With its enduring concern for the broader context, enterprise architecture is concerned with the enterprise: with all the circuses, and with all the monkeys.

  1. Enterprise Architecture in 140 Characters, Brenda Michelson, Elemental Links, http://www.elementallinks.com/2010/02/17/enterprise-architecture-in-140-characters/
  2. The Project, Programme and Portfolio Management InfoKit from JISC http://www.jiscinfonet.ac.uk/p3m provides a good overview of P3M.
  3. Bittler, R.S. (2012) Best Practices for EA and PPM Integration Toward Improved Business Outcomes, Gartner Research, Article ID #G00237525, http://my.gartner.com/portal/server.pt?gr=dd&ref=shareSummary&resId=2173516 gives a pragmatic and actionable set of best-practice suggestions for aligning enterprise architecture and P3M teams and initiatives.
  4. @howardtaylor on Twitter at https://twitter.com/howardtayler/statuses/260944798167482368

Ideal Circumstances for EA Frameworks

Significant touchstones, at least for some people, some of the time, the series of hype cycle devices published annually by Gartner inform and guide industry behaviours, lead and shape the formulation of strategy.

Three features of the current enterprise architecture hype cycle1 are noteworthy, or thought-provoking, or self-evident:

  1. Whole-of-Government enterprise architecture has been cancelled due to lack of interest and because it is unlikely to deliver transformational benefit… except under ideal circumstances.
  2. Enterprise Architecture Frameworks are on notice, because they’re implemented as a whole insufficiently often to make solid ground, they’re probably a decade away from delivering benefit, and too many enterprise architecture practitioners are distracted by them.
  3. Enterprise Architecture as a discipline “…proactively and holistically leading enterprise responses to disruptive forces by identifying and analysing the execution of change toward desired business vision and outcomes” is moving into the plateau of productivity, and the discipline of enterprise architecture will deliver transformational benefit within the next few years.

Tying these features together and thinking about what they mean for my own enterprise architecture practice generates the following simple good-vs-less-good system:

  • Old School: heavy-framework approaches tend to be neverending documentation exercises capable of producing enormous amounts of exactingly-beautiful and perfectly-irrelevant families of well-organised zero-benefit enterprise architecture artefacts.
  • Change-Friendly: the ultimate outcome of enterprise architecture is change-friendly capability delivery3

…and some unanswered questions:

  • Ideal Conditions: what are the ideal conditions under which enterprise architecture (as a discipline) and enterprise architecture frameworks (as a belief system) and whole-of-entity enterprise architecture (where “entity” might be a division, an enterprise, a government, or a global corporation) may thrive and deliver the transformational benefit they promise?
  • Measuring Benefit: particularly vexed and repeated plaintiffly everywhere, the question of how we as a community of enterprise architecture professionals measure (and communicate well) the benefit delivered by the enterprise architecture discipline.

Whether emergent, pace-layered, pragmatic, lean, agile, or just-enough — by any name, involving enterprise architecture in change initiatives, in strategy formation, in policy review, in service design, in everything, usually leads to improved outcomes.  This happens through a focus on the discipline, values, and core principles of enterprise architecture, rather than through the naked and contextless application of the heavy frameworks.

With the enterprise architecture discipline thriving, and in some areas undergoing a resurgence, we might yet as a community of practice be able to create for ourselves those very ideal conditions under which the frameworks, too, might thrive… what are the ideal conditions for enterprise architecture to succeed?

  1. Burton, B. & Allega, P. (2012) Hype Cycle for Enterprise Architecture, 2012, Gartner Research, Article ID #G00234608
  2. Gall, N. (2012) Gartner’s 2011 Global Enterprise Architecture Survey: EA Frameworks Are Still Homemade and Hybrid, Gartner Research, Article ID #G00226400
  3. Enterprise Architecture in 140 Characters, Brenda Michelson, Elemental Links, http://www.elementallinks.com/2010/02/17/enterprise-architecture-in-140-characters/
Follow

Get every new post delivered to your Inbox.