• rm@rmbastien.com

Roles

Designing Your Stairway to Heaven

Standing the Test of Time

I’ve been an unflagging fan of Led Zeppelin since my early teens. I’ve been a worshiper of their founder and lead guitarist Jimmy Page.  That’s probably why YouTube’s algorithm presented me this 17 minute video from the BBC where Mr. Page describes the intent and the result of Zep’s most iconic composition: Stairway to Heaven.  Saying that this piece has an enduring popularity is an understatement.  Today, teenagers whose parents weren’t yet born when this opus was written are still fascinated by the creation. 

Jimmy’s Architecture

There are certainly a series of reasons why Stairway to Heaven is so good, and not being a musician, I’m not cognizant enough to comment on all of them.  However, at 4:38 into the video, Jimmy said something that struck me:

“All this stuff was planned.  It was not an accident, or everyone chipping in.  It really was a sort of design.”

Jimmy Page

If you listen to the whole video, there will be no possible doubt: Stairway to Heaven is the result of conscious design.  The magnum opus was architected, from the beginning, with a clear vision about the sequence of movements, the textures, the build-up of tempo and the unfoldment of the majestic finale.

Innovation Is Not Design — It Feeds It

Another clear learning from Master Page: this was not the result of some brainstorming session, an unplanned mashup, or random amalgamation in hopes of finding a gem.  Unknowingly, Jimmy brought more fuel to a conviction that I’ve seen building in my mind over the years:  innovations and epiphanies emerge before the actual design of digital solutions begins.  These pieces of enlightenment are then embedded into the greater creation. The innovations —if any— reside in specific areas of the final product, but they are not the final achievement. 

Architecture and Design Make the Masterpiece

This leads to another observation, which is supported by decades of scrutiny and involvement in the world of information systems design: brainstorming sessions, focus groups, innovation dives —and all the good practices that encourage seeing things differently— will not yield a masterpiece.  They will nourish the subsequent process of architecting a creation that uses the innovative gems, but the master work comes from intentional design.

Randomly searching for innovation may lead to interesting designs; but masterpieces that stand the test of time are architected.

If you’re tempted to think that great business systems emerge from innovation, beware that it’s far from enough.  Don’t put all your marbles on the lateral thinking side of things.  Save a few for conscious design.

Beauty in All Creations

In the world of buildings, the importance of architectural beauty is rarely questioned.  Well-designed buildings inspire us, comfort us, and ignite seldom felt emotions.  The widely recognized merit of beauty is, in part, founded on the fact that human constructions are tangible creations. We live in them, work in them, and look at them.  We can relate the design to what we see or know and understand the value of beauty.

The Many Faces of Beauty

This very interesting video, sent to me by Wolfgang Göbl,  is an emotionally compelling reminder that beauty can take many forms.  But just because beauty can take many forms does not mean that it is anything. If beauty can be anything, it loses its significance. Something repulsive or ugly is not beautiful just because someone, somewhere may find beauty in it.

Beauty is Important

This video is also a reminder that beauty is far-reaching.  Having been designing for a few decades now, I feel compelled to make a bold statement about it:  beauty should be a sought after attribute in everything that is worth the time and effort to be designed.  

And that’s not just me saying that after some sort of epiphany.  Business architecture expert Mike Rosen once reminded me that back in 40 BC, Marcus Vitruvius postulated that all buildings should have three attributes: firmitasutilitas, and venustas, which could be translated to durability, utility and beauty

The Many Names of Beauty

I use thesaurus.com every day, so,  I searched for the related meanings of the word beauty.  I found that one of the synonym tabs was labelled advantage.  That’s interesting, I thought.  I clicked on  ‘advantage’  and a world of related meanings appeared: feature, importance, value, asset, attraction, benefit, blessing, boon, merit, and worth. 

These synonyms  and the video remind us that beauty is not just visual and can be found in the value that something brings. Isn’t that beautiful?

Beauty in the Intangible Creations

The designs that architects create for information systems and digital technology solutions are chiefly abstract and not visual.  Saying that what you see on your computer screen is just the tip of the iceberg is an understatement.  These designs are impossible to relate to for any user of the system. In fact, these designs are hard to link to for the majority of computer-literate geeks that work in one IT field or another. That’s why beauty in these types of designs is not just a hard sell; it is often viewed by the uninitiated as a ludicrous quest rooted in some form of designer’s vanity. 

But it’s there.  Some information technology designs bear beauty because they bring value, asset, attraction, benefit, resilience, intelligence or wisdom.   

Beauty in All Designs

I strongly believe that the quality criteria for architecture and design in information technology creations needs to include beauty.  A corollary of this belief is that those who declare themselves designers or architects should understand the importance of beauty, what beauty means for their design, and seek to achieve it… or else leave it to others that care.

“They Don’t Know What They Want!” and a Few Ruthless Questions About Estimation in Corporate IT

Estimating how much effort is required for digital transformation projects is not an easy task, especially with incomplete information in your hands. If one doesn’t know in sufficient detail what the business solution to be built has to do, how can they estimate correctly?  In face of such an unchallengeable truth, my only recommendation is to look at the problem from another angle and ask these simple but ruthless questions: 

Q1: Why are there so many unknowns about the requirements when estimation time comes?

Instead of declaring that requirements are too vague for performing reliable estimation, couldn’t we simply get better requirements? My observations are that technical teams that need clear requirements aren’t pushing enough on the requesting parties. This could be rooted in a lack of direct involvement in the core business affairs, an us-and-them culture, an order-taker attitude, or all of the above. Whatever the reason, there is a tendency to take it as an ineluctable fact of life rather than asking genuine questions and doing something about it.

Q2: Why do IT people need detailed requirements for estimation?

There are industries where they get pretty good estimate with very rough requirements. In the construction world, with half a dozen questions and square footage, experts can give a range that’s pretty good —compared to IT projects. I can hear from a distance that IT projects are far more complex, that “it’s not comparable”, etc. These are valid arguments that do not justify the laxity with which your corporate IT teams tackle the estimation process. In the construction industry, they have worked hard to get to that point and they relentlessly seek to improve their estimation performance.

Couldn’t IT teams develop techniques to assess what has to be done with rough requirements, then refine those requirements, re-assess estimates, and then learn from the discrepancies between rough and detailed to improve their techniques?  Read carefully the last sentence: I did not write ‘improve their estimates’ but rather ‘improve their techniques’. IT staffs know how to re-assess when more detailed requirements are known, but they are clueless about refining their estimation techniques.

Q3: Is IT the only engineering field where customers don’t know in details what they want at some point? 

Of course not!  All engineering fields where professionals have to build something that works face the challenge of customers not knowing what they want, especially at the early stages.  Rough requirement can be as vague as “A new regional hospital”,  “ A personal submarine”, “A multi-sports stadium”, “A log home”, “A wedding gown”. Professionals in these other fields genuinely work at improving their estimation skills and techniques even with sketchy requirements. But no so in corporate IT.

Q4: Who’s accountable for providing the requirements? 

The standard answer is that it should come from the user or the paying customer, and that’s fair. The problem is that IT folks have pushed too far such a statement and distorted it to a point where requirements should fall from the skies and be detailed enough for precise estimation. Which has led to an over-used and over-written statement that “Users don’t know what they want!”  And that’s not fair, especially when it is used to declare that estimating is a useless practice.  Which leads to the next question.

Q5: Who’s accountable for getting clear requirements?

