Where Consulting Orgs and Their People Should Focus – Culture


The question of why a project manager would choose one consulting firm over another is something that greatly interests me – even deeper than this is the question, why would anyone choose consulting over a traditional employee/employer relationship. For me, prestige is the first thing that jumps off the table: consulting firm employees are much more likely to have selected that as a major reason for choosing a “firm” vs the McDonalds IT department. Which makes sense: if you work for a prestigious firm, you’re presumably more likely to list it as an important factor I’d think.

Employees of big consulting firms are likely to list prestige as a deliberation in making a career choice. I don’t have anything close to a fully thought-out theory to explain this, but here are my two working hypotheses:

1)      Maybe the consulting firm does a great job of hiring modest, attentive employees who care about doing the best possible job they can for clients.

2)      When you by now know your firm is the top of the pile in its industry, maybe you justify other factors instead, and prestige is just the ante to play the game.

(Or perhaps it’s something else entirely. Feel free to draw your own conclusions)

OK, so you’re a part of a consulting org, a prestigious one; what revs your engine every day – is there a fire in your belly, is there a fire in your managers belly? Carnegie Mellon University did a survey of 30 organizations to examine the impact on several performance categories when they moved from one maturity index level to the next. In Project/Program Management in particular, the situation at most of the clients where I’ve worked follows a discrete pattern: a pressure exists between customer-facing business units and internal cost teams like IT. Customer needs for new products and services almost always surpass internal capacity to deliver, whether in terms of people, skills, equipment, economics, or something else. That gap between what’s needed and what can be delivered is where the project team and its manager need to focus. Prestige takes the face of many helpers, while insignificance takes the form of many who are arrogant.

Prestigious firms have tools, prestigious firms have mentors – not all firms are prestigious.

Some consulting establishments typically operate at a fairly low level in terms of their project management maturity. You’re no doubt familiar with the “capability maturity model”, a guideline created at the Software Engineering Institution in Carnegie Mellon University that spells out five levels of maturity. Level one of the PM maturity model implies the use of ad-hoc practices. When a crisis hits, for instance, plans are often unrestrained altogether. Projects tend to be chaotic. When a project succeeds, it’s often because experienced individuals perform “heroic” efforts.

Scheduling in improved optimizations by 50 percent; proved out that productivity increased by 61 percent – that’s an 18% margin just for the sake of getting better at your craft. In other words, as companies grow in their maturity levels, the payback is dramatic. You’re now asking yourself, how prestigious would Carnegie Mellon consider my company if they looked at us on the maturity model scale.

Even moving from level one to level two, according to research by Gartner, helped organizations improve schedule variance by 145 percent – schedule variance being an indicator of over-all success, a driver of prestige. In other words, moving from chaotic processes managed on the fly to some fairly basic project management practices can help a company that misses its schedule predictions nine out of 10 times to actually hitting its schedule 14.5 times more frequently. Even with as simple as this all sounds, implementation is difficult at best.

Beyond “prestige” and the maturity model mentioned above, part of maturity management progression goes beyond producing project charters, comprehensive schedules and colorful status reports. Today’s project manager must obtain the skills necessary to combat numerous contemporary challenges. Factors such as rightsizing, private equity merger mania, constricted finances, a multidisciplinary ecosphere, mounting competition and seemingly perpetual change, whether acting singularly or in-concert, demand so much more. Learning to manage time, money, quality, scope, risks and other traditional practices is vital groundwork for creating a great firm and at its foundation is often good project management and moving the maturity needle.

In MBB firms, (McKinsey, Bain and BCG) the most prestigious in consulting, more than anything else, you’re going to see big variances among these firms when it comes to process and culture – the maturity model paragraphs above cover the process, the ones below cover the culture.

McKinseyites are smart, business-like, and do not very often carry the highest EQ scores amongst their colleagues. They are trained to attack a problem in a specific way – so no matter which office you’re in or what job grade you’re at, you can count on The McKinsey Way. The organization itself is structured and formal, and everything from attitude and attire at McKinsey reflects that. The firm is known for its long legacy client relationships and even longer reports.

BCGers are imaginative, pioneering, and play in the “C” ranks – they are thought leaders in their fields. BCG puts a strong emphasis on both teamwork and individual contributions when it comes to projects. BCG is also great at looking forward for trends in business and the worldwide economy.

Camaraderie, network, and principle characterize the culture at Bain, where the local office culture is strong and the focus is on collaboration. Considered the “frattiest” of the MBB firms, Bainees know how to enjoy a beer in the office on Fridays. This atmosphere of “work hard, play hard” is a huge magnet for new recruits. In head to head recruiting, Bain often beats out BCG because of culture but loses to McKinsey based on prestige or brand-name.


Developing a culture where people can be confident and where improvement is continual incorporates a lot of characteristics of the corporation – guidance, the atmosphere, the practices of the individuals involved and their expertise and ability, how gaps in aptitude are addressed, and at some point, the developments and methodologies adopted to help people and teams function.

