What is Complex Program Management?

Start by understanding what a complex project is and ask yourself if it applies. 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 to project management 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 approaches simply do not work for the entire project.

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. 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 driving constant schedule changes, personnel changes and cost containment measures – complex, and hard by their nature.

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 even, unexpected outcomes. 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, add safety measures via your portfolio of strategic methodologies to manage each element of complexity acknowledged by the analysis. And once compounded, these four complexities can submarine even the best and most experienced PMs. 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.

We:

  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:
http://www.enterprise-architecture.org/blogs/2013/02/27/the-clash-between-enterprise-architecture-and-project-management/

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)

 

A “Rainless” Cloud Needs Solid Physical Infrastructure

A “Rainless” Cloud Needs Solid Physical Infrastructure

Posted by Bill Thomas June 15, 2012 7:08:25 PM

The one important thing to remember about the cloud is that companies like the ROI and that they like it — a lot.

That may seem to be an obvious opinion, but it makes the fact that its existence is likely to be experienced across the entire IT continuum. IT and its business constituency is now single-mindedly absorbed on the cloud for greater efficiency and data flexibility.

Even physical infrastructure being deployed is undergoing change today. Automation is the key driver, cloud platforms now offer a range of self service sign-up and visibility and optimization tools to ensure that the systems going into place will provide the widest support for shifting virtual and cloud configurations.

In many cases, the cloud will produce a contraction of physical footprint rather than an expansion, see what Viawest has done with their KINECTed™ Cloud offering. Resources without capital expense. KINECTed™ Cloud provides a dynamic pool of computing, storage, and networking resources without capital expense or ongoing personnel costs. Through resource pooling, KINECTed™ Cloud offers an elastic yet measured service ideal for public facing content, disaster recovery, staging, test, and development resources.

As time continues to march on in dog years, hardware platforms will forge ever-closer ties with cloud resources, both as a means to lower costs and increase performance. Nvidia’s new VGX platform, for example, aims to improve graphics and advanced applications across numerous devices by forging direct links between server-based graphics cards and client-side VMs. This is seen as a step up from previous initiatives like RemoteFX and View 5 in that it removes all abstraction between the physical GPU and the VM, preserving crucial drivers and abilities like Directx11, OpenGL and CUDA.

And because demand for cloud resources is growing so fast, the pressure is on to put the physical layer in place quickly and on budget. That’s why much of the cloud will rest on commodity hardware, which is gaining increased favor among the very largest enterprises. Facebook, for example, has issued an entire commodity blueprint under its Open Compute Project, which seeks to nail down everything from board, server and rack dimensions to power supplies and cabinet designs. The company has numerous vendors on board, including HP, AMD, VMware and Dell — a testament to the clout of one of the industry’s biggest hardware buyers.

Conventional thinking holds that hardware is irrelevant once you’re on the cloud, which is true enough for the user. Cloud providers, however, will care very much about the design and deployment of future generations of hardware. After all, the ability to maintain service levels in the cloud will depend largely on what is happening on the ground.