That’s the most interesting question.  The query is different from the previous question, read carefully.  It’s about getting the requirements and being accountable for getting clear requirements.  Digital systems are not wedding gowns or log homes.  Non-IT people often have a hard time understanding how and what to ask for.  Whose responsibility is it to help them? If the requirements aren’t clear enough, who’s accountable for doing something about it?  The answer to all these questions should be those that have the knowledge, and that’s generally the IT folks.  What I observe is that IT staff are too often nurturing an us versus them culture where they don’t know what they want.  Let’s turn for a moment that statement around to: “We don’t know what to do”.  Isn’t that an interesting way to see things? It’s not anymore that they don’t know what they want, but rather that the IT teams don’t know what to build to provide the outcome that the organization needs.

Q6: Who’s accountable for knowing what to do? 

We all know who they are. Seeing the problem from that end and with another lighting may substantially reduce the cases when “they don’t know what they want” is a valid point.

Agile™ and Iterative Development to the Rescue! Or is it?

The clarity of requirements issue has lead smart IT people to use iterative prototyping to solve it for good.  The idea is ingenious and simple: let’s build smaller pieces of the solution within a short period of time, show that portion to the users and let them determine if that’s what they thought they wanted.  That’s great, and that’s one reason why the Agile™ methods have had such a widespread acceptance.  However, iterative prototyping doesn’t solve everything, and it certainly avoids a few important issues:

Q7: Are users getting better at understanding their requirements with Agile™?

Are sponsors and users getting any better at knowing what they need before they get any technical team involved? Of course not. Things haven’t improved on that front with Agile™ methods or any iterative prototyping technique for that matter.

Q8: Could prototyping be used as a means for improving how people define requirements

It certainly could, but that is not being taken care of.  Worse, it encourages laxity in the understanding of the requirements.  After all if we’re going to get something every 3 weeks that we can show our sponsor, why should we spend time comprehending the requirements and detailing them?  That’s a tempting path of least effort for any busy fellow.  The problem is that thinking a bit more, asking more questions, writing down requirements, having others read them and provide comments takes an order of magnitude less effort than mobilizing a whole team to deliver a working prototype in 3 weeks. The former option is neglected at the expense of having fun building something on the patron’s cuff.

The False Innovation Argument

Iterative prototyping is used across the board for all kinds of technology-related change endeavors, including those that have little to no innovation at all.  Do not get fooled into thinking that all what the IT teams are doing is cutting edge innovation. 

In fact, I posit that for the vast majority of the work done, the real innovation has occurred in the very early stages, often at a purely business level, totally detached from technology.  What I see for most endeavors, is IT teams building mainstream solutions that have been done dozens or hundreds of times within your organization or in others. Why then is iterative prototyping required? In those cases, using iterative development methods is less for clarifying requirements than to manage the uncertainty around teams not knowing how to build the solution or not understanding the systems they work on.

In many cases, using Agile™ is a means for managing the uncertainty around IT folks not knowing how to do it.

Did I ask this other cruel question: who’s accountable for knowing the details of the systems and technologies in place? You know the answer, so it’s not in the list of questions. It’s more like a reminder.

And finally, the most important question related to estimation:

Q10: Is iterative prototyping helping anyone get better at estimating?

Of course not.   The whole topic is tossed on the side as irrelevant when not squarely labelled as evil by those that believe that precious time should be taken to develop a new iteration of the product rather than guessing the future.

The Rachitic (or Dead) Estimation Practice

The consequence is that there is no serious estimation practice developed within corporate IT.  Using the above impediments about ‘not knowing what they want’ to explain why estimations are so often off-mark is one thing.  Using these hurdles as an excuse to not get better at estimating is another.  IT projects are very good at counting how much something actually costed and comparing it to how much was budgeted.  But no-one in IT as any interest in comparing actual costs with what was estimated with the genuine intent of getting better estimations the next time. 

This flabbiness in executing what should be a continuous and relentless quest for improvement in the exercise of estimating takes its root in a very simple reality:  corporate IT is the one and only serving your needs, providing to your organization everything under the IT sun.  While in the infrastructure side of IT, competition has been around and aggressively trying to offer similar services to your organization as alternatives to your in-house function, the other portion of corporate IT –the one driving change endeavors and managing your application systems—operates in a dream business model: one locked-in customer that pays for all expenses, wages and bonuses, and pays by the hour.  When wrong estimates neither make you lose your shirt nor any future business opportunity, the effort for issuing better ones can safely be put elsewhere, where the risks imminent.

Don’t Ask for Improvement, Change the Game

These behaviors cannot be changed or improved without providing incentives for betterment. Unfortunately, the current, typical engagement model of corporate IT in your organization is a major blocker. Don’t ask your IT teams to fix it: they’re stuck in the model. The ones that can change the game are not working on the IT shop floor.

Want some sustainable improvement? Start your journey by understanding the issues, and their true root causes.

Episode Six – Joe Peppard on Radical Change Ideas for Corporate IT

If you had a magic wand and you could radically modify the way corporate IT engages itself in organizations, what would you change?
That’s the question we asked Joe Peppard, Principal Research Scientist at the Center for Information Systems Research of MIT Sloan School of Management.
Joe provides awesome answers based on years of field research about the need to change the IT structure. His insights cover many areas such as:

  • Why the classical IT department holds back organizations in their quest for digital success;
  • Where do the real opportunities lie;
  • Managing information technologies vs organizing for success with information technology;
  • Comfortable positions and longstanding behaviors;
  • The inwardly focussed self-management regime of IT departments.

Listen with transcript at this link.

Episode Five – Bard Papegaaij on Radical Change Ideas for Corporate IT

If you had a magic wand and you could radically modify the way corporate IT engages itself in organizations, what would you change?
That’s the question we asked Bard Papegaaij, Chief Change Facilitator at Transgrowth, and former Research Vice-President at Gartner.

Bard gives awesome answers about the need to change corporate culture when it comes to IT.  He also provides insights in many other areas, such as:

  • The great divide between IT and the rest of the organization;
  • How silos are nurtured by the people inside them;
  • The socializing geeks;
  • The IT knowledge gap;
  • The social responsibility of the IT community;
  • How social change can replace a magic wand and create a joyful experience.

 


For complete transcript, use this link.

Episode Four – Mike Rosen on Radical Change Ideas for Corporate IT

If you had a magic wand and you could radically modify the way corporate IT engages itself in organizations, what would you change?
That’s the question we asked Mike Rosen, Chief Scientist at Wilton Consulting Group, and co-founder of the Business Architecture Guild.

In answering the question, Mike provides loads of wisdom on:

  • The new drivers of the Digital Economy;
  • Accountability as a means of achieving cross-enterprise results;
  • The Learning Organization: what you have to become, or succumb to;
  • The IT knowledge gap;
  • The enterprise architect’s role and the true value of their work;


For a view of the transcript, use this link.

Episode Three – Scott W. Ambler on Radical Change Ideas for Corporate IT

If you had a magic wand and you could radically modify the way corporate IT engages itself in organizations, what would you change?
That’s the question we asked Scott W. Ambler, author and Chief Scientist of Disciplined Agile at the Project Management Institute.

Scott shares his wisdom on many important topics, including:

  • Integrated roles in organizations;
  • Collaboration and the great IT-Business divide;
  • Leadership;
  • Outsourcing;
  • Cultural gaps and teamwork;
  • Measurements;
  • Humility as a means of improvement…


You can also read the transcript with this link.

Episode Two – Wolfgang Göbl on Radical Change Ideas for Corporate IT

If you had a magic wand and you could radically change the way corporate IT engages itself in organizations, what would you change?
That’s the question we asked Wolfgang Göbl, founder and President of the Architectural Thinking Association®.