There is no silver bullet in realizing authoritative command of your organization. Creating prestige isn’t easy, you need to drill down on the business inadequacy that’s limiting the firm; then you need to present a case for solving it in a quantifiable way. Six months to a year. That’s all it should take to get your momentum going in the right direction and to give you the energy you need to build a culture that will advance your business’ performance.

Shakespeare’s perception – “we know what we are but know not what we may be” eloquently ratifies the potential for you to improve your excellence. Permit yourself to seek the right skills. Cultivate high performance. Delight in the results. Be prestigious in your own right.

Hive Minds in Program Management

“Hive Minds Create the Perfect Program Management Model”

by Bill Thomas
March 16, 2019

 Hive Mind; (Google Definitions)

  1. a notional entity consisting of a large number of people who share their knowledge or opinions with one another, regarded as producing either uncritical conformity or collective intelligence.

The Hive activity expressed in the intricate, coordinated performance of a colony of honey bees, is regarded as analogous to a single mind controlling the behaviour of an individual organism. The collective consciousness or Hive mentality, analogous to the behaviour of social insects, in which a group of people become aware of their commonality and think and act as a community, sharing their knowledge, thoughts, and resources – the global hive mind that has emerged with sites like Twitter and Facebook where such a group, attitudinally categorized by uncritical conformity and loss of a sense of individuality and personal accountability


“The tiny bees in a hive are more or less unaware of their colony, but their collective hive mind transcends their small bee minds.”

— Sven Birkerts and Kevin Kelly

It’s en vogue at companies today to be single-minded toward speed. Fanatical to fail fast. Dedicated to deploying daily. Impassioned to iterate immediately. This regularly translates well for software development and IT teams but can backfire when building a consulting division Your question is likely, why or how can it backfire? There’s suddenly a very urgent and important question. Like democracy, a hive mind free-for-all where the non-management always outnumber the management;  Hive or Democracy enables the many to outvote the few. A profoundly threatening prospect to the few or to the management. If the few possess power and leadership, they may respond to this prospect by resisting the Hive before it arrives—or sabotaging it afterward. Notwithstanding the lure of agility and victory, don’t take the shortest footpath hunting for riches or ease. Use a business-based process for building an authentic and engaged communal community where everyone understands at the end of the day, business is business and this isn’t a democracy, but it is an environment where one can flourish and excel.

Understanding the pains and gains is another aspect of the Hive coalescence.  Ask enough “whys” and you’ll get to these facts. Pains are usually the most uncomplicated to list – most people stop there. Put a group together, incent them to be the best and they’ll eventually ask “What gets in the way of a person’s job?” Gains are NOT simply the “contrary” of pain. Instead, gains are the hidden motivations people have, their purposes, actions that bring them satisfaction. It takes an attitude and a determination to uncover these. Keep asking better open-ended questions, dig a bit deeper. What does your stakeholder really aspire to do that they cannot do now? If gains sound rather existential to you, that’s undoubtedly because great gains often are.

Program Management now focuses on much more than being billable. Google turned 20 years old in September of 2018, that significant birthday realizes a business more powerful than ever before. The Big G gives the impression that it is likely to grow even further. Their secret sauce? For me, a Principal Program Manager, it’s the “Google hive-mind” where robot arms learn to negotiate a cluttered world. Markedly different than others that follow an inflexible top-down master plan, the Big G’s approach and follow-on success is formed by pronouncements often made autonomously of Larry Page and Sergey Brin. But Collectively, Consciously, and Competently these conclusions DO articulate a master plan, a hive mind plan that prescribes what the company will do. Getting robots to pick up objects with the same dexterity and success-rate as a five-year-old child is no minor task in the advancement of flexible automation systems. Getting clients to be successful in spite of their own politics sometimes take out-of-the-box thinking. Google research scientist Sergey Levine, said at a high level, current robots “observes the world around it, formulates an internal model, constructs a plan of action, and then execute this plan. This approach is modular and often effective but tends to break down in the kinds of cluttered environments that are typical of the real world.” Here, insight is imprecise, all representations are wrong in some way, and no strategy endures its first contact with reality. Hive minds can break the paradigms, they can break the codes.

The hive mind has been enormously effective in increasing Google’s business through a symbiotic relationship between its robots and management. If you look at other successful Hive-oriented entities like GitHub, Xamarin, Braintree, Twilio, Heroku, Stack Overflow, and MongoDB. They all have a common equation; Collective Consciousness – the trend is clear.

In some organizations, its Program Managers believe that their teams live or die on the effectiveness of their members. Team Members advance mission critical business rain or shine, hot or cold, good or bad and even tough or impossible. Many have found that clients call when the risk is FAILURE and they need to stack the deck in their favor.

What many are beginning to do:

  1. Support a “Collegial Methodology” which:
    1. Is built around an uber-unique culture based on the “hive mind coalescence”
    2. Uses its brain-trust to craft ever improving process, methodology and increases “time to solution” KPIs and captures it for reuse
    3. Recognizes that “synergy” is at the heart of their success and people are their asset
    4. Have a collective approach: “when one of us is challenged, we call upon the scrum, the entire team – all of our mates”