Wolfgang provides great answers to the question, with a focus on accountability.
In addition, he shares his opinions on a several important topics, including:

  • The CIO, a role that is bound to become irrelevant;
  • Why certain key tasks should not be left to a distinct IT team;
  • The death of the corporate IT department;
  • The importance of the vocabulary when designing business change;
  • Why the devil may hide in too much detail;

You can also follow the episode with transcript.

NYC Marathon

Is You Corporate IT Good Enough? You Get What You Measure For.

I jog.

But honestly, I’ve never liked jogging; I only do it because I need to exercise and there are times when other physical activities aren’t feasible or require too much engagement to get started. Cycling when it’s pouring rain or cross-country skiing with bad snow conditions are not good ideas. Jogging, on the other hand, usually requires no more preparation than a quick change of clothes and lacing up running shoes. Since I don’t really like jogging, I just run and that’s it. Don’t ask me how many minutes it takes me to run a kilometer. Don’t ask me how many Ks I ran this morning or this week. Don’t ask me if I’m improving either. I don’t know because that’s not important to me. I don’t bring my smartphone running. My watch doesn’t calculate my heart rate. I just run for forty-some minutes until it makes me feel good and then I’m done.

If ever someone succeeded in convincing me to enroll in a marathon running club where members have to successfully finish at least one official 42.2-kilometer race per year—or else they lose their membership— things would be different. I would wear a smartwatch, track all my runs, plot my progress on a chart and be very serious about measuring.

“When it’s really important, you measure it. The same thing can be said about paid work.”

If the attainment of a certain goal is critical enough to be linked to a bonus, a promotion or keeping your employment, chances are it is appraised with numbers —or will be soon enough. Conversely, failure to attain an expected performance level that is gauged quantitatively is more likely to be subject to a performance problem. We all get the hidden message when a boss is giving us numerically metered objectives: these goals are undoubtedly important.

This is universal enough to be appropriate to your digital teams as well.  Applying this common wisdom to corporate IT, three questions should be asked and answered:

  1. What are the outcomes expected from the work performed by corporate IT? Can you associate a set of objectives to these outcomes?
  2. Is the attainment of these objectives assessed? And if so, is it gauged quantitatively?
  3. And finally, do these measures of performance relate to the actual work performed and lead to empowered improvements?

The first question is the most crucial one because it directly impacts the answers provided to the next two. There’s nothing wrong in defining strategic objectives such as “driving business value through digital excellence” or any other objective that can be shared between IT folks and the rest of the organization. Bridging the great divide between technical teams and business stakeholders is certainly an objective that many —including yours truly— are craving for.

“At a very high level, business objectives for IT teams to spur a culture of cooperation is fine. But to drive performance improvement, that’s far from enough.”

Given the huge distance between business objectives and the actual services provided by your IT function, such a link becomes arbitrary and out of reach from an IT viewpoint.  Although it may be wise to link CIO performance to the organization’s success as a whole, the chosen business criteria would have to be translated into other measures of performance that IT teams can relate to and know they can improve upon. Market share or customer satisfaction index do not provide IT staff any clue for betterment. T

hen whatever the chosen set of objectives, is it measured quantitatively? It’s not jogging, but it nevertheless needs to be metered. And as discussed above, metrics that are too far from what technical staffs are actually working on, it won’t drive much improvement, and you may well get debatable numbers.

In this previous article —or better by looking at the bigger picture in this book about things executives need to know about IT— you will understand how today most IT teams are evaluated on. These typical metrics have a direct impact on what gets improved, but also, what isn’t being taken care of.  Enjoy!

Silo Generator #3


The two previous silo types could be labeled as structural silos. They are almost permanent and vary only after major reorgs or when applications are introduced or retired. The third one, the project silo, is the most damageable type of silo.
Although projects and their rigorous management are an absolute must for any organization to govern change endeavors, their very nature and the absence of strong counterbalancing mechanisms make projects temporal silos.
Because all projects are temporary endeavors with a start and an end date, anything that happened before is not managed within the project, and all that happens after is not either taken into account.

Learn more about how silos of all sorts that hamper business agility: https://rmbastien.com/book-summary-the-new-age-of-corporate-it-volume-1/
#CorporateITGameChange #ITMeasures #ITQuality #Sustainability #BusinessAdaptability

Silo Generator #2

The IT function is usually structured in a way to align itself with lines of business, which extends the LOB silo into equivalent silos within corporate IT.

Furthermore, IT teams are also aligned around applications, an ensemble of IT components that serves a LOB or a major business process.

Technology and knowledge walls are nurtured by those IT application teams that slowly build little fiefdoms based on the uniqueness of their application and a privileged relationship with the sponsoring business unit.

Learn more about how silos of all sorts hamper business agility: https://rmbastien.com/book-summary-the-new-age-of-corporate-it-volume-1/
#CorporateITGameChange #ITMeasures #ITQuality #Sustainability #BusinessAdaptability

Silo Generator #1

In most organizations of a certain size, IT budgets are allocated by business units, roughly following the organizational chart.  Business units need to present their investment projects which invariably require to purchase, develop or modify some information system component.  In many industries, business projects are often quasi exclusively made of IT activities.  The investment projects presented do need to show positive business returns when not clearly proven financial returns on investment (ROI).

But very often, the costs and the benefits of a given project are aligned with a corresponding business unit.  This impedes the sharing of IT resources across these lines of business.  It also hampers the creation of IT assets that could be eventually shared with other units.

Regardless of the benefits they provide, the more IT assets you have, the more you will spend in future change endeavors.

Learn more about how silos of all sorts hamper business agility: https://rmbastien.com/book-summary-the-new-age-of-corporate-it-volume-1/

Episode One – Milan Guenther on Radical Change Ideas for Corporate IT

If you had a magic wand and you could radically change the way corporate IT engages itself in organizations, what would you modify?
That’s the question we asked Milan Guenther, founding partner at Enterprise Design Associates, author of the Enterprise Design Framework found in his book Intersection.

Not only does Milan provide a great answer to the question by positioning the leadership role that corporate IT has to play, but he also shares great insights on many important topics affecting organizations:

  • Collaboration
  • The IT mess
  • Start-ups and scale-ups
  • Opportunity seeking
  • The true nature of innovation

You can also follow the episode with transcript.

Here’s the link the to Milan’s favorite design author, also mentioned in the podcast:Design Driven Innovation

Small, Autonomous and Fast-Forward to Lower Quality

I am a jack-of-all-trades.  Admittedly  — and proudly  —  I realize that a lifelong  series of trial and error, crash courses, evening reading and incurable curiosity have  resulted in this ability to do many things  —  especially things involving some manual work. I feel self-satisfaction to think about all the situations that could arise in which I would know what to do, and how to do it.  I can help someone fix a kitchen sink on a Sunday afternoon.  I can drive a snowmobile, sail a catamaran, or connect a portable gasoline generator to your house.  My varied skill-set affords me a serene feeling of power over the random hazards of life.  That, and it’s also lots of fun to do different things.

There is currently an interesting trend in many organizations to favour highly autonomous teams.  The rational is quite simple: autonomy often translates to an accrued operational leeway that offers a better breeding ground for innovation.  By not being weighed down by other teams, there’s a hope that the group will perform better and yield more innovative ideas.  There is also the expectation that the team, using an Agile™ method, will produce tangible implementations much faster if it can be left alone.  The justification is founded in  the belief that small teams perform better.  Makes sense:  the smaller the team, the easier the communication, and we all know that ineffective communication is  a major source of inefficiency  —  in IT as well as in any  other field.  And if you want your team to be autonomous and composed of as few individuals as possible, then there is a very good chance that you need multi-skilled resources. 

Jacks-Of-All-Trades and Interchangeable Roles

You need jacks-of-all-trades or else either the number of individuals will increase or you will need to interact with other teams that have some of the required skills to get the job done. As a result, you will not be as autonomous as you’d like.  

But there is more: the sole presence of multi-skilled individuals is not enough to keep your team small and efficient in yielding visible results at an acceptable pace.  You must have an operating rule that all individuals are interchangeable in their roles.  If Judy —a highly skilled business analyst— is not available in the next two days to work on sketching the revamped process flow, then Imad —a less skilled business analyst, but a highly motivated jack-of-all-trades nevertheless— needs to take that ball and run with it.   You need multi-skilled resources and interchangeable roles.  That’s all pretty basic and understandable, and your organization might already have these types of teams in action.

For a small and autonomous team to keep its low size and independence upon others, it needs to be made of jacks-of-all-trades and roles must be interchangeable, or else it will either grow in size or depend on outsiders.

Conflicts of Roles in Small Autonomous Teams

Before you declare victory or you rush into hiring a bunch of graduates with a major in all-trades resourcefulness and let them loose on a green field of innovation turf, read what follows so that you also put into place the proper boundaries.   If you want to ensure maximum levels of quality and sustainability of what comes out of small, autonomous, multi-skilled teams, you need to ensure that there are no conflicting roles put on the shoulders of the individuals that need to juggle them.

Conflicts of role occur when the same person needs to do work that should normally be assigned to different persons.  The most obvious —and, in corporate IT, the most abused — combination of conflicting roles, is creating something and quality controlling that same thing.  This can be said of any field, really  — not just IT.  Industrial production process designers have understood for centuries now that he who quality checks should never be the one that is being checked.  Easily solved, might you think. You just need to have Judy check Imad’s work in two days when she’s available, and the issue is solved!  Maybe  —but there’s a catch. 

No Accountability and No Independence

Proper quality control requires at least one of these two conditions: (a) the person being checked and the controller must be both accountable for the level of quality of the work, or else (b) the person doing the quality control must be able to perform the reviews independently.  If Imad and Judy are both part of a team that is measured on the speed at which it delivers innovative solutions that work, then there is a good chance that quality is reduced to having a solution that works, period.   Other quality criteria are undoubtedly agreed upon virtues that no-one is against, but are not as important as speed.  As described in another article, in IT more than any other field, a working solution might be ‘under-the-hood’ a chaotic technical  collage, hardly holding itself with haywire and duct tape— but it can still work. 

These situations often occur when IT staff are put under pressure and are forced to cut corners.  As such, speed of delivery becomes in direct competition with quality when assigning the person hours required to deliver excellence.  If the small, autonomous, multi-skilled team’s ultimate success criterion is speed, then Judy’s check on Imad’s work is jeopardized if the quality of his work has no impact on speed.  In this case, because Judy and Imad are both part of a group that must deliver with speed, then none of them is really accountable for any other quality criterion than simply have that thing work. As long as it doesn’t impede delivery pace, any other quality criterion is just an agreeable and desirable virtue, but nothing more. Judy is not totally independent in her quality control role and worse, there is no accountability regarding quality.

When a small and autonomous team’s main objective is to deliver fast, any quality item that has no immediate impact on speed of delivery becomes secondary, and no-one is accountable for it.

And it doesn’t stop there: considering that quality control takes time, the actual chore of checking for quality comes in direct conflict with speed, since valuable time from multi-skilled people will be needed to ensure quality compliance.  After two days, when she becomes available, Judy could check on Imad’s work, yes, but she could also start to work on the next iteration, thus helping the team run faster.  If no-one is accountable for quality, Judy’s oversight will soon be forgotten.  Quality is continuously jeopardized, and in your autonomous teams there is a fertile soil for the systematic creation of lower quality work.  

There’s No Magic Solution: Make Them Accountable or Use Outsiders

So, what precautions must be taken to ensure maximum levels of quality in multi-skilled, autonomous teams?   The answer is obvious: either (1) the whole team must be clearly held accountable for all aspects of the work —including quality— or (2) potentially conflicting role assignments have to be given to individuals who are independent; that is accountable and measured on the work they do, not for the team’s performance.  

If you go with the first option, beware of not getting trapped into conflicting accountabilities again, and read this article to understand how quality can be challenged by how it is measured.  To achieve independence (second option), you will require having team members report to some other cross-functional team, or allow an infringement to your hopes of total autonomy by relying on outsiders.  Although multi-skilled and autonomous teams are an enticing perspective for jacks-of-all-trades, the agility they bring to the team should not be embraced at the expense of the quality of the assets you harvest from them.

Lower Quality at Scale

If you want to understand how and why unwanted behaviors such as those depicted above are not only affecting small autonomous teams, but are also transforming the whole of corporate IT into a mass complexity-generating machine that slows down business, read this mind-changing book.  It will help you understand why lower quality work products are bound to be created, not only in small, autonomous and innovation-centric teams, but almost everywhere in your IT function.

Let’s Start Fresh with a Digital Platform!

A dichotomy seems to be emerging in corporate IT strategy and enterprise architecture. Let’s take a closer look at what looks like a seemingly promising strategy to propel your business into the digital era.

A Reliable but Inflexible Set of Operational Assets

In the right corner, we have the technology backbone of an organization’s operations. This platform must be robust and standardized, and allow the business to shift toward new paradigms as seamlessly as possible. These types of platforms have been around for decades; some of them outlasting many foundational technology changes. The ability of these operational backbones to support transactional operations effectively and speedily is, in my view, a success for the IT world. Unfortunately, their flexibility and agility in face of changing business needs are mediocre, at best. Decades of chaotic short-sighted design deployments have transformed these backbones into liabilities. Such backbones are not always able to sustain change, being highly sensitive to heterogeneous, non-standard, or stove-piped solutions that find their way to production status through the loose mesh of ineffective quality governance.

In the right corner, your operational backbone: rapid, robust, but inflexible yet indispensable.

A Fresh New Platform for Digital Integrations

In the left corner we have a newer concept, often labeled the Digital Platform, envisioned as an innovative way to achieve flexibility and quick turn-around times. The central idea is smart: let’s put in place an IT infrastructure that allows the rapid development of new business integrations at the level of the extended enterprise.  By extended enterprise, I am referring to an obvious focus on external partnerships, including opportunities created by social media, Internet of Things, or the entire array of cloud-based services that relentlessly expands every month.

One of the most appealing features of the platform in the left hand corner is that it provides a clean slate for a project to start from. Absent is the burden imposed by legacy systems like those constituting the technology backbone we have in the right corner.  The novelty provided by the Digital Platform is bound to create a fertile soil for agility to blossom, inspired by the bold, highly publicized start-ups known as Market Disruptors.

In the left corner, your digital platform: new, nimble, source of promising business value.

The second promising characteristic of this paradigm lies in its function as a foundation where things can be not only rapidly developed, but easily removed. When something developed last year doesn’t make business or technical sense anymore, you can unplug it and work on a more promising integration. With no legacy artifacts slowing your momentum and your ability to continually apply and reapply integrations, you will surely be able to provide enhanced customer experiences or new amalgamated products, positioning yourself as the disrupting player.

So are Digital Platforms the way to go? Yes of course! I strongly recommend our contender in the left corner.  That being said, I also feel compelled to share a few very important words of caution on how to introduce it, as well as some caveats regarding your expectations.

I never believed in miracles – at least not in corporate IT.  Most of great things therein come from discipline and hard work.

Parallel for a Long Time