Clients rely on the primary beliefs around the Collective Conscious Competency, the Hive Mind and uniquely patented methodologies that have been proven over time. Imagine now that when a client engages one of ‘us’, they get all of ‘us’. As part of the Hive, every Program Manager has immediate access to the Global Collective Conscious Competency model when they have a client situation. These models can include:

  • 911 emergency email distribution list
  • Incentives based on “First Responder” and “Best Responder” participation
  • Exclusive access to the Collective Conscience Competency Knowledge Base Library that uses Situation, Background, Assessment and Recommendation [SBAR] case scenarios that are industry specific for situational problem solving
  • And the “tour de force”, a hot-line for their members, “le temps d’agir” or “time to act” Emergency Alert Notification Response System – a 24/7/365 hosted WebEx where their team members help every onsite Program Manager run solution scenarios just like a heart surgeon running the aorta for a potential aneurysm

This is the basis for the mantra: “Wherever I go, there we are

Collective Conscious (Wikipedia) French: conscience collective; a set of shared beliefs, ideas, and moral attitudes which operate as a unifying force within society. The term was introduced by the French sociologist Émile Durkheim in his “The Division of Labour in Society” in 1893. “The totality of beliefs and sentiments common to the average members of a society forms a determinate system with a life of its own. It can be termed the collective or creative consciousness.” — Émile Durkheim

Like many instances, the Hive Mind was born out of a need to repudiate the status quo of program management. With opportunity facing teams, the opportunity to make program management more important, Program Managers gathered like the eusocial, flying insect within the genus Apis of the bee clade. Known for construction of perennial, colonial nests from wax, for the large size of their colonies, and for their surplus production and storage of honey. PPM members together, asked the question “What if we could build an expert system made up of the best consultants you’ve ever worked with, people that you wouldn’t hesitate to put in front of your best customer?“ What if we created a better honey-comb….

It’s all about team trust – all of us recollect the best consultants we’ve worked with for their capacity, hunger, capability and like-ability. At emerging Program Management Offices, they bring these people together for their experience in creating communities of problem solvers who are at the top of their game, giving colleagues a delivery system, enabling them to support clients from concept initiation through operationalization. They take this wide-ranging and bottomless web of requirements and wrap it together through extensible process architectures, systematically documented experiences and Big Data driven pursuits; then via a decentralized management infrastructure, they provide world-class services.

If Honey Bees must gather nectar from two million flowers to make one pound of honey and one bee has to fly about 90,000 miles – three times around the globe – to make one pound of honey; “then how many Program Managers does it take to solve your companies Digital Transformation problem?”

The bees’ buzz is the sound made by their wings which beat 11,400 times per minute. What kind of noise does a group of Program Managers make?

Wherever I go, there we are

Bill Thomas is a Principal Program Manager and Enterprise Architect for Dell Technologies Global Transformation Professional Services division since 2011. Bill is based out of the small, quiet suburb of Anthem, Arizona, just 15 miles north of Phoenix. Bill works in the Health Care and Financial Services sectors and supports some of Dell Technologies very largest clients.

What is Complex Program Management?

Most “complex” projects are ones, estimated by executives, which are or will get into trouble. Usually caused by cost, schedule or performance issues which require an unending amount of re-programming or configuration driving constant schedule changes, personnel changes and cost containment measures – complex, and hard by their nature.

Nearly all large and many small projects exhibit characteristics of complexity. In complex programs, problems for management stem from the assumption that the outcomes, imagined at the beginning of the project, can be determined early in the project and then delivered as planned. This approach or assumption of projects and programs only works for a limited number of project types – non complex types. Once a project reaches a critical size, time-frame, level of ambiguity and dependencies, standard management approaches simply do not work for the entire program.

So, to answer the question “what is complex program management and how do you manage complex programs”; start by understanding what a complex project is by using the characteristics outlined above and ask yourself if it applies to your current situation.

If this defines your project, you have a complex project and this will require a different approach. The key to handling complexity is to appreciate where the complexity originates, and the safeguards that your strategy puts in place up front, to undertake each element of complexity identified in your analysis.

As consultants, we should remember that programs that are hard are not necessarily complex. More often than not, most projects and programs will be “hard” if you, the consultant, are there. Companies do not generally hire consulting companies for soft-ball programs. Companies pay our rates when projects and programs are considered high risk, beyond internal skills, too big for staffing levels, or just technically beyond current capabilities. So make sure you are honest with yourself when looking at the characteristics outlined above; is this a hard program or is it a complex program?

As a Transformational Program Director for Dell Technologies, having worked and led several uber-large programs I would consider complex. It is my belief that there are four elements to program complexity, these are based on my experience in top 50 accounts.

First: political complexity, second: cost complexity, third: schedule complexity, fourth: technical complexity.

Politics: This critical element entails sometimes combating, sometime ebbing and flowing with corporate dogma, political alignments, commingled budgets, fractious-priorities, work-force atmosphere and executive sponsorship. This requires a detailed political agenda which constantly requires personally touching and communicating with executives and underlings highlighting the goodness of the project or program.

Cost: Money is always a complexity. From not having enough to complete contracted requirements, to how money is phased (milestones) into the project. Undoubtedly the most complex is getting it. Know your numbers by heart.