My first piece of advice relates to the right hand option. Do not think for a second that the sudden wave of hype and excitement stimulated by your new digital platform will cause your operational backbone to disappear.  Your new products, new markets, and new ideas, however promising, will not replace all the current products and existing markets overnight. The base of older technology already in place might very well continue to produce the bread and butter used to feed new ideas.

You may wish it were the case, your business is not a start-up, and your new platform will co-exist with the older ones for a long time.

Don’t assume that the latest technology replaces the previous one entirely; they must exist in parallel. Anything you do to position your business on the cutting edge of the market is a step in the right direction, but you must take responsibility for the amalgamation of your platforms. Remember: he who wills the end wills the means.  Your new platform absolutely needs the old one.

If your new digital platform were a vehicle, it would be a lightweight 4×4 truck. But you mustn’t forget that if this were the case, your operational backbone would be a train on rails with a tanker car containing the fuel for your 4X4. The implementation of a new digital platform comes nowhere near any form of rationalization.

The Old Impacts the New

My second warning involves the state of your right corner assets. The apparent separation between the two sides of corporate IT strategy, and the expected leeway provided by a clean slate solution may not last that long.  Sooner than you think, or maybe right from the onset, you will need to use data or function provided by your operational backbone; this requires an integration point like any other that your IT has created in the past. The fact that it takes its source in your new digital platform will make little difference regarding speed or limitations.

Any dependency between the old and the new will be as easy to implement as the state of the weakest link in the chain allows.

Depending on the flexibility and agility of your right hand corner backbone, the new link may be implemented in a breeze, or become the boat anchor that slows everyone down.

Magical Thinking is of Little Help

My last point concerns the business agility of the new digital platform. The new infrastructure’s ability to adapt gracefully to changing business requirements is based on two factors. Firstly, the fact that it’s new means that it hasn’t deteriorated into the state of entropy found in older assets; the clean slate is a benediction.  Secondly, the architecture patterns used to develop the new digital solutions offer evolutionary possibilities.

But declaring a new platform’s ability to support nimbleness, by easily adding, replacing, or removing components is no guarantee whatsoever that it will actually happen. Why? Because easily adding, replacing, or removing portions of a solution, an application, or a platform have been desired outcome from the onset of the operational backbone sitting in the right hand corner! Creating malleable products has been a central focus of IT architecture for longer than I’ve been working in the IT field.

Malleability has been a desired characteristic for as long as IT solutions have been designed.  This wish hasn’t shielded your current platforms from becoming what they are today.

It takes more than wishes and strategic statements to ensure that you get the agility that you expect from the new digital platform.  For that to happen consistently beyond the first 18 months of the new platform’s introduction, you need talented and forward-thinking IT architects designing assets that can be quickly rolled-out, easily replaced, and painlessly removed. These disciplined IT teams must also define and abide by strict quality standards. Finally, you need healthy governance processes to guide your decisions and determine whether or not you have successfully achieved the coveted agility ideal.

Careful design and quality work in your new digital platform are as needed as ever.

If you don’t have all the right safeguards in place, your new digital platform may organically grow into an inextricable tangle that will eventually collapse under its own weight.  It’s been often witnessed before[1], and nothing suggests that the left corner is shielded from unwanted complexity.


[1] To understand how it systematically happens, see this easy-to-read, non-technical book.

Perennial IT Memory Loss

There is a strange thing happening in corporate IT functions; a recurring phenomenon that makes the IT organization lose its memory. I’m not talking about a total amnesia, but rather a selective one afflicting corporate IT’s ability to deal with the current state of the technical assets it manages. This condition becomes especially acute at the very beginning of a project focussed on implementing technical changes to drive business evolution. Here’s how it happens:

It all starts with project-orientation. As we discussed in another article, the management of major changes in your internal IT organization is probably project oriented. Projects are a proven conduit for delivering change. Thanks to current education and industry certification standards of practice, managed projects are undoubtedly the way to go to ensure that your IT investment dollars and the resulting outputs are tightly governed. Unfortunately, things start to slip when project management practices become so entrenched that they overshadow all other types of sound management, until the whole IT machine surrenders to project-orientation.

The Constraints of Project Scope

As you may know, by definition, and as taught to hundreds of thousands of project managers (PMs) worldwide, a project is a temporary endeavor. It has a start date and an end date. Circumstantially, what happens before kickoff and after closure is not part of the project.

The scope of the project therefore excludes any activity leading to the current state of your IT portfolio. The strengths or limitations of the foundational technical components that serve as the base matter from which business changes are initiated are considered project planning inputs. The estimation of the work effort to change current assets, or the identification and quantification of risks associated with the state of the IT portfolio, will always be considered nothing more than project planning and project risk management.

Further excluded from project management are considerations that will apply after the project finish date. These factors encompass effects on future projects or consequences for the flexibility of platforms in face of subsequent changes. Quality assessments are common project related activities, likely applied as part of a quality management plan. But a project being a project, any quality criteria with impact exclusively beyond the project boundaries will have less weight than those within a project’s scope – and by a significant margin. Procedures directly influencing project performance – that is, being on-time and on-budget (OTOB)– will be treated with diligence. All other desired qualities, especially those that have little to do with what is delivered within the current project, become second-class citizens.

Any task to control a quality criterion that does not help achieving project objectives (OTOB) becomes a project charge like any other one, and an easy target for cost avoidance.

This ranking is more than obvious when a project is pressured by stakeholder timelines or in cases of shortages of all sorts become manifest. Keep in mind that the PM is neck-deep into managing a project, not managing the whole technology assets lifecycle. Also remember that the PM has money for processes happening within the boundaries of the project. After the project crosses the finish line, the PM will work on another project, or may look for a new job or contract elsewhere.

When all changes are managed by a PM within a project, with little counter-weight from any other of type of management, corporate IT surrenders to project-orientation.  When no effective cross-cutting process exists independently from project management prerogatives, your IT becomes project oriented.  I confidently suspect that your corporate IT suffers from this condition unless you already have made a shift to the new age of corporate IT.

Project Quality vs. Asset Quality

Project orientation has a very perverse effect on how technology is delivered: all radars are focussed on projects, with their start and end dates, and as such the whole machine becomes bounded by near term objectives. The short term project goals in turn directly impact quality objectives and the means put in place to ascertain compliance. Again, since quality control is project funded and managed, the controls that directly impact project performance will always be favored, especially when resources are scarce.

In project-oriented IT, quality criteria such as the ability of a built solution to sustain change, or the complexity of the resulting assets don’t stand a chance.

The result is patent: a web of complex, disjointed, heterogeneous, and convoluted IT components which become a burden to future projects.

It’s here that the amnesia kicks in.

All IT Creations Are Acts of God

When the next project dependent on the previously created or updated components commences, everyone acts as if the state of these assets was just a fact of life.

Whatever the state of the assets in place, at the beginning of a new project, it’s as if some alien phenomena had put them place; as if they were the result of an uncontrollable godly force external to IT.

Everyone in IT has suddenly forgotten that the complexity, heterogeneity, inferior quality, inflexibility, and any other flaws come from their own decisions, made during the preceding projects.

This affliction, like the spring bloom of perennial plants, repeats itself continuously. At the vernal phase of IT projects, when positivism and hopes are high, everybody looks ahead; no one wants to take a critical look behind. This epidemic has nothing to do with skills or good faith, but can instead be traced to how accountabilities are assigned and the measurement of performance.

When all changes are subject to project-oriented IT management, the assets become accessory matter. Your corporate IT team delivers projects, not assets.

The Unmeasured and Inconsequential Aren’t Getting Any Better

In part 1 of this article, we saw that what really counts in corporate IT is not only measured, but also metered quantitatively, with standardized gauges that leave as little space as possible for misinterpretations. Through exploring a parallel with the pizza delivery business, I attempted to show that anyone can be assigned conflicting accountabilities, such as delivery speed on one hand, and driving regulation compliance or fuel consumption mindfulness on the other. The only way to juggle these clashing devoirs is through the application of control measures, and the establishment of personal or team-based incentives linked to the resulting indices.

Incentive-Based Performance

Now, if one of the controlled expectations is quantified and directly linked to next year’s bonus, but the other anticipated behavior is not numerically evaluated, what will happen? The result will be the same as it would within our pizza delivery example. If you don’t measure the time it takes for each driver in your team to deliver pizza, then respecting driving rules (because the controls are already in place) and minimizing fuel burnt (assuming this is metered) become the top priorities. When the time comes for yearly performance reviews, delivery time will be left to the manager’s memory of the past 12 months and the driver’s ego. You already know that the manager’s memory will be focused on the most recent weeks, and that the drivers will naturally overstate their delivery speed.  This just wouldn’t work; you would get safe, low-carbon footprint, legally respectful driving, but slower delivery times that would jeopardize customer experience –and your competitive edge.

What’s Measured and What’s Important

In Part 1, I presented a table illustrating the usual assessments of performance for the IT function. These indicators are measurable and precise. They also represent the true gauges of personal performance.  Failure to perform adequately in the KTLO (Keep The Light On) category, can rapidly lead to dismissal.  Underperformance in the OTOB (On-Time On-Budget) category may take more time to notice, but will eventually translate into career changes. I’ve charted this reality in a simple but eloquent figure.

At the end of Part 1, I related a simple question: “What about all the other good things you should expect from your corporate IT function?”.  You should now grasp that any such remaining features will fall in the lower left hand quadrant of this figure. They are not measured quantitatively or not even gauged, and they have little impact on IT staff keeping their jobs.  If you believe that IT’s performance should cover much more than KTLO or OTOB accountabilities, then I strongly suggest that you scale back your expectations concerning behaviors unassociated with the upper right hand categories.

I strongly suggest that you scale back your expectations concerning behaviors associated with anything else but KTLO or OTOB accountabilities.

The next burning question is obviously: “What falls under ‘The Rest’?”  As its name implies, this category encompasses all other desired duties: the mundane and less significant ones, as well as the crucial virtues that seriously impact the quality of corporate IT’s output.

Another Problem For IT to Solve?

In several upcoming articles you will discover that the perception of quality and the means of its control are significantly related to its position in the chart above. Quality controls specifically associated with quantitatively measured KTLO performance objectives will be defined and applied.  I can safely bet that your IT function is pretty good at those tasks. I can also confidently speculate that the quality controls which play an active role in delivering products on-time and within budget are taken seriously and applied systematically.

The remaining controls are mostly subjective, or plainly nonexistent, thanks to the few repercussions that inefficiencies in these areas have on people’s jobs.

Unfortunately, many missing measures can have a direct impact on your organization’s capability to react promptly in an ever-changing environment.  Important areas such as compliance to your own standards, ease of maintenance of platforms, reuse of existing assets, adaptability, or documentation have little impact on people’s jobs, and are, at best, qualitatively measured, if measured at all. These areas fall under “The Rest”, and are probably poorly managed.

But if you think that you simply need to demand that your IT organization be better at those things, you are misled.  The performance criteria in The Rest have been neglected for decades.

All attempts that I have seen or heard of were either weak, unevenly applied, or didn’t last very long.  As long as the current hierarchy of rewarded behaviors reigns, it won’t happen.

But expanding what really counts above and beyond KTLO and OTOB requires to remove the conflicting accountabilities.  As described in a previous article, your IT function is stuck in an engagement model where, for convenience and historical reasons, a single desk is given all accountabilities.  As you will see in my upcoming book, your IT has little means for implementing a healthy segregation of duties, and has cashable incentives to remain mediocre in several key areas.

What Drives Quality

Making parallels between corporate IT work products and those of other fields is adventurous. Nevertheless, I need to find a way to explain what quality control means for corporate IT without getting technical.

Imagine for a moment that your corporate IT team was not delivering technology solutions to your business, but rather automobiles.  Also assume, for the sake of the parallel, that your usual corporate IT quality controls would be applied to these cars.

The car would be put on a tarmac track and a test driver would start the car, accelerate, turn right, turn left, and brake. She would also open all doors and windows, check the fuel gauge, engage the lights, turn on the radio, open windows, tilt seats – everything.  In short, all features would be tested for their practical effectiveness. The car would then be handed off to its owner. That’s it.

Are you tempted to say that it’s enough? If all features and functions are operational, then the quality is where it should be? Of course not.

Fortunately for car makers and owners, some important points are missing from the quality control plan I’ve outlined above; especially determining how well the car is built and assess its ability to handle sustained use over a period of time – long after its sale to a customer.  In the automotive industry, these procedures will address a world of additional concerns such as: will the car be plagued with rust holes in 12 months?  Will the brakes require changing every 1000 miles? Will the corner garage mechanic need to drill a hole in the engine pan to make an oil change?

Carmakers have understood long ago that features are not enough if the product does not show many other qualities like longevity, safety, maintainability or reliability. But corporate IT is a strange beast whose behaviors often defy common sense.

So strange that the IT equivalent of drilling a hole in the oil pan is not that farfetched.

Project-Oriented IT and Quality Control

The scope of quality control on technology solutions can be qualified as business requirements centric. Far be it from me to downplay the extent of the tests required to ensure that all requirements are fulfilled, but that’s far from enough. The resulting output can only suffer from inferior levels of excellence when certain areas aren’t duly inspected. It’s true for cars and applies universally to any situation where there’s a mix of human beings and tight schedules.

How simple will it be to expand the solution? How much effort will it take to retire that solution? Will future generations of IT staff have crystal clear technical documentation at their finger tips? Can this solution easily integrate with other systems or technologies? These questions cannot be answered by controlling the correctness of features and functions.

To understand the dynamics responsible for deficient quality control of corporate IT output, one must first recognize that any change to existing assets or new asset creations are made within the context of a project. This makes sense, since nobody wants multi-million endeavors governed by anything less than good project management practices.

The issue doesn’t lie with the use of project management wisdom. The problem is that corporate IT decision-making processes are heavily skewed toward the use of project management logic, even in cases where different rationales should be applied. I call this ubiquitous pattern Project-Oriented IT.

Remember that a project is, by definition, a temporary endeavor[1]; it must have a start date and an end date, or else it’s not a project. This also means that anything happening before the project start or after its finish will not be considered part of the project.

So, within our carmaker analogy, the project end date will be when the automobile is delivered to the customer with all promised features functional.  An IT project will be deemed complete when the solution and all of its components are successfully tested to make sure that every feature works properly.

These tests do not acknowledge issues that may (or may not) arise months or years later. A few moons after the IT solution is delivered, the project will have been closed for a long time. Long-term quality does not fit easily into a project.  In project-oriented IT, considerations equivalent of car maintenance costs, body rust, or the premature wearing of parts are rarely a concern.

QA Skills and Independence

“Aren’t corporate IT quality control processes intended to check all these things?” You might be tempted to ask.  The sad but true answer is: not really. For all aspects of quality to be checked systematically and consistently, there needs to be a certain degree of separation between those that build quality and those that control its presence. In most cases, the independent quality controls cover only business features and are being carried out by the only unconnected parties in the equation: non-IT folks working for the business sponsor.