Schedule: Time is like money, there never is enough of it. Technologies or demanding engineering tasks that obtrude the critical path also obscure schedule because of the risks associated with them. Many projects cannot move from one phase to next without these critical path tasks completed. Understand your minimal viable product (MVP) and the critical path to deliver it.

Technical: Technology is itself a complex issue. First, divergent to the biological species, technologies are not “given” in nature, but man-made constructs built on the premise of creating some sort of a ROI. Technology is the product of cultural and disruptive revolution, rarely anymore just evolution. Technologies do still, evolve, this creates the need for backwards compatibility and regression testing. There are many other reasons the technical content of a program can cause complexity, such as technology, significant systems engineering, large complex software development, multiple integrated interfaces and interfacing with multiple complementary projects, programs, systems and users. Find and keep trusted resources close.

You are in a complex program when your arrangements as a manager have effects that are tough to predict or present, when unexpected outcomes are becoming more the nrom. Program developments come together so that it is challenging to see how root causes and outcomes share binaries, and it is demanding work to disentangle all the various characteristics in the final outcome.

So to this Program Director, the key to spotting complexity is to question it as outlined above, and the fundamental success to managing it is to understand where the complexity started. Once there, meaning – you understand the nexus of the issues, begin by adding safety measures via your portfolio of strategic methodologies to manage each element of complexity acknowledged by the analysis.

Once the four elements of complexity are compounded by one another, these can submarine even the best and most experienced Program Managers. That’s why it’s important to have a scientific and systematic way of approaching and simplifying the complexity.

Projects in Crisis: Fire-Jumper Turnaround Plan

Your project is in grave trouble and its deliverables are behind schedule. The current project team is stressed, client anxiety is high, team morale is low, key executive sponsors are on the hot seat and your senior management is fuming. You, as a Program Manager, are brought in to take over the project and turn it around. Unlike starting a project where you have your standard 30-60-90 day plan, here you have a 3-6-9 day plan to implement a get-to-green blueprint. What do you do? Well, before just jumping into the deep end and running the risk of being pulled under by other drowning members, consider the following reasons why projects generally run into trouble:

• Unclear requirements/scope
• Poor planning
• Lack of formal project management processes
• Unclear roles of team members including that of the project manager
• Inadequate communication
• Inexperienced team members

My step step-by-step approach may be useful. Before your start: In your mind’s eye, think of an old round analog clock. Picture twelve-o-clock, three-o-clock, six-o-clock, etc – now were going to work our way around the clock; one to twelve.
1. The reason that you have been called upon to rescue the project is because you have handled projects like this in the past therefore, have the abilities and knowledge required to fix this problem. One-o-clock, don’t panic, you have the skills to do this. Self-confidence and a sense of calm is important. Get your hands on all the relevant project documentation (scope, planning, charter, specifications, etc.) and read it.
2. Now you have “some” background, next you need to have your communication plan for letting stakeholders understand your expectations from the outset. Make it clear to all parties concerned that you will need time to familiarize yourself with the project, but let them know what the steps are you’ll use to quickly right the ship and just how quickly you’ll move everyone through the process. This twelve step process is what you share so to speak. A solid “Purpose, Process, Pay-off statement works well here – “what I’m here to do is this, I’m going to use these steps to do it and if you support me, you’ll get this in return”
3. Who do you talk to first? YOUR sales colleagues – they’ll have the insight and they’ll have anxiety as well. Whenever there’s an issue at an account, it’s possibly threatening their livelihood. They want to know and need to know that you’re their partner. Ask them about the situation and lots of questions; don’t argue – just probe.
4. Next, talk to your program team – just touch the top people. Right now we’re just trying to define the problem, not solve it.
5. It’s now 5:00. Now go interview the CLIENT stake holders and their top program lieutenants. Their reaction will be similar to that of our sales team. They’ll have insight as well as anxiety. They want to know and need to know that you’re their partner. Ask them about the situation and lots of questions; don’t argue – just probe.
6. You are now half way through your 3-6-9 day plan. You’ve held a series of individual meetings/conference calls with the main stakeholders, teams and members to introduce yourself and pick their brains. Among all the questions you’ve asked, you probably can now see how you’d answer the following questions yourself:

o What is the problem?
o Why is the project out of control?
o What should be done to get it back on track?
o How can individual people or teams with whom you are working help in rescuing the project?

7. A. Now hold a more formal, cross functional meeting with the core project teams including the client, your team and (always) a sales representative. Focus on going through the project by comparing:
o Initial scope vs current + reason for change in scope (if any)
o Initial schedule vs current schedule + reasons for schedule issues
o Current state of deliverables + initial estimation for completion
o Initial budget vs money spent so far + reasons, if applicable, for budget overrun
B. This meeting will help you drive consensus around the root causes of the project’s problems. You have finished the first phase of damage assessment. Write a damage assessment report using the points above.
8. Now work with your team and other stakeholders to come up with a new plan for the project. Note that the project might be in crisis because of poorly defined scope, requirements or objectives. Revisiting the planning process will help in bringing the project back on track and identify issues that were subsequent to improper planning or execution.
9. It is nine-o-clock now, so you’re on day six of your nine-day plan. At this point, you can now hold a damage assessment meeting with the main stakeholders to report your findings and update them on your teams steps for getting to green
10. Depending on the size and complexity of your project, the new planning document might include new or altered sections such as:

o Project management approval page
o Executive summary
o Project charter
o Objectives
o Project assumptions
o Project risks
o Project scope
o Deliverables
o Stakeholders
o Project organization
o Work breakdown structure
o Network diagram
o Gantt chart
o Resources
o Costs
o Procedures
o Lessons learned so far
o Project directory

11. Get your new planning validated by all the main stakeholders, and start managing your project to completion.
12. It’s now twelve-o-clock – Note that creating such a new planning document is an iterative process, and for complex, off the rail projects or programs, you will need to run with your standard Plan-Do-Check-Act model making sure your program is coming back up to green as planned. Make sure that you enforce stricter monitoring and reporting procedures so you increase your chances of identifying issues earlier. Communicate, communicate, communicate!! Others will tell you when you can slow down the flow: It’s a great indicator of trust and success.

Start with why…

Are you fascinated by the leaders who make impact in the world, companies and politicians with the capacity to inspire; Simon Sinek (http://www.startwithwhy.com) has discovered some remarkable patterns in how they think, act and communicate. Here’s how I started with why….

Have you heard people talking about being in the digital Zettabyte Era? Well, I’m part of defining and implementing what everyone is calling the 3rd platform of IT, which for me is what keeps me from sleeping all but 4 hours a night I’m so excited by it.

Have you ever thought about a Zettabyte? In 2007 we created 281 EB’s of new data. Now 1 ZB = 1,000 Exabytes which equals 1 billion terabytes. The Library of Congress has 19 Million books in it. One ZB would hold 100 million copies of all those 19 Million books. It’s been said that 5 Exabytes would be equal to all of the words ever spoken by mankind. Get this now; annual global IP traffic will reach the 1.1 zettabyte threshold by the end of 2016, and will reach 2.3 ZB per year by 2020. All that data rests on enterprise storage.

I’m part of a new little start-up you might have heard of; on August 1st it will become/became the world’s largest privately-controlled, integrated technology company which was recently created by Michael Dell and EMC. Michael placed 69 billion votes on our ability as an enterprise solutions powerhouse to bring our clients industry-leading innovation across their entire technology environment. We are the worlds #1 external storage provider, cloud infrastructure provider, converged infrastructure provider and the #1 server provider in North America.

Across our Fortune 100 clients, my role in the global professional services division is to lead client’s digital IT transformations by delivering innovation, lowering costs, creating agility, and increasing business insight. My clients realize and achieve their transformation through the use of our methodologies, tools and people.


  1. Transform infrastructure,
  2. Consolidate and migrate data centers,
  3. Realign applications,
  4. Convert a company’s IT operating model and
  5. Deliver enhanced business intelligence by emancipating a company’s big data.

I’m a Senior Program Manager and I manage huge global portfolios of projects for the new Dell EMC Technologies company.

Program Management-as-a-Service 2.0

By: William (Bill) Thomas, Senior Program Manager at EMC

Business success is not measured by a consulting company’s ability to conceive a great idea, but rather by their ability to put it into action.

It is time to adjust our Program Management structure and our go to market strategies to allow for what our customers are really asking for:

  • don’t sell something to me, do something for me,

  • Help me with my outcomes,

  • be involved not just at the beginning of the project, but stay engaged and earn my business for life.

Whether managing an array farm upgrading to a Premium Support Services integration program or implementing a strategic technology Data Center Migration, many clients are looking to product consulting companies to turn a winning strategy into a successful reality.

There is an opportunity where Program Management can add considerable value where we don’t necessarily do today. We help companies drive business transformation by providing industry-leading program management consulting services; we bring methods and tools, we bring resources on demand, we bring governance. We do this for very large corporations where there are many projects that can be stitched together in order to afford the over-riding tax required to support this financial encumbrance called PMO.

Program Management as a PMO is big, it brings great value, but in the beginning it’s a lot like trying to eat an elephant. It really must be taken in small bites; not only to a client, but to our own sales teams – value must be proven. What better way than to break it up into small, discrete services that can be eaten one bite at a time, just like that huge elephant – Program Management-as-a- service is launched.

We have as a practice group, delivered some of the largest, highest profile and most effective transformation programs in corporate history.

You want to begin to rely on us to help you turn a well-crafted strategy into a well-executed plan for today and for whatever the next instantiation of business produced.

Here are a few ideas where Program Management-as-a- service might fit:

Program Rescue or Get-to-Green

These quick and highly intense, very structured and time-critical remedial actioning interviews and planning sessions are mapped out to turnaround the expected outcome of a failing program.

Complex Program Delivery

Project kick-off: alignment of a new or existing project against the enterprise strategy to ensure maximum return on portfolio investment matched-up with quarterly QA assessments and read-out level readjustments.

Delivery Health-check or QA

Like a rescue program, this rapid and possibly ongoing assessment service baselines the underlying health of a specific portfolio and the critical actions needed to achieve the target benefits. Quarterly re-checks are common.

Enterprise Portfolio Management

Short term audit or creating of a centralized management of processes, methods, and technologies used by project managers and project management offices (PMOs) to analyze and collectively manage current or proposed projects based on corporate key characteristics.

Business Transformation using Enterprise Architecture Framework Creation

Apply best practices, professional program management rigor with TOGAF/Zachman EA to ensure business strategic objectives are realized while insuring TCO does not exceed business case modeling. The EA component of this Program Management-as-a-Service begins the introductory processes required in order to build a longer-term approach for designing, planning, implementing, and governing an enterprise information technology architecture.

IT Transition Management

Transition management is a model of environmental governance which seeks to guide the steady, continuous process of transformation of tech-political landscapes, financial-technical practices and “the structural character of an IT practice” from one equilibrium to another. In its application, program management transition management seeks to swiftly, with the boundary of a time commitment, steer the outcome of change to lessen any inherent uncertainty, produce desirable outcomes and enhance resilience during the transformation of newly adopted business-technical norms.

This is primarily achieved by engaging, via a prepared practice, a wide range of stakeholders over the multiple levels to create shared visions and goals which are then tested for practicality through the use of experimentation, learning and adaptation at the niche level.

We will begin to delivery small distinct opportunities for clients and sales to begin to see the value of program management. Program Managers drive business transformation and portfolio success by providing industry-leading program management consulting services; we bring methods and tools, we bring resources on demand, we bring governance – we bring portfolio success one step at a time.

We want to begin to help companies envisions a next-generation tech industry where suppliers play an active, ongoing role in helping business customers achieve unparalleled value from their technology investments.

A Cloud Enabled Wine Refrigerator; Really?

Today my 75-year-old father told me that he bought a new, “cloud enabled” wine refrigerator. My dad, Elwin, told me my wine refrigerator was so “twenty-thirteen” like I was some sort of a rube or something. Twenty-thirteen? When did my dad start saying twenty-thirteen? When did Elwin start thinking about cloud as something other than just vapor, puffy white somethings full of water and if you stand under it for long enough you’re going to get wet or if you lay on your back long enough, caricatures show up that look like Snoopy, or a train, maybe even a pretty little sailboat? I’m not sure which bothered me more, Elwin, my dad accusing me, an EMC guy of being a technology rube, or that he now had a better wine fridge? So why is everyone talking about Cloud? Why is my 75 year old dad talking about the cloud? What the what?

Ever since Google Chief Executive Eric Schmidt publicly uttered the term “cloud computing” in the 90’s, a CLOUD (pun totally intended) has been gathering over Silicon Valley as well as over the Hopkinton Valley. Known for peddling books online, Amazon began selling an Elastic Compute service in 2006 for programmers to rent giant computers – Wow!

If you were a part of the “twenty-oh-five” era, then everything you did was about the cloud. Puffy white clouds had become the go-to metaphor for all things Internet. The PowerPoint deck du jour used cloud icons in their presentations, at times referring to the Internet simply as “the cloud.” New shades of meaning emerged over the past decade as tech companies created software that could run simultaneously on multiple servers, on demand, in a multi-tenant environment — hence, operate in a “cloud.” Voila, and I just get what I need, when I need it and the best part, I don’t worry about what’s under the covers, because everything is delivered inside of a SLA.

Fast forward to yesterday, now everybody is cloud this and cloud that; Elwin is in the cloud. Which BTW, is actually pretty cool. He gets to keep track, via an app on his, yes – – – SmartPhone, that tracks temp, humidity and the turn-over of wines he has in his 200 bottle fridge all brought down onto his home wifi and all the data is hosted at Rackspace. BooYah!

Anyway, so what does cloud mean to me – – – today?

Think the Jetson’s meet Star Trek all the while I’m in first class on Richard Branson’s Virgin Airlines newest 777 going to Turks and Caicos on mileage and hotel points and I’m checking the temp and humidity in my humidor.  That’s what the cloud is for me – – – today. At least it is right now as I’m writing this sitting in seat 31B, because I think I forgot to add water a couple of weeks ago to that humidor.

My dad Elwin, is so twenty-fourteen; what a rube! 😉

Bill Thomas is a senior program manager and enterprise architect for EMC’s Global Professional Services division since 2011. Bill is based out of the small, quiet suburb of Anthem, just 15 miles north of Phoenix. Bill works in the financial services sector and supports some of EMC’s very largest clients.

The Clash between Enterprise Architecture and Project Management

My goal is to promote the value that enterprise architecture can bring to organizations of all sizes. As both an EA and an Enterprise Program Manager, these two can often be at odds.

Finding the right approach for your individual organization can help build eventual and success for your company. Tension between EA and Program Management is predictable, many have been able to show that it is a collaboration just waiting to happen. I say that it can be controlled and even leveraged in order to deliver positive results for your organization.

This article brings a nice set of pro’s and con’s for each profession. Give it a read at:

Enterprise Architecture – The Contemplative Man’s Amusement

Because Enterprise Architecture (EA) gleans such a holistic view of the enterprise, pursued in sometimes discreet, off-the-record meetings and Starbucks® get-togethers, many IT’ers and non-IT’ers carry an almost mystical impression of the sport of EA; I believe it is a lot like fly-fishing. I am frequently asked what I get out of Enterprise Architecture; I think those people really are asking, “What would I learn if I took this sport up?”

Wikipedia and The Open Group say that “Enterprise Architecture (EA) is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution.”

Practitioners of EA call themselves enterprise architects, some call themselves anglers – ok, not really. An enterprise architect is a person responsible for performing this complex analysis of business structure and processes and is often called upon to draw conclusions from the information collected. By producing this understanding, architects are attempting to address the goals of Enterprise.

What would be garnered by taking up such an endeavor? A lot. It’s a sport that combines composure, triumph and frustration in exactly the right proportions to teach long-lasting life lessons. Time on a project can include a mix of wily engineers, un-imitable vice-presidents and wild beasts such as CIO’s and other enterprise architects. Here are the four-and-a-half life truths I learned from all of this.

Truth One: Old engineers don’t rise quickly to the fly. This is how they get to be old.

To the exasperation of anyone who has meticulously matched size, color and pattern to actual insects on a stream. Big old trout will watch flies drift overhead only to not noisily gulp down your best Blue Wing Olive Dry Fly. These fish watch for anything — a wake or ripple — that flags the fly as artificial. Old engineers are the same, they have a whole closet filled with been-there-done-that t-shirts. Don’t throw them a ripple, a noise or even a scent of fear.

Aesop could pen a fable from this: An enterprise architect must show the patience of an old trout, that even one unusual ripple in a stream full of eddies can portend a threat, and that it’s wise to keep your mouth closed, for fear that you end up looking like a fool displayed on the wall.

Truth Two: We are not always at the top of the food chain.

I turned around one time at a client meeting and saw that a vice-president with a grizzly bear attitude had sauntered near and was evidently critiquing my newest fishing technique.

When I’m more than 100 miles from my home turf and in grizzly country, I carry bear repellent. In fact, I carry the “Bear”icuda size, which is slightly larger than a fire engine red commercial fire extinguisher. In my world, empathy, sincerity and silence are the equivalent of bear spray.

Books advise not to look a grizzly in the eyes, to speak gently, to back up slowly and to not use the mace unless they charge. If you want to show inspirational leadership, you have to build some skill in dealing with those who can’t keep from moaning, growling, roaring, and grunting in the board room.

There are several things to “bear” in mind when trying to turn a conflict back toward collaboration; one of the most important is to reduce the emotional content of the interaction. Just listen. The idea is to let some time pass, let some of the adrenaline ventilate, and wait for things to calm down.

Studies have shown that the average corporate executive doesn’t have the energy to maintain the highest levels of snorting and ground scratching for more than about ninety seconds. It might seem like 90 minutes, but when they finally calm down, try some empathetic words in a soothing tone, and you are likely to find you’re better able to communicate and make a point.

A well worn Colorado ranger once told me, “It didn’t maul you, so you did something right.”

Truth Two and a Half – A Corollary to Truth Two: Trust but verify.

A client representative, we’ll call him Mr Knowitall had told me that he had been at this company for 12 years and that he had all the information I’d need to scope out what the business needed to be successful. What a comforting thought during my earlier grizzly face off. After the bear left, and Mr Knowitall left, my new allies in room whipped out a reporting matrix and showed me he was the son of a board member and that his “mace container” was the size of a roll of pennies. It wouldn’t have discouraged a petulant child, let alone an adult grizzly. Lesson learned, understand who else is fishing on the pond.

Truth Three: Seek the truth but respect the narrative.

Engineers and anglers tell stories about events that could — except for the lack of believability — be regarded as miracles. One cool night around a fire outside a lodge, listening to funny scotch-fueled fishing stories, I decided to pull out my digital camera and show a photo of a small but nice trout that I had caught, photographed and returned to the stream earlier in the day.

The other anglers had been telling stories about their arms growing tired from catching so many fish, or hooking brownies big enough to spit up Jonah. When I showed the photo the stories ended. The evening turned ruminative and quiet. And I no longer confuse Story Hour with Show and Tell.

Truth Four: Rivers and Data Centers really are the perfect metaphor for life.

At least once in your life, you should wade into a fast-flowing river and look upstream. And, at least once in your life, you should stride into a cool blowing data center isle and look up toward the miles and miles of cable and blinking lights. All of the visible landscape — cuts, creeks, draws, hills, racks, the obligatory ping pong and billiards table, the odd metal detector and the retinal scanner — it’s all a giant system to deliver bits and pieces precisely to where you are standing. Water and data from multiple sources — springs and small creeks, V-Blocks and the EMC Symmetrix, small rivers and distant clouds — are joined right at your feet.

Turn downstream or walk into another client and you suddenly yearn to find out what else will add to this river as it continues on. This fits nearly any aspect of your life: family, knowledge, career, politics, and Enterprise Architecture. Streams becoming rivers and executive’s working to make change provide the perfect reason to go to work and to go fly fishing.

Enterprise Architecture Training Justification

Quoting a long-time executive; We need to “Simplify, Amplify and Re-invent” organizations

I agree. Like many today, I listened with intrigue to the words and the explanations in the presentation. Given my recent training request for additional EA training and still waiting for a response status, I found it almost ironic when his very first words were those that are foundational to the subject matter of my training request – “reference architectures”, “repeatable services creating repeatable success” and “standardization in their [design] methodology”. He is referring to what EA brings to businesses via consultants like myself. So, why can’t I get my training approved? This stuff works, just look at it!

In watching IT teams talk to business partners I’m reminded of a line from Cool Hand Luke in which the Captain says to Luke “What we’ve got here — is a failure to communicate.”  There is in a sense, a failure and if the two can’t overcome it, then many IT efforts are going to be for naught. In many cases client IT teams are surrogate sales people [selling consultant delivered solutions] talking to the corporate decision makers on our behalf as consultants. You can only hope you trained your sales person well.

Why do we have this situation? Most times, those of us in IT exhibit too much “inside-out-thinking”. We talk of “services” we deliver to the business – we talk about applications, technologies and architectural domains. This terminology or lexicon is ours and it is effective when we speak between ourselves, but it is ineffective when we need to communicate to business leaders, our clients. Clients are not going to change, so in this case we are going to have to “go-to-the-mountain” because the mountain is not going to come to us.

So what language do corporate leaders understand?

Don’t completely forget the hard-dollar ROI calculations of the past, executives today are savvy and are accustomed to discussing and focusing on game-changing questions to prove business investment value. From my experience, the best way to “value-justify” projects is for EA’s to help drive answers to critical business questions that can help CIOs do a fundamentally better job.

Three hot-button questions I like to help answer are:

1. How can we free up a certain amount of the 80% of spending that is imprisoned in maintaining the existing environment and use it for more strategic initiatives?

2. How can we safeguard that IT is doing the right projects, and doing them right (e.g. quickly and effectively), and,

3. How can we decrease risk by ensuring that applications are leveraging supported, safe technologies and are installed on solid infrastructure platforms?

Driving a shift of funds from maintenance, support, and break/fix — “institutional spend” — to discretionary spend is critical because CIO’s are trying to meet increasing user needs with dwindling budgets. Yet, costs for fixed expenses such as salaries, software licenses, and data center operations isn’t falling, or decreasing quickly enough to make up for new, abridged budgets. That means there are fewer and fewer “discretionary dollars” every year. And as we know, our consulting delivery goals get bigger and bigger every year. Large enterprise executives understand this change in messaging, but people in our commercial space are probably running into CIO and CEO’s who are not there yet with this new messaging. This is what an expert EA working inside delivery could do, help drive the new valu-propositions required in this ever, self-educating economy.

When the corporate executive comes to the table with hundreds of demands and the 20% of the budget that’s discretionary, their budget will satisfy only a tenth of these demands – it’s not going to be a very positive chat is it?

The imbalance creates “selection’ism” and someone invariably gets kicked to the curb. If short EA engagements or assessments can uncover savings by eliminating duplicate or underutilized platforms and use these savings for discretionary projects; this will help the CIO “be a hero to the business” and help us [consultants] uncover current and future opportunities for our consulting companies.

Moreover, by establishing the link between elements of the IT infrastructure and critical business processes, functions, and priorities; EA pre-consolidation/migration/go-to-the-cloud engagements or assessments can help the IT organization focus only on projects that deliver the greatest business benefit and are based on the proper, agreed upon strategy.

Going back to the original presentation one last time; he said the focus is on Cloud, Security and Data – this is clearly stated, and is a very focused strategy for such a large company. This focus is likely the result of a series of sessions outlining the corporations ‘Operating Model*.  The Operating Model, an EA tool, informs the executive team of the appropriate level of business process integration and standardization in order to deliver the organizations promises to stakeholders. The Operating Model also informs leaders about how various technical and business components and competencies should be designed and implemented to enable the chosen or new Operating Model. I suspect that of the four Operating Models; Coordination, Unification, Diversification and Replication, the speaker understood his business was in one model, but needed to grow into another.

The EA message isn’t that cost-savings aren’t important — they are — but we need to communicate them in new terms that will resonate with IT and business leadership, whose executive support we will need to fund and properly execute our next initiative. EA helps IT do all this; “Simply the message, while Amplifying the process as we Re-invent IT services”. It’s the triple-play; IT wins, the business wins and consulting wins.

Once we have identified these key business drivers using EA methodologies within the client’s organization, how do we communicate with them? By showing how EA centered delivery methodologies can produce the results that stakeholders need to do a markedly better job in 2013.

Last, how do we do this, simple – APPROVE my training!!!


* EA’s “Operating Model” explained:

  • Coordination – low process standardization but high process integration (Compare with allied strategy – where subsidiaries provide varied products to the same customers)
  • Unification – both high standardization and integration (compare with integrated strategy)
  • Diversification – businesses requiring low standardization and low integration (compare with holding company strategy)
  • Replication – high standardization but low integration (Compare with Franchisees or Replicated Facilities of an Integrated Strategy)