These individuals will conduct checks according to their skill sets, which don’t include the technical knowledge required for looking under the hood.  Those that have the skills to inspect the engine and the cabling are probably busy welding another car (working on another project). Even when the internals of the solution are checked, the reviewers are rarely independent enough because they are working under the auspices of project-oriented IT where many quality concerns are of a lesser importance.

In an upcoming article, I show that conflicting roles lead stakeholders to quickly pushback against any quality criterion that doesn’t directly help a project within its immediate lifecycle. You will also discover that these same accountability issues are killing the independence required to perform quality controls covering all aspects of the value of what is delivered.

Your takeaway from this article is simple: when it comes to controlling the quality of what you get from your IT investment, you hardly get anything better than a test drive.

To change this, the distribution of measured accountabilities must change in such a way that all aspects of quality are evaluated, not just those that directly impact a project’s delivery. In a soon-to-be-published book, I will dive in all aspects of IT that impede the creation of quality assets, all of them being rooted in the roles distribution, the accountability given to these roles, and the associated measures of performance.

[1] As defined by the Project Management Institute and applied by its hundreds of thousands of certified professionals.

No One is Accountable for What Is Not Measured

In a previous article on the construction industry’s distribution of roles, I demonstrated that centuries of cumulative trials and errors have led to a clear delineation between the main stakeholder’s responsibilities, all to the benefit of the paying customer and the public in general. In corporate IT, as we saw in the following article, things are quite different: the paying customer deals with a single desk that plays all roles.

The healthy segregation between those that define the solution and those that build it, those that set standards and those that use them, those that deliver excellence and those that control that quality, is unquestionably absent. 

It would be a mistake to believe this is due to the nature of the solutions being built, as segregation of roles was not always present in the construction industry either. Roles definitions were once an issue, as we can see by this citation from Philibert Delorme [1514-1570], architect and thought leader of the Renaissance:

Patrons should employ architects instead of turning to some master mason or master carpenter as is the custom or some painter, some notary or some other person who is supposed to be qualified but often than not has no better judgment than the patron himself […]”[1]

In my career in IT, I have seen it all: projects without architects, improvised architects with skills issues, true architects without any architecting accountability, architects left to themselves with no organizational support, IT managers architecting, project managers architecting, customers architecting, programmers architecting. These cases are not exceptions, but rather the norm, in one form or another.

There are two main reasons for so much laxity in the execution of such an important function as IT architecture: conflicting roles and lack of measures.

First, the conflicting placement of the architect, often located in a quarter where he/she isn’t able to truly defend the customer’s interests, is subordinate to line managers or project managers that have higher priorities than architecting solutions the right way.

Second, expectations towards the quality of the architecture are neither set nor gauged, again, because there are more urgent and measured accountabilities hanging in the balance.

With little consequences for wrongdoings, it’s no wonder the architect’s role is so easily hijacked by whoever wants to have a say in that area. 

IT architecture is a field where anyone can be elected, or self-elected, to the status of an architect, as long as he/she can make things work. But as we saw in a previous article, a working solution doesn’t prove much. Everyone can have an opinion on the right way to design but is never held accountable for the quality of it.  Opinions without accountability on the subject are as relevant as any other conversation around the coffee machine.

Fortunately, by balancing the distribution of roles with healthy segregation, measures of performance can move toward a healthier equilibrium, so that coffee machine discussions don’t become IT strategies that put at risk million-dollar projects.  The architect’s role will stop being usurped, for doing so will then entail being accountable for it.  An in-depth analysis of these insights and more will be available in my upcoming book, to be published soon.

——-

[1] Catherine Wilson, “The New Professionalism in the Renaissance,” in The Architect: Chapters in the History of the Profession, University of California Press, 1977, p. 125.

The Impossible Polygon Behind the Single Desk

In Part 1 of this series of two articles, I presented a high-level description of the engagement model used in the construction industry, and how the 3 main stakeholders share accountabilities and duties. Although these three poles have diverging concerns which often lead to conflicting viewpoints, the system works because (a) the roles are clearly defined, and (b) there are institutionalized mechanisms in place to safeguard the stakeholders from potentially detrimental misbehavior.

Let’s look at the most interesting part of this comparison, focusing on the relationship between stakeholders[1].

The Construction Industry Engagement Model

In the construction industry, a customer hires an architect to define the specifics of the structure to be built. The customer then hires a builder, often collaborating with the architect during the selection process. It is quite customary for the architect to perform worksite inspections within the construction engagement model, in order to ensure that the builder has conformed to the drawings and specifications.

The Turn-key Alternative

There is an alternate engagement model in the construction industry called a “turnkey” project. In this model, a customer hires a builder (usually a general contractor) to take care of everything, including architecture, engineering, building, landscaping, and even the procurement of permits. There are two major advantages for the customer within a turn-key project: engaging with a single point-of-contact, and getting a single price that includes all costs.

There are, however, major risks for the customer choosing this type of project: he is placing complete trust in a single party, while forfeiting the independent quality control available through an architect’s worksite inspections.

Industry Safeguards at Play

Most customers are aware of these potential liabilities, which is why many of them chose the standard A-B-C engagement model. But if one chooses to go with a turnkey arrangement, there are many structural mechanisms to protect the customer in a standardized industry such as civil construction, as described in Part 1 and depicted in the figure below.

Even when the customer deals with only one provider who monopolizes project operations, the city inspectors, trades certifications, building codes, and professional orders remain independent. As for standards compliance, an architect can lose her license to practice if building codes aren’t respected; professional order disciplinary committees or judges will demonstrate little empathy for the fact that she was working for a general contractor who signed directly with that customer.

This variation of the construction engagement model (turnkey) is very important because it mirrors the usual relationship between your organization’s business sponsors and corporate IT. This similarity only exists on the surface, however. There is a huge difference:

there are no external, independent bodies that oversee, standardize, or control the activities and the outputs of your IT department.

The IT Engagement Model Applied to Construction

If we were to apply the IT engagement model to the construction industry, it would resemble the figure below:

The IT systems builder who you engage with is, in fact, responsible for literally everything: gathering requirements, designing the architecture, engineering, managing all the various specialty skills, and of course delivering the solution that you need.

But that’s not all. Your IT builder takes care of the (not so) independent controlling bodies in our construction parallel. The IT counterparts of the construction industry safeguards described above are embedded in that same team.

The corporate IT function determines all standards, establishes mid and long-term plans, baselines the required skills for all IT trades, assesses the adequate knowledge level of staff, delineates roles and their respective accountabilities, and last but not least, oversees its own compliance to the quality standards it defines.

It’s Worse Than You Think

If you think it’s already too much for your definition of segregation of duties, there’s more. Corporate IT is not just responsible for building technology-based business solutions; the same team takes care of everything under the IT sun.

If we were talking about the construction industry, your builder would also be responsible for supplying water, power, gas, road maintenance and emergency services. To top it all off, you are left with a single builder, and very little leeway to shop for alternatives.

I’ll let you call this model what you like. The detrimental effects caused by this monopolization of roles are significant and serious. It increases costs, slows the speed of delivery, and of course lowers the quality of deliverables. In the upcoming articles and book, I will describe in more relatable detail the repercussions of this engagement model. The source of these woes can be traced to its most fundamental, foundational root cause: ill-distributed roles. And that’s a promising news, because it has nothing to do with technology and non-IT business people can shift the model to a healthier and balanced geometry where the paying customer’s interests will be better served.

————–

[1] For a deeper dive into the construction industry, its structure, and the wisdom it can impart, take a look at the soon to be published Volume 1 of An Executive Guide to the New Age of Corporate IT . This article is in fact an elevator pitch for Chapters 1 and 2.

The Geometry of the Corporate IT Engagement Model

Part 1 – Century-Old Wisdom

If there’s one business where they’ve got their angles set right, it’s the construction industry. I am not referring to the fact the workers all carry carpenter’s squares in their tool boxes, but to their organized management of roles, responsibilities, and accountabilities*. I came to this realization a few years ago while digging through construction contractual agreements, governmental regulations, and professional order bylaws. The structure of stakeholders in the construction industry and their relationships can be summarized and abstracted as follows:

  1. The customer (C). His responsibilities are to provide the requirements, supply the funding, and approve the specifications.
  2. The architect (A). Her duty is to define what has to be built, based on the customer’s requirements, in compliance with codes and regulations. The customer hires the architect.
  3. The builder (B). His job is to build the conception based on the architect’s specifications, while adhering to codes and regulations. The customer hires the builder.

 

The Three Poles Dance

In general, the ABC business model works fine, despite the following natural antagonisms that exist between these polarized roles:

  1. The customer often knows exactly what needs to be done, and feels he could manage without the high-priced services of an architect. He also feels that the builder, especially if the chosen one was the lowest bidder, is trying to transform any unspecified detail into a change order and will do everything to get his profit back. The customer’s objective is to maximize his return on investment, whether it be sales, rent, property value, family happiness, or social pride.
  2. The architect often has the impression that the customer changes his mind too often, doesn’t have the means for his ambitions, or is inaccessible when time comes to sign-off on blueprints. She is also convinced that the builder will cut corners to raise the profit margin, or consult directly with the customer and deviate from her specifications. The architect’s objective is to maximize customer satisfaction while remaining profitable, given the time spent on the project. The architect works in a market where reputation and past experience are crucial.
  3. The builder is convinced that he knows how to build with or without the architect: an extraneous player who often can’t drive a nail into a 2X4. He also believes that customers take advantage of him by constantly requesting incidental extra work while remaining resistant to official change orders. The builder’s objective is to remain profitable by maximizing effectiveness, minimizing rework, and optimizing material usage. The builder operates in a highly standardized and competitive market where price is the main differentiator.

Fences Around the Construction Playground

The polarized roles described above could lead to discord or confrontation. But the construction industry, through centuries of feuds and casualties, has developed a series of safeguards to control the behavior of the stakeholders. The main defenses against misconduct are:

  • Building codes that define standards required to ensure minimum levels of quality and safety.
  • Town planning departments that provide additional guidance regarding building sites, optimized use of shared infrastructures, and development expectations of community residents.
  • Constituency construction inspectors who independently examine the project’s compliance with the approved plans, building codes, and local regulations.
  • Trades certifications that legally enforce safe standards of practice for builders.
  • Professional orders that endorse the right to practice for architects and engineers, define a code of conduct and manage alleged or confirmed misbehaviors.
  • Duly voted laws and published regulations that legally enforce all of the above, from building code compliance to the letters patent of professional orders.

All of these safeguards have the obvious objective to protect the customer and the public in general.

When Things Go Awry, Roles Are Never Questioned

The construction industry has a pretty heavy legacy of issues that often finish in courts of law. These range from petty misunderstandings to serious worksite casualties and building collapses. As in any other business, when things go awry in construction, fingers point in all directions until guilt is determined and restitution is achieved.

But in such cases there is one thing that is never questioned: the engagement model and the respective duties of the three roles. The customer owns, pays, and approves. The architect understands, designs, and complies. The builder constructs and complies. Each stakeholder knows what the other has to do, and can recognize when another steps out-of-bounds. These crystal clear roles leave little space for interpretation, and are often textually described in contracts.

Century-Old Wisdom

Houses are buildings, but a software-based business application is not a building. Corporate IT is a very different business than the civil construction industry; processes, tools and, most importantly, the base matter to work from are worlds apart. I nevertheless strongly believe that corporate IT could benefit from focusing on the applicable similarities rather than technical differences with this model from another field. Centuries of trial and error have yielded highly reusable practices:

  1. Clearly delineated roles that minimize misunderstandings and quickly expose conflicts.
  2. Defined standards, which are understood by all.
  3. Independent bodies that control compliance of the work.
  4. Incentives and penalties that are directly linked to responsibilities.

In corporate IT, these four elements are either absent, neglected, or ill-defined.  In my opinion, these deficiencies can be traced to the engagement model used internally for corporate IT. And this is the subject of the second part of this article.

———————————————–

* For a deeper dive into the construction industry, its structure, and the wisdom it can impart, I invite you to read my book, Volume 1 of An Executive Guide to the New Age of Corporate IT.  This article is in fact an elevator pitch for Chapter 1.

Suspicious About Your Corporate IT’s Speed?

Are you left perplexed when you compare the technological quantum leaps that humanity has witnessed in recent decades to their net effect on the efficiency and speed of your corporate IT function?

Does your mood range from remotely curious to downright fed up when you assess your IT department’s inability to keep up with the pace of your business?

Are you coming to the same conclusion as me: that when it comes to responding to changing business needs, corporate IT has been, at best, steadily mediocre throughout the years?

Do you have the unending impression that your corporate IT continues to show signs of an immature field, even after decades of experience?

Are you suspicious that behind the curtains of technological know-how lies a monstrous amalgamation of old and new technologies, created by the same corporate IT team whom it baffles?

If you’ve answered yes to any or all of these questions, then I have two pieces of good news for you.

The Good News

Firstly, you’re not paranoid.  After three decades of working in corporate IT, I can assure you that these are matters that you should be concerned about.  Even in different times, amongst different industries, or within different countries, every IT professional I consulted before publishing acknowledged the manifestation of these issues again and again.

Secondly, you will soon have a refreshingly different perspective on the sources of these issues.  The processes that have been used to explain or to deal with corporate IT’s performance issues until now lack a deeper understanding of their non-technological root causes.

Ignore the Technobabble

The answer is not yet another miracle IT solution, vendor, system, or new technology.  You’re probably already under a deluge of technobabble sales pitches, each implying in their own way that big data, disruptive innovation, artificial intelligence, internet of things, machine learning, augmented reality, DevOps, micro-services, or the acronym of the year will propel you into another sphere beyond your current issues.

To get to a new age of corporate IT, a different approach is required: to understand how corporate IT’s underachievement in certain crucial areas — notably, the quality of deliverables — is unrelated to technologies and methods.  You’ll discover the true culprits: basic management and governance issues leading to unwanted behaviors, which, in turn, diminish agility.  We will get to the bottom of a cause-and-effect sequence, and reach a point where everything will look much simpler, for the root causes of it all are areas where non-IT business executives can act upon.

Lead the Next Phase in IT

By changing role distribution, transferring accountability, and reviewing the measures of performance, business leaders can bring about a profound and lasting movement to the next phase in corporate IT maturity.

You can shift the center of mass in your business and then let the technically savvy execs and managers take care of the detailed processes and logistics required to complete the transition  to the next level.  Don’t change the players, change the game.  Don’t engage with the details yourself; change the engagement model.

What’s Coming Up

Over the next weeks, you will learn why your suspicions are far from being groundless.  You will also gain priceless knowledge about how corporate IT operates behind the closed doors of technical expertise. I will provide a fair -and at times brutal- investigation of these concerns, unveiling issues such as the systematic creation of pointless complexity, the over-use of project management principles, the corporate IT “amnesia syndrome”, and many other quality issues that hinder attempts to speedup IT delivery. It should get you primed for a new book available now.

1